8 ms·

I replaced grub with systemd-boot

176 points by pabs3 4y ago

MobiusHorizons 4y ago
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.
smackeyacky 4y ago
For the lazy, here's a couple of links. https://wiki.archlinux.org/title/systemd-boot https://wiki.archlinux.org/title/systemd-boot https://www.reddit.com/r/archlinux/comments/mxzfox/systemdboot_vs_grub/ https://www.reddit.com/r/archlinux/comments/mxzfox/systemdbo... https://support.system76.com/articles/bootloader/ https://support.system76.com/articles/bootloader/ Pop!OS uses it on anything with a UEFI secure boot setup which was something of a surprise to me since I didn't notice anything except that I don't see the GRUB menu at boot time, and to dual boot I have to drop to the bios or use the Windows 11 restart bollocks to get back to Pop!OS Although there is a reddit comment that I think was quite apropos: LILO got too complex so we got GRUB, now GRUB is a beast and we have systemd-boot. Not sure what other advantages it might have over GRUB other than perhaps it plays nicer with Windows/UEFI. I still prefer GRUB on my other machines where I'm still allowed to use it.
aliqot 4y ago
Can you still use LiLo these days on a systemd enabled system?
- boomboomsubban 4y ago
  Seems like it. https://wiki.archlinux.org/title/LILO https://wiki.archlinux.org/title/LILO
candiddevmike 4y ago
I wish systemd-boot had implemented a BIOS shim somehow, since we're still stuck with grub for most cloud providers and other non-UEFI capable setups. Basically something that BIOS boots into a UEFI loader-esque so it uses the same path for everything, similar to how ARM can "UEFI boot".
- paulfurtado 4y ago
  FWIW on AWS, all nitro instance types can boot as UEFI if the AMI has itself set to use UEFI and all arm64 instances only support UEFI. So if you stick to modern instance types, you can happily use UEFI in AWS. GCP looks like it does UEFI too. And Azure Gen2 instances use UEFI too.
- secondcoming 4y ago
  What difference does it make what boot loader cloud providers use?
- pabs3 4y ago
  ISTR there is work on making GRUB do that.
andrewstuart 4y ago
I find booting, grud, uefi and related technologies are one of the most complex and hard to make sense of parts of modern systems.
- yjftsjthsd-h 4y ago
  I think UEFI actually helps; I do not miss having to manually overwrite the first sector of my hard drive in order to make the bootloader work. (But yes, booting remains a pain)
- xxpor 4y ago
  It's a genuinely complex problem. Booting x86-64 with arbitrary hardware attached while maintaining compatibility with boot modes from 30+ years ago is quite a feat. https://en.wikipedia.org/wiki/Das_U-Boot https://en.wikipedia.org/wiki/Das_U-Boot + https://en.wikipedia.org/wiki/Devicetree https://en.wikipedia.org/wiki/Devicetree is an alternative, but it's a massive pain because you lose PnP.
  - userbinator 4y ago
    It's only complex if you want to make it so. Load the first sector of the chosen boot device into memory at 7c00h, and jump to it. That's how all PCs booted before the monstrosity known as UEFI came into existence.
    - xxpor 4y ago
      That's like saying the only thing that actually makes a car move is the spark from the spark plug. Yeah, that's the literal handoff, but a LOT of things need to happen before that. Even before UEFI, you still have to deal with ACPI and friends.
    - rfoo 4y ago
      > and jump to it After CPU setup, memory training, dealing with ACPI shit, loading (and executing! [1]) Option ROM, and others? There are things called "BIOS" doing this before UEFI came into existence. [1] https://en.wikipedia.org/wiki/Option_ROM https://en.wikipedia.org/wiki/Option_ROM
rsyring 4y ago
I replaced Grub w/ rEFInd a few years ago and I've never looked back. The ability to just scan filesystems and boot images is so simple/easy compared to the Grub menu edit and "reinstall" process you have to go through every time you want to make a change. I've never used systemd-boot but highly recommend rEFInd over Grub. I also have a Python script for installing Ubuntu on native ZFS w/ encryption and using rEFInd. You can use this script from a live boot environment. If nothing else, can easily review for how to do it manually. - https://www.rodsbooks.com/refind/ https://www.rodsbooks.com/refind/ - https://wiki.archlinux.org/title/REFInd https://wiki.archlinux.org/title/REFInd - https://github.com/rsyring/zfs-on-root/blob/master/zor.py https://github.com/rsyring/zfs-on-root/blob/master/zor.py
- hashhar 4y ago
  For examples of how amazing rEFInd can look - see https://github.com/hashhar/rEFInd-theme/ https://github.com/hashhar/rEFInd-theme/ and https://github.com/EvanPurkhiser/rEFInd-minimal https://github.com/EvanPurkhiser/rEFInd-minimal
