sfdisk is a bit crusty - it doesn't understand gpt partition tables very well,
for example. By switching to parted, we can handle gpt issues (which may be
useful in the future, and is definitely useful for other boards), and we no
longer have to hardcode that 4M alignment workaround. Parted will tell us
the free space at the end of the disk.
Because we're already using partprobe, there's no additional dependencies
needed.
Switch away from using a systemd service for the initial root resize.
Instead, we resize the root partition and filesystem in the initrd.
To simplify things, the initrd script will check whether it should resize
the partition on every boot. It does this by checking if the entire disk
(ignoring an empty 4MB) is in use. However, the scripts themselves are
deleted from the system after the initrd is generated. After the image
is installed, the resize script should exist only in the initrd. When the
kernel gets upgraded (eg, for a security update) or a new initrd is generated
due to a package install, the new initrd will not contain the resize script.
At that point, nothing will remain from the image's initial resize
bootstrapping process.
This process (but not the scripts) is similar to what cloud-initramfs-growroot
does. However, that particular package has an indirect dependency on Python,
and we don't necessarily want that overhead in our images just for resizing.
rpi-reconfigure-raspi-firmware.service requires /boot/firmware to be
mounted, but mounting local filesystems requires local-fs-pre.target,
so trying to run rpi-reconfigure-raspi-firmware.service before
local-fs-pre.target results in a cyclic order dependency. systemd
breaks the cycle in an arbitrary place, and the result is unlikely to be
what we want.
Instead, delay reconfiguration of config.txt until after local
filesystems are mounted, but before sysinit.target. This breaks the cycle
(image-specs#49).
This still orders it before all non-early-boot services, because
sysinit.target is part of the DefaultDependencies; so in particular
it will finish before rpi-generate-ssh-host-keys.service starts, which
avoids the two services fighting over the dpkg lock (image-specs#45).
Resolves: image-specs#45
Resolves: image-specs#49
Signed-off-by: Simon McVittie <smcv@debian.org>
Why almost? Because Rpi0w uses ttyS1 instead of ttyAMA0 desipte being part of the RPi1 family...
...But it will work fine for the _second_ boot onwards, if things go according to plan.
For all other RPi models, it should work from the first boot on.
Andres Salomon