Difficulties booting from luks encrypted root, raspi5, dietpi test image with 2 kernels

[abusr]

Hello,

I've been trying to boot a dietpi test image (with 2 kernels and 2 initramfss) in my raspi5.
No matter what I've tried, I cannot reach the prompt to unlock the cryptrootfs (luks, one partition formatted with ext4). So, kernel panics. Indicatively, in I've tried things in cmdline.txt like:

set root=/dev/mapper/cryptroot, root=UUID=uuid_of_encrypted_partition, root=PARTUUID=part_uuid_of_encrypted_partition, root=UUID=uuid_of_decrypted_partition

set cryptdevice=UUID=uuid_of_encrypted_partition, cryptdevice=PARTUUID=part_uuid_of_encrypted_partition

disabled logo of course

have even tried device names directly. No matter, same.

I have observed cryptsetup is already present in the initramfs. Inside the luks encrypted root my crypttab and fstab are checked to be ok, as I have adapted them from one of the ubuntus I am setting up from time to time. I have tried update-initramfs -u and updateiniramfs -c -k all from chroot, with the (system's I am preparing) boot partition mounted on chroot's /boot/firmware.

No matter what, the kernel panics because it cannot find root device. Am I missing something or is any kind of support missing from the dietpi kernels and is causing so much refusal??

[Joulinar]

or is any kind of support missing from the dietpi kernels

We don't have own kernel on RPi devices, it's the original one provided by RPi foundation.

[MichaIng]

If cryptsetup support was added to the initramfs properly, please also assure the RPi is using it. See /etc/default/raspi-firmware. At least SKIP_INITRAMFS_GEN=no would need to be set, so any /boot/initrd-* is moved to the right place on the boot partition to be loaded by the RPi bootloader.

[abusr]

Back, Happy New Year!

Seems like an initrd/initramfs placement problem. I could not have the produced initrds loaded at all so no initramfs, no askpass, just an infinite hang without a clue what could be going wrong. I was considering such things ditto and solved uptodate and was only focusing what could be going wrong inside cmdline.txt.

So I tested with latest ubuntu which also reproduced the problem (something that I knew as working in 22.04). The remedy for ubuntu was to manually copy/rename the produced initrd (from update-initramfs -c -k all) inside the vfat boot partition so its name matches the name in config.txt. I guess that towards this direction may be the solution for dietpi as well, but as I see you have various scripts and infrastructure built around debian, I don't have the resources to catch_up/follow.

In brief I suggest having a quick check, which inirds, where would these initrds and with which name be and if they are in par with config.txt or its equivalent functionality.

Better if you could press against debian ppl to drop this dual kernel approach and unite the kernels, so we won't be having to keep unnecessary dualities in the systems. Ubuntu as I have fresh seen had a single kernel which booted successfully in rpi5, rpi400 and rpi zero2w I had available for test.

Tia,
abusr.

[MichaIng]

Then SKIP_INITRAMFS_GEN=no as mentioned is all you need. The RPi kernel postinst script will handle the renaming for you on kernel upgrades.

Note that this is a pure RPi thing, unrelated to Debian. RPi decided to use this uncommon kernel and initrd names and require a dedicated boot FAT partition. Their own kernel packages solve it for their users, but for any other distro it is of course a nasty hassle to handle RPis as special cases always, and then other SBC manufacturers joined that in earlier days, instead of following common standards. Debian allows to install multiple kernel versions and matching initrd, and have GRUB to even allow selecting the desired one interactively at boot. Only RPi cannot do that, but requires the kernel to have a particular name, matching default or as defined in config.txt on that boot FAT partition.

But of course this has all been discussed and accepted years ago, so that won't change quickly. However, RPi is swapping more and more drivers, APIs and standards to be closer to what is common on other platforms. The kernel packages are already generated by the Debian build tools (a fork of them) now, hence multiple kernels can already be installed, and are properly named in /boot. Only the firmware is not yet able to lead them like that from a Linux filesystem, but still requires them with different name on the FAT partition. Things change, but slowly.

You can also boot the "DietPi_RPi234-*" images on RPi 5, hence on all 64-bit capable RPi models with a single kernel build. That is not the problem. The dedicated step to copy kernel and bootloader to the FAT partition is still needed, also on Ubuntu.

[abusr]

Yes, this led me search a bit about how this rpi thing really boots. Nonstandard. About SKIP_INITRAMFS_GEN, I tried it right away since proposed but saw no difference. Dual initrds continued to be created in /boot and to be copied to /boot/firmware (the vfat first partition) with simplified names. I was using update-initramfs -k all -c, minus c, to force creation in any case.

And this is what confused me because I fell into supposing that since the inirds were created and copied with simplified names inside the /boot/firmware vfat, that some script was orchestrating the entire procedure including setting them up for boot as well. Which was not the case and I had futilely focused in cmdline.txt, recalling it as the only place needed to intervene for ubu22 cryptroot.

So this explains it all and closes the case. Many thanks for your time and immediate responses. The solution for the rpis' way of booting is an intermediate, ro mostly, sdcard with some proper efi or grub based thing upon, which could then selectively boot whatever partition from whatever hdd. I greatly agree with you against adhoc implementations, while we have wandered for decades for a bit of a standard on systems' boot.

abusr.

[MichaIng]

See /etc/initramfs/post-update.d/z50-raspi-firmware, and check whether you see some output of this script. If there is any /boot/initrd.img-*-rpi-*, that script would copy the latest of those to the FAT partition (in case it is mounted).

If this does happen, and there is hence a /boot/firmware/initramfs_2712 (for RPi 5 kernel), then indeed it should be used automatically. No other config change is needed for this, same like /boot/firmware/kernel_2712.img is used automatically by the firmware, being the default names for those.