overlayroot package does not build initrd

[CarlFK]

expected:

Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-20-amd64

guessing bacause dpkg-trigger update-initramfs;; https://git.launchpad.net/ubuntu/+source/cloud-initramfs-tools/tree/debian/overlayroot.postinst

On Raspios Processing triggers for initramfs-tools (0.140) ... but then doesn't seem to do anything.

commands and output on raspi:

wget -N http://http.us.debian.org/debian/pool/main/c/cloud-initramfs-tools/overlayroot_0.18.debian11_all.deb

krakenrf@krakensdr:~$ sudo apt install ./overlayroot_0.18.debian11_all.deb 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'overlayroot' instead of './overlayroot_0.18.debian11_all.deb'
The following additional packages will be installed:
  cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run
Suggested packages:
  haveged
The following NEW packages will be installed:
  cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run overlayroot
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 761 kB/776 kB of archives.
After this operation, 2,902 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 /home/krakenrf/overlayroot_0.18.debian11_all.deb overlayroot all 0.18.debian11 [15.2 kB]
Get:2 http://deb.debian.org/debian bullseye/main arm64 cryptsetup-bin arm64 2:2.3.7-1+deb11u1 [407 kB]
Get:3 http://deb.debian.org/debian bullseye/main arm64 cryptsetup arm64 2:2.3.7-1+deb11u1 [228 kB]
Get:4 http://deb.debian.org/debian bullseye/main arm64 cryptsetup-initramfs all 2:2.3.7-1+deb11u1 [72.5 kB]
Get:5 http://deb.debian.org/debian bullseye/main arm64 cryptsetup-run all 2:2.3.7-1+deb11u1 [54.4 kB]
Fetched 761 kB in 0s (2,807 kB/s)         
Preconfiguring packages ...
Selecting previously unselected package cryptsetup-bin.
(Reading database ... 42070 files and directories currently installed.)
Preparing to unpack .../cryptsetup-bin_2%3a2.3.7-1+deb11u1_arm64.deb ...
Unpacking cryptsetup-bin (2:2.3.7-1+deb11u1) ...
Selecting previously unselected package cryptsetup.
Preparing to unpack .../cryptsetup_2%3a2.3.7-1+deb11u1_arm64.deb ...
Unpacking cryptsetup (2:2.3.7-1+deb11u1) ...
Selecting previously unselected package cryptsetup-initramfs.
Preparing to unpack .../cryptsetup-initramfs_2%3a2.3.7-1+deb11u1_all.deb ...
Unpacking cryptsetup-initramfs (2:2.3.7-1+deb11u1) ...
Selecting previously unselected package cryptsetup-run.
Preparing to unpack .../cryptsetup-run_2%3a2.3.7-1+deb11u1_all.deb ...
Unpacking cryptsetup-run (2:2.3.7-1+deb11u1) ...
Selecting previously unselected package overlayroot.
Preparing to unpack .../overlayroot_0.18.debian11_all.deb ...
Unpacking overlayroot (0.18.debian11) ...
Setting up cryptsetup-bin (2:2.3.7-1+deb11u1) ...
Setting up cryptsetup (2:2.3.7-1+deb11u1) ...
Setting up cryptsetup-run (2:2.3.7-1+deb11u1) ...
Setting up overlayroot (0.18.debian11) ...
Setting up cryptsetup-initramfs (2:2.3.7-1+deb11u1) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for initramfs-tools (0.140) ...
krakenrf@krakensdr:~$ 

krakenrf@krakensdr:~$ ls /boot
 bcm2708-rpi-b.dtb          bcm2711-rpi-cm4s.dtb   kernel8.img
 bcm2708-rpi-b-plus.dtb     bootcode.bin           kernel.img
 bcm2708-rpi-b-rev1.dtb     cmdline.txt            LICENCE.broadcom
 bcm2708-rpi-cm.dtb         config.txt             overlays
 bcm2708-rpi-zero.dtb       COPYING.linux          start4cd.elf
 bcm2708-rpi-zero-w.dtb     fixup4cd.dat           start4db.elf
 bcm2709-rpi-2-b.dtb        fixup4.dat             start4.elf
 bcm2710-rpi-2-b.dtb        fixup4db.dat           start4x.elf
 bcm2710-rpi-3-b.dtb        fixup4x.dat            start_cd.elf
 bcm2710-rpi-3-b-plus.dtb   fixup_cd.dat           start_db.elf
 bcm2710-rpi-cm3.dtb        fixup.dat              start.elf
 bcm2710-rpi-zero-2.dtb     fixup_db.dat           start_kraken.sh
 bcm2710-rpi-zero-2-w.dtb   fixup_x.dat            start_x.elf
 bcm2711-rpi-400.dtb        issue.txt             'System Volume Information'
 bcm2711-rpi-4-b.dtb        kernel7.img            wpa_supplicant_example.conf
 bcm2711-rpi-cm4.dtb        kernel7l.img

