GRUB-stage LUKS passphrase prompt not accepting any input

Support
, ,
1

Hey all,

Stuck trying to boot my Manjaro setup (Lenovo laptop, LUKS-encrypted disk, BTRFS with Timeshift snapshots).

2 issues, posting both since they might be linked or might not be.

Issue 1: Double passphrase prompt, second one just doesn’t work

After picking my boot entry in GRUB, I get asked for the LUKS passphrase twice, at 2 different stages:

  1. First prompt: Enter passphrase for hd0,gpt2 (e3eb537b-72bc-...), this is GRUB’s own cryptomount, before the kernel loads.
  2. Second prompt: Enter passphrase for /dev/disk/by-uuid/782ef7a4-..., this is the later systemd-cryptsetup prompt, after the kernel/initramfs loads.

The problem: at the 2nd prompt, typing anything and hitting Enter does nothing. No re-prompt, no error, no progress, it just sits there.

At the 1st GRUB prompt at least something happens (I get an actual “Invalid passphrase” message when it’s wrong), but at the 2nd prompt nothing happens no matter what I type, correct passphrase or pure gibberish, same result either way: nothing.

Issue 2: Some Timeshift BTRFS snapshots won’t boot anymore

I used to be able to fall back on a known-working Timeshift snapshot from GRUB’s snapshot submenu, but some of them aren’t working anymore either.

Trying to boot snapshot 2026-05-28_03-27-38 (tried both the 6.19 and 6.18 kernel entries in it) gives:

