Until I develop a captive portal-based mechanism for initially
configuring the WiFi on Raspberry Pi machines, the easiest way to do
initial provisioning is using the CLI via the serial console. Since the
root account has no password, and I don't want to have to specify one in
downstream projects' configurations, I've added a configuration option
to enable automatically launching a root shell connected to the serial
console instead of a login prompt. The security risks here are pretty
minimal, because someone would need phyiscal access to the device in
order to use this shell, in which case they could use any number of
other methods to get control of the system.
For an optimal out-of-the-box experience, we need to automatically
configure any wired network interfaces with DHCP. `systemd-networkd`
does not do this by default.
The `system-update` and `install-update` scripts are the same as from
Aimee OS v1, with references to Gentoo replaced, of course. We need
some additional kernel features in order to mount the firmware partition
and update the GRUB environment file, and of course the `grub-editenv`
tool itself. We also need `wget` for now, since that's how the tool
downloads the specified update file from the network.
Eventually, `system-update` will be replaced by a much more robust tool,
with package URL discovery, signature verification, etc. The shell
script will do for now while development is still proceeding rapidly.
Most of the logic in the `init-storage` script is the same as it was in
Aimee OS v1 (Gentoo). The major difference is now we are initializing
the data volume in the initramfs instead of in the real OS. This allows
us to make all of `/etc` writable via OverlayFS, instead of having only
certain sub-directories writable via bind-mounts.
Buildroot doesn't really have any tools for building an initramfs,
unfortunately. It does have a bit of infrastructure for running
`dracut`, but I'd really rather avoid having that much complexity in the
initramfs; all we need is to run the `init-storage` script and then
switch root. Instead, the `mkinitramfs.sh` script, called in the
post-build stage, creates the CPIO archive from files in the target
directory. The only particularly interesting bit is how it resolves
shared library dependencies, to make sure the appropriate resources are
available for the requisite commands.
I briefly considered building a statically-linked BusyBox just for the
initramfs. Since it doesn't provide several important tools like
`btrfs`/`mkfs.btrfs`, I had to implement the dynamic link resolution
function anyway. It made sense, then, to copy Dash and the necessary
Coreutils binaries themselves.
