On Sun, May 3, 2015 at 5:51 AM, Chris Morgan <chmor...@gmail.com> wrote: > Is there a standard way? We've seen a few different approaches between > android systems (phones), Linux distributions, and things like chromebook. > > In our case we are using two uboot, two kernel, and two root file system > partitions with uboot environment controlling the active one. Squashfs for > the root fs. Raw images for uboot and kernel. Overlayfs in another rw > partition that we put on top of the rootfs where we keep system > configuration. Media and other stuff goes into yet another btrfs partition > that, like the overlayfs, isn't managed by the update system. > > Approach is to update the second rootfs while one rootfs is running. Swap > env in uboot environment to point at the other rootfs and then when > appropriate reboot. This lets us avoid downtime while downloading the > update, we download in the background. > > We build everything with yocto but afaik we don't have much specific stuff > for the update system because we don't have an upgrade partition but rather > two sets of partitions. > > Thoughts?
Hi Chris, Thanks for the description. We do something very much similar to that on one of our systems (except for the part about downloading in the background). As I have been thinking about this, I have been thinking about something along the lines of creating a rescue/boot partition with the following: core-image-minimal squashfs ssh (for rescue operations) kexec-tools U-boot would boot that image. That image would contain an rc.local that would mount the active partition and kexec the kernel it found there. The active partition would contain our deployed application, which would likely also have a squashfs rootfs (because I don't want to trash the flash when the power goes out). It would also have whatever hooks we needed to upgrade images in place. My thinking is that the boot/rescue image would be a factory/expert image. It (of necessity) needs special tools and/or access to the board (JTAG header, USB rescue port, etc...) to be installed. But once it is installed, it is capable of booting whatever Linux I place in the active partition. I might make it smart enough to support an "active" partition and a "fallback" partition, but I kinda feel like I already have a "fallback" mechanism in place with the boot/rescue image. At some point, I begin to think that I am overthinking this. I also begin to think that everybody (in this space) has these same issues. Why do we keep reinventing the wheel? --wpd -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto