В письме от 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/ -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
