Well, I only speak of demands for the moment. But the other parts you have mentioned came and come up from way different persons, not you. As you have now mentioned them: That is the point bcause the impression may vary towards the real point behind. Meaning also: Grub is very very hard to build, takes also a long time doing so and patching is a tremendous act in that. When we make one error within that we break the whole boot for all people using Grub at the moment. So I need to underline the point we are operating into.

In general: I would then use this now as callout. If people are there granting jim and us from packaging a helping hand? Interested in testing? Please keep a call and come.

You really do not need to be that careful: Comparing to understand errors is always fine. The only point I (personally speaking) just react harder when it comes like "X has Y, Hyperbola has not Y, why" - because it binds that amount of time to reply and get all the information again (we want to be fair and answer with correct parts and decisions made) that you loose time ... being more better to help the person asking for example or solving the more essential question behind: Why is there no real minimalistic or more minimalistic project solving that need from the person? Or did we just not found it until now?

Comparisons for solving errors or issues? Who am I to question that? Just be cautious that you don't fall into the comparison-trap and the version from Parabola is even more different from Arch GNU/Linux and we have another issue we also need to solve. When Parabola is not working the way you have in mind: Try it with Trisquel or Devuan for example. Doing comparisons for test-approval is just a normal way understanding issues. You can have:

- functional tests
- regression tests
- quality approvals and comparisons when there is no current definition known

And many more.

As you may or may not know, there is another project called Gnuboot that uses a minimal number of blobs (I believe the smallest of all)
unlike Libreboot or Coreboot, here is their repository =>  https://ftp.gnu.org/gnu/gnuboot/gnuboot-0.1-rc3/  , but there is one BUT, at the moment, this is that Grub Gnuboot does not support Luks2+argon2id, but if the distribution supports Luks2+argon2id in our case it is Hyperbola, then you can install full-disk encryption including /boot partition using Luks2 +argon2id !

Hello Other_Cody . You're wrong ! Gnuboot is not Canoeboot, not Libreboot.at, not Libreboot.org, not Coreboot.
Here is the information => https://savannah.gnu.org/news/?id=10571

Regarding Grub Hyperbola, I was wrong.
If the GRUB in the ROM supports LUKS2, then it can unlock the drive and boot the distribution directly - you don't even have to install GRUB in your distribution

Gnuboot developer answer

GNU Boot uses the official/main/major version of GRUB. At the moment, GRUB does not officially support Argon2, which means that using GRUB with Argon2 support may cause problems (and don't say it does, just say it can, since it hasn't been tested by the GRUB maintainers), so we're not changing his. So the answer is no, we do not support Argon2.

I had told you, I have gotten luks2 working with argon2id already.

It works. Only question is how to do ti for FDE + encrypted /boot

At the moment the situation is this: I can log in using Payload> "c"> grub>

grub> cryptomount -a

ls

grub> set root='lvm/matrix-rootvol'
grub>insmod linux
grub> linux /boot/vmlinuz-linux-libre root=/dev/matrix/rootvol cryptdevice=/dev/sda1:lvm
grub> initrd /boot/initramfs-linux-libre.img
grub>boot

the same method works

grub> ls (hd0,msdos1)/boot/grub/i386-pc/normal.mod
normal.mod
grub rescue> insmod normal
grub rescue> normal

But this needs to be done every time you log in, I made a mistake somewhere, I think it’s with the boot partition and that’s why when I log in I get an error related to lvmid

error : disk 'lvmid /WuGDE4-Po2w-3n6d-9pcY-sqsoV-eTsq-aLxagJ' not found