Output of timedatectl status
→ local time Sun 2023-03-26 16:12:42 CEST
->Universal Time Sun 2023-03-26 14:12:42 UTC
→ RTC Time Sun 2023-03-26 14:12:43 CEST
→ Timezone Europe/Berlin (CEST, +0200)
→ System clock synchronized : no
→ NTP Service : Active
->RTC in local TX: no
output of ls -al /etc/locatime
→ lrwxrwxrwx 1 root root 35 March 26 2023 /etc/localtime->…/usr/share/zoneinfo/Europe/Berlin
Relevant commands to make sure sync is correct
display current status > timedatectl status
sync time > qvm-sync-clock
set ntp > timedatectl set-ntp true
set time zone > timedatectl set-timezone ‘Country/City’
If there is anything I am missing that may be helpful to other users please reply to this so it can be edited. Thanks.
Could it be, that the computer loads time from RTC and think it’s CEST (when it’s really UTC) and then ends up 2h wrong? - I’m just guessing … I’ve not been able to reproduce the issue on my machine. :-/
I am having a similar problem. My system clock is off by 1 minute and a few seconds. That is affecting my pass-otp TOTP code generation. Can someone help?
I tried
(dom0) $ sudo qvm-sync-clock
But it did absolutely nothing.
For the record, the sys-net timedatectl output reports
System clock synchronized: no
NTP service: n/a
So I need to install systemd-timesyncd package to my debian-11-minimal template that my sys-net uses? Why is this package not named so under minimal template guide: Minimal templates | Qubes OS
The full Debian template should probably install systemd-timesyncd by default, instead of the ntpdate package which is installed but appears to be not enabled (and lacking Qubes specific integration anyway).
Yep, that was it. Installing systemd-timesyncd has solved my issue. Now my sys-net clock, and all the other qubes’ clocks are in-sync with the UTC. And my OTP codes are working again. Thanks!