11 ms·

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 d

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 https://wiki.archlinux.org/title/EFISTUB

m4lvin 4y ago
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 https://wiki.debian.org/EFIStub
- nubinetwork 4y ago
  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)
- abnry 4y ago
  > 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.
  - MobiusHorizons 4y ago
    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.
- still_grokking 4y ago
  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.
  - thedanbob 4y ago
    > 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.
boomboomsubban 4y ago
>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.
dezgeg 4y ago
Because having boot menu for stuff like older kernels, recovery mode, and access to kernel command line is pretty useful.
- Asmod4n 4y ago
  You don’t need a boot manager for that except the one built into your motherboard.
  - AshamedCaptain 4y ago
    Most UEFI devices out there don't have any type of boot menu.
    - Asmod4n 4y ago
      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?
      - deleted 4y ago
        [deleted]
    - aesh2Xa1 4y ago
      https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-manager https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-manag... https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html
      - AshamedCaptain 4y ago
        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.
noodlesUK 4y ago
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.
- rwmj 4y ago
  I think Fedora is moving to this? https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1#Detailed_Description https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...
fuzzy2 4y ago
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.
- Volundr 4y ago
  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.
  - MobiusHorizons 4y ago
    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.
- deathanatos 4y ago
  > 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?
  - fuzzy2 4y ago
    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.
Asmod4n 4y ago
Only thing that comes to mind is if you swap disks between machines and want the same boot menu on all of them.
candiddevmike 4y ago
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.
CorrectHorseBat 4y ago
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
- yjftsjthsd-h 4y ago
  Well there's https://zfsbootmenu.org/ https://zfsbootmenu.org/ if you're on ZFS, but that's a whole different thing
- still_grokking 4y ago
  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.
  - CorrectHorseBat 4y ago
    How would you snapshot that? Afaik EFI doesn't support snapshottable filesystems
    - still_grokking 4y ago
      You don't need "snapshottable filesystems" to make filesystem snapshots.
demindiro 4y ago
> 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.
dtgriscom 4y ago
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...)
- usr1106 4y ago
  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.
  - still_grokking 4y ago
    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?
    - justsomehnguy 4y ago
      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
    - usr1106 4y ago
      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.
greyw 4y ago
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.
teo_zero 4y ago
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.
rodgerd 4y ago
> 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.
INTPenis 4y ago
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.

m4lvin 4y ago

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 https://wiki.debian.org/EFIStub

nubinetwork 4y ago
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)
abnry 4y ago
> 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.
- MobiusHorizons 4y ago
  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.
still_grokking 4y ago
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.
- thedanbob 4y ago
  > 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.

boomboomsubban 4y ago

>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.

dezgeg 4y ago

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

Asmod4n 4y ago
You don’t need a boot manager for that except the one built into your motherboard.
- AshamedCaptain 4y ago
  Most UEFI devices out there don't have any type of boot menu.
  - Asmod4n 4y ago
    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?
    - deleted 4y ago
      [deleted]
  - aesh2Xa1 4y ago
    https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-manager https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-manag... https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html
    - AshamedCaptain 4y ago
      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.

noodlesUK 4y ago

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.

rwmj 4y ago
I think Fedora is moving to this? https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1#Detailed_Description https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...

fuzzy2 4y ago

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.

Volundr 4y ago
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.
- MobiusHorizons 4y ago
  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.
deathanatos 4y ago
> 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?
- fuzzy2 4y ago
  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.

Asmod4n 4y ago

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

candiddevmike 4y ago

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.

CorrectHorseBat 4y ago

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

yjftsjthsd-h 4y ago
Well there's https://zfsbootmenu.org/ https://zfsbootmenu.org/ if you're on ZFS, but that's a whole different thing
still_grokking 4y ago
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.
- CorrectHorseBat 4y ago
  How would you snapshot that? Afaik EFI doesn't support snapshottable filesystems
  - still_grokking 4y ago
    You don't need "snapshottable filesystems" to make filesystem snapshots.

demindiro 4y ago

> 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.

dtgriscom 4y ago

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...)

usr1106 4y ago
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.
- still_grokking 4y ago
  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?
  - justsomehnguy 4y ago
    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
  - usr1106 4y ago
    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.

greyw 4y ago

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.

teo_zero 4y ago

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.

rodgerd 4y ago

> 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.

INTPenis 4y ago

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.