An empty `/etc/machine-id` file does _not_ trigger systemd's "first
boot" logic. This means with `ConditionFirstBoot=true` will not run,
and the unit preset policy will not be applied. To ensure a first boot
behaves the way we want, we need to pre-populate the `/etc/machine-id`
file with the string `uninitialized\n`, per _machine-id(5)_ § _First
Boot Semantics_.
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
the `KCONFIG_ENABLE_OPT` macro will not switch a `=m` value to `=y`, so
if the downstream kernel configuration already enables these
filesystems as modules, they will not get built into the kernel image,
making the system unbootable. We need to call `KCONFIG_SET_OPT` instead
to explicitly set them to be built-in.
Aimee OS/aimee-os/pipeline/head This commit looks goodDetails
It turns out, Buildroot already sets a variable, `LINUX_IMAGE_NAME`,
that holds the name of the Linux kernel image file. Instead of figuring
it out for ourselves (incorrectly, it turns out), we can just use that.
Aimee OS/aimee-os/pipeline/head This commit looks goodDetails
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.
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.
We set the default kernel command-line arguments to tell systemd to
spawn a debug shell on the serial console, instead of the default getty.
This will allow tests to run commands directly on the console, without
any authentication, etc.
The `AIMEEOS_DEFAULT_ROOTFLAGS` kconfig option can be used to set the
default value for the `rootflags` GRUB2 environment variable. The value
of this variable will be passed along as command-line arguments to
whatever kernel is chosen at boot.
Since post-image scripts do not have access to kconfig option values, we
need to build the GRUB2 environment file in the
`GRUB2_INSTALL_IMAGES_CMDS` script fragment instead.
If a value is provided for the `CUSTOM_TARGET` parameter, the specified
target will be built first, before building the filesystem images. This
provides a way to e.g. rebuild a specific package.
Different architectures and/or configurations can use a different name
for the Linux kernel image file. The `gen-grub-cfg.sh` shell script
needs to be able to identify the correct file name in the GRUB
configuration fragment it embeds in the root filesystem image.
U-Boot will not boot without the primary UART console enabled; the Pi
just hangs at the rainbow splash screen. There are three ways to enable
a UART console, but disabling Bluetooth is usually the best, as the
others have performance implications. Applications that need Bluetooth
will have to choose one of the other options, depending on their
specific requirements.
The default U-Boot configuration tries to build tools that depend on
OpenSSL _and_ GnuTLS. We need to enable the corresponding buildroot
configuration options, or the build system will try to use the
system-wide headers and libraries.
At this point, we can generate an SD card image that is composed of an
EFI system partition, a SquashFS root partition (a), a blank root
partition (b), and a data partition. On the EFI system partition are
the Raspberry Pi firmware and device trees, U-Boot and GRUB. The
SquashFS filesystem contains the kernel and the whole filesystem tree.
A Raspberry Pi can successfully boot from an SD card containing this
image. It's not quite usable yet, because there's no writable storage
available, or indeed any way to log in.
Dustin