- gbin 4y ago
  I concur. Refind is pretty much universal for me: it detects Linux kernels automatically, windows, boots from USB or detect USB (I always have an emergency copy that will boot my systems if I screw up), it also runs on Intel macs... Also... It is very customizable with good a 100% graphic UI.
- avhception 4y ago
  Another rEFInd user chiming in, the best bootloader ever. Using it on all my Gentoo and Arch installs. The Fedora installs are still on Grub2 though.
- indigodaddy 4y ago
  I put a bunch of live environment/rescue images (trinity, UBCD, hirens, systemrescue etc) on a usb flash with ventoy, and ventoy couldn’t boot any of them except for systemrescue (seemed like it had an issue with EFI with the other ones).. As an alternative to ventoy, can I use refind on a usb flash drive with iso images?
klooney 4y ago
Fun fact about systemd-boot, you have to hold down the spacebar to get the boot prompt, and it remembers the last boot. So if you let your toddler bang on the keyboard while booting, and you're boot looping into the BIOS config screen, hold down space at the next boot and maybe everything will work out OK.
- doubled112 4y ago
  It has a number of keyboard shortcuts, and uses UEFI variables to store some of this config. It took me a long time to figure out what I did to change defaults by accident and how it stayed changed. Jumped the gun and typed my LUKS unlock password a moment too soon.
