#Wipefs raspbian update
#Wipefs raspbian archive
#Wipefs raspbian plus
#Wipefs raspbian windows

But for anything bootloader related they refer to the u-boot docs. The swupdate docs introduce a high level overview on how you could implement this yourself. Swupdate has support for updating such u-boot environment variables from linux userspace, though it doesn’t offer a fully working dual rootfs with rollback mechanism by itself. The rootfs partition is passed into the kernel as kernel argument. The u-boot bootloader relies on environment variables to select which partition contains the rootfs of our Linux system. E voila, we got ourselves a dual rootfs with rollback mechanism.įor our embedded device the bootloader assures which rootfs (A or B) is loaded.

#Wipefs raspbian update

If anything goes wrong during the update to B, we should still be able to load A because it was working fine for us previously. After reboot B becomes the active rootfs and A can be used for updates. When a new updates arrives it goes into B, while rootfs in A is active. What we want is something as following… One rootfs partition (A) is active and executing, the other one (B) is used for the update.

#Wipefs raspbian windows

But other questions arise: how can we have a rollback mechanism when things go wrong? And can we do a rollback automatically for our devices in the field? How can we reduce the downtime during the upgrade? Because what we want to avoid are scenarios such as with the Windows Update system which takes an endless amount of time during reboot to perform its tasks, rendering the device useless endlessly. After having experimented a few things I found that Swupdate does fine in parsing the update manifest, fetching artifacts, and deploying the stuff that we want. For example I could make sure that the updater checks the board’s hardware compatibility, and deploys the rootfs to my partition of choice.

#Wipefs raspbian archive

I also found little issues creating a valid cpio archive that contains the update manifest and artifacts.

#Wipefs raspbian plus

After creating a new image I booted my target device and at least swupdate was working, plus it was also hosting its “Mongoose” update website on port 8080. I tried the Zeus (3.0) branch, made sure to set the PREFERRED_PROVIDER to libubootenv, and made sure that all temporary build files from the u-boot-fw-utils recipe are deleted (important!). Only the more recently branches of meta-swupdate contain a recipe for using libubootenv as alternative to u-boot-fw-utils. The problem with libubootenv is that it was not yet introduced in the Yocto Rocko (2.4) branch that I’m on. More recently they also started offering an alternative called libubootenv.

For that functionality Swupdate relies on u-boot-fw-utils. Well that’s the theory… Although the docs claim that you should be fine using u-boot 16.05, and mine was 17.03, bitbaking failed because of some missing function calls that are needed to write to the u-boot environment. Swupdate and YoctoĪdding swupdate to your Yocto build is as easily as downloading meta-swupdate sources and adding the meta layer to your nf. Aside of that, os-tree also looks very promising on paper but is to far fetched from my current solution and will probable require a bigger overhaul. It should allow us to do our own stuff more easily while still relying on some of the implementations that are already inside the framework. My choice went out to swupdate since it’s more of a framework rather than supplying an end-to-end solution (like Mender). For this purpose there are a few solutions available such as swupdate, Mender, RAUC, os-tree etc.

I’ve spend some time building my own Linux distro using Yocto, and now I’ve come to the point where I want to update my devices remotely.