Skipping the LUKS Password Prompt with a Keyfile

Home / Blogs / LUKS keyfile

Skipping the LUKS Password Prompt with a Keyfile

Aug 28, 2026 · disk encryption, Arch, Limine

Goal: hide/skip the LUKS disk-encryption password prompt at boot so the system boots straight to the login screen (SDDM), unlocking the root LUKS volume automatically with a keyfile.

Environment: Omarchy (Arch) with a UKI boot via Limine, Plymouth splash, and the legacy encrypt initramfs hook (HOOKS=... encrypt filesystems fsck).

Important: device naming gotcha

The root OS drive is nvme0n1 (NOT nvme1n1):

Root LUKS partition: nvme0n1p2
ESP (boot): nvme0n1p1

Always reference disks by PARTUUID; the nvme* names can be ambiguous.

1. Recovery key (fallback, always keep)

sudo systemd-cryptenroll /dev/nvme0n1p2 --recovery-key   # -> key slot 1

Recovery key saved separately on paper. Never lose it.

2. TPM token (enrolled but NOT used here)

sudo systemd-cryptenroll /dev/nvme0n1p2 --tpm2-device=auto   # -> key slot 2

Note: the legacy Plymouth + encrypt hook does NOT honor TPM2 tokens (systemd-cryptenroll only helps systemd/sd-encrypt initramfs). The TPM token is inert with this boot stack. The keyfile below is what actually removes the prompt.

3. Keyfile (chosen approach)

Generate a random 4 KiB keyfile on the ESP:

sudo dd if=/dev/urandom of=/boot/cryptkey.bin bs=512 count=8
sudo chmod 600 /boot/cryptkey.bin
# chattr +i not possible: /boot is vfat (FAT32), no immutable attr

Enroll it as a LUKS slot (prompts for a current passphrase to authorize):

sudo cryptsetup luksAddKey /dev/nvme0n1p2 /boot/cryptkey.bin

4. First attempt (ESP-mounted keyfile) — FAILED at boot

echo 'KERNEL_CMDLINE[default]+=" cryptkey=PARTUUID=<esp-partuuid>:vfat:/cryptkey.bin"' \
  | sudo tee /etc/limine-entry-tool.d/cryptkey.conf

The keyfile worked at runtime (cryptsetup luksOpen --test-passphrase --key-file /boot/cryptkey.bin said "Key slot unlocked"), but the encrypt hook still prompted at boot: the legacy hook mounts the ESP too early and silently falls back to the passphrase prompt.

5. Working fix: embed the keyfile inside the initramfs

Copy the key to a root path and add it to the initramfs via a mkinitcpio drop-in:

sudo cp /boot/cryptkey.bin /crypto_keyfile.bin
sudo chmod 600 /crypto_keyfile.bin
echo 'FILES=(/crypto_keyfile.bin)' | sudo tee /etc/mkinitcpio.conf.d/cryptkey.conf

Point the encrypt hook at it:

echo 'KERNEL_CMDLINE[default]+=" cryptkey=rootfs:/crypto_keyfile.bin"' \
  | sudo tee /etc/limine-entry-tool.d/cryptkey.conf

Rebuild the UKI + limine config (so it persists across regenerations):

sudo limine-update
sudo limine-snapper-sync

Verify:

sudo lsinitcpio /boot/EFI/Linux/omarchy_linux.efi | grep crypto_keyfile  # crypto_keyfile.bin
sudo grep 'cryptkey' /boot/limine.conf                                    # cryptkey=rootfs:/crypto_keyfile.bin

Result

Boot no longer asks for the disk-encryption password; the LUKS root volume unlocks from the embedded keyfile inside the UKI/initramfs, and the system goes straight to the SDDM login.

Files / configs changed

File	Change
/etc/mkinitcpio.conf.d/cryptkey.conf	FILES=(/crypto_keyfile.bin)
/etc/limine-entry-tool.d/cryptkey.conf	KERNEL_CMDLINE[default]+=" cryptkey=rootfs:/crypto_keyfile.bin"
/boot/cryptkey.bin	keyfile (enrolled as LUKS slot)
/crypto_keyfile.bin	copy embedded in initramfs

Security tradeoff (read this)

With a keyfile in the initramfs on the ESP, anyone with physical access to the boot media while the machine is off can read the key and decrypt the volume. This only protects against pulling the drive from a powered-off machine. The original passphrase slot and the recovery key (slot 1) still work as fallbacks.

← Back to Blogs · Home

↑ Back to Top