I run Arch Linux as an encrypted /, /boot and swap system. That encrypted /boot
is nothing more than a folder under /, however two Keyslots are required to
boot.
If I understand the boot process correctly, LUKS Keyslot 1 is used by grub to
unlock /boot, then control is handed off to the kernel which uses Keyslot 0 to
unlock /. My passphrase, entered once, unlocks both.
Grub can easily unlock /boot, assuming / is originally encrypted as a `type=
luks1` partition. It seems, however, it is not possible for grub to unlock this
same /boot if / is converted to `--type= luks2`.
Is my assumption correct, and if so, what is preventing grub from this `type=
luks2` /boot unlocking?
I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). This
package was last updated on 7 Feb 2020. See:
https://aur.archlinux.org/packages/grub-git/
I originally encrypted the partition with: `cryptsetup -c aes-xts-plain64 -h
sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ`
Then I set up two LVs: swap (512M) and / (remaining partition space). That swap
LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 runs BTRFS, if that
matters. Grub boots that system without issue.
The process I used to test LUKS2 encrypted /boot support:
1. UEFI boot from any reasonably recent arch iso, and run: `cryptsetup convert
--type luks2 /dev/sdXZ`. That command will succeed, and luksDump will show
PBKDF: pbkdf2 for both Keyslot 0 and 1.
2. Run cryptsetup open /dev/sdXY <something>
3. Mount everything and arch-chroot into /
4. Run `mkinitcpio -P linux`
5. Run `grub-install --target=x86_64-efi --efi-directory=/efi --modules="luks2
part_gpt cryptodisk" --bootloader-id=<some-id>`.
Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to
grub-install, then the `ls` results in step 9 (below) only lists (proc) and
(hd0) - and/or cryptodisk: command not found.
6. Run grub-mkconfig -o /boot/grub/grub.cfg
7. Exit, umount and reboot.
8. Immediately following power on: you are greeted by the dreaded: error: disk
'lvmid/some-lengthy-UUID' not found. Entering rescue mode. That lengthy UUID is
exact UUID of my `dm-2` which is my encrypted / LV.
9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) and
(hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where my encrypted
/ resides.
10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then requires
my passphrase. After correct passphrase entry, and hitting Enter only returns:
`error: Could not parse digest 1.`
Incredibly, if you repeat step 10 and intentionally enter an incorrect
passphrase, you get the same:
`error: Could not parse digest 1.`
In fact, if you enter NO passphrase and hit Enter, you also get:
`error: Could not parse digest 1.`
Very frustrating indeed!
Does anyone know why grub is failing this way, and does a workaround exist?
Thank you for your time...suggestions welcome.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
