Отрицательные временные различия с last reboot

Рассматривая last reboot | head -3, я получаю следующий результат:

reboot   system boot  5.7.10-201.fc32. Fri Jul 31 11:29   still running
reboot   system boot  5.7.10-201.fc32. Fri Jul 31 11:22 - 09:29  (-1:53)
reboot   system boot  5.7.10-201.fc32. Tue Jul 28 23:14 - 09:21 (2+10:07)

Сначала я подумал, что время и даты показаны как “запуск – завершение работы”, но это не имеет смысла, учитывая вторую строку, где показывается отрицательная разница во времени.

procinfo возвращает корректное время запуска:

$ procinfo | grep Bootup
Bootup: Fri Jul 31 09:29:39 2020    Load average: 0.01 0.06 0.06 1/1071 28719

Аппаратные часы показывают правильное время:

$ date; sudo hwclock --show
Fri 31 Jul 2020 11:55:17 AM CEST
2020-07-31 11:55:17.436472+02:00

Проблема, похоже, заключается в last reboot и who -b:

$ date; uptime; who -b
Fri 31 Jul 2020 11:55:43 AM CEST
 11:55:43 up  2:26,  2 users,  load average: 0.00, 0.04, 0.05
         system boot  2020-07-31 11:29

/var/run/utmp, читаемый по умолчанию who -b, не существует в моей системе, и /var/log/wtmp, читаемый last reboot, имеет следующие разрешения:

$ ll /var/log/wtmp
-rw-rw-r--. 1 root utmp 39K Jul 31 11:23 /var/log/wtmp

Что может быть причиной этих расхождений?

ИЗМЕНЕНИЕ

Корректное время завершения — 09:29 UTC+2. Времена 11:29 и 11:22 из last reboot должны быть 09:29 и 09:22 соответственно. Как заметил @telcoM, можно подумать, что ранний запуск может использовать часовой пояс UTC, но тогда 11:29 должно быть 07:29…

Еще одна деталь: я использую простую физическую машину Fedora 32.

Ваш часовой пояс — CEST, поэтому ваше текущее смещение от UTC должно быть 2 часа в плюс.

Соответствовали бы временные метки, если предположить, что 09:21 на самом деле означает 11:21, а 09:29 — 11:29 соответственно?

Если да, то ваш ранний запуск может изначально использовать часовой пояс UTC, но исправлять его на CEST в какой-то момент после того, как будет определено время запуска.

Использует ли Fedora по-прежнему классический стиль RedHat /etc/sysconfig/clock? Если это так, возможно, в нем есть установка, указывающая, используется ли аппаратные часы UTC или нет. Существует также другое место для той же информации: третья строка /etc/adjtime будет указывать либо UTC, либо LOCAL для указания, какое время хранится в аппаратных часах. Если эти два положения не согласуются друг с другом, я видел такое поведение. Если вы обнаружили ошибку здесь, пересоберите ваш initramfs, чтобы исправление было включено в него.

Является ли ваш /etc/localtime символической ссылкой на /usr/share/zoneinfo/your/timezone или фактической копией этого файла? Это может иметь значение для генератора initramfs. Если генератор initramfs просто копирует символическую ссылку в initramfs без копирования фактического файла, симлинк будет поврежден на этапе загрузки initramfs, и система может по умолчанию использовать UTC до монтирования реальной корневой файловой системы.

(И если вы не нашли ошибку, но временная метка модификации /etc/localtime, /etc/adjtime или /etc/sysconfig/clock более свежая, чем у вашего initramfs, пересоберите initramfs в любом случае, так как кто-то мог забыть сделать это при изменении настроек часов/часового пояса.)

Кроме того, если это виртуальная машина или физическая машина на аппаратном обеспечении blade, возможен механизм синхронизации времени VM/blade с часами hypervisor/blade chassis при загрузке. Часто такой механизм будет поставлять местное время для удобства Windows-систем. Если вы используете синхронизацию NTP, система может загружаться с использованием местного времени как UTC или наоборот, но как только сетевые интерфейсы начнут работать, она может получить действительное UTC время от сервера NTP, снова вызывая скачок времени на 2 часа.

Это происходит, когда система настроена читать время RTC в местном часовом поясе. И как упомянул @telcoM, ранняя загрузка читает время RTC как UTC. Попробуйте команду timedatectl, чтобы показать/изменить конфигурацию RTC.