Hello Guilhem, Le samedi, 11 janvier 2020, 14.01:53 h CET Guilhem Moulin a écrit : > On Sat, 11 Jan 2020 at 11:56:35 +0000, Didier 'OdyX' Raboud wrote: > > From diffing the initramfs'es, I see that > > kernel/arch/x86/crypto/aes-x86_64.ko was present in 5.3.0-3 kernels, but > > not present anymore in 5.4.0-1 or 5.4.0-2 kernels. > > kernel/arch/x86/crypto/aes-x86_64.ko isn't in 5.4.0-2's module tree. Do > you build the initramfs with MODULES="most", MODULES="dep", or something > else? Looking at the output of > > cut -d" " -f1 /proc/modules | xargs -d"\\n" /sbin/modinfo -F filename | > grep /crypto/ > > before and after (formatting and) opening a cbc-essiv:sha256 device > with > > $ cryptsetup luksFormat --type luks1 --cipher aes-cbc-essiv:sha256 > --hash sha1 /tmp/disk.img <<<test $ cryptsetup luksOpen --debug > /tmp/disk.img test_crypt <<<test > > I see that the ‘essiv’ module (and its dependency ‘authenc’) has been > loaded. Is that module missing from your 5.4.0-2 initramfs? If so, > could you please add it to ‘/etc/initramfs-tools/modules’, re-generate > the initramfs and see if that helps?
It helps. :-) I can confirm that adding 'essiv' at the tail of ‘/etc/initramfs-tools/ modules’ is sufficient to let me unlock my LUKS volume with MODULES="dep"- built initramfs. Thanks for the hint! > Devices formatted since 2:1.6.1-1 (June 2013) use XTS by default and > AFAICT aren't affected. For other devices and when the initramfs is built > with MODULES!="most" I guess we should change populate_CRYPTO_MODULES() so > the ivmode is appended too, not only cipher+chainmode+ivopts. https://sources.debian.org/src/cryptsetup/2:2.2.2-1/debian/initramfs/hooks/ cryptroot/?hl=318#L318 That'd be useful yes! Cheers, OdyX
signature.asc
Description: This is a digitally signed message part.