Which means that timedated is trying, entirely sensibly, to atomically overwrite the /etc/localtime symlink with the new timezone. This doesn't work with our ro-/etc scheme that we have on our device images. There will be a similar problem with updating /etc/timezone atomically too, but that's a file instead of a symlink.
The rough workaround that we have in mind (suggested by cjwatson, thanks) is to create a writable directory and make /etc/localtime /etc/timezone /etc/adjtime be symlinks to files/symlinks as appropriate inside there, which are themselves atomically updated. Do this for the fallback case (EROFS) only.
It does mean that we'll need to play whack-a-mole with anything else which thinks it can update these, sadly. I wonder if it'd be better to revisit making the whole of /etc writable on our images and deal with the conffile issues another way.
If you issue timedated's SetTimezone D-Bus call and strace the daemon, you see that it fails because of this:
symlink( "../usr/ share/zoneinfo/ Europe/ Berlin" , "/etc/. localtime4e4960 6a750b8c2c" ) = -1 EROFS (Read-only file system)
Which means that timedated is trying, entirely sensibly, to atomically overwrite the /etc/localtime symlink with the new timezone. This doesn't work with our ro-/etc scheme that we have on our device images. There will be a similar problem with updating /etc/timezone atomically too, but that's a file instead of a symlink.
The rough workaround that we have in mind (suggested by cjwatson, thanks) is to create a writable directory and make /etc/localtime /etc/timezone /etc/adjtime be symlinks to files/symlinks as appropriate inside there, which are themselves atomically updated. Do this for the fallback case (EROFS) only.
It does mean that we'll need to play whack-a-mole with anything else which thinks it can update these, sadly. I wonder if it'd be better to revisit making the whole of /etc writable on our images and deal with the conffile issues another way.