error: fs/btrfs.c:find_path:1890:file `/timeshift-btrfs/snapshots/2026-05-28_03-27-38/@/boot/vmlinuz-6.19-x86_64' not found.
error: loader/i386/linux.c:grub_cmd_initrd:1082:you need to load the kernel first.

So right now I don’t have a confirmed working fallback, which is the part that worries me the most.

Questions:

  • Any idea why the 2nd passphrase prompt (systemd-cryptsetup) would stop taking any input at all, not even rejecting it, just doing nothing, when the first GRUB prompt is at least responsive?

  • Could this be some known interaction between GRUB’s cryptomount unlocking the boot partition and systemd-cryptsetup unlocking root, where it gets stuck at that second stage specifically?

  • For the snapshot issue, is this the known thing where /boot isn’t part of the snapshotted subvolume, or did the kernel just get removed from disk since the snapshot was taken? Is there any way to still boot that snapshot, like pointing it at a kernel that actually exists on disk?

  • Given my main boot is stuck and at least one snapshot fallback is also broken, what’s the safest way to recover here? Chroot from a live USB to fix grub.cfg/initramfs, or something else first?

2

Figured it out, writing this up in case anyone else hits the same thing.

What was actually wrong

The 2nd passphrase prompt wasn’t for root, it was for SWAP. And the auto-unlock path for swap was never actually wired up to run.

My setup:

  • nvme0n1p2 (e3eb537b): encrypted root
  • nvme0n1p3 (782ef7a4): encrypted swap
  • A /crypto_keyfile.bin was supposed to auto-unlock both
  • /etc/crypttab listed both pointing at the keyfile

What I missed: mkinitcpio’s encrypt hook only reads cryptdevice= from the kernel command line, it does NOT read /etc/crypttab. So during initramfs, only root (which had cryptdevice= in my GRUB cmdline) was getting unlocked. Swap was being kicked to systemd-cryptsetup later in boot, which tried the keyfile but couldn’t reach it (initramfs already torn down), and just hung silently instead of prompting properly. That’s why GRUB prompts worked but the later prompt was dead.

On top of that I had a separate issue I hit while debugging: kernel 7.0 was hanging at “Hold until boot process finishes up” on every boot (some post-Docker systemd job that doesn’t finish on that kernel on my hardware). 6.18 worked fine. So I dropped 7.0 too.

For the broken snapshot boot entries (the original Issue 2): those were a known thing, the snapshot’s GRUB entry references whatever kernel version was current at the time. Uninstall that kernel later and the entry points at a non-existent file. The 2026-05-28 and 2026-06 snapshots were broken this way (referenced 6.19 which was no longer installed). The older March snapshots were fine.

The fix

Two options for the swap issue:

  • (a) add swap to the cryptdevice= kernel param so mkinitcpio handles it the same way as root
  • (b) drop swap encryption entirely

I went with (b) since the auto-unlock design was already fragile.

The trick that took me forever to figure out: you can’t do the edits from the snapshot boot. When booted into a Timeshift snapshot, /etc/... is the snapshot’s copy, not your real @ subvolume. Edits go to the snapshot’s fork and don’t survive a reboot into the real system. You have to mount real @ separately and chroot into it.

So the actual sequence is: boot a working snapshot → mount real @ from there → chroot → fix configs and rebuild → reboot.

Commands (chrooted from a working snapshot)

Phase 1: from the snapshot, diagnose + drop swap encryption

# what kernel + config state
mhwd-kernel -li
ls /boot
sudo blkid | grep crypto_LUKS

# current config
sudo cat /etc/crypttab
grep -i cryptdevice /etc/default/grub
ls -la /crypto_keyfile.bin
grep -E "^FILES" /etc/mkinitcpio.conf
grep -E "^HOOKS" /etc/mkinitcpio.conf

# confirm keyfile is a valid slot for the swap partition
sudo cryptsetup open --test-passphrase --key-file /crypto_keyfile.bin /dev/nvme0n1p3 && echo OK || echo FAIL

# turn off swap and tear down its LUKS layer
sudo swapoff -a
sudo cryptsetup close luks-782ef7a4-eaf4-4355-af38-3065acab082a 2>/dev/null

# wipe the LUKS header and reformat as plain swap (note the new UUID mkswap prints)
sudo wipefs -a /dev/nvme0n1p3
sudo mkswap /dev/nvme0n1p3

# remove the swap LUKS line from /etc/crypttab
sudo sed -i '/782ef7a4/d' /etc/crypttab

Phase 2: mount real @ subvolume and fix configs there

sudo mkdir -p /mnt/realroot
sudo mount -o subvol=@ /dev/mapper/luks-e3eb537b-72bc-47fb-8d9f-a6396be77f16 /mnt/realroot

# find every leftover reference to the old encrypted swap UUID
grep -r "782ef7a4" /mnt/realroot/etc/ 2>/dev/null

# fix them in real @
sudo sed -i 's|/dev/mapper/luks-782ef7a4-eaf4-4355-af38-3065acab082a swap           swap    defaults   0 0|UUID=2edd6d77-c39b-4fb6-961c-e5076d5df3f6 swap           swap    defaults   0 0|' /mnt/realroot/etc/fstab
sudo sed -i 's|resume=/dev/mapper/luks-782ef7a4-eaf4-4355-af38-3065acab082a|resume=UUID=2edd6d77-c39b-4fb6-961c-e5076d5df3f6|' /mnt/realroot/etc/default/grub
sudo sed -i '/782ef7a4/d' /mnt/realroot/etc/crypttab
sudo sed -i 's/ openswap//' /mnt/realroot/etc/mkinitcpio.conf

Phase 3: chroot into real @ and rebuild

sudo mount --bind /dev /mnt/realroot/dev
sudo mount --bind /proc /mnt/realroot/proc
sudo mount --bind /sys /mnt/realroot/sys
sudo mount --bind /run /mnt/realroot/run
sudo mount --bind /boot/efi /mnt/realroot/boot/efi
sudo chroot /mnt/realroot /bin/bash

# inside chroot
mount /boot/efi
mkinitcpio -P
update-grub
exit

sudo umount -l /mnt/realroot

Phase 4: after reboot into real @ via 6.18, drop kernel 7.0

sudo pacman -Rdd linux70 linux-meta
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo mkinitcpio -P

Boot is clean now. One GRUB passphrase for root, no 2nd prompt, no hang.

Note: uuid’s in original post and my own reply have been made anonymous.

5 Likes
3

Is your swap partition encrypted now ?

4

Your statement is correct, however the arch wiki explains how to solve this:
mkinitcpio’s sd-encrypt hook reads /etc/crypttab IF /etc/crypttab.initramfs exists. A hard link from /etc/crypttab to /etc/crypttab.initramsfs sudo ln /etc/crypttab /etc/crypttab.initramfs need to be created.
See arch wiki - section 1.2.4 Using systemd-cryptsetup-generator.

Above is used for Arch, with Manjaro just use this:

sudo manjaro-chroot /mnt /bin/bash (adapt /mnt to your needs)
1 Like
5

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.