ODROID Boot

[Rob Spanton]

Hey,

You may recall that I previously was planning on using containers
combined with a union filesystem to permit changes to the robot's
shipped root filesystem. I spent some time investigating this route
[1], and concluded that there was a simpler way that involved modifying
fewer things. I've now written this.

A small shim script that sits in the place of the init executable, and
does the following:

* Waits for a robot.zip-containing block device to arrive.
* Mounts that block device.
* Starts a separate process that will hard reboot the system when
the block device is unplugged.
* Observes if there's an overlay present on the block device. If
there is:
* Mounts it.
* Mounts an overlayfs with the overlay as the "upper" fs.
* pivot_root's onto the overlaid situation.
* exec's systemd.

Now that I have this written, I am moving on to sorting out the root
filesystem for the device. Code will appear for that soon.

A couple of other notes:

* I'm looking at using squashfs on the SD card. I'll be checking
out how this affects performance. Sizewise, it reduces the 2GB
filesystem down to 700MB. My expectation is that boot is IO
bound, so I think this will bring some winnings. Overlay files
will almost certainly be squashfs too.
* I'll have a quick look into the feasibility of an optional kexec
in the boot process too. That would win us in-field kernel
updates.

Cheers,

Rob

[1] Reasons the containers option isn't ideal:

* Booting a "full system" within a container (i.e. systemd init,
and all services) would have been good, however this would have
meant that the contained system's interaction with the system's
hardware would have been troublesome. In particular, both
hardware enumeration and wifi would have been nightmares.
* Booting a "full system" (systemd) in a mount namespace (i.e. all
other things in the same namespaces) would allow hardware
enumeration and wifi to work properly. However, it would have
been painful with systemd, as systemd behaves differently if its
PID isn't 1.
* Running systemd and udevd outside the container was also an
option. This would have meant that these things couldn't have
been upgraded using overlays, which isn't great.

[Peter Law]

Rob wrote:
> You may recall that I previously was planning on using containers
> combined with a union filesystem to permit changes to the robot's
> shipped root filesystem. I spent some time investigating this route
> [1], and concluded that there was a simpler way that involved modifying
> fewer things. I've now written this.

Cool. Thanks for doing this.

I've not been involved with the software on the kits much in the past,
but I'd like to be more so. With that in mind, are the sources for
this somewhere, and are there any instructions for getting going with
them? Do we have any dev kits yet?

Thanks,
Peter