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>
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>
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>
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.
The broadcom wifi driver needs NVRAM data in order to work. Manually
grab upstream's board-specific NVRAM file for now, until we can get
it added to the firmware-brcm80211 package.
This allows you to run "make raspi_4.img" and create a raspberry pi 4
image. It doesn't yet add pi 4 to the list of images that are autobuilt.
We're pulling the latest kernel and raspi3-firmware in order to get pi4
support (which was added in Linux 5.5). We're also working around a bug
where cma= stops the 5.6 kernel from booting (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951744#10).
This is based on Lucas Nussbaum's initial yaml.
Create a variable called BUILD_PLATFORMS that lists the various pi images
to build. This keeps the platform list in one place in the makefile, rather
than sprinkled and repeated throughout multiple dependency and build lines.
When a platform is added (ie, the pi4) or removed, it won't touch multiple
rules and obscure other changes. This uses gmake-specific addprefix and
addsuffix.
Gunnar Wolf