Check the logs in your vault appvm:
sudo journalctl -b -u qubes-sync-time.service
Check the time in your BIOS and update it if needed. That could be the problem. Mine was off by 8 hours and Qubes was locked to it.
Also try this (remember to shut down the template after install):
Then: In Dom0 sudo qvm-sync-clock
I’m not sure if you need to reboot during those steps.
1 Like
Took some time, because sometimes it works, sometimes it doesn’t, then it works again …
qvm-run --pass-io --user root whonix-gateway-17 'journalctl -b -u qubes-sync-time.service'
Nov 10 00:25:52 host systemd[1]: qubes-sync-time.service - Update time from ClockVM was skipped because of an unmet condition check (ConditionPathExists=!/etc/sdwdate.d/qubes-sync-time-disabled-by-sdwdate.marker).
Check logs in your vault AppVM, not in your Whonix TemplateVM.
sudo journalctl -b -u qubes-sync-time.service
Jan 22 01:00:15 vault systemd[1]: Starting qubes-sync-time.service - Update time from ClockVM...
Jan 22 01:00:15 vault systemd[1]: qubes-sync-time.service: Deactivated successfully.
Jan 22 01:00:15 vault systemd[1]: Finished qubes-sync-time.service - Update time from ClockVM.
What’s the output of timedatectl in your clock qube (sys-net?)? Does it have correct time?
Check the output of timedatectl in your clock qube and logs in your vault AppVM at the same time.
Get your GPS clock working and sync when neccessary and you will not have these things happening. This is a very old turd since 2016. If you want Qubes history search for Whonix boot clock randomization. The JR’s theory won the Voitila price for excelence in brainwashing. It does wonders for Kerberos and friends (OTP TOTP etc). The only fool is you for expecting the developers not to sell out. This is life!
THANK YOU.
That package was missing from my minimal sys-net-wifi’s template.
One of my systems was off by 8 minutes. The other one goes completely nuts and gains an hour or two per day.
I issued the manual sudo qvm-sync-clock you mentioned. Let’s see, down the road how well it keeps in sync.
Also, you have to restart sys-net (or in my case sys-net-wifi).
You might have to sync the BIOS clock too with your local time.
sudo hwclock -l systohc
My BIOS clock was set to UTC. I’ve been messing with a few motherboards lately and don’t know what caused what, but it took me forever to figure out why the BIOS and OS clock were out of sync sometimes and not others. I thought syncing the OS clock would automatically fix the BIOS clock but that wasn’t the case.
sys-net (correct time):
$ timedatectl
Local time: Tue 2024-01-30 01:58:16 CET
Universal time: Tue 2024-01-30 00:58:16 UTC
RTC time: Tue 2024-01-30 00:58:16
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$ sudo journalctl -b -u qubes-sync-time.service
-- No entries --
vault (incorrect time):
$ timedatectl
Local time: Mon 2024-01-22 01:14:40 CET
Universal time: Mon 2024-01-22 00:14:40 UTC
RTC time: n/a
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
$ sudo journalctl -b -u qubes-sync-time.service
Jan 22 01:00:22 vault systemd[1]: Starting qubes-sync-time.service - Update time from ClockVM...
Jan 22 01:00:18 vault systemd[1]: qubes-sync-time.service: Deactivated successfully.
Jan 22 01:00:18 vault systemd[1]: Finished qubes-sync-time.service - Update time from ClockVM.
What’s the output of this command in vault?
qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds
Do you have any policy errors in dom0 journalctl?
What’s your sys-net TemplateVM?
What happens if you add this for the vault settings?
Settings > Services
add clocksync
There’s also this with an open ticket:
in vault:
$ timedatectl
Local time: Fri 2024-02-02 02:18:09 CET
Universal time: Fri 2024-02-02 01:18:09 UTC
RTC time: n/a
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
$ qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds
2024-02-02T14:09:49,439237555+00:00
It’s based on fedora-38-xfce, same as sys-net.
How do I check for policy errors in dom0?
dom0:
$ sudo journalctl -b|grep -i policy
Feb 02 02:10:47 localhost kernel: Policy zone: Normal
Feb 02 02:10:47 localhost kernel: iommu: DMA domain TLB invalidation policy: lazy mode
Feb 02 02:10:47 localhost usbguard-daemon[420]: [1706836247.826] (W) PERMISSIONS CHECK ON POLICY FILE ARE TURNED OFF!
Feb 02 02:11:08 dom0 usbguard-daemon[2761]: [1706836268.885] (W) PERMISSIONS CHECK ON POLICY FILE ARE TURNED OFF!
Feb 02 02:11:09 dom0 polkitd[2838]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Feb 02 02:11:09 dom0 systemd[1]: Started qubes-qrexec-policy-daemon.service - Qubes remote exec policy daemon.
Feb 02 02:11:09 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qrexec-policy-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 02 02:11:09 dom0 qrexec-policy-daemon[2894]: warning: !compat-4.0 directive in file /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be deprecated
Feb 02 02:11:18 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.InputKeyboard+: sys-usb -> @adminvm: allowed to dom0
Feb 02 02:11:18 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.InputKeyboard+: sys-usb -> @adminvm: allowed to dom0
Feb 02 02:11:18 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.InputMouse+: sys-usb -> @adminvm: allowed to dom0
Feb 02 02:11:21 dom0 at-spi-bus-launcher[4423]: Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf +15: Eavesdropping is deprecated and ignored
Feb 02 02:11:21 dom0 at-spi-bus-launcher[4423]: Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf +17: Eavesdropping is deprecated and ignored
Feb 02 02:11:24 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: sys-usb -> @default: allowed to dom0
Feb 02 02:11:24 dom0 at-spi-bus-launcher[4559]: Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf +15: Eavesdropping is deprecated and ignored
Feb 02 02:11:24 dom0 at-spi-bus-launcher[4559]: Policy to allow eavesdropping in /usr/share/defaults/at-spi2/accessibility.conf +17: Eavesdropping is deprecated and ignored
Feb 02 02:11:25 dom0 systemd[1]: Starting rtkit-daemon.service - RealtimeKit Scheduling Policy Service...
Feb 02 02:11:25 dom0 systemd[1]: Started rtkit-daemon.service - RealtimeKit Scheduling Policy Service.
Feb 02 02:11:25 dom0 polkitd[2838]: Registered Authentication Agent for unix-session:2 (system bus name :1.40 [/usr/libexec/xfce-polkit], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.utf8)
Feb 02 02:11:31 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.WindowIconUpdater+: sys-usb -> @adminvm: allowed to dom0
Feb 02 02:11:37 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.WindowIconUpdater+: vault -> @adminvm: allowed to dom0
Feb 02 02:11:37 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.WindowIconUpdater+: sys-net -> @adminvm: allowed to dom0
Feb 02 02:11:41 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: vault -> @default: allowed to dom0
Feb 02 02:11:43 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.WindowIconUpdater+: sys-whonix -> @adminvm: allowed to dom0
Feb 02 02:11:47 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.WindowIconUpdater+: disp7630 -> @adminvm: allowed to dom0
Feb 02 02:11:52 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: disp7630 -> @default: allowed to dom0
Feb 02 02:13:18 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: vault -> @default: allowed to dom0
Feb 02 02:17:34 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: vault -> @default: allowed to dom0
Feb 02 02:17:37 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: vault -> @default: allowed to dom0
Feb 02 02:18:13 dom0 qrexec-policy-daemon[2894]: qrexec: qubes.GetDate+nanoseconds: vault -> @default: allowed to dom0
I don’t know if this matters:
On boot only sys-usb boots up. Only after I login, other qubes are loaded (sys-net, vault, …)
What’s the output of these commands in vault?
date
qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds
sudo qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds /usr/lib/qubes/qubes-sync-clock
date
$ date
qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds
sudo qrexec-client-vm --filter-escape-chars-stderr '@default' qubes.GetDate+nanoseconds /usr/lib/qubes/qubes-sync-clock
date
Mon Jan 22 01:01:07 CET 2024
2024-02-02T15:57:26,305349790+00:00
Fri Feb 2 16:57:26 CET 2024
Seems like it works fine.
Try to restart vault and check its time. Will it have correct time or not?
If not then try to run these commands:
date
sudo systemctl restart qubes-sync-time
date
The qubes-sync-time service is run on qube boot and then run periodically each 6 hours to update the qube time.
My guess is that you start vault qube before sys-net is getting the correct time from network. So vault gets wrong time at start.
Check the date/time in your BIOS, most probably you have some problem with RTC, maybe the RTC battery is dead so the hardware clock is reset of poweroff.
Yes it does.
I’ll put sys-net to auto boot and see where it gets me.
I’ll also keep an eye on the BIOS clock/settings.
Thank you so far for your help.
Bios seems to be proper. Vault updates time correctly too, so far.
It’s a little bit annoying to fire up a dispVM Firefox and having to wait 10 seconds to browse ssl sites (e.g. forum.qubes-os.org).
Further more whonix template still don’t get updates (see first post, sys-whonix is updateVM).
Any ideas on those?
gateway + workstation whonix 17 template:
% timedatectl
Local time: Fri 2023-11-10 00:25:52 UTC
Universal time: Fri 2023-11-10 00:25:52 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
sys-net:
$ timedatectl
Local time: Sun 2024-02-04 08:39:12 CET
Universal time: Sun 2024-02-04 07:39:12 UTC
RTC time: Sun 2024-02-04 07:39:12
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
sys-whonix:
% timedatectl
Local time: Sun 2024-02-04 07:39:10 UTC
Universal time: Sun 2024-02-04 07:39:10 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
dom0:
$ timedatectl
Local time: So 2024-02-04 08:39:08 CET
Universal time: So 2024-02-04 07:39:08 UTC
RTC time: So 2024-02-04 07:39:08
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
Seems like some problem with sdwdate.
Check the service status in whonix dispVM:
sudo systemctl status sdwdate.service
Also check the logs in sys-whonix regarding sdwdate and check the dom0 journalctl for policy errors for your dispVM and whonix.NewStatus+status qrexec.