Regression introduced in f89f71560d2ca1bd60d97dbb26b89782657d56ae:
the sed call modifies /etc/default/raspi-firmware, which used to be
/etc/default/raspi3-firmware; while not ideal, working on
/etc/default/raspi*-firmware shouldn't interfere on unrelated files.
It used to be pulled this way (up to Bullseye), via systemd:
Depends: […] systemd-timesyncd | time-daemon […]
Starting with Bookworm, this was downgraded to:
Recommends: […] systemd-timesyncd | time-daemon
Install it all the time: NTP support is important on Raspberry Pi
devices, which usually don't feature an RTC.
But be careful since Buster had systemd itself provide that feature (no
separate systemd-timesyncd package yet).
Thanks, David Tomaschik!
See 3f9e671fed in the boot-consistency
branch, later adjusted in 2b2bb9d6d7 for
the master branch and the new bookworm builds.
With the pythonize approach, a single change is needed.
Commit 422a0d60 fixed the img.sha256 target itself, but it didn't update
the corresponding clean variant, so add that too.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
(cherry picked from commit 60513d46f6)
Signed-off-by: Cyril Brulebois <cyril@debamax.com>
Commit 26a7de63b0 in master:
/etc/machine-id needs to exist and be empty on buster, while bullseye
needs this file not to exist at all. For now, treat both bullseye and
bookworm the same way.
See https://salsa.debian.org/raspi-team/image-specs/-/issues/57 for
detailed background.
Summary, e.g. on the Pi 4:
- fresh build and first boot means:
console=ttyS1,115200 console=tty0
- after dpkg-reconfigure raspi-firmware has run, with the default
settings:
console=tty0 console=ttyS1,115200
Having some consistency across boots seems desirable (esp. when the Pi
fails to boot and the hints are on a serial console which might not be
wired), so insert the console= parameter for the serial console right
before the root= parameter.
Currently, the /etc/kernel/postinst.d/z50-raspi-firmware hook uses:
${pre_cmdline} root=$ROOTPART […]
and console= parameters are inserted via ${pre_cmdline}, so inserting
the serial console before root= should get us the same results.
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.
For starters, the pattern no longer exists since this commit in
raspi-firmware:
commit dd456f4746a800ac85bdf376b5efcdb1fac133de
Author: Gunnar Wolf <gwolf@gwolf.org>
Date: Wed Aug 5 12:02:57 2020 -0500
Don't set CMA in RPi4 unless specified expressly
and there's now a SET_CMA variable instead.
And more importantly, the Pi 4 gets appropriate treatment thanks to this
commit (empty SET_CMA), which the Pi Compute Module 4 might get soon too
(see #996937).
This commit first shipped in debian/1.20200601-2, and we are using one
of those at the moment for the Pi 4 family:
- 1.20210303+ds-2 (bullseye)
- 1.20210303+ds-2~bpo10+1 (buster-backports)
Commit 422a0d60 fixed the img.sha256 target itself, but it didn't update
the corresponding clean variant, so add that too.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
The RPi 3 wants an extra firmware file which isn't available in normal
Buster, but is available in buster-backports, so install that version of
firmware-brcm80211.
Note that dmesg shows it as an error, but wifi should work without it.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
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>
For (at least) rpi4 Buster target, it gets replaced (again) by a package
from backports, resulting in <pkgname>/backports, making the sed
statement invalid. That isn't the case when using '#' as separator.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Split dynamic target generation across several lines to make the nested
loops more obvious. Backslashes are needed for make to be happy about
what would otherwise be detected as unfinished foreach function calls.
This means the generated recipes are getting two empty lines if there
are no such commands (that's the case for everyone right now), but this
emphasizes the existence of this placeholder, the same way as for its
__EXTRA_ROOT_SHELL_CMDS__ twin.
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.
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.
fakemachine launches a virtual machine reusing the host system's /usr,
and runs commands as root on that virtual machine. It's used by debos,
but can also be used to wrap arbitrary commands, in particular vmdb2;
it's enough to run the parts of vmdb2 that need to mount filesystems
and run apt.
This won't work if fakemachine isn't available (in particular on non-x86),
but that seems better than just failing altogether.
Signed-off-by: Simon McVittie <smcv@debian.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.
Cyril Brulebois