I am now fairly sure this is a bug. Looking at luks2.c, it looks like the code is assuming there is a one-to-one mapping between keyslots, digests, and segments. In the trivial case (keyslot=0, digest=0, segment=0) this is true, but the code can't handle my setup (keyslot=1, digest=0, segment=0), even though cryptsetup can.
On Tue, 7 Jul 2020 at 08:10, Mike Benson <[email protected]> wrote: > I am playing around with full disk encryption, but Grub is not being > cooperative. > > I am using a build of Grub cloned from the Git repository, so luks2 > support is available. I have run grub-mkconfig and grub-install, preloading > part_gpt, luks2 and cryptodisk modules > > The boot partition is locked with two keys at the moment. The second is a > temporary, memorable (but low entropy) passphrase for testing. > > If I boot from the live usb, I can do: > *Code:* > cryptsetup luksOpen /dev/nvme0n1p2 BOOT > > and that works fine with the second key. > > When I boot the target, I get a "no such device" error and get dropped > into a rescue shell. I'll deal with that later. > > I type: > *Code:* > set debug=all > cryptomount (hd0,gpt2) > ... > Enter passphrase for hd0,gpt2 (<UUID follows>): <Types passphrase> > disk/luks2.c:598: Trying keyslot 0 > disk/luks2.c:613: Decryption with keyslot 0 failed > ... > error: Could not parse digest 1. > > > If I do a luksDump, I can confirm there is no digest 1 (although there is > a digest 0, referenced by both keyslots). I don't know if this is a bug > with searching the keyslots, or a problem with the LUKS header (though > surely cryptsetup would have problems if that were the case). > > Any grub masters available to offer suggestions? >
