How do get graceful retry for bad/wrong password entry at disk decryption during boot?

[qsu]

tl;dr anyone know how (both before and after install) one can setup more graceful retry (rather than falling into grub rescue when password is mistyped?

As reported here I frequently run into the following grub flow whenever I mistype my password:

Attempting to decrypt master key...
Enter passphrase for hd2,gpt2(...long-hex-string...):
error: access denied.
error: no such cryptodisk found.
error: disk 'cryptouuid/...long-hex-string...' not found.
Entering rescue mode...
grub rescue>

However, Manjaro’s the first place I’ve seen this happen. All other distros I’ve installed (entirely via GUI - not doing anything too “advanced” I don’t think - just always choosing encryption of my full disk): I encounter some sort of UX that allows me to try again rather than dropping me to a grub rescue> prompt. Is there a way to get this (nicer “retry UX”) behavior with Manjaro? I’m interested in both after-the-fact (I’ve already installed, now how do I get said behavior) and before-hand (I’m about to install, what do I do in the installation UI to ensure I’ll be configured with said retry behavior).

[qsu]

Also, I’d be happy to hear that others do not get this behavior for their disk-encrypted installs, in which case this means I just clicked the wrong thing at some point during my install (which at least gives me a lead)

[winnie]

@qsu

All other distros I’ve installed (entirely via GUI - not doing anything too “advanced” I don’t think - just always choosing encryption of my full disk): I encounter some sort of UX that allows me to try again rather than dropping me to a grub rescue> prompt.

With these other distros, did they create a separate /boot partition? or was the only thing non-encrypted your EFI system partition?

The prompt you’re seeing (to input your LUKS passphrase) is a rudimentary method from the EFI executable itself.

The former method of using full-disk encryption would leave a small separate non-encrypted /boot/ partition where the kernel and initramfs would live, which would be used to prompt for your LUKS passphrase to later unlock the root partition. (Failed passphrases would re-prompt you a few more times before aborting.)

---

A workaround for the moment, provided by the Arch Wiki:

If you enter an invalid passphrase during boot and end up at the GRUB rescue shell, try cryptomount -a to mount all (hopefully only one) encrypted partitions or use cryptomount -u $crypto_uuid to mount a specific one. Then proceed with insmod normal and normal as usual.

I haven’t tried this yet myself, and I’m not sure if it works for all distros or versions of LUKS.

[Fabby]

Please read this:

[HowTo] Post screenshots and links

Difficulty: ★☆☆☆☆ You’ve probably been sent here by a more experienced user because you cannot post links nor screenshots so please follow the simple instructions of this tutorial below to allow you to post both screenshots and links in any post and have a short explanation of why you can’t do this easily… If you’re reading this in response to a question, please click the green link above this text to bring you to the full unabridged text of the tutorial itself. If you …

Furthermore, I’ve marked this answer as the solution to your question as it is by far the best answer you’ll get.

How do get graceful retry for bad/wrong password entry at disk decryption during boot?

With these other distros, did they create a separate /boot partition? or was the only thing non-encrypted your EFI system partition? The prompt you’re seeing (to input your LUKS passphrase) is a rudimentary method from the EFI executable itself. The former method of using full-disk encryption would leave a small separate non-encrypted /boot/ partition where the kernel and initramfs would live, which would be used to prompt for your LUKS passphrase to later unlock the root partition. (Failed p…

However, if you disagree with my choice, please feel free to take any other answer as the solution to your question or even remove the solution altogether: You are in control! (If you disagree with my choice, just send me a personal message and explain why I shouldn’t have done this or or if you agree)

P.S. In the future, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:

so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.