Clock is not immediately displayed in the user's local time

[tutaleedoo]

Qubes OS version:

Qubes release 4.0 (R4.0)

Affected TemplateVMs:

dom0

---

Steps to reproduce the behaviour:

1. Start Qubes OS

Expected behaviour:

• The clock displays in the user's local time

Actual behaviour:

• The clock displays in UTC

General notes:

• Eventually, I don't know how, the clock displays in the user's local time
• It doesn't matter whether the clock's timezone settings are set or not (right-click the clock, click Properties, see Timezone:)
• After some seemingly random use of Qubes OS, something automatically causes the clock to appear in the user's local time
• dom0 autoconnects to the network on startup, so does have a network connection

---

Related issues:

[andrewdavidwong]

This is possibly related to (but does not appear to be a duplicate of) #3210.

As for how the time system works, Marek explained it here:

Here is how it works:

1. sys-net runs some standard clock synchronization service (ntpd,
   systemd-timesyncd - depending on template); it is enabled by setting
   'clocksync' service (qvm-service tool in dom0).

2. Then every VM, including dom0, synchronize its time directly from
   there. In case of VMs, it is done by qvm-sync-clock (called from
   qubes-time-sync.service in the VM), controlled by two things:

• absence (or disabling) of 'clocksync' service (qvm-service)
• qrexec policy, where actual VM used for time sync is set
  (/etc/qubes-rpc/policy/qubes.GetDate)
  For dom0, also qvm-sync-clock is used (slightly different one for dom0),
  and the VM is set by 'clockvm' global setting (qubes-prefs).

In theory, all those places should synchronize UTC time, and honour
local timezone for display purposes. But maybe somewhere it is messed
up... I'd start with checking timezone in sys-net and time
synchronization with the network (systemd-timesyncd.service) there.

[andrewdavidwong]

This is possibly related to (but does not appear to be a duplicate of) #3210.

As for how the time system works, Marek explained it here:

Here is how it works:

1. sys-net runs some standard clock synchronization service (ntpd,
   systemd-timesyncd - depending on template); it is enabled by setting
   'clocksync' service (qvm-service tool in dom0).

2. Then every VM, including dom0, synchronize its time directly from
   there. In case of VMs, it is done by qvm-sync-clock (called from
   qubes-time-sync.service in the VM), controlled by two things:

• absence (or disabling) of 'clocksync' service (qvm-service)
• qrexec policy, where actual VM used for time sync is set
  (/etc/qubes-rpc/policy/qubes.GetDate)
  For dom0, also qvm-sync-clock is used (slightly different one for dom0),
  and the VM is set by 'clockvm' global setting (qubes-prefs).

In theory, all those places should synchronize UTC time, and honour
local timezone for display purposes. But maybe somewhere it is messed
up... I'd start with checking timezone in sys-net and time
synchronization with the network (systemd-timesyncd.service) there.

[nunesgh]

Same issue here. But in my case, I've also noticed that, when the clock automatically updates to my local time, it doesn't happen to all VMs. Right now, sys-net, dom0 (apparently), and untrusted appear to be in the correct time, but personal is still in UTC.

[nunesgh]

Same issue here. But in my case, I've also noticed that, when the clock automatically updates to my local time, it doesn't happen to all VMs. Right now, sys-net, dom0 (apparently), and untrusted appear to be in the correct time, but personal is still in UTC.

[nunesgh]

Marek has suggested, on the mailing list you've linked above, to try calling sudo hwclock --systohc --utc. But when I do so, I receive the message:

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

When using the debug option, it returns:

hwclock from util-linux 2.28.2
hwclock: cannot open /dev/rtc: No such file or directory
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

I hope this might help to find the source of the issue!

Edit: I'm also having trouble when I try to shut down Qubes, as I've reported here. Could these issues be related somehow?

Edit 2: If I run sudo qvm-sync-clock on dom0, the clock is updated but I receive some extra outputs that I don't get if I run the same command on other VMs:

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

Traceback (most recent call last):
   File "/bin/qvm-sync-clock", line 46, in <module>
       main()
   File "/bin/qvm-sync-clock", line 43, in main
       stdout=subprocess.DEVNULL)
   File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call
       raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['hwclock', '--systohc']' returned non-zero exit status 70

[nunesgh]

Marek has suggested, on the mailing list you've linked above, to try calling sudo hwclock --systohc --utc. But when I do so, I receive the message:

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

When using the debug option, it returns:

hwclock from util-linux 2.28.2
hwclock: cannot open /dev/rtc: No such file or directory
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

I hope this might help to find the source of the issue!

Edit: I'm also having trouble when I try to shut down Qubes, as I've reported here. Could these issues be related somehow?

Edit 2: If I run sudo qvm-sync-clock on dom0, the clock is updated but I receive some extra outputs that I don't get if I run the same command on other VMs:

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

Traceback (most recent call last):
   File "/bin/qvm-sync-clock", line 46, in <module>
       main()
   File "/bin/qvm-sync-clock", line 43, in main
       stdout=subprocess.DEVNULL)
   File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call
       raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['hwclock', '--systohc']' returned non-zero exit status 70