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>
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.
bmaptool(1), from the bmap-tools package, can write the used blocks
in a sparse disk image to media, while saving time and I/O by not writing
zeroes to the unused blocks. Typical use:
make raspi2_bullseye.img.bmap raspi2_bullseye.img.xz
... upload those two files ...
... download those two files ...
bmaptool copy raspi2_bullseye.img.xz /dev/disk/by-id/usb-Generic-_SD_MMC_*-0:0
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
Distributing vc4-blacklisted images is a disservice to our users as soon as
vc4+serial work again, and RPi4 is quite often used for desktop or multimedia
tasks.
It now xz compresses the image and then still calculates the sha256 hash
on the non-compressed file. The xz.sha256 target (already) compresses it
and calculates the hash on the xz file.
Signed-off-by: Diederik de Haas <didi.debian@cknow.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.
Cyril Brulebois