I’ve been running Fedora 34 pre-release version even before it became beta. Everything has been working so far until recently when a package dracut was updated from 0.58 to 0.58-1. What is dracut? Good question. It’s an initramfs infrastructure used on Fedora system. Find out more from Dracut.

The issue that introduced in version 0.58-1 on F34 is that it prevents any machines that use LUKS encryption for root partition to boot. The issue has been reported here. As of today, there is not yet a fixed version of dracut for F34 yet.

A suggested solution is very simple. We just need to patch a modules.d/35network-manager/nm-run.service as the following:

@@ -2,6 +2,8 @@
 # SPDX-License-Identifier: GPL-2.0-or-later

 #make sure all devices showed up

So here is how I applied the fix on my laptop running F34 with luks encryption.

Fortunately, I still have an old kernel, 5.11.6-300.fc34.x86_64, which was installed when dracut’s version was older than 0.58-1. (I suspect it was 0.58.)

  1. Boot the machine using this working kernel.

  2. Update /usr/lib/dracut/modules.d/35network-manager/nm-run.service to include DefaultDependencies=no under [Unit] as in line 5.

  1 # This file is part of dracut.
  2 # SPDX-License-Identifier: GPL-2.0-or-later
  4 [Unit]
  5 DefaultDependencies=no
  7 #make sure all devices showed up
  8 Wants=systemd-udev-settle.service
  9 After=systemd-udev-settle.service
 11 #pull the network targets into transaction
  1. Regenerate the initramfs. I only want to test it out on kernel-5.11.12-300.
# rpm -q kernel

# dracut --hostonly --kver 5.11.12-300.fc34.x86_64 --force
  1. Then reboot the machine and select 5.11.12-300.

For me, I was able to boot using 5.11.12 instead of getting stuck after typing the luks password as before.

I have a strong feeling that this bug will get fixed soon by Fedora team.

Update (2021-04-10):

  • Fedora just released dracut 0.53-2 with this bug/issue fixed.

Further Reading: