DM_CRYPT module unavailable in initramfs after update to 6.1.115

[David Zarebski]

 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?

Edited December 14 by David Zarebski

[David Zarebski]

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.

Edited 1 hour ago by David Zarebski

[Werner]

11 minutes ago, David Zarebski said:

confusing

I am confused as well by getting a clue what you are trying to do

Kernel and userspace are independent in Armbian. You can use any userspace (Ubuntu Jammy, Noble, Resolute, Debian Bookworm, Trixie, Forky, Sid) with any kernel package. Latter is always the same.

 

Rockchip RK3588 is a bit special in terms of kernel versions. Let me give you brief overview.

6.1.y is a based on Rockchip BSP kernel which is close to feature-complete but a bit outdated.

6.12.y which is currently our current branch and was the latest mainline LTS kernel until a few days ago. However at the time this was released a bare minimum of drivers were merged into this version

6.18.y (or soon 6.19-rcX) is edge and has a lot more hw features merged into but still isn't feature-complete. Collabora is working on that like crazy.

 

16 minutes ago, David Zarebski said:

, after pointing my apt sources to trixie repos

Userspace upgrades are neither tested nor supported by Armbian. Not because we don't want but because we don't have resources to test all kinds of scenarios for dist-upgrades.

[David Zarebski]

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