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?
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?
