> UEFI fixes that to some extent, but it’s a pain to maintain the UEFI entries manually and change them every time the kernel updates.
… you don't have to update the UEFI entries every time the kernel updates. (I guess you might if you do like a kernel w/ CONFIG_EFI_STUB, and you place the new kernel under a different filename than what the UEFI boot entry point to then you might … but I was under the impression that that'd be kind of an unusual setup, and I thought most of us booting w/ EFI were doing so with Grub.)
Even if you do CONFIG_EFI_STUB, there should be a post-update hook to automatically call efibootmgr.
I have 2 entries, /efi/current.efi and /efi/old.efi... when I upgrade, I copy current to old, and copy my new kernel out of /boot as current and reboot.
or just copy the latest kernel to something like /vmlinux and /initramfs
Or use UKI and throw the current kernel to /efi/boot/bootx64.efi; there's plenty of solutions to sane bootloader/kernel management if you're willing to invest 15 minutes into the topic and not act like it's scary and complicated (it really is the opposite).
Grub2 is scary and complicated. Remove grub from the equation, and all the scary goes away.
Grub is really impressive in how it consistently spent the last 30 years focused on improving everything except the UX of the one workflow 99.99% of its involuntary users need it for (boot linux as reliably as possible, and make it easy to debug when it does not).
grub is just a operating system. it is quite good when shit hits the fan
~90% of the failure modes grub can fix don't exist without grub. I can't remember any time when its needless complexity was actually a net benefit compared to literally any of its alternatives (and between gummiboot/syslinux/efilinux/isolinux/systemd-boot/efistub I've used a lot of them).
i never got it to work