ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 2015-05-20 11:04 AM, Martin Pitt wrote:
> Hello Iain,
> 
> Iain Lane [2015-05-20 15:19 +0100]:
>> We sometimes come across bugs where software expects to be able to
>> rename files to work properly (either to atomically update, or perhaps
>> to disable some functionality). This doesn't work with our read-only
>> partition layout. We know how to work around this limitation by making
>> code changes, for example
>>
>>   https://code.launchpad.net/~seb128/whoopsie-preferences/touch-writable-image/+merge/259531
> 
> Indeed, I have similar hacks in systemd. Our current approach to
> making writable parts of /etc via file bind mounts is hopelessly
> doomed, as it breaks file system semantics like the one you mentioned.
> 
>> to make use of a symlink into a writable directory. It's not a great
>> solution, not least because we have to implement it on a case-by-case
>> basis and we don't have any good way of proactively spotting the bugs -
>> they typically manifest themselves by settings not being saved but
>> people usually do not check for rename failures or surface these to the
>> user.
>>
>> Can anyone think of a way to fix this class of problem and remove the
>> need for us to have to go and patch code? Or at least to detect these
>> rename failures (check for EROFS) and aggregate them somewhere so that
>> they can be fixed. This is on touch - I'm not sure if snappy does
>> anything different here.
> 
> TBH, the only clean way that I see is to flip the whole thing around.
> Keep /etc (and /var) writable, and instead deal with the things that
> should *not* be modified. I. e. ship them in e. g. /usr/etc/ and
> symlink/bind-mount them to /etc, or longer-term, get rid of them
> completely. IMHO this would be a much saner architecture than trying
> to play eternal catch-up with bugs like this and getting an
> ever-growing spaghetti heap of file bind mounts which we'll never be
> able to revert/change.

+1

Marc.