[yocto] Yocto-ish upgrade-in-place strategy

[Chris Morgan]

On Sunday, May 3, 2015, Patrick Doyle <wpdster at gmail.com> wrote:

> On Sun, May 3, 2015 at 5:51 AM, Chris Morgan <chmorgan at gmail.com
> <javascript:;>> 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
>


We thought about the rescue/recovery approach as well. The issue was how
the system would recover in the field and how updates were handled.

Consider that to update the full system image you'd have to download and
store that image to flash, unless you stored it somewhere, and if you were
going to store it you'd have to have extra space for that. For recovery
you'd have the similar approach of booting recovery but you could write
directly to the primary fs since you're booted to recovery. The trouble
there is download speed and connectivity. The system is down until you
download the update diff/full image and that could take some time. And the
system is down for that period.

So we didn't see a path forward that would support slow connections plus no
down time. And we would still need some place to put the new image that was
guaranteed to be available which means it couldn't be used for application
or other data that had to be preserved across updates. With two rootfs
partitions we can download in place and take our time doing so. Plus no
special recovery image and no reserved area that is unused except during
update. We do have a full duplicate rootfs though.

I see where you are going, for other use cases it may be better to have a
primary and a recovery. Our rootfs is around 200MB at this point.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150503/a9e99257/attachment.html>