Turned on my QubesOS to find its dom0 clock and calendar completely out of sync. It was displaying december of last year. Other qubes, especially the clock-qube (sys-net) were showing the correct time and date information.
On dom0 terminal, I performed sudo qvm-sync-clock command. It put the dom0 date & time in their correct values.
I wonder, what is the cause of this mis-behavior in the first place? Is this the correct way to deal with it?
I had a similar issue but mine was never yet online, and I just used the GUI to manually input the time and it is now off about a whole minute.
I never have figured out how to get the main setting to 12 Hour Clock time (aka AM/PM) as I absolutely hate trying to figure out 24 Hour Clock time (23:59 aka “military time”) formatting. Do you know how to force AM/PM everywhere?
Dom0
maybe of interest:
currently I only start sys-usb automatically. upon login a simple bash script starts sys-net, syncs clock with dom0 and starts whonix afterwards.
I left my Qubes laptop on standby and when resuming today it showed the time when I had left it and didn’t update, which never happened before for me. Maybe some bug related to the leap year? In any case, one of the following measures fixed it:
sys-netsudo date --set HH:MM:SS with correct current time (probably what fixed it ~1 min after running the command)Okay yeah I just did another 30 min standby and same issue, so I think it’s related to Feb 29th and some bug with the date program perhaps.
The command above (3rd list item) fixed it again, so that’s the only method that needs to be used.
Same problem today here on 4.2 on boot, the laptop was shutdown yesterday.
[irrelevant comment retracted]
I think this is the cause, and that this problem is not related to qubes os
Didn’t experience this on any of my non corebooted laptops, but did on my corebooted thinkpad.
PS: I think most of laptops that use some sort of coreboot are affected as most of them just updated rtc.c with fixes on their public repos.
Yup, this is a known issue since 2021 in coreboot. Purism pureboot is based upon it, and I got hit as well this morning. Some discussion on the purism forums: Clock reset to 2070-01-01 on February 29 - PureOS - Purism community
Interesting. In my case, my dom0 clock was reset to 24 December 2023, as far as I remember this morning.
I’m glad this thread is here! I also ran into this bug and I tend to get nervous when my computer does unexpected things.
So, this would explain why people are getting a bunch of different times instead of epoch or something more consistent, because build dates are inconsistent. But it looks like my computer was set to February 27 at midnight (ish), and I haven’t reinstalled pureboot in the past couple of days so that couldn’t be the build date. Unless the bug somehow exhibits itself differently in pureboot?
A support technician on the purism forum confirmed that the bug can cause the clock to reset to times other than the build date.