This system has been booting with a dracut-generated initramfs for several years. i ran into some trouble with the systemd 256 transition, but that was resolved. today, i tried to reboot and found that the dracut-generated initramfs was unable to find cryptsetup in a way that would unlock the local encrypted disk. I do not have systemd-cryptsetup installed, but i do have cryptsetup installed, and the root filesystem is derived from an LVM logical volume extracted from an lvm physical volume based on a dmcrypt LUKS volume. I've now uninstalled dracut and moved to initramfs-tools. while the initramfs-tools-generated initramfs is twice the size of the dracut-generated initramfs, it does contain the utilities i need to get the system to boot again. I'm willing to debug further if it would help. This was a pretty nasty failure, as it made the machine completely unbootable.
Using lsinitrd /boot/initramfs.... you can check which dracut modules are available in the initrd. Following modules are available for crypt stuff: crypt systemd-cryptsetup crypt-gpg crypt-loop Maybe you have to add some of these modules into dracut config. Adding rd.debug during booting the initrd would give you a lot of debugging (like set -x in shell) output.
Hi Thomas-- thanks for the suggestions! some comments below: That doesn't matter for this system any more, as i've moved from dracut back to initramfs-tools, and i actually need to get some work done with the system at the moment so i can't keep rebooting it. I also don't understand enough about dracut to know how to ensure those modules are loaded; i'd expect dracut to be able to autodetect that the system needs cryptsetup for the root volume to work, and to include them by default. it used to work by default, and i don't think the answer is that the sysadmin should need to update their configuration files in order to reboot safely. Regards,
Hi Thomas, dkg, I also got bit by this one today. Looking at the generated initrds, they look like they have the necessary information in them -- I've attached the lsinitrd for the record, but the modules I'd expect to be there are there (i.e., crypt, lvm, systemd-cryptsetup, tpm2-tss). I don't actually get a password prompt at all, and setting hostonly to either parameter doesn't work, so I think the problem has to do with the way disks are being detected. I'm curious, dkg, how do you have your disks specified in the kernel_cmdline config -- and do you have hostonly set to yes or no? I'd also love to get a copy of the output of blkid from you; were you using the magic UUIDs? Sincerely,
tag 1074609 +patch, +upstream thanks Hello all, Quick update on this; I tracked the problem down to an upstream decision to stop decrypting encrypted devices by default ( https://github.com/dracut-ng/dracut-ng/commit/39eacd9223f2e8c14c76cbe885789a84df36a29b). It looks like they introduced decrypting by default in v102, then removed it in v104. We skipped straight from an old version (v60) all the way up to 102, so the behavior didn't change even though technically it was new to dracut-ng. Patch attached which simply reverts the reversion. I've tested this and it appears to work for me. I mentioned to upstream that this was the problem in their Matrix channel, but it should probably be sent up as an official bug. Thomas, would you like me to take care of that, or do you want to do the coordination with them? (Happy to help, but don't want to step on your toes!) Sincerely,
Just adding some more info and links here... Unless I'm mistaken, this is basically bug #1029324: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029324 Which was also reported upstream: https://github.com/dracutdevs/dracut/issues/2437 Fixed here: https://github.com/dracut-ng/dracut-ng/commit/2339acfaeee60d6bb26a1103db2e53bc8f9cb2d1 And then the fix was reverted here: https://github.com/dracut-ng/dracut-ng/commit/39eacd9223f2e8c14c76cbe885789a84df36a29b The situation is still a *bit* better than it was back when I submitted #1029324, using a test installation in qemu, doing the "normal" root-on-LVM-on-LUKS installation, and then switching from initramfs-tools to dracut, the only fix that's necessary to keep booting is to add "rd.auto=1" to the list of boot arguments (e.g. to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub).