Encrypted root cannot be unlocked during boot · Linux Fix Lab

Symptoms & scope

A known passphrase is rejected only at early boot.
The initrd reports an unavailable keyfile or cannot create the expected encrypted mapping.

Relevant environment

LUKS-encrypted Linux root using cryptsetup/systemd-cryptsetup, possibly with a keyfile, TPM or hardware token in the early boot path.

Recognizable messages (synthetic examples)

systemd-cryptsetup[400]: Failed to activate with specified passphrase.

Inspect the surrounding error and device identity; this message alone does not prove an incorrect password or header damage.

systemd-cryptsetup[400]: Failed to activate with key file '/run/keys/root.key': No such file or directory

Verify early-boot file inclusion and source device availability; do not publish the keyfile or recreate the encrypted volume.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

The early keyboard layout, selected container or cached credential may differ from the normal session.
A missing token/keyfile, changed TPM measurement or absent cryptsetup integration can prevent automatic unlock; none of these proves lost encrypted data.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace /dev/nvme0n1p3 with the verified encrypted container. This reads header metadata and normally requires administrator device access; never add a volume-key dump option.

cryptsetup luksDump /dev/nvme0n1p3

Interpret the result: Check LUKS UUID, version, keyslots and token metadata. A valid header does not test the supplied secret, and an inner filesystem UUID is a different identity.

Check 2

Read the affected installation’s crypttab from a recovered or rescue environment; this file can contain paths to sensitive key material, not the key contents itself.

cat /etc/crypttab

Interpret the result: Compare container UUID, mapping name, key source and initrd options with the failing prompt. The live environment’s crypttab is not authoritative for the installed system.

Evidence-guided next steps

Use a known interactive recovery secret

If automatic unlock fails, use an already enrolled passphrase or recovery key through the distribution’s normal fallback prompt after checking keyboard layout and target container. If it works in rescue but not early boot, correct the early keymap/configuration.

Precautions: Never type the secret into logs or chat, and do not remove keyslots, erase TPM enrollment or run luksFormat to solve an unlock failure.

Recovery / rollback: Restore the previous keymap or unlock source configuration; existing enrolled credentials remain the recovery path.

Did this solution help you?

Share this solution #

Restore the required key source and initrd integration

If the error identifies a missing keyfile/device or token path, restore that source through the documented encrypted-boot setup and regenerate the specific initramfs after verifying its inclusion rules. For TPM changes, recover interactively before planning documented re-enrollment.

Precautions: Keep a header backup and a verified independent unlock method available before modifying enrollment. Never make a keyfile broadly readable to bypass a boot problem.

Recovery / rollback: Boot the retained initramfs and restore its crypttab/key-source configuration if the new automatic path fails.