Group raspi-firmware and firmware-brcm80211 together, and make the
firmware package a regular list item in the master YAML file (making
editors happy about it).
Of course, this means that in all generated recipes, linux-image and
raspi*-firmware switch places.
This is a proof of concept rather than an ideal, final situation.
It can be used this way:
for v in 1 2 3 4 ; do
for s in buster bullseye; do
./generate-recipe.py $v $s
done
done
and it has been verified to produce very similar results compared to the
existing many-sed approach.
Differences are as follows:
- Missing newline after some backports stanza, due to the removal of
the other APT line. There's already MR#51 that aims at fixing some
newline-related issues anyway, so this can be addressed separately.
- Less schizophrenia in the generated sources.list for buster/4, as we
are now only showing a reason for enabling the backports, instead
of starting by explaining why backports are disabled by default.
- Dropping APT::Default-Release = buster in the buster/4 case, which
is no longer needed as we are pulling things from buster-backports
rather than pulling them from unstable (see 57e90df103).
- No longer trying to fix the firmware package name by throwing a
broken sed at rpi-reconfigure-raspi-firmware.service in the buster/4
case: the syntax was buggy and fixing it would have made us try to
replace raspi-firmware with raspi-firmware/buster-backports, while
the correct thing to do is to not touch it in the first place
(raspi-firmware is the correct name for the firmware package, pulled
from buster-backports).
As a side effect, this transforms the existing __EXTRA_SHELL_CMDS__ into
a slightly more explicit __EXTRA_ROOT_SHELL_CMDS__ which now has its
__EXTRA_CHROOT_SHELL_CMDS__ twin. That's the entry point that was
missing and made 45cb5619d4 necessary in the past.
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