Without this, the block device holding the root filesystem would be
resolved at the first boot when reconfiguring raspi-firmware (e.g.
/dev/mmcblk1p2) which would then make the system fail to boot if it
ever shows up under a different name (e.g. /dev/mmcblk0p2).
Set ROOTPART parameter explicitly to stick to label-based booting.
The logic wrt /etc/machine-id changed between Buster and Bullseye.
While on Bullseye the file should not exist, on Buster the file must
exist, but be empty, in order to generate a new machine-id on first
boot.
It seems that /var/lib/dbus/machine-id is a symlink to /etc/machine-id
on Buster, while a separate file on Bullseye, so nothing needs to be
done with that file/symlink.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
This is needed to use Debian repos served over https, but also a LOT of
other programs, like reportbug, which want to communicate securely.
Also sorted the list of packages alphabatically as I couldn't find a
reason for the current order and then a logical sort order is better.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
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.
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.
Cyril Brulebois