Definitive guide to time setting & sync in Qubes OS

I have read many threads and doc sections about time setting and synchronisation in Qubes OS.

However none of the solutions works and in the majority of cases the issue remains unresolved or mysteriously fixed itself.

For example: despite following guides, my system is still offside by 2 hours.

[My hope is that this thread becomes a reference of solutions and eventually makes it into the troubleshooting guide. ]

QUESTION:
Is there a definitive way to set dom0 and displayed clock to correct time and keep it synchronised accurately?

1 Like

Without knowing what you’ve tried, I’ll just ask about the first places I would look:

What do you get with:

ls -al /etc/localtime

and

timedatectl status

in dom0? … does the zone match your location?

1 Like

Made an error, editing this now:

  1. checked UTC in bios = 100% correct

  2. Status printout = off my 2 hours on both utc and local time, name of timezone correct

  3. etc/localtime off by one hour and a few minutes

What do you think is the issue ?

Are you willing to share the output from the commands? :slight_smile:

You can use the command qvm-sync-clock in dom0

2 Likes

Ran qvm-sync-clock

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

Bios time is 14:12:42

Posted output of commands in prior post, please let me what can be done to adjust correctly. Thanks.

Seems to be working fine now…

For other users:

  1. Set bios time correctly to UTC

  2. 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.

2 Likes

The CEST looks incorrect/strange in:

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. :-/

That is what I think was hapenning, and ntp was not set. Sync is fine now. Posted comands above so other users can repair their clocks :slight_smile:

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

For a Debian (minimal or not) ClockVM, systemd-timesyncd can be installed through the package of the same name.

Fedora templates (minimal or not) have it installed by default.

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

Why not go ahead and add it to that page.

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!

I think the minimal template guide should mention installing systemd-timesyncd to the minimal debian sys-net template. cc: @adw

1 Like

Please feel free to submit a doc PR.

1 Like