On 23.11.2015 22:15, Mariano Lopez 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). > > 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. > > 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. This is mostly what we have implemented for our O3D3xx 3D Camera at ifm. We are using the swupdate tool developed by Stefano and sponsored by ifm.
We have two flashes one small SPI NOR flash which is responsible for booting and a larger NAND which contains the root filesystem. Due to the restrictions to not have any buttons on the camera Stefano implemented a boot counter which allows us to boot into swupdate from the rootfs. Or if the rootfs is not able to boot we automatically boot into swupdate mode itself. To have the same ip address in both cases we have a small partition in the SPI NOR which contains the network config and some stuff which must retain during software update. The swupdate itself is implemented as a kernel with an initramfs. We decided to have such an fallback to not loose any camera during a field update. BTW this was a good decision and we have a lot of good feedback on this feature. Another option was the way how for example AVM Fritz.Box! implements the update, they do download the image and install the image from the rootfs during shutdown. But if someone removes power the box is bricked unless you do some tftp magic. I guess swupdate is tunable to support this usecase as-well. Regards, Christian -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
