Hacker News Reader

Comment by MobiusHorizons | Hacker News Reader

Years ago on an arch system I would boot directly from UEFI to the kernel (using a feature known as EFISTUB[1]) Ever since then I have not understood why most distros don't switch to this setup. It would seem like removing an entire bootloader from the boot sequence would significantly improve boot times, which was my experience with that setup at the time.

Does anyone know why anyone would choose systemd-boot over something like efistub?

1: https://wiki.archlinux.org/title/EFISTUB

View on HN

IIRC, systemd-boot relies on EFISTUB. It's just a boot manager, not a boot loader. One EFI application calling another.

For trivial setups (one kernel that keeps getting updated in-place), a boot manager is not required. For more sophisticated setups (version in kernel file name or Nix style system versions or whatever), a boot manager is very convenient.

Yeah, exactly. This is why you still need to sign kernel images if using Secure Boot with systemd-boot.

Personally the only reason I have it in the loop is it makes it so much easier to switch the an lts kernel if say... zfs has failed to build on a kernel update and I didn't notice (not that THAT would ever happen). Could use multiple EFI entries for that, but systemd-boot is simpler.

Fair enough this type of thing was my main worry with that setup, and I kept a backup known-good configuration around manually for this purpose. Any automation there seems useful.

> It's just a boot manager, not a boot loader. One EFI application calling another.

Is this not exactly what GRUB is, on UEFI systems?

I don’t think so. GRUB still retains its boot loader capabilities for Linux and others. It can also be a pure boot manager, using chainloading.

Simply put: It can boot Linux on EFI without EFISTUB.

EFISTUB can also be done on Debian [1]. I used this for a while, but it felt too fragile and inconvenient:

- the same disk is now impossible/harder to boot in another system/mainboard.

- no more choice between different kernels in case the newest one broke something

- to change the cmdline with kenel parameters you now need to run efibootmgr

Still, the quick boot can be worth it :-)

[1] https://wiki.debian.org/EFIStub

You could always bake the cmdline into the kernel itself, but that would mean recompiling the kernel each time. (Although if that's the only change, that shouldn't take too long)

> no more choice between different kernels in case the newest one broke something

Ah, I see. That's a deal breaker for me. Switching to an older kernel has saved me many times, usually when I completely mess up my nvidia drivers.

As long as you don’t delete the old kernel, you can recover by creating a known good entry every few updates. The arch article also has an ego shell you can install that got me out of a few unbootable cases with a failed Nvidia dkms.

I'm using an "Unified Kernel Image" directly through the EFI boot-manager.

It's the most simple boot setup I've ever used, and it doesn't have the mentioned issues:

> the same disk is now impossible/harder to boot in another system/mainboard.

Just go and select your UKI in the EFI boot-manger. Works on every modern system OOTB.

> no more choice between different kernels in case the newest one broke something

You can have more than one UKI around. You can, for example, have even one with a whole recovery system included in the initrd part!

> to change the cmdline with kenel parameters you now need to run efibootmgr

You only need to recreate the UKI with an updated command line. No change to the boot-manager needed.

Also a UKI has a better security story compared to all other options. You have only one signed EFI binary. No need for complex setups that validate the initrd after the fact, as everything is included in the UKI and signed as a whole.

Have this setup on my Debian box but used actually the superior documentation form the Arch wiki to get there.

> I'm using an "Unified Kernel Image" directly through the EFI boot-manager.

I just recently switched all of my Arch boxes to this setup. The first was so I could enable Secure Boot on that machine, the rest just because it felt so much simpler and cleaner than Grub. Actually, the last one just stopped booting entirely with Grub but worked just fine with UKI.

> You can have more than one UKI around. You can, for example, have even one with a whole recovery system included in the initrd part!

Same! I was considering writing up how to do this for the Arch wiki since it’s handy and I couldn’t find any complete guides.

I also am a huge fan of EFISTUB. EFISTUB is basically the only way of making secure boot work in a sane way for Linux - include the initramfs in the kernel and sign the whole thing with your secure boot keys. You don’t even need to compile the kernel, you can use dracut to package everything up yourself.

I think Fedora is moving to this? https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...

Because having boot menu for stuff like older kernels, recovery mode, and access to kernel command line is pretty useful.

You don’t need a boot manager for that except the one built into your motherboard.

Most UEFI devices out there don't have any type of boot menu.

Haven’t seen one PC or Server mainboard without a UEFI boot menu no matter the price range and age. What devices are you referring to?

https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-manag...

https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html