krakenrf@krakensdr:~$ grep initramfs /boot/config.txt
(nothing)

My workaround: update-initramfs -c -k "${KERN}"

https://github.com/CarlFK/pici/blob/main/ansible/roles/onpi/files/install_overlayroot.sh

[mithro]

https://wiki.debian.org/DpkgTriggers might be useful....

[mithro]

update-initramfs: Triggers are supported from version 0.92 on.

[mithro]

Setting up cryptsetup-initramfs (2:2.3.7-1+deb11u1) ...
update-initramfs: deferring update (trigger activated)                          <------ ?????
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for initramfs-tools (0.140) ...

[CarlFK]

from #raspberrypi irc waveform:

/usr/bin/linux-version list (nothing)

okay, I think (just double checking with the code as linux-version's just perl) it's because raspios has a rather weird kernel setup (at least from a debian perspective)... linux-version's expecting to find /boot/vmlinuz-KVER files but on raspios the raspberrypi-kernel package installs several kernel images named /boot/kernel[678].img (which aren't different kernel versions but variants for different pi boards) so on raspios, the only way to run update-initramfs is to explicitly specify a kernel version which also means the dpkg-trigger for update-initramfs isn't going to operate correctly there

in other words, your workaround is the "correct" way of doing this on raspios currently

raspios could patch update-initramfs (or more precisely the initramfs-tools package) to work correctly; they already patch quite a lot of stuff from debian (though not initramfs-tools currently)

it potentially breaks people's initrds on kernel upgrades that would make it a valid bug (at least in my eyes; the counter-argument would be that raspios doesn't use an initrd by default, and the only circumstance in which it does, with overlayroot, the rootfs is read-only anyway so kernels won't be updated) still, it's a worthwhile case to make I think

[CarlFK]

raspi-config workaround: update-initramfs -c -k "$KERN" https://github.com/RPi-Distro/raspi-config/blob/master/raspi-config#L2686

[CarlFK]

on RaspiOS: when apt-get upgrades the kernel, it doesn't update the initrd. and so things break on the next reboot.

I think there are 2 things I need to fix:

1. update-initramfs -k "all" need to work, likely by patching linux-version list to work with RaspiOS's kernel versioning
2. config.txt needs "initramfs = initrd.img-5.15.84-v8+"

I don't think there is anything in Raspios to handle config.txt updates, other than

# modify config.txt
  sed -i /boot/config.txt -e "/initramfs.*/d" ;
echo initramfs "$INITRD" >> /boot/config.txt

which takes the place of Debian's update-grub

[CarlFK]

On Debians:

$ linux-version list
3.13.0-141-generic
4.19.0-12-amd64
4.19.0-16-amd64
5.10.0-20-amd64

On RaspiOS:

$ linux-version list
(nothing)

$ dpkg -S /boot/kernel.img 
raspberrypi-kernel: /boot/kernel.img

$ dpkg -L raspberrypi-kernel | grep "/lib/modules/[^/]*/kernel$" | grep --only-matching -P "\d[^/]*"
5.15.84+
5.15.84-v7+
5.15.84-v7l+
5.15.84-v8+

Implementation:

1. create 4 initrd files with the same pattern as the existing /boot/kernel*.img pattern.

2. add support for all 4 to config.txt i think you have to list every single model, and point p0 and pi1 to the same armv6 initrd

   $ ls /boot/k*
   /boot/kernel7.img  /boot/kernel7l.img  /boot/kernel8.img  /boot/kernel.img
   
   [pi1]
   initramfs=initrd.img
   [pi2]
   initramfs=initrd.img

[shadowcat-mst]

Given update-initramfs is heavily reliant on the standard debian approach to naming images in term of constructing filenames from the versions it's given, and even more so on the idea that different kernels will be installed with different file names, raspbian having thrown that entire structure out the window in favour of directly overwriting the current kernel image with the new one on upgrade makes things a little tricky.

It seems to me extremely unlikely for it to be possible to work around in the tools themselves without adding so much extra code that it would probably be less of a maintenance burden to simply fork it.

I'd suggest, though, that given the kernel image name is effectively hard-coded per system, the raspi-config approach would be far less intrusive in terms of vendor patching, seems like the best you're going to get, and the right place to patch this would be in the rasbpi package so it arranges to call update-initramfs with those arguments automatically.

[CarlFK]

overlayroot added to debian, flowed into raspi.