kzlz
June 10, 2023, 2:26pm
1
It is off the correct time.
What is your Clock qube in Qubes Global Settings?
kzlz
June 10, 2023, 6:21pm
3
It’s sys-net.
Check the output of this command in sys-net:sudo systemctl status systemd-timesyncd
opened 01:39PM - 05 May 23 UTC
closed 10:15AM - 02 Jun 23 UTC
T: bug
C: Debian/Ubuntu
P: default
diagnosed
pr submitted
### Qubes OS release
`4.1.2`
### Brief summary
Qubes is difficult to re… cover from wrong system time.
`sudo qvm-sync-clock` is confusing and doesn't fix dom0 or VM clocks.
### Impact
Why does it matter? If system time is too far off it breaks TLS (https websites), Tor, system upgrades and more.
### Steps to reproduce
Set the wrong time just for the sake of reproducing this issue. This is to take the same perspective as the user would have. Obviously nobody is shooting their own feet on purpose. But this is a situation a user might find itself in. (Clock might be wrong by factory default, prior other operating system, user mistake or hardware clock issue.)
1. set a wrong time in dom0 `sudo date --utc --set "Fri 04 May 2023 01:16:10 PM UTC"`
2. `sudo hwclock --utc --systohc`
3. reboot (or at least restart sys-net (actually ClockVM))
Now try to fix the issue. From a user's perspective.
5. Try to fix in dom0 `sudo qvm-sync-clock`.
6. Alternatively try to fix dom0 clock by using GNU date (or any other mechanism).
### Expected behavior
* `qvm-sync-clock` fixes the dom0 clock.
* Newly started VMs have the correct time.
* ClockVM should have a mechanism to fix its own time even if it is far off.
### Actual behavior
* `qvm-sync-clock` sets the dom0 to the incorrect (outdated, slow) time, which it gets from ClockVM. Technically speaking, dom0 `/usr/bin/qvm-sync-clock` simply calls the ClockVMs `/etc/qubes-rpc/qubes.GetDate`, which still has the wrong time which then dom0 uses.
* Newly started VMs the an incorrect time.
* If just manually fixed using GNU date, then newly started VMs will get the correct time of a while. Except, until...
* After `qvm-sync-clock` was automatically run (it seems to be periodically run), it will set again the wrong time from ClockVM.
* dom0 clock will be periodically (whenever `qvm-sync-clock` automatically runs in dom0) be reverted to the wrong clock coming from ClockVM.
* Highly confusing and took me a while to debug.
### Workaround
1. Shutdown all VMs. (Or at least ClockVM, most likely the default sys-net.)
2. Correct the time in dom0.
3. Restart VMs.
4. Done.
kzlz
June 11, 2023, 5:41am
5
output is this.
Unit systemd-timesyncd.service could not be found.
I corrected the time manually. It is very annoying to do this every time.
Install the systemd-timesyncd package in sys-net TemplateVM (debian-11?):sudo apt install systemd-timesyncd
Late to the party, but I have a similar issue in VMs which are based on a kicksecure template.
systemd-timesyncd in sys-net is up and running. When QubesOS is coming back from sleep, debian based VMs sync their clock correctly, kicksecure based VMs don’t sync their clock. Manually doing a sudo qvm-sync-clock works in both type of AppVMs.
In debian-11 VMs qubes-sync-time.service is triggered by the according timer but in kicksecure VMs it won’t as it has a condition failed.
This might be solved by manually doing a
sudo rm /etc/sdwdate.d/qubes-sync-time-disabled-by-sdwdate.marker
in the kicksecure template.
This file might be part of kicksecure’s hardening efforts, so (as always) use at your own risk.