Hi, @Marko tl;dr: it's going a bit offtopic. Marko, try to hardcompile those modules into your kernel. This should be the simplest fix of your problem.
On 04/18/2015 02:44 PM, Heiko Baums wrote: > Am 18.04.2015 um 14:12 schrieb Ralf: > >> No. Could you please explain why you think so? >> Even if your root partition is encrypted, your ramdisk could load the >> modules. > Are you sure about that? Are you sure that the necessary modules are > definitely put into the initrd and that the kernel will be able to load > them soon enough at boot time? I double checked it and now I am sure: For reasons of comfortability I inspected a standard Arch-Linux installation. It supports rootfs encryption and xts is loaded in the initrd as module. So it is possible to treat it as a module. Besides that: Why should your kernel config allow you to compile it as module if it isn't useable as module? > > Compiling those modules into the kernel is definitely more secure (in > terms of being sure that they are always available) and doesn't do any > harm, because they need to be loaded anyway. Yes for a homebrew kernel, i can second that. > > Btw., several dm-crypt/LUKS documentation (all that I've read) say that > those modules have to be compiled into the kernel directly. > >> After loading the modules you can see that they are available by cat >> /proc/crypto. > You won't be able to run this command when the kernel tries to unlock > the LUKS container at boot time. No, but it is accessible when creating your LUKS volume, and that's Marko problem at the moment. > >> The modules can be loaded _after_ bootup as well. > If you want to unlock the LUKS container at boot time (particularly if > your root partition is encrypted), loading the modules after bootup is > too late. Loading those modules during the early bootup phase in your initrd is actually not too late. Ah, and for completeness sake: Grub2 is able to speak LUKS. So your kernel and initrd maybe inside an encrypted volume. > > So I wouldn't risk it. Neither do I. Cheers Ralf
