[xfs]

I have used EFISTUB for 10 years but I wouldn't recommend it for the next install. The bootloader is the one arcane place that you don't want to be clever with and get reminded of its presence daily, because once it fails for some reason, it wastes much more time to find and read docs and diagnose than the time saved in boot speedup, because the knowledge to debug it is not something you would remember everyday. And this setup is even rarer than Grub, so any failure cases will not have help from cached knowledge and thus require much more research from first principle. Some backup options here would help in case, even if they impose some tax in boot speed. (If Grub takes a tax of 3 seconds per boot, and if a failure in EFISTUB takes 1 hour to resolve, it takes 1200 boots for EFISTUB to be worth the risk, which is 3 years if it's a laptop booting once per day, and much longer for a desktop.)

Once my desktop using the EFISTUB setup had a kernel that failed to boot, stuck at some filesystem error. Then I had to come up with a rescue plan at the spot, because there was no other way to boot into the desktop and there was no tutorial to help with this at the time.

The issues of EFISTUB:

- It doesn't interact with kernel updates nicely. I used a script in /etc/kernel/postinst.d to copy /vmlinuz to \EFI\debian\vmlinuz.efi. There is no rollback, and no multiple kernels.

- It doesn't work well with kernel parameters. The parameters are encoded in UEFI NVRAM. You have to create separate entries for different kernel parameters, or manipulate the NVRAM back and forth with efibootmgr, which is another gun that easily shoots the foot (you can easily mess up the bootorder variable).

- It doesn't play nicely with Windows and Secure Boot.

[CaptainMarvel]

I use EFTSTUB with Arch Linux and I agree about it taking up more of your time. However, for me, this was all the very start to first set it up. Since then, it’s been smooth sailing.

I also use multiple kernels and I have had issues with kernel updates, and no issues with kernel parameters. However, there is friction with creating separate entries and so I created a very simple shell script to save my commands.

I’ve had no issues dual booting with Windows using BitLocker. I do not use secure boot (yet).

If you’re willing to spend an hour to set it up, I’d go for it. However, that’s an hour of your life you can save with Grub.

[xfs]

Sure, it's common to have it working for a long time, because breaking changes and interactions between different systems occur very infrequently at the level of bootloader and firmware, but when it happens it can easily get into very difficult support situation. Logistically speaking, firmware is not a nice place to play around. It's not well coded, not well tested, and rarely "used" by an end user.

For one I wouldn't put great confidence in a script to manipulate UEFI boot entries, because it is not idempotent and there are precedents to brick the UEFI with unexpected sequence of interaction. Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.

[csdvrx]

> Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.

I'm mostly a Windows user, and this has never happened in my experience: at worst Windows might reorder the UEFI boot options, or change the default boot option, but it has never overwritten or erased an entry.

At worst they are still available in the F12 boot menu.

[csdvrx]

> The parameters are encoded in UEFI NVRAM.

You can embed the parameters in the EFISTUB, this is explained in the arch wiki.

I use that to test different parameters with the same kernel packaged in different EFI payload, which I can select from the F12 boot menu if I don't want to use the commands to specify "use this payload only for the next boot"

[orangepurple]

It's completely seamless after initial setup on Arch Linux. No scripts, copying, or anything. It just works for years. I almost forgot it exists.