We ship our product globally and and timezone is set by the customer via an UI as it may be the case with many embedded systems.
Using export TZ=‘fullzonename’ would change the timezone accordingly, but not persistently.
Using the “timedatectl set-timezone” command instead makes the edit persistent and changes the time zone by
- writing the file /etc/timezone while concurrently
- adding or changing the symlink /etc/localtime -> /usr/local/share/zoneinfo/…
This timezone setting must of-course survice OTA updates, therefore I wanted to create symlinks in the usual manner, for example: /etc/timezone -> /data/etc/timezone
First, I was optimistic that for /etc/localtime I could make a concatenated symlink, for example: /etc/localtime -> /data/etc/localtime/ -> /usr/local/share/zoneinfo/…
But: This doesn’t work because the “timedatectl set-timezone” command always overwrites any existing symlink named “/etc/localtime -> …” with its own new symlink.
Searching this forum I found this link
where using “mount -t bind /data/localtime /etc/localtime” is recomended.
I am unsure if “mount -t bind” is really necessary here because our rootfs is writable and also feel uncertain about the reliability of this solution.
Are there any ideas how to solve this satisfactory with on a writable rootfs with a persistent /data partition ?
In the same post you will see how I have overcome this problem. Maybe you should try something like that. The main issue lies with the way timedatectl is written, it specifically looks for the absolute path of /etc/localtime.
There is no easy way around it.
But you have brought out an important discussion. I had raised this issue with systemd group and it was shot down with a vengeance. Maybe folks from mender can chime in and see if my patch needs to be included in the mender-repo.
Since I do think that in today’s age embedded linux software don’t reside in one place but instead can be deployed everywhere. It doesn’t make sense why something as trivial as timezone needs to guarded with so much care.
Many thanks for your quick answer, I was already afraid that this may be not easy to solve.
To set time zone permanently with mender, the only idea I had so far, is as follows:
Instead of using “timedatectl set-timezone” command I could write the same symlink instead from our userland application as “/data/etc/localtime/ -> /usr/local/share/zoneinfo/…”
In the rootfs A/B I could place the symlink “/etc/localtime -> /data/etc/localtime/” which wouldn’t get overridden if nobody accidentially uses timedatectl set-timezone.
But this will only work, if at all, in an embedded system where we have full control over the whole “thing” (which is the default use case for mender).
And I would have to check if the given zone is valid in our application in the same way as it is done currently by “timedatectl set-timezone” etc.
What does the mender community think ? It’s hard to imagine, that we are the first facing this issue …
Is it maybe possible to somehow use UpdateModules or StateScripts during update process for saving and restoring the existing “/etc/localtime” symlink manually ?
That’s the general approach used for these kinds of things but I think the root of the problem here is that the timedatectl command appears to require the file in /etc and perhaps even a symlink will not work. I don’t know the details but it sounds like @thesillywhat has investigated it more thoroughly.
Drew
Sorry, but I don’t exactly understand what I have to do,
when I want to make the timezone setting to reliably survive mender OTA updates ?
are you using a read only root file system? If not, then I think you can achieve it by using state script.
Have you tried creating a state script?
Yes, our rootfs is writable, as you can see in my initial post.
I haven’t worked with state scripts yet, but if this should be a way, it will be the first opportunity to become friendly with them …
maybe this could help you get started