I am currently experimenting with them. I forked the main template to keep it clean and installed some software. The software in turn reported my actual timezone even though it was put through proxy. I went and checked what timedatectl was reporting. It indeed was my actual timezone I set up during initial Qubes installation. If I use regular debian-13 template I don’t experience this issue
Any chance you made a typo, or enabled it as a “service” instead of a plain “feature”? What’s the output of
qvm-features VMNAME | grep anon-timezone
1 Like
Do you have anon-timezone enabled on your regular debian-13 template but not on your forked main template?
I use UTC for everything instead of the anon-timezone feature, so I never really looked into how timezones are inherited from a template until now. Apparently, if an AppVM has anon-timezone enabled, it will use the timezone that was active in its TemplateVM the last time the the latter was running - inherited via /etc/localtime and possibly /etc/timezone and /etc/sysconfig/clock.
1 Like
the output is
anon-timezone 1
1 Like
I have it enabled both on debian-13-minimal and on it’s forks. For whatever reason I don’t have /etc/sysconfig/clock. However checking the contents of /etc/timezone in the original shows Etc/UTC and /etc/localtime shows als UTC plus some garbage. I don’t know if it’s identifiable garbage or not
I’d compare the real target of the timezone files, not the raw /etc/localtime contents. In the TemplateVM and in a fresh AppVM based on it, check something like: readlink -f /etc/localtime ; cat /etc/timezone ; timedatectl. Debian normally won’t have /etc/sysconfig/clock, so that part may just be Fedora/RHEL-specific. Also make sure the template was fully shut down before starting the AppVM you test, otherwise you can end up looking at old template state.
After taking the minimal template with anon-timezone working and recreating it’s forks I managed to make it work. I don’t know why but I can’t fix already existing minimal templates