LUKS decryption "Dependency failed" and double password prompt on Fedora 42/43 (NVMe YMTC PC411)

Ask Fedora Common Issues Proposed Common Issues
, , , ,
1

Hi everyone,

I wanted to share a solution for a specific boot issue I encountered in Fedora 42 and 43. If you have an encrypted disk and the system fails to boot after a kernel update, this might be for you.

The Problem

Starting with Fedora 42/43 (Kernel 6.11+), I couldn’t boot normally.

  • The system would ask for the LUKS password twice.
  • After the second entry, it would fail with: Dependency failed for cryptsetup.target.
  • Recovery mode worked perfectly fine.
  • This happened specifically on a YMTC PC411 NVMe SSD.

The Cause

It turns out that newer kernels have more aggressive power management (APST) for NVMe drives. The YMTC controller enters a deep sleep state during the early boot stage (initramfs) and doesn’t wake up fast enough when systemd-cryptsetup requests the key. This causes a timeout and a crash of the decryption process.

The Solution

You need to prevent the NVMe from sleeping too deeply during boot and tell the system to wait longer for the device.

  1. Boot into Recovery Mode (or any working kernel).
  2. Edit your GRUB configuration: sudo nano /etc/default/grub
  3. Add the following parameters to the GRUB_CMDLINE_LINUX line: nvme_core.default_ps_max_latency_us=0 rd.luks.options=timeout=0 rootwait
  4. Update your GRUB config: sudo grub2-mkconfig -o /boot/grub2/grub.cfg
  5. Reboot.

Why this works:

  • nvme_core.default_ps_max_latency_us=0: Disables deep power saving for the NVMe, keeping the controller responsive.
  • rd.luks.options=timeout=0: Forces systemd to wait indefinitely for the password entry instead of timing out.
  • rootwait: Ensures the kernel waits for the asynchronous disk initialization.

I’ve already reported this to Red Hat Bugzilla. Hope this saves someone a few hours of debugging!

P.S.
Just try to remove parameter rhgb (RedHat Graphical Boot) from your GRUB config and it still works as well. Probably plymouth and graphical drivers fight for a component initialization or what? It also doesn’t depend on intel-media-driver installed on your system or not.

In addition, if you want just only cryptsetup password asking with no logs and then see GDM, then just also add plymouth.enable=0.

3 Likes
2

While these steps work it can more easily be done with one command.
sudo grubby --update-kernel=ALL --args='nvme_core.default_ps_max_latency_us=0 rd.luks.options=timeout=0 rootwait'.
grubby manages all the steps you listed, including updating /etc/kernel/cmdline, /etc/default/grub, and all the *.conf files under /boot/loader/entries/

2 Likes
3

I’ve already reported this to Red Hat Bugzilla.

It would be even better if you could report this upstream, then a patch like Making sure you're not a bot! could be made and then it would just work for everyone out-of-the-box – including you when you have to reinstall sooner or later.

3 Likes