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

[Chris Morgan]

On Saturday, May 2, 2015, Patrick Doyle <wpdster at gmail.com> wrote:

> Rather than inventing this from scratch yet again, I would like to ask
> what the Yocto-ish best practice is for deploying an embedded system
> that has to support in-place upgrades.
>
> It seems to me that this should be a fairly common scenario:
> I have (or, rather am in the process of developing yet another) an
> embedded application that will be running on a device whose power
> supply is uncertain at best.  Consequently, I want to run from a
> read-only squashfs rootfs, with some small amount of seldom changed
> configuration data (most likely stored in a JFFS partition).
>
> But I need a strategy to upgrade this system in place.  Since I am
> running from a read-only squashfs, I can't apt-get or rpm upgrade
> individual packages.  I must redeploy the entire image.
>
> I can divvy up the flash however I want, so I am thinking that I would
> like to use u-boot to boot a rescue image from one partition, that
> would kexec the deployed image from a different parition.
>
> Are there Yocto recipes, blogs, community experience with this sort of
> thing, or should I invent my own solution?
>
> Again, this feel like a common problem that others should have already
> solved, and I would rather solve uncommon problems than re-solve
> common ones.
>
> --wpd
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org <javascript:;>
> https://lists.yoctoproject.org/listinfo/yocto
>

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?

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