Re: [qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from? (Take two)
Hello Ivan, El mar., 1 may. 2018 01:13, Ivan Mitev escribió: > Hi, > > On 05/01/2018 03:18 AM, Pablo Di Noto wrote: > > Hello all, > > > > I asked this question when Qubes R3.2 was out, and solved with help from > Andrew in a somewhat weird way (running local scripts on each AppVM). > > > > Now that we are at R4.0, I am again having this issue: > > > > After install, dom0 gets proper timezone: > > > > |[root@dom0 Desktop]# timedatectl > > | Local time: Mon 2018-04-30 21:12:20 -03 > > | Universal time: Tue 2018-05-01 00:12:20 UTC > > |RTC time: Tue 2018-05-01 00:12:20 > > | Time zone: America/Argentina/Cordoba (-03, -0300) > > | Network time on: no > > |NTP synchronized: no > > | RTC in local TZ: no > > > > but for some reason, all AppVM get the wrong timezone on their > configuration script: > > > > |user@p-vault:~/p-vault$ ls -l /etc/localtime > > |lrwxrwxrwx 1 root root 39 Apr 30 23:32 /etc/localtime -> > ../usr/share/zoneinfo/Argentina/Cordoba > > > > which of course does not exists, so all AppVM end up in GMT. > > > > So my original question is back: Where does that value come from? > /usr/lib/qubes/init/qubes-early-vm-config.sh > Yes, I see it. That is why I was after the source of the "Argentina/Cordoba" as answer to "qubesdb-read /qubes-timezone" on any AppVM. For some reason, despite dom0 has proper "America/Argentina/Cordoba" timezone after a clean install, AppVMs get "Argentina/Cordoba" when they ask dom0. Will check qubesdb code to see if there is some hardcoded regexp that is asuming timezones are only "" or "/" break when it is three item "//" Regards, ///Pablo > -- 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/CAOJFbN8BQ-_sdO-tcjGDO1v%3D7xV55Q8sBjFWU8YP5LXsipxVeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from? (Take two)
Hi, On 05/01/2018 03:18 AM, Pablo Di Noto wrote: > Hello all, > > I asked this question when Qubes R3.2 was out, and solved with help from > Andrew in a somewhat weird way (running local scripts on each AppVM). > > Now that we are at R4.0, I am again having this issue: > > After install, dom0 gets proper timezone: > > |[root@dom0 Desktop]# timedatectl > | Local time: Mon 2018-04-30 21:12:20 -03 > | Universal time: Tue 2018-05-01 00:12:20 UTC > |RTC time: Tue 2018-05-01 00:12:20 > | Time zone: America/Argentina/Cordoba (-03, -0300) > | Network time on: no > |NTP synchronized: no > | RTC in local TZ: no > > but for some reason, all AppVM get the wrong timezone on their configuration > script: > > |user@p-vault:~/p-vault$ ls -l /etc/localtime > |lrwxrwxrwx 1 root root 39 Apr 30 23:32 /etc/localtime -> > ../usr/share/zoneinfo/Argentina/Cordoba > > which of course does not exists, so all AppVM end up in GMT. > > So my original question is back: Where does that value come from? /usr/lib/qubes/init/qubes-early-vm-config.sh the script gets the timezone from dom0 with `qubesdb-read /qubes-timezone` and sets it early during a VM's boot. see this post/thread for more details: https://www.mail-archive.com/qubes-users@googlegroups.com/msg21693.html > And the obvious next one: How can I change it to a proper > "America/Argentina/Cordoba"? I tried to set a different timezone in dom0 but qubesdb-read would return the old value in VMs ; I don't know how the db is updated (a reboot would probably do but it seems overkill and I have too much stuff open to test). But if you're rebooted already and you still get the wrong string in VMs, maybe it's a bug in how qubesdb-read reads the timezone (interestingly, that's the first time I see 3 fields like 'X/Y/Z' - I always thought a timezone would be 'X/Y'). > > Thanks! > -- 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/29748e05-37a9-48eb-dfc6-674cd81c83c2%40maa.bz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from? (Take two)
Hello all, I asked this question when Qubes R3.2 was out, and solved with help from Andrew in a somewhat weird way (running local scripts on each AppVM). Now that we are at R4.0, I am again having this issue: After install, dom0 gets proper timezone: |[root@dom0 Desktop]# timedatectl | Local time: Mon 2018-04-30 21:12:20 -03 | Universal time: Tue 2018-05-01 00:12:20 UTC |RTC time: Tue 2018-05-01 00:12:20 | Time zone: America/Argentina/Cordoba (-03, -0300) | Network time on: no |NTP synchronized: no | RTC in local TZ: no but for some reason, all AppVM get the wrong timezone on their configuration script: |user@p-vault:~/p-vault$ ls -l /etc/localtime |lrwxrwxrwx 1 root root 39 Apr 30 23:32 /etc/localtime -> ../usr/share/zoneinfo/Argentina/Cordoba which of course does not exists, so all AppVM end up in GMT. So my original question is back: Where does that value come from? And the obvious next one: How can I change it to a proper "America/Argentina/Cordoba"? Thanks! -- 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/698c13f7-532a-4d23-8d08-034e19785b8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
