• https://github.com/mendersoftware/mender
• https://resin.io/
• https://github.com/rauc/rauc
• https://github.com/sbabic/swupdate

1. Building an initramfs
2. Configuring the boot to use it.

Building the initramfs¶

The kernel build could do this for us but it's probably easier to generate a basic Busybox and populate it with a custom init script that mounts partitions and sets up the overlays. This would need to be added as a new Busybox target in the build system and the new target added to the default set of top level targets.

This design requires the kernel to support squashfs and overlays. These can be compiled into the kernel for simplicity, otherwise the drivers need to be stuffed into the initramfs. Currently both are enabled as modules in the kernel build.

The root file system will need to be converted from tar to squashfs format. This is supported by Buildroot in the Filesystem Images submenu.

Configuring boot¶

The config.txt needs a new option: initramfs. This points to the file to use and the memory location where it should be loaded. To simplify, you can specify to load it after the kernel.

 initramfs <filename> followkernel

The initramfs image will need to be stored in the FAT partition on the SD card with the Linux kernel.

Filesystem layout¶

1. /overlay - Where overlay directories live.
   1. /overlay/current - Symlink to the currently active image
   2. /overlay/next - Symlink to the next (upgrade) image
   3. /overlay/image_id - a specific release image
      1. /overlay/image_id/presentation - what we see; the combined view
      2. /overlay/image_id/upper - where runtime root file system changes are saved; userdata (application runtime data) is not stored in the root filesystem but rather in /userdata.
      3. /overlay/image_id/work - used by the overlay driver
      4. /overlay/image_id/backups - temporary storage used during upgrades and resets
      5. /overlay/image_id/squashfs - The squashfs root filesystem for this image release
      6. /overlay/image_id/utils - Utilities required to manage bank switching/overlays/squashfs
2. /userdata - Application save data is stored here. It is bind mounted into the presentation layer of the current image. Application data has to be migrated to new formats, as needed, by the applications on first boot.

Bank switching would imply two banks: current and next. A new release gets a new squashfs and a copy of the old upper directory, which may have package updates or similar that we want to propagate to the next release. If the new version fails self-check (which needs to be implemented as an init script function) then we swap back to the old version.

Filesystem images need to be signed. Signing verification tools go in /utils. I'm not sure how to do this yet. Other utilities, including release-specific tools will be placed in the utils directory. This will allow the init script to be updated on the fly by dropping new utilities specific to the new release in /utils and having the init script find and then run them as part of its processing. Anything dropped in /utils has to be signed and is probably an archive that is unpacked by the init script for use.

Boot Process¶

The initramfs mounts raw partitions under /boot (vfat partition) and /root (ext partition) from the SD card. The /root partition is structured with the overlay directories. The initramfs uses these directories to mount the currently active image as the runtime environment.

The real root and boot partitions are made accessible through a bind mount into the overlay's presentation layer by the initramfs.

Image Upgrades¶

An image can be downloaded and upacked to a directory under /overlay on the real root partition. Symlinks are updated so the next boot will start the new image. The image must have a self-test included on firstboot. If the self-test fails then the boot sets up a fallback to the old image and reboots.

If an image boots successfully it will check for a next tree and clean it up.

Minor update: I tried to get QEMU to work the RPi2 build. There are instructions for running QEMU specific to RPi2 which I've scripted. It boots up to a login prompt but I can't get any keyboard input.

I would really like to get QEMU working with this because it will make testing the initramfs easier than having to write an SD card and install it to a board. The latter isn't that hard but then I need power, a display, a keyboard, etc. With QEMU I can do it from my dev box.

Still reviewing options here. There are other generic ARM types I may be able to use. I know, however, that the aarch64 QEMU doesn't work with my RPi2 build even though that build does run on real hardware just fine.

Last night I got the init script working to the point of mounting the overlay and booting PiBox. The boot process stops before it gets to a login for some reason but I'm not particularly worried about that yet. It may be an artifact of how I'm booting in QEMU. I'll know more when I try on real hardware, which is pretty much required now that I have the overlay mounting cleanly.

There is one more step in the init script to complete: bind mounting real partitions into the overlay. I have two choices here.

First, I can keep the mounts I have in the init script and bind them to the overlay, then disable their mounting by mdev in the rootfs.

Second, I can skip the boot and userdata mounts in the init script (they aren't needed to get the overlay running) and let mdev mount the partitions as it currently does.

The second method seems simpler so I'll try that first.

Quick test of the image on real hardware: it boots fine up to getting a login. Login does work. Mount points look okay - userdata is under mmcblk0p3 as it should be. However, X does not start. I'm not sure why yet. Running "S99UI start" manually doesn't do anything. Then again this is a dev platform so maybe xinit has nothing to do for some reason.

More testing soon.

Firstboot doesn't set pibox-config (by calling tvservice) correctly. That's why X.org didn't start. If I run it manually after I've logged in genConfig (in the functions script) properly creates the pibox-config so S99UI starts X correctly.

So something is fishy with how firstboot is working using an initramfs.

Found it. The tvservice program fails because vchiq is not loaded during firstboot. This is because S10mdev has not been run. So I need to add that to firstboot and then I think setup of pibox-config will complete correctly. This is still to be tested though I've run it manually and it seems fine.

Well, I can't figure out why mjpeg-streamer won't open /dev/video0 under the new overlays. The device file is there, the mjpeg-streamer uvc_video.so module is there and all modules are loaded. But I keep getting a "No such file or directory" error.

Worse, if I don't do the overlay/squashfs (re: copy the rootfs directly to disk) then it works perfectly.

So this can't be used until I figure out what's wrong with video, specifically v4l. It might be that I didn't move /dev from the initramfs into the switch_root. But I kinda doubt it.