David Zarebski

Well, at this point, hard to say what's going on: I'm not sure what happened during my chroot sessions but it looks like / in now non crypted and the boot options were completely overridden by who know's what verbosity=1 bootlogo=false console=both extraargs=cma=256M overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588-rock-5-itx.dtb rootdev=UUID=92f542d4-5a03-424e-b953-e711111186dc rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u And I can boot without having to luks decrypt. It is probably a side effect of what I mounted in the chroot (/run /sys, etc) but I did not know this was even possible and I would be interested in theories or possible explanations. Thanks to all of you, especially @IBV

lsinitramfs -l boot/initrd.img-6.1.115-vendor-rk35xx | grep dm-mod -rw-r--r-- 1 root root 249464 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/md/dm-mod.ko Looks like it is. Interestingly, when I update-initramfs -u, I do get warning about mdadm (failing to scan array) but I thought that the two issues were unrelated. Could it have an effect on the mapper availability? update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.1.115-vendor-rk35xx W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays. W: mdadm: failed to auto-generate temporary mdadm.conf file.

@IBV good call but it looks good to me lsinitramfs -l boot/initrd.img-6.1.115-vendor-rk35xx | grep crypt drwx------ 2 root root 0 Dec 22 11:35 cryptroot -rw------- 1 root root 69 Dec 22 11:35 cryptroot/crypttab -rwxr-xr-x 1 root root 246 May 4 2025 scripts/local-block/cryptroot -rwxr-xr-x 1 root root 253 May 4 2025 scripts/local-bottom/cryptgnupg-sc -rwxr-xr-x 1 root root 449 May 4 2025 scripts/local-bottom/cryptopensc -rwxr-xr-x 1 root root 1038 May 4 2025 scripts/local-bottom/cryptroot -rwxr-xr-x 1 root root 757 May 4 2025 scripts/local-top/cryptopensc -rwxr-xr-x 1 root root 8150 May 4 2025 scripts/local-top/cryptroot -rwxr-xr-x 1 root root 5686 May 4 2025 usr/bin/cryptroot-unlock lrwxrwxrwx 1 root root 17 Dec 22 11:35 usr/lib/aarch64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0 -rw-r--r-- 1 root root 198664 Jan 16 2025 usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 -rw-r--r-- 1 root root 6302952 Nov 1 12:22 usr/lib/aarch64-linux-gnu/libcrypto.so.3 lrwxrwxrwx 1 root root 24 Dec 22 11:35 usr/lib/aarch64-linux-gnu/libcryptsetup.so.12 -> libcryptsetup.so.12.10.0 -rw-r--r-- 1 root root 603376 May 4 2025 usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.10.0 lrwxrwxrwx 1 root root 20 Dec 22 11:35 usr/lib/aarch64-linux-gnu/libtomcrypt.so.1 -> libtomcrypt.so.1.0.1 -rw-r--r-- 1 root root 919496 Nov 1 2024 usr/lib/aarch64-linux-gnu/libtomcrypt.so.1.0.1 drwx------ 2 root root 0 Dec 22 11:35 usr/lib/cryptsetup -rwxr-xr-x 1 root root 67912 May 4 2025 usr/lib/cryptsetup/askpass -rw-r--r-- 1 root root 26980 May 4 2025 usr/lib/cryptsetup/functions drwxr-xr-x 2 root root 0 Dec 22 11:35 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/arch/arm64/crypto -rw-r--r-- 1 root root 19928 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/arch/arm64/crypto/chacha-neon.ko -rw-r--r-- 1 root root 17128 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/arch/arm64/crypto/poly1305-neon.ko drwxr-xr-x 3 root root 0 Dec 22 11:35 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto drwxr-xr-x 2 root root 0 Dec 22 11:35 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx -rw-r--r-- 1 root root 8424 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx/async_memcpy.ko -rw-r--r-- 1 root root 16520 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx/async_pq.ko -rw-r--r-- 1 root root 8768 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx/async_raid6_recov.ko -rw-r--r-- 1 root root 11400 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx/async_tx.ko -rw-r--r-- 1 root root 14616 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/async_tx/async_xor.ko -rw-r--r-- 1 root root 15616 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/authenc.ko -rw-r--r-- 1 root root 16792 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/authencesn.ko -rw-r--r-- 1 root root 8592 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/echainiv.ko -rw-r--r-- 1 root root 20176 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/essiv.ko -rw-r--r-- 1 root root 9344 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/md4.ko -rw-r--r-- 1 root root 8352 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/michael_mic.ko -rw-r--r-- 1 root root 9352 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/crypto/seqiv.ko -rw-r--r-- 1 root root 84336 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/md/dm-crypt.ko drwxr-xr-x 2 root root 0 Dec 22 11:35 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/lib/crypto -rw-r--r-- 1 root root 5272 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/lib/crypto/libchacha.ko -rwxr-xr-x 1 root root 288448 May 4 2025 usr/sbin/cryptsetup