c7DJTLrn 4y ago
The biggest blocker for me using systemd-boot is that there's no signed EFI binary yet so you can't use Secure Boot (unless you want to enrol your own signing key, which is inconvenient and I'm not even sure is possible on cloud providers.) If you use Ubuntu, Canonical provide a GRUB binary signed by Microsoft's shim.
- georgyo 4y ago
  Here is a question for you, what value is secure boot providing you that you cannot get from an encrypted root filesystem with a TPM and systemd-cryptsetup. That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub. On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct. Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry... One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
  - sgtnoodle 4y ago
    Secure boot doesn't prevent code from doing whatever it wants once it's running. It prevents the system from starting to run code that isn't trusted in the first place. That's still necessary even if you have a TPM. If you're storing your disk encryption key in a TPM, there needs to be an API for the OS init routine to access the key from the TPM. You can't depend on any secrets outside of the TPM before decrypting the storage (otherwise you wouldn't need a TPM), so instead you need to guarantee that the code accessing the TPM's API isn't malicious. Typically, once the OS reads out the storage encryption key, the OS then immediately asks the TPM to disable its API until a subsequent boot. From that point on the kernel has the key in RAM, and there's no way for unprivileged code to access it (other than bugs). Secure boot provides the mechanism to make that possible. If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure. Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.
sureste 4y ago
I pretty much did this too but in Arch Linux. It's just a script[1] that I run and I have it working with the linux and the linux-lts kernels. It's pretty nifty. It just works on Arch Linux since kernels don't have version numbers on the name I never have to touch again after installation. [1]: https://github.com/adcpe/sh/blob/main/boot.sh https://github.com/adcpe/sh/blob/main/boot.sh
shmerl 4y ago
Is there a way to use it with encryption without boot partition? GRUB is super slow decrypting LUKS.
- Arnavion 4y ago
  In a systemd-boot setup there is no "boot partition", encrypted or otherwise. There is an EFI partition that contains the systemd-boot EFI binary and the UKI binary, and it is a regular unencrypted FAT32 partition. The UKI will contain kernel + initramfs to be able to mount your encrypted root partition as `/`, using regular cryptsetup, not the special low-perf code used by grub. And to be clear, this is how UEFI boot would work even if you didn't have systemd-boot and had your firmware directly boot the UKI.
  - shmerl 4y ago
    Hm, I don't want to put the kernel into EFI partition though. With GRUB the kernel sits in the encrypted /boot on the root. The catch is that GRUB can decrypt root on its own without the kernel, but it's super slow for some weird reason. So I need something similar, but without performance bottlenecks.
    - Arnavion 4y ago
      >Hm, I don't want to put the kernel into EFI partition though. Because?
      - shmerl 4y ago
        Let it be encrypted with everything else. That's the whole point of not using the boot partition.
        Arnavion 4y ago
        >Let it be encrypted with everything else. Why?
kamyl 4y ago
If you're lucky and your machine supports coreboot there is even better way to boot into linux - use slimmed down linux kernel as a direct payload of coreboot and kexec into your actual kernel. This way you're skipping any disadvantages of grub (if you can name any which matter) and don't need to deal with relatively new and not as much battle tested code to boot your trusted kernel.
- pabs3 4y ago
  Does this mean you're installing Linux into write-limited flash? If so that could eventually brick your system.
  - kamyl 4y ago
    No, just an intermediate kernel is written into flash memory along with coreboot. It doesn't wear little flash chip as it doesn't write anything which needs to persist, that's actually one of the points of this solution. Its sole role is to chain-load your destination kernel. So you just basically move your bootloader into non trivially writable memory (as it can be write-locked) to make it more tamper proof. There is always a risk of bricking your system if you're not careful, but wearing off flash isn't one of those risks if that's the concern.
  - KirillPanov 4y ago
    Nope; bootloader flash chips use NOR instead of NAND flash precisely to prevent this. NOR flash guaranteed for a minimum of 100,000 complete rewrites of every cell, with no flash translation layer gimmickery. The downside is that it is very expensive, which is why a few dozen megabytes of NOR flash costs as much as many gigabytes of MLC NAND. Typical NOR flash chip; "Minimum 100,000 Program/Erase Cycles": https://www.gigadevice.com/flash-memory/gd25b127d/ NAND flash vendors often advertise "up to" a similar number of P/E cycles on their SLC devices, but you'll have a hard time getting them to guarantee that. And for TLC and MLC NAND you find in non-industrial products the number is more like 3% of that: https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand TL;DR: bootloader flash chips are chosen such that they are nearly impossible to "wear out".
throwawaaarrgh 4y ago
At some point somebody's gonna make a distro that's just Systemd and a kernel.
- still_grokking 4y ago
  I'm waiting for that. Would be the ultimate base OS. But it's not so easy. I actually looked into all the dependencies of a Linux system and it turns out to be an extremely entangled monolith at the core. Everything depends on everything. So you actually can't have "just a kernel and systemd as 'user-land'".
  - zh3 4y ago
    Ever tried setting 'init=/bin/sh' on the command line? That gets you a shell (or any other program you care to run) and from there a little creativity is all it takes.
  - IceWreck 4y ago
    > actually looked into all the dependencies of a Linux system and it turns out to be an extremely entangled monolith at the core Any resources for this ? Most books I've read/seen are either about Linux kernel internals or using userspace Linux. I'd like to know more about what actually goes into making a complete usable distro.
    - bmicraft 4y ago
      Linux from scratch might be something you want to take a look at
  - throwawaaarrgh 4y ago
    Systemd and a stripped down BusyBox would do it. That's what Alpine is, plus libmusl, minus Systemd.
prima-facie 4y ago
Is there any way to add a 'Shutdown' and 'Reboot' menu entry to systemd-boot? Like you can with Grub? This has been holding me back from switching all my machines to systemd-boot. Mainly because I have an Optiplex micro hidden behind my monitor, where I use the keyboard to power on. Sometimes accidental power-ons happen so it's good to have that menu entry.
- prima-facie 4y ago
  I've found the answer: https://aur.archlinux.org/packages/powerofforreboot.efi https://aur.archlinux.org/packages/powerofforreboot.efi This works well on my system, YMMV.
dijit 4y ago
Last year I decided to go whole hog on Gentoo. It was a failed experiment overall, too much recompiling even for me, however one thing I did get out of it was that I discovered I didn't need a bootloader. You can boot Linux as an EFI executable. Granted, you cannot pass any dynamic boot arguments to it, and initramfs is out of the window it seems (or I just never got it working), but it was remarkably easy to add the commandline options I wanted into the kernel at compile time and just call it as an executable automatically from the EFI BIOS of my motherboard.

176 points by pabs3 4y ago

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.

smackeyacky 4y ago

For the lazy, here's a couple of links. https://wiki.archlinux.org/title/systemd-boot https://wiki.archlinux.org/title/systemd-boot https://www.reddit.com/r/archlinux/comments/mxzfox/systemdboot_vs_grub/ https://www.reddit.com/r/archlinux/comments/mxzfox/systemdbo... https://support.system76.com/articles/bootloader/ https://support.system76.com/articles/bootloader/ Pop!OS uses it on anything with a UEFI secure boot setup which was something of a surprise to me since I didn't notice anything except that I don't see the GRUB menu at boot time, and to dual boot I have to drop to the bios or use the Windows 11 restart bollocks to get back to Pop!OS Although there is a reddit comment that I think was quite apropos: LILO got too complex so we got GRUB, now GRUB is a beast and we have systemd-boot. Not sure what other advantages it might have over GRUB other than perhaps it plays nicer with Windows/UEFI. I still prefer GRUB on my other machines where I'm still allowed to use it.

aliqot 4y ago

Can you still use LiLo these days on a systemd enabled system?

boomboomsubban 4y ago
Seems like it. https://wiki.archlinux.org/title/LILO https://wiki.archlinux.org/title/LILO

candiddevmike 4y ago

I wish systemd-boot had implemented a BIOS shim somehow, since we're still stuck with grub for most cloud providers and other non-UEFI capable setups. Basically something that BIOS boots into a UEFI loader-esque so it uses the same path for everything, similar to how ARM can "UEFI boot".

paulfurtado 4y ago
FWIW on AWS, all nitro instance types can boot as UEFI if the AMI has itself set to use UEFI and all arm64 instances only support UEFI. So if you stick to modern instance types, you can happily use UEFI in AWS. GCP looks like it does UEFI too. And Azure Gen2 instances use UEFI too.
secondcoming 4y ago
What difference does it make what boot loader cloud providers use?
pabs3 4y ago
ISTR there is work on making GRUB do that.

andrewstuart 4y ago

I find booting, grud, uefi and related technologies are one of the most complex and hard to make sense of parts of modern systems.

yjftsjthsd-h 4y ago
I think UEFI actually helps; I do not miss having to manually overwrite the first sector of my hard drive in order to make the bootloader work. (But yes, booting remains a pain)
xxpor 4y ago
It's a genuinely complex problem. Booting x86-64 with arbitrary hardware attached while maintaining compatibility with boot modes from 30+ years ago is quite a feat. https://en.wikipedia.org/wiki/Das_U-Boot https://en.wikipedia.org/wiki/Das_U-Boot + https://en.wikipedia.org/wiki/Devicetree https://en.wikipedia.org/wiki/Devicetree is an alternative, but it's a massive pain because you lose PnP.
- userbinator 4y ago
  It's only complex if you want to make it so. Load the first sector of the chosen boot device into memory at 7c00h, and jump to it. That's how all PCs booted before the monstrosity known as UEFI came into existence.
  - xxpor 4y ago
    That's like saying the only thing that actually makes a car move is the spark from the spark plug. Yeah, that's the literal handoff, but a LOT of things need to happen before that. Even before UEFI, you still have to deal with ACPI and friends.
  - rfoo 4y ago
    > and jump to it After CPU setup, memory training, dealing with ACPI shit, loading (and executing! [1]) Option ROM, and others? There are things called "BIOS" doing this before UEFI came into existence. [1] https://en.wikipedia.org/wiki/Option_ROM https://en.wikipedia.org/wiki/Option_ROM

rsyring 4y ago

I replaced Grub w/ rEFInd a few years ago and I've never looked back. The ability to just scan filesystems and boot images is so simple/easy compared to the Grub menu edit and "reinstall" process you have to go through every time you want to make a change. I've never used systemd-boot but highly recommend rEFInd over Grub. I also have a Python script for installing Ubuntu on native ZFS w/ encryption and using rEFInd. You can use this script from a live boot environment. If nothing else, can easily review for how to do it manually. - https://www.rodsbooks.com/refind/ https://www.rodsbooks.com/refind/ - https://wiki.archlinux.org/title/REFInd https://wiki.archlinux.org/title/REFInd - https://github.com/rsyring/zfs-on-root/blob/master/zor.py https://github.com/rsyring/zfs-on-root/blob/master/zor.py

hashhar 4y ago
For examples of how amazing rEFInd can look - see https://github.com/hashhar/rEFInd-theme/ https://github.com/hashhar/rEFInd-theme/ and https://github.com/EvanPurkhiser/rEFInd-minimal https://github.com/EvanPurkhiser/rEFInd-minimal
gbin 4y ago
I concur. Refind is pretty much universal for me: it detects Linux kernels automatically, windows, boots from USB or detect USB (I always have an emergency copy that will boot my systems if I screw up), it also runs on Intel macs... Also... It is very customizable with good a 100% graphic UI.
avhception 4y ago
Another rEFInd user chiming in, the best bootloader ever. Using it on all my Gentoo and Arch installs. The Fedora installs are still on Grub2 though.
indigodaddy 4y ago
I put a bunch of live environment/rescue images (trinity, UBCD, hirens, systemrescue etc) on a usb flash with ventoy, and ventoy couldn’t boot any of them except for systemrescue (seemed like it had an issue with EFI with the other ones).. As an alternative to ventoy, can I use refind on a usb flash drive with iso images?

klooney 4y ago

Fun fact about systemd-boot, you have to hold down the spacebar to get the boot prompt, and it remembers the last boot. So if you let your toddler bang on the keyboard while booting, and you're boot looping into the BIOS config screen, hold down space at the next boot and maybe everything will work out OK.

doubled112 4y ago
It has a number of keyboard shortcuts, and uses UEFI variables to store some of this config. It took me a long time to figure out what I did to change defaults by accident and how it stayed changed. Jumped the gun and typed my LUKS unlock password a moment too soon.

c7DJTLrn 4y ago

The biggest blocker for me using systemd-boot is that there's no signed EFI binary yet so you can't use Secure Boot (unless you want to enrol your own signing key, which is inconvenient and I'm not even sure is possible on cloud providers.) If you use Ubuntu, Canonical provide a GRUB binary signed by Microsoft's shim.

georgyo 4y ago
Here is a question for you, what value is secure boot providing you that you cannot get from an encrypted root filesystem with a TPM and systemd-cryptsetup. That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub. On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct. Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry... One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
- sgtnoodle 4y ago
  Secure boot doesn't prevent code from doing whatever it wants once it's running. It prevents the system from starting to run code that isn't trusted in the first place. That's still necessary even if you have a TPM. If you're storing your disk encryption key in a TPM, there needs to be an API for the OS init routine to access the key from the TPM. You can't depend on any secrets outside of the TPM before decrypting the storage (otherwise you wouldn't need a TPM), so instead you need to guarantee that the code accessing the TPM's API isn't malicious. Typically, once the OS reads out the storage encryption key, the OS then immediately asks the TPM to disable its API until a subsequent boot. From that point on the kernel has the key in RAM, and there's no way for unprivileged code to access it (other than bugs). Secure boot provides the mechanism to make that possible. If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure. Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.

sureste 4y ago

I pretty much did this too but in Arch Linux. It's just a script[1] that I run and I have it working with the linux and the linux-lts kernels. It's pretty nifty. It just works on Arch Linux since kernels don't have version numbers on the name I never have to touch again after installation. [1]: https://github.com/adcpe/sh/blob/main/boot.sh https://github.com/adcpe/sh/blob/main/boot.sh

shmerl 4y ago

Is there a way to use it with encryption without boot partition? GRUB is super slow decrypting LUKS.

Arnavion 4y ago
In a systemd-boot setup there is no "boot partition", encrypted or otherwise. There is an EFI partition that contains the systemd-boot EFI binary and the UKI binary, and it is a regular unencrypted FAT32 partition. The UKI will contain kernel + initramfs to be able to mount your encrypted root partition as `/`, using regular cryptsetup, not the special low-perf code used by grub. And to be clear, this is how UEFI boot would work even if you didn't have systemd-boot and had your firmware directly boot the UKI.
- shmerl 4y ago
  Hm, I don't want to put the kernel into EFI partition though. With GRUB the kernel sits in the encrypted /boot on the root. The catch is that GRUB can decrypt root on its own without the kernel, but it's super slow for some weird reason. So I need something similar, but without performance bottlenecks.
  - Arnavion 4y ago
    >Hm, I don't want to put the kernel into EFI partition though. Because?
    - shmerl 4y ago
      Let it be encrypted with everything else. That's the whole point of not using the boot partition.
      - Arnavion 4y ago
        >Let it be encrypted with everything else. Why?

kamyl 4y ago

If you're lucky and your machine supports coreboot there is even better way to boot into linux - use slimmed down linux kernel as a direct payload of coreboot and kexec into your actual kernel. This way you're skipping any disadvantages of grub (if you can name any which matter) and don't need to deal with relatively new and not as much battle tested code to boot your trusted kernel.

pabs3 4y ago
Does this mean you're installing Linux into write-limited flash? If so that could eventually brick your system.
- kamyl 4y ago
  No, just an intermediate kernel is written into flash memory along with coreboot. It doesn't wear little flash chip as it doesn't write anything which needs to persist, that's actually one of the points of this solution. Its sole role is to chain-load your destination kernel. So you just basically move your bootloader into non trivially writable memory (as it can be write-locked) to make it more tamper proof. There is always a risk of bricking your system if you're not careful, but wearing off flash isn't one of those risks if that's the concern.
- KirillPanov 4y ago
  Nope; bootloader flash chips use NOR instead of NAND flash precisely to prevent this. NOR flash guaranteed for a minimum of 100,000 complete rewrites of every cell, with no flash translation layer gimmickery. The downside is that it is very expensive, which is why a few dozen megabytes of NOR flash costs as much as many gigabytes of MLC NAND. Typical NOR flash chip; "Minimum 100,000 Program/Erase Cycles": https://www.gigadevice.com/flash-memory/gd25b127d/ NAND flash vendors often advertise "up to" a similar number of P/E cycles on their SLC devices, but you'll have a hard time getting them to guarantee that. And for TLC and MLC NAND you find in non-industrial products the number is more like 3% of that: https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand TL;DR: bootloader flash chips are chosen such that they are nearly impossible to "wear out".

throwawaaarrgh 4y ago

At some point somebody's gonna make a distro that's just Systemd and a kernel.

still_grokking 4y ago
I'm waiting for that. Would be the ultimate base OS. But it's not so easy. I actually looked into all the dependencies of a Linux system and it turns out to be an extremely entangled monolith at the core. Everything depends on everything. So you actually can't have "just a kernel and systemd as 'user-land'".
- zh3 4y ago
  Ever tried setting 'init=/bin/sh' on the command line? That gets you a shell (or any other program you care to run) and from there a little creativity is all it takes.
- IceWreck 4y ago
  > actually looked into all the dependencies of a Linux system and it turns out to be an extremely entangled monolith at the core Any resources for this ? Most books I've read/seen are either about Linux kernel internals or using userspace Linux. I'd like to know more about what actually goes into making a complete usable distro.
  - bmicraft 4y ago
    Linux from scratch might be something you want to take a look at
- throwawaaarrgh 4y ago
  Systemd and a stripped down BusyBox would do it. That's what Alpine is, plus libmusl, minus Systemd.

prima-facie 4y ago

Is there any way to add a 'Shutdown' and 'Reboot' menu entry to systemd-boot? Like you can with Grub? This has been holding me back from switching all my machines to systemd-boot. Mainly because I have an Optiplex micro hidden behind my monitor, where I use the keyboard to power on. Sometimes accidental power-ons happen so it's good to have that menu entry.

prima-facie 4y ago
I've found the answer: https://aur.archlinux.org/packages/powerofforreboot.efi https://aur.archlinux.org/packages/powerofforreboot.efi This works well on my system, YMMV.

dijit 4y ago

Last year I decided to go whole hog on Gentoo. It was a failed experiment overall, too much recompiling even for me, however one thing I did get out of it was that I discovered I didn't need a bootloader. You can boot Linux as an EFI executable. Granted, you cannot pass any dynamic boot arguments to it, and initramfs is out of the window it seems (or I just never got it working), but it was remarkably easy to add the commandline options I wanted into the kernel at compile time and just call it as an executable automatically from the EFI BIOS of my motherboard.