看看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 物理机。
答案1
您的时区是 CEST，因此当前 UTC 偏移量应比 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，因为有人可能忘记了更改时钟/时区设置时执行此操作。）
此外，如果这是虚拟机或刀片硬件上的物理机，则可能有一种机制可以在启动时将虚拟机/刀片的时间同步到虚拟机管理程序/刀片机箱的时钟。通常，这种机制将提供本地时间，以利于 Windows 系统。如果您使用 NTP 同步，系统可能会使用本地时间作为 UTC 启动，反之亦然，但一旦网络接口出现，它可能会从 NTP 服务器获取有效的 UTC 时间，再次导致 2 小时的跳跃。