So, here at UBports we’re still using system-image with read-only rootfs - much like Ubuntu Core. As we’re transitioning our base to Ubuntu 20.04, we’re also (finally) transitioning to systemd, and that means adding more paths to writable-paths, including /etc/systemd.
Upon studying, I’ve found that the core snap (16.04 one) defines the directory as synced (i.e. new files will be copied on every boot)
However, since core18, this path is instead re-defined as persistent transition (i.e. files are copied only on the first boot).
What I don’t understand is, when e.g. upgrade from core to core18, won’t the newly-shipped units become not-enabled by default? I think that it was a problem before in core which prompts the change from persistent transition to synced.
Isn’t it also a problem in core18+?
And, BTW: since Ubuntu Touch is special-purpose, personally I don’t really want the /etc/systemd to be completely writable, but we need it so that a few selected units can be disabled (e.g. systemd-timesyncd.service and ssh.service). Maybe there’s a better way to achieve this?
@zyga, since you seem to be the person that wrote the initial version of core18’s writable-paths, could you please give some insight here? (And please pardon me if this is inappropriate)
Responding from phone so please forgive thr brevity.
I was not working on writable paths. I wanted to replace that with special mode of snap-confine back when it was still separate from snapd.
The change, however, I do remember. It was caused by the desire to control ssh from snapd. The synced mode was unable to express this and @mvo made the switch, if I recall correctly.
My advise is to abandon writable paths and switch to a different system. The original had countless issues and is far too inflexible.
@zyga Thank you for your response and sorry for late reply.
The limitation you mentioned seems to be the same that I discovered too. For our case though, I think we can live with it - for any unit that we want to be disable-able, we make sure that it’s disabled on the read-only layer (and then enable it on first boot if we want it to be enabled by default). And not being able to disable arbitrary units is sort of what I want anyway…
As for migrating away from writable-paths, at the moment I’m not sure what could replace it. Maybe a system which boots with empty /var/ and /etc/ would be nice, but we don’t have the resource to investigate into that at the moment.
