Unsure if the chosen severity is appropriate, but this bug renders
affected systems unbootable and the recovery procedure is a serious
headache, so I think this counts as "breaking the whole system".

Steps to reproduce:

* Install Debian Trixie with LUKS full disk encryption. The encryption
  + LVM setup created by D-I works, as does a encrypted root +
  unencrypted /boot setup made using Calamares with a live Debian
  Trixie ISO.
* Boot into the installed system.
* Install `dracut` with `sudo apt install dracut`.
* Reboot.

Expected result: The system should present a passphrase prompt for you
to unlock the disk, upon providing the passphrase the disk should be
unlocked and the system should boot.

Actual result: The system hangs on the Plymouth screen for about 360
seconds. If you attempt to boot with `rd.debug` set, you will see it's
unable to find the root filesystem.

What's happening here, based on my research, is that dracut does not
install the info needed to find the LUKS volume into the initramfs
unless `hostonly=yes` is set. As a result, the initramfs isn't able to
find the encrypted disk, and then of course the system fails to boot.

If you end up with an unbootable system, the recovery procedure requires
booting the system from a live USB, manually decrypting the LUKS volume
with the right name, mounting it, mounting in the boot directory,
bind-mounting in critical other directories, then chrooting in and
regenerating the initramfs that way. It's doable, yes, but it's not
easy, and I believe if you don't specify the right name when decrypting
the disk, you'll probably end up with a broken initramfs when you
regenerate it.

The solution is to set `hostonly=yes` somewhere in Dracut's config in
Debian. This will cause the generated initramfs to be machine-specific;
this can be mitigated by also setting `hostonly_mode=sloppy` so that
additional drivers are installed into the initramfs. That way the
installation is more likely to work if moved between different
computers. See
https://www.man7.org/linux/man-pages/man5/dracut.conf.5.html.

Note, I believe this is the same issue reported by Celejar at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792#75. However,
the root cause of the issue was fundamentally different than that
(already fixed) bug, so I filed a new report.

I discussed this issue upstream and it looks like the current behavior
when using `hostonly=no` may be a bug. See [1]. Setting `hostonly=yes
hostonly_mode=sloppy` might be the wrong thing to do.

[1] https://github.com/dracut-ng/dracut-ng/pull/1238#issuecomment-2814286818

Hi,

there are still ongoing discussions which config should be the
default. Therefore I lower the severity, so we can upload new versions
of dracut, which may improve the situation.

Hello,

I ran into that problem, too. An easier recovery procedure for me was
passing "rd.auto" on the kernel command line.

Also note that dracut 107-1 and later default to host-only operation.

Best regards
Uwe

Hello,

I ran into that problem, too. An easier recovery procedure for me was
passing "rd.auto" on the kernel command line.

Also note that dracut 107-1 and later default to host-only operation.

Best regards
Uwe

I'm using Dracut on my arm64 laptop, configured to decrypt LUKS disks
using systemd-cryptenroll and FIDO2 devices.
It was working till yesterday's update to 108-1.

It looks like after that upgrade dracut stopped respecting hostonly=yes.
$ cat /etc/dracut.conf.d/10.local.conf
hostonly=yes

initramfs is bigger now (26MB instead of previous 19MB).
It is missing etc/cmdline.d/90crypt.conf
and etc/cmdline.d/95root-dev.conf while at the same time contains
much more modules in initrd.img.

Replacing new initrd.img with one generated using 107-2 makes system
bootable.

If this is different issue, I can create new bug.

Best regards.