Re: [oe] RFC: Reference updater filesystem

[Roman Khimov <roman@khimov.ru>]

В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
> 1. Use a separate partition for the configuration.
>    a. The pro of this method is the partition is not touched during the
> update.
>    b. The con of this method is the configuration is not directly in
> rootfs (example: /etc).

That's the right solution, although to do it really right (at least IMO) you 
need to implement the /usr merge [1] (and that's orthogonal to using or not 
using systemd), which can also help you make your /usr read-only (because 
that's just code and static data) with read-write / for user data of various 
sorts.

> 3. Have an OverlayFS for the rootfs or the partition that have the
> configuration.
>    a. The pro is the configuration is  "directly" in rootfs.
>    b. The con is there is need to provide a custom init to guarantee the
> Overlay is mounted before the boot process.

And this is the approach I would recommend not doing. I've used UnionFS for 
thing like that (overlaying whole root file system) some 6 years ago, it 
sounded nice and it kinda worked, but it wasn't difficult to make it fail 
(just a little playing with power), we've even seen failures on production 
devices, like when you have whiteout file for directory already written, but 
don't have new files in it yet and that can completely ruin the system.

Also, it usually works better when you don't have any changes in the lower 
layer, but we're talking about updating it here, you can easily end up in a 
situation where you have updated something in the rootfs but that was 
overriden by upper layer and thus your user doesn't see any change.

> With the above information I'm proposing to use a separate partition for
> the configuration; this is because is more reliable and doesn't require
> big changes in the current architecture.
> 
> So, the idea is to have 4 partitions in the media:
> 1. boot. This is the usual boot partition
> 2. data. This will hold the configuration files. Not modified by updates.
> 3. maintenance. This partition will be used to update rootfs.
> 4. rootfs. Partition used for normal operation.

You probably don't need to separate 1 and 3, all the code for system update 
should easily fit into initramfs and just making /boot a bit larger would 
allow you to store some backup rootfs.

Also, you can swap 4 and 2 which will be useful if you're installing on 
different sized storage devices, usually you know good enough the size of your 
rootfs, but you probably want to leave more space for user data if there is an 
opportunity to do so, that's just easier to do with data partition at the end.


[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/