On 8/28/20 11:28 AM, HardenedArray via Grub-devel wrote: > 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.
If I remember correctly, you mentioned on IRC that you could successfully use grub-git to cryptomount a luks1 /boot/grub directory, then use the grub modules there to further cryptomount a luks2 partition. The problem sounded like an issue actually getting grub-install to generate a grubx64.efi with proper, usable luks2 support. Am I right? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel