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

[Patrick Doyle]

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