This is a significant peeve of mine. The need to explicitly specify resolution in boot managers is annoying for both laptops and machines that aren’t always used with the same monitor, because no matter what it’s going to end up in fallback with an ugly stretched resolution some portion of the time, rendering beautification with themes somewhat moot.

This limit made sense 20+ years ago but today it feels highly anachronistic, kind of like finding a corded rotary phone mounted on a wall in the kitchen of an otherwise cutting edge home. Surely it’s something that could be fixed?

May be, but this is so minor in general, that I barely care as long as it boots properly.

Way bigger annoyance is that grub still doesn't support luks2 and uses some gimped variant of libcrypto without proper hardware acceleration that decrypts boot volumes for almost a minute. That is way more serious than boot resolution annoyances.

That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things

Yes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.

> They are in the process of switching,

Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it

Also, do you know whether grub plans to support luks2?

And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)

The main bug is here: https://savannah.gnu.org/bugs/?55093

But I do recall some other post which went into more details and was saying that switching was taking time due to lack of stable API and other issues.

Try searching for grub 2 + libgcrypt. Some links are also in that bug.

In terms of material impact, it is minor but as far as impression shaping papercuts go, bootloader jank is pretty high up on the list.

What can I say? Feels weird to include a JSON library in a bootloader.

We are talking about a stage 3 bootloader which supports booting from encrypted volumes and ZFS snapshots.

JSON-support would be adding 0.001% extra to the overall package.

Maybe a stage 0 bootloader, definitely not a stage 3 one.

My pet peeve is that grub repartitions windows disks on chain load, so if it ever boots with the disks remapped, there's a chance it'll plow apart the partition table of whatever poor disk got mapped to that hd#.