What's the point of using this over plain EFISTUB? I use it with Arch, and whenever I want to boot to Windows, I just use the BIOS menu. I don't see what benefit a Linux-based bootloader provides.
Entering the BIOS menu takes several seconds on my ThinkPad, and getting to the EFI boot menu from there takes a few more. That's after hitting the key during the correct time during the boot process, which sometimes takes guessing.
In principle, the EFI multiboot mechanism should be the way to handle basic multiboot options. It would of course be nicer and cleaner from a design perspective not to have redundant mechanisms on top of each other. In practice, though, using the EFI boot menu can be clumsy. The real solution would be for it to not be clumsy but it doesn't look like we're necessarily there.
UKIs provide mechanisms for adding additional sidecar modules which can extend the initramfs, provide additional command line modifications, and so on.
EFISTUB requires recompiling the kernel every time initramfs, microcode or commandline change, no? That would get annoying pretty quickly on desktop PCs, which are not that fast with recompiling, and would need to do all of this quite often, e.g. on nvidia driver updates.
I've never once had to recompile the kernel on my laptop for any reason. The kernel command line is set in the bios entry, which is somewhat tedious to change, but that's just an efibootmgr command. Initramfs gets rebuilt by pacman on larger updates, but that would happen no matter what bootloader I use.
Vendor support for the command line coming from the EFI boot entry is of variable quality. If it works for you that's great, but unfortunately there's a bunch of boards in the wild where it doesn't. It's not a great solution for general purpose distributions as a result.
The command line can be part of the UEFI boot entry depending on your particular firmware.
I think I can recompile the Linux kernel in around 15 minutes, but I have a 12400F. And 15 minutes is still 60 times longer than most people are willing to wait.
It wouldn't be impossible to change the default kernel commandline in the image without recompiling the whole kernel if anyone cared about making that fast.
I mean, even the initramfs can be stored in the ESP, can't it? How's that work with Secure Boot? (assuming you don't just use a shim that makes the TPM happy and then proceeds to not actually verify anything afterwards.)
