On Friday, April 27, 2018 at 10:28:04 PM UTC-5, Ivan Mitev wrote: > On 04/27/2018 11:20 PM, Matthew Wyenandt wrote: > > On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: > >> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > >>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: > >>>> Hey, > >>>> > >>>> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > >>>>> Hi all, > >>>>> > >>>>> I'm new to Qubes 4.0 and loving it. I'm having an odd situation where > >>>>> the time on my clock is showing -5 from my current timezone, rather > >>>>> than -5 from UTC. For instance, I'm physically located in > >>>>> America/Chicago timezone, which is -5 UTC. My Qubes OS clock is set > >>>>> for America/Chicago timezone, which also says -5 UTC; however, the > >>>>> clock is now showing -10 UTC. I've tried to figure out a way to > >>>>> manipulate the clock within dom0, but I'm not finding anyway to do so. > >>>> > >>>> your hw clock is likely set to local time instead of UTC ; this usually > >>>> happens because you use(d) MS Windows. > >>>> > >>>> `hwclock` allows you to tweak the hardware clock; you can manually set > >>>> the time and then run `hwclock --systohc --utc`, that should fix your > >>>> problem. > >>>> > >>>> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the > >>>> offset automatically: it first syncs dom0's time with the time in > >>>> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and > >>>> it then runs `hwclock --systohc`. > >>>> > >>>> If you still have issues, check that the timezone and time are OK in > >>>> sys-net (or whatever clockvm you have defined). > >>> > >>> Thanks for this info, Ivan. I followed these steps. Should my sys-net > >>> clock be set for UTC? When I run hwclock --show, it's still showing EDT > >>> as the current time. Do I need to set this manually? I would prefer > >>> that it get updated via ntp. > >> > >> The clockVM's clock is synchronized with NTP, you don't need to set > >> anything manually... > >> > >> Clock synchronization works like that (if I'm not mistaken): > >> > >> 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh` > >> script sets the VM's timezone (the script gets the timezone from dom0 > >> with `qubesdb-read /qubes-timezone`). > >> > >> 2a- if the VM is defined as the clockVM (sys-net by default) then the > >> `systemd-timesyncd` service synchronizes the VM's clock with NTP. > >> > >> 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd > >> timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with > >> the time in clockVM (sys-net). > >> > >> > >> So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should > >> point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago). > >> Then the easiest way is to perform a *full* reboot and everything should > >> be fine. > >> > >> > >> If it isn't, you'll have to debug a bit further: > >> > >> - make sure the timezone is OK in VMs too (again with `ls -l > >> /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone` > >> returns: it should be the same as dom0's timezone. > >> > >> - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl > >> status systemd-timesyncd` should output a line like > >> > >> Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)." > >> > >> the clock in sys-net should show the right time (both `date` and `sudo > >> hwclock` should show the same time, with the EDT format). > >> > >> - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time > >> should then be OK. > >> > >> > >> Hope this helps ! > > > > Okay, so something doesn't seem to be configured correctly. During further > > debugging, i was able to get the correct timezone using 'timedatectl > > set-timezone Americas/Chicago'. However, when running 'systemctl status > > systemd-timesyncd' I get the following output: > > > > systemd-timesyncd.service - Network Time Synchronization > > Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; > > enabled; v > > Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d > > └─30_qubes.conf > > Active: inactive (dead) > > Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago > > └─ ConditionPathExists=/var/run/qubes-service/clocksync was not > > met > > Docs: man:systemd-timesyncd.service(8) > > > > It seems the clocksync file is missing from /var/run/qubes-service/ > > directory. > > > If the output above is for your clockVM (sys-net) then something isn't > right. Otherwise that's the standard output for other VMs: > /var/run/qubes-service/clocksync is set only in the clockVM > > I'm afraid I can't help more than that - maybe someone more experienced > will chime in, otherwise you should file an issue. > > just in case, please paste the output of the following commands: > > in dom0: > - `timedatectl` > - `ls -l /etc/localtime` > > in sys-net: > - `systemctl restart systemd-timesyncd` followed by `systemctl status > systemd-timesyncd` > - `timedatectl` > - `qubesdb-read /qubes-timezone` > > in another VM: > - `sudo qvm-sync-clock` > - `timedatectl` > - `qubesdb-read /qubes-timezone`
Okay, so I read through the man pages of hwclock and timedatectl and finally got this resolved. Ivan, you were correct that my hwclock in bios was set to localtime, throwing everything off. I set that to UTC. I then reviewed your first two posts and set dom0 to point to the correct timezone. I then set hwclock in clockvm to be utc. Then reboot. All is correct and times are displaying correctly. I think I was making everything too complex when I was reading your posts, I apologize. steps I took to correct the problem: Dom0: 'sudo rm /etc/localtime' 'sudo ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime' clockvm (sys-net): 'sudo hwclock --systohc --utc' reboot computer now in both dom0 and clockvm 'ls -l /etc/localtime' points to the correct timezone and 'timedatectl' shows correct UTC and Local time as well as time zone. Thanks again for your help, it took some time, but I learned a lot about the interaction between Dom0 and the other VM's. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e2d005d8-f526-4f09-8fb6-06cd04dab747%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
