On Mon, Nov 23, 2015 at 1:41 PM, Mariano Lopez < mariano.lo...@linux.intel.com> wrote:
> There has been interest in an image based software updater in Yocto > Project. The proposed solution for a image based updater is to use Stefano > Babic's software updater (http://sbabic.github.io/swupdate). This > software do a binary copy, so it is needed to have at least two partitions, > these partitions would be the rootfs and the maintenance partition. The > rootfs it's the main partition used to boot during the normal device > operation, on the other hand, the maintenance will be used to update the > main partition. > > To update the system, the user has to connect to device and boot in the > maintenance partition; once in the maintenance partition the software > updater will copy the new image in the rootfs partition. A final reboot > into the rootfs it is necessary to complete the upgrade. > > As mentioned before the the software will copy an image to the partition, > so everything in that partition will be wiped out, including custom > configurations. To avoid the loss of configuration I explore three > different solutions: > 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). > > Configuration files can be anywhere a package decides to install them. So having a single partition would be difficult. If you could, you would most likely be forced to have an initramfs to make sure /etc was mounted before init runs. > 2. Do the backup during the update. > a. The pro is the configuration is directly in rootfs. > b. The con is If the update fail most likely the configuration would be > lost. > > Why would the configuration be lost if the update fails? Couldn't it just be stored on the thumbdrive? > 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. > > 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. > > Mariano > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