I didn't say boot loader, I said boot _menu_. The boot loader may be a mandatory part of UEFI (otherwise the entire thing wouldn't actually work...), but there is absolutely no mandate for having any type of GUI, not even a boot menu.

Most devices out there will always boot the first entry (or BootNext) no questions asked. Some devices may allow reordering boot loader entries in their setup program. Almost no devices will actually a) pause booting whenever there are multiple valid entries b) show you a menu where you can choose one of alternatives c) respect your timeout value, choosing the first boot entry if the timeout expires. Incidentally these 3 happen to be the basic properties of what people usually demand from a boot manager.

And some devices are simply hardcoded to _always_ boot \EFI\BOOT\BOOTX64.EFI, no matter what. EFI implementations are all over the place. It's gotten somewhat better, but it's hard to rely on anything. But we got decorative flames in the firmware setup dialogues now. Flames make computer go fast.

what kind of exotic devices are you buying to get flames in firmware setuos and not have boot menu?

I've only ever got those white in a blue screen firmwares.

A Lenovo or HPe system won't have that, of course. But I've had plenty of "consumer" boards for my gaming rigs, or handled friends gaming mainboards.

It's not all flames of course. But the design of the firmware UI certainly got really flamboyant when UEFI hit the scene while quality of implementation really suffered.

It's gotten somewhat better, but now it's getting hard to buy non-enterprise hardware without over 9000 RGB LEDs on there. Sigh. At least the LEDs don't bother my bootloader.

The whole point is that I don’t want it to pause boot to show me a menu unless the system is broken. Boot should not need to be interactive by default. But every uefi laptop and desktop device I have ever used has a key you can press during boot to bring up a boot menu.

Both URLs I sourced directly mention a menu. Here's the first:

> UEFI allows the consolidation of boot menus from the OS loader and platform firmware into a single platform firmware menu. These platform firmware menus will allow the selection of any UEFI OS loader from any partition on any boot medium that is supported by UEFI boot services. An UEFI OS loader can support multiple options that can appear on the user interface. It is also possible to include legacy boot options, such as booting from the A: or C: drive in the platform firmware boot menus.

That's not my experience. I've only ever seen HP do an actual file browser in UEFI to pick an arbitrary .EFI file, but overall every computer and laptop I've seen has a button you can press to pick from a list of operating systems available to boot.

You might not think of it as a boot menu, but every uefi system I have ever used has a menu you can bring up by holding a key during boot that lets you choose which disk to boot from. In reality this menu has all the entries you set up in efibootmgr. You can also usually see this menu from the save and exit page of the setup/bios page. These entries are about as customizable as grub entries via efibootmgr.

The one in my Dell laptop takes quite long to get into and out of. It’s not something you would want to use regularly.

If it's for recovery, etc. then that may not be a real issue?

EDIT: Anyway, I'd probably only ever rely on an external USB stick, but I don't know how that interacts with Secure Boot, tbh. I use Ventoy + loads of images of popular distros. Can fit quite a few distros on a 128 GiB USB stick! :D

As long as the bootloader/kernel image is signed, I don't think it matters to secure boot whether or not it was loaded off a USB stick. Presumably the firmware implementing the secure boot check must copy the image into RAM before verifying it anyway, at which point the USB storage doesn't matter.

Of course, the firmware may be configured to refuse to boot a USB drive as a matter of policy.

Well, one reason you'd need one is if your boot filesystem is encrypted and you want to be able to reboot the machine remotely. (I use ZFSBootMenu for this purpose; it's accessible via SSH and can be used to decrypt the filesystem and choose what to boot.)

There are hardware solutions to that problem, but most regular PCs don't come with a remotely-accessible boot menu.

Except if the boot manager implementation of the UEFI is bad. For example on Intel NUCs you cannot use one-shot functionality and kernel command line at the same time. If you put systemd-boot in between it works.

My old mobo would refuse to accept NVRAM changes, overwrite them at boot or something, then hardcoded try to launch the windows bootloader from the ESP. I had to trick it by naming my bootloader the same thing as the Windows bootloader. Signing new things for secure boot didn't work at all but luckily it could be disabled.

This was an MSI motherboard in case anyone's wondering.

Yeah, this was my one concern with the setup. But to be fair, it's not a flaw with efistub, it's a flaw with the kernel update logic in arch. I manually added an entry for a known good configuration which I periodically updated manually, but I know of no reason why the kernel update logic couldn't do that for me like it does in grub. And as a fallback you can install a UEFI shell option to boot into which works in emergencies.

As a distro I wouldnt want to rely on uefi implementations that range from ok to garbage tier (no cmdline arguments, hidden boot selection menu etc)

