[OE-core] [oe] RFC: Reference updater filesystem

[Lopez, Mariano]

On 11/24/2015 4:30 AM, Roman Khimov wrote:
> В письме от 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.

To be honest I'm not familiar with /usr merge, I need to check on that 
to see if it is a good option with the current OE-core infrastructure.

>
>> 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.

Thanks for sharing your experience, this is another big con for the 
Overlay option.

>
>> 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.

I left the /boot partition separate just in case there is need to 
replace the kernel or the bootloader. This way it would be easier to 
change using the same method as the upgrading the 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.

I was thinking in the same thinking just backwards, usually 
configuration files are just small text files that don't require too 
much space. If you require a new feature in the target that will make 
rootfs to grow depending on the feature. I plan to use wic to accomplish 
the filesystem structure. A good thing about wic is that it will be very 
easy to do the swap, just need to modify two options in the .wks file.

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