Thanks for the info about the versioning logic. What I'm trying to achieve is simply to be able to unlock my root partition (Cf explanation in my first post), what I could not do anymore after upgrading to 6.1.115. I do not remember choosing a rolling release distro, used for almost a year until this kernel update broke everything. My update to trixie was simply motivated by the hypothesis that, because of the kernel update, some incompatibility with cryptsetup (resp. dropbear, initramfs.....) might have occurred and could explain this abrupt behavior change. Obviously, it did not but keep in mind that the problem is anterior to any of the changes I realized in the userspace. In a nutshell, my initial problem remains and I still do not get why. Again: the kernel seems compiled with the proper option initramfs points to the proper libraries. Is dm_mod kernel module loaded? cannot use device rootfs name invalid or still in use IYO, is it really a matter of kernel module availability? cryptsetup-initramfs and dropbear-initramfs are available, to my knowledge, UUID are stable entities cat etc/crypttab rootfs UUID=7afe59bd-ca3d-4618-ae75-f2e9b417eb71 none initramfs,luks So I just don't get it. I also just try 6.12 but rollback because my system did not even boot despite of the proper symlinks in the boot partition

So, I chrooted in the system, updated it, used the trixie repos, fixed the NIC issues using a udev rule (aka the unlikely hypothesis) and regenerated the boot image with update-initramfs -u lsinitramfs /boot/initrd.img-6.1.115-vendor-rk35xx | grep cryptsetup usr/lib/aarch64-linux-gnu/libcryptsetup.so.12 usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.10.0 usr/lib/cryptsetup usr/lib/cryptsetup/askpass usr/lib/cryptsetup/functions usr/sbin/cryptsetup I'm now certain that the module is loaded with the proper version but the problem remains. What is going on? Also why, after pointing my apt sources to trixie repos + update and with a kernel v 6.1 (<6.12 current trixie kernel version), does armbian complaining about my system being under Debian forky. I find those multiple layers of versioning pretty confusing.

After my last update on my radxa5-ITX, apart from the name changes of the NIC (related?), I remarked that I could not cryptroot-unlock the root partition because of dm_mod apparently missing from initramfs. To give some context, this is how I set things up some while ago and things went pretty smooth until recently. Too bad armbian does not keep the previous kernel (though I get the reason why). Inspecting the boot partition, cat config-6.1.115-vendor-rk35xx | grep DM_CRYPT CONFIG_DM_CRYPT=m the kernel seems to have been compiled with the proper option and lsinitramfs initrd.img-6.1.115-vendor-rk35xx | grep 'usr.*cryptsetup' usr/lib/aarch64-linux-gnu/libcryptsetup.so.12 usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.9.0 usr/lib/cryptsetup usr/lib/cryptsetup/askpass usr/lib/cryptsetup/functions usr/sbin/cryptsetup and initramfs seems properly linked to the relevant libraries so I do not understand why device mapper remains unavailable. At this point, I have no hypothesis except a very unlikely one An unlikely hypothesis Could failure to initialize the device mapper have nothing to do with dm_mod availability but be solely the side effect of Because I always unlocked the root part either from console or from a dropbear session, I understood device mapper init as an anterior step, independent from NIC availability. But is it really the case. What am I missing?