This is not a definitive survey, but things are looking much better!
+--------------------------------+------+------+
| Image type | Old | New |
+--------------------------------+------+------+
| PiRogue-OS-12-Pi3_and_Pi4 | 491M | 255M |
| PiRogue-OS-12-Pi5-Experimental | 594M | 313M |
+--------------------------------+------+------+
That script is deployed in a VM maintained by DEBAMAX, initially building
and publishing raspi_4_bookworm.img.xz(.sha256) every Monday below:
https://pirogue.apt.debamax.com/raspi-images/
Given a RASPBERRYPI_IMG_URL, this automates downloading the image and
its checksum, validating it, then modifying it to generate two images:
- PiRogue-OS-12-Pi3_and_Pi4
- PiRogue-OS-12-Pi5-Experimental
Those are then compressed, checksums are generated, and the resulting
4 files are listed in a MANIFEST.txt file at the top-level, making it
trivial to publish the relevant files.
At least for the time being, no clean-up is performed. That means the
original image can be used to run ./toaster again if a new development
iteration is required.
Another way could be to install the Raspberry Pi kernel first, compare
the contents of the initramfses for the Debian and the Raspberry Pi
kernels, and fix the missing files in the latter. Duplicating hook and
script seems a little more straightforward.
For the time being, let's keep both Pi 3/Pi 4 and Pi 5 recipes separate,
making it easy to modify the latter freely. Later on, it will probably
make sense to have a common section.
Let's *disable* ssh.service to make sure it doesn't start too soon, and
modify the rpi-generate-ssh-host-keys.service unit (that triggers the
generation during the first boot) to enable+start ssh.service when
everything is ready.
See: https://salsa.debian.org/raspi-team/image-specs/-/issues/72
The original image leads to repeated failures to start for sshd.service
since there are no host keys initially. Make sure the unit in charge of
getting those keys generated runs before sshd.
The following block gets repeated otherwise:
systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
sshd[795]: sshd: no hostkeys available -- exiting.
systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: ssh.service: Failed with result 'exit-code'.
systemd[1]: Failed to start ssh.service - OpenBSD Secure Shell server.
systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
It's a matter of habit more than an absolute technical requirement.
Quoting the useradd manpage:
useradd is a low level utility for adding users. On Debian,
administrators should usually use adduser(8) instead.
The default SSH configuration is Debian 12 is as follows:
#PermitRootLogin prohibit-password
#PermitEmptyPasswords no
(The default values are commented out, ready to be tweaked by local
admins.)
It's pretty standard to have 127.0.0.1 match localhost while the actual
machine's name (FQDN and hostname) matches 127.0.1.1 instead.
We would be happy to be told if something similar exists for IPv6!
This is a tiny shell wrapper developer by DEBAMAX for a customer, making
it possible to tweak amd64 and arm64 system images: they are duplicated
first, their partitions are mounted, and the contents can be modified at
will.
This makes it possible to move fast, as the original images don't need
to be built again to test modifications. For the PiRogue Tool Suite
project, that means we can focus on modifying Debian-provided images
instead of building them from scratch.
At the moment, support for partition tables is pretty basic, the second
partition is the root filesystem, the first partition might be mounted
on /boot/firmware (arm64 images for Raspberry Pi) or on /boot/efi (amd64
images for 64-bit PCs).
If we end up using this tool for Cloud images, at least that part will
require some modifications.
