Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results

[HardenedArray]

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.