The 'eatmydata' program is "designed to disable fsync and friends" and
can speed up tasks at the risk of potential data loss.
The speed up is welcome and the data loss not important as it would only
make the pipeline fail (most likely), but you can run it again.
It's unclear (to me) what they filter out. And why.
https://salsa.debian.org/help/ci/yaml/index#only-except says:
"NOTE: only and except are not being actively developed. rules is
the preferred keyword to control when to add jobs to pipelines."
So if filtering is desired, it should be added using the 'rules' keyword
and the reasoning behind it should be clarified in comments and/or
commit messages.
As we're just starting out using CI, it is especially important to be
aware of any failure, so that we can fix it.
Such a workaround can be added later in case it is deemed necessary.
Debian's Salsa team has their own registry of images they maintain, so
use them instead of ones maintained by gitlab.
At https://salsa.debian.org/salsa-ci-team/pipeline/container_registry
one can view the various images they maintain.
Switch to using 'unstable' instead of 'sid'. The idea is to later also
add steps based on 'stable' and then 'unstable' matches better.
It's common to define variables/constants in the top of a file, so do
that here too.
Move 'stage' field directly under step name as it's quite significant
and seen in other salsa-ci.yml as well.
Move 'image' line after 'stage' line as it's quite important as well.
This was the initial trigger for the tag-rename 'operation' as it caused
confusion (with me) as it was also a mislabeled tag, so remove the
ambiguity by renaming it to 'tag-firmware'.
Using path identifiers for tag names causes ambiguity as it's not
(immediately) clear whether a reference to it is a path or a tagname.
This causes hard to read/interpret log files and can lead to subtle and
hard to detect bugs.
The same tag can refer to different things based on the context
(partition/device/mountpoint/etc), so just use the 'tag-' prefix.
On the previous 'mount: /' step, I also added that it's to be mounted on
"dirname: '/'" to make it (more) explicit.
And removed it again as it seems you need to specify both 'dirname' AND
'mount-on' or neither. See https://bugs.debian.org/1023321
The firmware partition holds a copy of the initramfs and the kernel and
over the years we have seen a steady increase in its sizes.
Resizing the firmware partition later on is cumbersome as the root
partition follows directly, so it's better to make the firmware
partition not too small. A size of 508MB should be enough to accommodate
4-5 kernels+initramfs, which seems desirable.
Previously one had to calculate how large the /boot/firmware partition
would be, but expressing it directly in MiB units is much clearer.
This also has the benefit that the /boot/firmware partition's size would
not change if the total image size would be changed.
Such a change should be a deliberate decision and not some side-effect.
As that 'side-effect' did happen since first submitting this patch,
revert the /boot/firmware partition's size back to 300MB.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
The wireless firmware is in the firmware-brcm80211 package, but that is
still in 'non-free', so add 'non-free' back to the sources until all
the needed firmware packages are in 'non-free-firmware'.
https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/36
is where the move to non-free-firmware is proposed, but not yet merged.
Previous commit not only replaced 'non-free' with 'non-free-firmware',
it also removed the 'contrib' archive area from the sources.list.
It added a note about it in the code comments, which I think is the
wrong place. The 'why' of a change belongs in a git commit message,
where one can be as verbose as needed.
Code comments should be used to clarify the 'what' (it does) in case it
would not be immediately obvious.
The removal of 'contrib' totally makes sense though.
We did not use it and 'contrib' and 'non-free' are not part of
(official) Debian, whereas 'non-free-firmware' is now part of Debian
(official media) as a consequence of the change to the Debian Social
Contract following the GR vote.
With this change, we only use what Debian itself would only use.
Fixes: 1ffce8e6bb
When the image was build also determines which package versions got
installed in the generated image and could help explain why a user has
problems with the downloaded image.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
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>
Diederik de Haas