I want to enter a sane booting environment as soon as possible (gummiboot, refind, grub). Also why not? Its basically free and In my experience doesnt really complicate secure boot.

> Ever since then I have not understood why most distros don't switch to this setup.

The persistence of GRUB for x86-64 systems is both fascinating and irritating; the original driver for users paying the price of the complexity of GRUB was the idea that it would bring consistency across architectures and be an overall reduction in complexity for distro maintainers. Instead the bootloaders for non-x86 architectures are generally not-GRUB (zipl, various ARM options which are sometimes SoC specific, and so on), while x86 users are stuck with the byzantine complexity of GRUB.

I have my taylor-made kernel compiled with all and only the drivers I need, without an initram and with EFISTUB, directly called by the UEFI as its first boot option. That's how I manage to boot in 5 seconds.

Then I have some distro-supplied kernels, with initram, modules, non-standard parameters AND grub, just for those times when I need something exotic. I have to stop the normal boot with Esc and select the second boot option from the UEFI menu, that points to grub. It's clumsy and slow but I just need it once in a blue moon.

Only thing that comes to mind is if you swap disks between machines and want the same boot menu on all of them.

>Does anyone know why anyone would choose systemd-boot over something like efistub?

Lots of people dual boot without manually going through their UEFI. It's important enough that I can see why many distros wouldn't make it default.

systemd-boot presents a boot menu at startup. It can support different boot targets defined in files under the EFI directory, and it automatically detects Windows UEFI targets.

How often do you actually reboot your machine? My office compile box is showing 17 days uptime, and that's quite low (I think I did an update).

Optimizing a few seconds off of something you seldom do isn't that useful. (Not that I haven't been guilty of that, again and again and again and...)

Given that you are supposed to work 8 hours and not work 16 your office box should not heat the planet 66% unnecessarily.

Disclaimer: I don't meet the 8 hour goal and the unattended boot of my office machine setup has been incomplete for 5 years...

Edit: We do also nightly builds, but they take between 5 minutes and less than 3 hours.

Even if you almost never reboot your box it can go into deep sleep when it's not used. It doesn't "heat the planet" significantly when doing so.

Actually it would be interesting to calculate whether frequent reboots don't use more energy in sum than putting the machine into sleep. Does anybody have numbers on that?

In mobile phones similar optimizations where done at least when battery sizes were well below 1000mAh. I think race to sleep was very competitive. So you run at full power for a short time and then you go to a deep sleep mode.

Discaimer: Have not worked with mobile phones for 10+ years.

Typical boot is somewhere.. okay, lets take 30 seconds for all boot shenanigans. Okay, 1 min for ease of count. That's 0.0694444444444444% a day. Doubt it. Even monster servers (like 4CPU and TBs of RAM) boot up in 10 minutes and that's only 0.69% of the day. Modern systems don't gobble all up all available power at the startup and pretty quickly go to a power controlled mode. Sure if you have some monster with a dozens of HDDs then there could be some nuances, but at that point you surely don't reboot often anyway

I wish we could heat the entire Planet with 40-50 Watts/hour

I wish there were only 1 computer on the planet?

I wish only computers heated the Earth.

Some kind of ideas are stupid and we must go back to reasoning about real problems, not fictional problems.

A computer that stays in sleep most of the times is the last problem we have in modern societies.

Meanwhile people set their home temperature at 30C in winter (when it's 10-15C outside) and the AC at 16C during summer (when it's 28-30C outside)

maybe just don't?

At the time I was dual booting to windows, and had just gotten my first ssd. I was a bit obsessed with boot time.

> Ever since then I have not understood why most distros don't switch to this setup

I still use GRUB because IIRC my Gigabyte motherboard kept forgetting entries and/or associated settings.

I think you do understand if you think about it.

You have so many different hardware vendors, but one common boot loader. Who can you rely on working every time for every vendor?

Also I use grub to select old deploys in Fedora Silverblue.

I'd love to use systemd-boot though.

One issue I have with it is that I can't snapshot it like the rest of my system, but I don't really know if any other bootloader solves this issue

Well there's https://zfsbootmenu.org/ if you're on ZFS, but that's a whole different thing

I don't think there is any boot setup that is better suited to being snapshoted than a "Unified Kernel Image".

With an UKI your whole boot setup is a self-contained and portable EFI executable.

How would you snapshot that? Afaik EFI doesn't support snapshottable filesystems

You don't need "snapshottable filesystems" to make filesystem snapshots.

Reply on news.ycombinator.com