我最近对我的 Arch Linux 系统进行了全面更新,现在,由于某种原因,系统时钟在启动时被设置为与硬件时钟相比 +5 小时的偏移。我在美国东部时间 (UTC-5)。当我启动时,硬件时钟似乎是正确的;然而,系统时钟提前 5 小时:
# date
Sun Feb 4 12:07:01 AM EST 2024
# hwclock --show
2024-02-03 19:07:07.691763-05:00
如果我进入 Mate Desktop 设置并将系统时间更正到应有的位置,它就不会持续存在 - 下次启动时,我再次遇到上述情况,系统时钟提前 5 小时。
5 小时偏移表明我的时区设置可能存在问题 - 系统时钟不知道正确的时区(尽管date
上面的输出显示“EST”?)。有谁知道我该如何解决这个问题?
请注意,我使用 Arch Linux 和 OpenRC (不是systemd)并且我目前没有使用 NTP。
编辑:
添加 的输出hwclock -v
。据我所知,所有这些看起来都是正确的。因此,问题似乎是在启动时从硬件时钟设置系统时钟的问题。也许系统假设硬件时钟是当地时间,而不是 UTC(这可以解释 5 小时的偏移)?但是,我不确定为什么要这样做,或者该设置在哪里。
# hwclock -v
hwclock from util-linux 2.37.2
System Time: 1707100379.710788
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1707004842 seconds after 1969
Last calibration done at 1707004842 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2024/02/04 21:33:01
Hw clock time : 2024/02/04 21:33:01 = 1707082381 seconds since 1969
Time since last adjustment is 77539 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2024-02-04 16:33:00.624087-05:00
答案1
可能有一个启动脚本将您的硬件时钟设置为 UTC。您需要在操作系统中搜索它。
您可以hwclock
通过以下方式将主机设置为使用您的本地时区:
hwclock --localtime && hwclock --systohc
。
答案2
上次更改时间戳是否/etc/localtime
比当前 initramfs 文件的时间戳新?
如果是这样,您的 initramfs 文件仍然保留旧的时区设置,并且在启动的最早阶段使用它......在此期间,系统时钟是从电池支持的实时时钟模块设置的。
一旦真正的根文件系统被挂载,系统就会看到正确的/etc/localtime
,但到那时就为时已晚了:系统时钟已经设置好了。
我对 Arch 不太熟悉,但我相信mkinitcpio
可能是刷新 initramfs 文件时使用的命令。
另外,每当您使用hwclock
调整硬件时钟时,它都会更新第三行/etc/adjtime
以指示硬件时钟是本地时间还是UTC。如果 initramfs 版本/etc/adjtime
与真实根文件系统中的版本不同步,则可能会导致系统时间也出现偏移。
答案3
将您的系统/BIOS 时钟设置为所需的时区
如果您仍然使用 Windows,我建议您进行以下注册表修改:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001
上述注册表设置告诉 Windows 您的系统时间是以 UTC 格式设置的,您可能已经从查看详细hwclock
输出中应用了该时间。
既然您已经删除了 Windows,要解决此问题,我们有 2 个选项:
- 通知
hwclock
时间存储为当地时间(艾伦已经这样做了,直到我重新阅读评论)。 - 手动将系统时钟和日期设置为 UTC,然后
hwclock
再次通知。
选项1
- 访问您的 BIOS/UEFI 固件,并将时间和日期设置为您的本地时间。
- 重新登录并从终端登录:
hwclock --systohc --localtime
选项2
这对您来说是最简单的,因为时间已经存储为 UTC(根据您的输出,但我不确定):
- 访问您的 BIOS/UEFI 固件,并将时间和日期设置为 UTC(
hwclock -v
确认已完成) - 重新登录并退出终端问题:
hwclock --utc
- 对于附加检查:
hwclock --systohc --utc
- 对于附加检查:
- 验证您是否仍然设置了正确的时区:
ls -l /etc/localtime
如果一切正常(选项 2),操作系统现在将计算时区偏移,并显示您所在时区的时间,并且系统将以 UTC 格式存储时间。
选修的
回应评论
- 回复:Windows
- 我于 1996 年左右进入初级学院一年级,在收养窗口期之间视窗3.1到视窗95(我提供了带有屏幕截图的链接,因为随着时间的推移,我们称之为死亡的事情不会像我这样的人记得)。
- 1996 年,大多数 PC 用户仅将计算机用于个人的任务例如(没有广泛采用的互联网使用):
- 游戏——这更像是一款增强版的 8 位任天堂游戏。看波斯王子| 1989年。看一下端口部分。
- 在以下程序中编写文档完美词。 DOS 版本是Windows 3.1 用户的最爱。旁注:Word Perfect 至今仍然是 MS Office 的主要竞争对手
- RE: 硬件时钟
- 虽然还有其他用途,但我没有列出,请注意,我没有包含任何与 Internet 或网络有关的内容,因为 Windows 的第一个设计从未内置任何网络。Windows 中的网络堆栈实际上是一个附加组件。请参阅上面链接中的 Windows 3.11。正因为如此,并且由于 Windows 被出售给世界各地的每个人,因此开发人员选择存储相对于人们居住的时区的时间和日期。CMOS电池,又称当地时间。
- Linux 内核是使用内置的网络组件构建的,而 Windows 则将它们作为额外组件添加。UTC 或协调世界时自 1963 年以来一直存在,最初被军方用来协调单位或潜艇等车辆之间的通信。
Linux 中选择 UTC 作为默认时间机制,主要是因为 Linux 在服务器中的使用。美国的服务器与美国或世界其他地方的服务器之间正确通信和记录的唯一方法是忽略时区。因此,默认值为 UTC。
- 硬件时钟,又名 CMOS 电池需要调整,因为除非通过上面的注册表黑客重置,否则无论版本如何,Windows 仍将电池中的时间存储为本地时间,并保持向后兼容性。在您进行 Arch 更新之前确实如此,但
/etc/localtime
已从包中符号链接到正确的时区tzdata
,并且hwclock
可能正在使用--localtime
.这只是我的猜测,但如果tzdata
更新了,则符号链接会/etc/localtime
在更新期间被删除/替换。如果删除,时区将恢复为 UTC。因为时间存储为本地时间,即使 Windows 被核攻击,并且符号链接现在丢失了,Arch 以不同的方式计算时间,您看到的结果是时区之间的 7 小时差异(UTC+0 加上或减去 UTC-7)。
现在电池中存储的时间与计算的时间之间存在 7 小时的差异由 Arch 因为 Arch 会查看现在错误地返回 UTC 的时区配置,然后 Arch 会询问hwclock
系统时间,该系统时间将作为 UTC 返回和计算。然后 Arch 计算时区的偏移量,因为hwclock
仍然设置为本地时间(考虑到 Windows)。 MATE 的本地化设置配置为增加 5 小时(东部时区)或 7 小时(山区标准时间)。
如果您没有仔细阅读 UTC 链接,研究这张当前时区的照片。如果您不在东部标准时间的时区(19 - 12 = 7,这将使您处于 MST - 山区标准时间、新墨西哥州科罗拉多州等,根据 AlexK 的评论,这里有些奇怪,因为偏移量应该是 17 - 12 = 5(对于 EST):如果hwclock
从命令给出的时间中减去 给出的时间date
,差值就是偏移值),使用图片确定您应该处于哪个时区并进行相应调整。
调整:
- 设置
hwclock
为 UTC,然后重新启动 - 请参阅选项 2.2 - 通过转到 PC 的设置实用程序,确定存储在 CMOS 电池中的时间和日期的实际值(我有预感这是你的当地时间 - 根据你的输出,
hwlock
正在报告Time read from Hardware Clock: 2024/02/04 21:33:01
,以及根据你对艾伦评论的回答,输出确实确认了“就在 9:30 之后”,这是你的当地时间,并证实了我的预感)。 - 如果需要,手动设置时间,尽可能接近当前 UTC 时间和日期(因为 Linux 更喜欢 UTC,而 Windows 已经消失了),然后重新启动
- 阅读上述链接中第 3.3 节的全部内容,有关 UTC 的行和有关 NTP 的行是您遇到问题的原因,并撰写了您的帖子
- 安装 NTP 守护程序 - 请参阅可选
- 将服务添加到默认运行级别,以便每次重新启动/重新启动时都会同步时间。
- 现在和 NTP 守护程序均已安装并正确设置,重新创建
/etc/localtime
符号链接(使用图片中所需的时区)hwclock
如果调整顺利,MATE 将显示正确的本地时间,但该时间现在将存储为 UTC。
答案4
也许系统假设硬件时钟是当地时间,而不是 UTC(这可以解释 5 小时的偏移)?但是,我不确定为什么要这样做,或者该设置在哪里。
听起来很有道理。问题是:为什么?
在 Gentoo 上,当使用 OpenRC 时,有一个名为 的 init 脚本hwclock
。可以将其添加到启动服务中,然后它将处理启动时从 RTC 设置系统时钟,并将关闭时的系统时钟写回到 RTC。
这个 init 脚本在 中有一个配置文件/etc/conf.d/hwclock
,其中包含一些配置设置:
# Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
# Greenwich Mean Time). If that clock is set to the local time, then
# set CLOCK to "local". Note that if you dual boot with Windows, then
# you should set it to "local".
clock="UTC"
# If you want the hwclock script to set the system time (software clock)
# to match the current hardware clock during bootup, leave this
# commented out.
# However, you can set this to "NO" if you are running a modern kernel
# and using NTP to synchronize your system clock.
#clock_hctosys="YES"
# If you do not want to set the hardware clock to the current system
# time (software clock) during shutdown, set this to no.
#clock_systohc="YES"
# If you wish to pass any other arguments to hwclock during bootup,
# you may do so here. Alpha users may wish to use --arc or --srm here.
clock_args=""
这里clock_hctosys
标志控制启动操作(从 RTC 设置系统时钟),clock_systohc
标志控制关闭操作(将系统时钟复制回 RTC)。当然,还clock
控制 RTC 是否以 UTC 时间或本地时间存储时间。
我不是 Arch 专家,但我希望类似的东西也能在那里运行。