Aimee OS/aimee-os/pipeline/head This commit looks goodDetails
Occasionally, especially on a Raspberry Pi, the storage subsystem has
not fully enumerated all of the disks before the `init-storage` script
starts. This prevents the system from being able to boot, since the
script attempts to identify the root filesystem very early. Now, we try
a few times to identify the filesystem before giving up, to give the
kernel a chance to discover everything.
Aimee OS/aimee-os/pipeline/head This commit looks goodDetails
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.
Dustin