Get the top HN stories in your inbox every day.
rsyring
gbin
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.
Arnavion
systemd-boot is also pretty hands-off. My distro's (OpenSUSE Tumbleweed) kernel packages build regular initrd images in package postinstall, but since the postinst script uses dracut I just had to drop a dracut config (`uefi=yes`) in /etc to make it build UKIs in /efi instead. systemd-boot automatically picks up those UKIs.
I just have to remember to delete the UKIs manually when I uninstall the corresponding old kernel package, otherwise the EFI partition would fill up eventually. If my distro ever switches to UKIs by default then the postuninstall script would handle that automatically.
veidr
I also switched to REFind because I wanted to boot my various Linux installations from encrypted ZFS pools, but after realizing how much more convenient it was (because it can just boot from whatever bootable OS installation it finds by scanning the disk), now I always use it instead of grub, regardless.
I noted recently that it also sees systemd-boot installations and will boot from those, if desired (in my case it was a fresh installation of Pop OS, which uses systemd-boot by default).
For me, it's unambiguously better (meaning easier, with no extra periodic steps required to maintain my ability to boot whatever bootable thing I want), but I am curious about what scenarios would make one want to use systemd-boot (or grub) instead.
rfoo
> I am curious about what scenarios would make one want to use systemd-boot (or grub) instead.
I have Linux VMs which boots in ~2s (to ssh login; ~700ms to userspace). I use systemd-boot because it has nicer integration with my distro of choice than bare EFI stub, and it adds very minimal overhead in boot time.
alias_neo
That's pretty impressive, can you share some information about what you're using to achieve that?
indigodaddy
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?
rsyring
Yes. But when I did this I had to modify some things in my Dell's BIOS to get it to run refind from the USB.
More a Dell thing than refined I believe.
avhception
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.
hashhar
For examples of how amazing rEFInd can look - see https://github.com/hashhar/rEFInd-theme/ and https://github.com/EvanPurkhiser/rEFInd-minimal
Tha_14
I also used to use rEFInd while I was running macOS/windows dualboot for a short time. I am going back to it from grub now since booting from my zfs root partition with grub has become a hassle.
MobiusHorizons
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?
fuzzy2
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
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
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
> 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
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.
m4lvin
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 :-)
still_grokking
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
> 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.
abnry
> 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
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.
nubinetwork
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)
noodlesUK
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
I think Fedora is moving to this? https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...
dezgeg
Because having boot menu for stuff like older kernels, recovery mode, and access to kernel command line is pretty useful.
Asmod4n
You don’t need a boot manager for that except the one built into your motherboard.
usr1106
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.
Kwpolska
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.
veidr
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.
AshamedCaptain
Most UEFI devices out there don't have any type of boot menu.
MobiusHorizons
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.
greyw
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.
rodgerd
> 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.
teo_zero
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.
Asmod4n
Only thing that comes to mind is if you swap disks between machines and want the same boot menu on all of them.
klooney
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
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.
smackeyacky
For the lazy, here's a couple of links.
https://wiki.archlinux.org/title/systemd-boot https://www.reddit.com/r/archlinux/comments/mxzfox/systemdbo... 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.
andrewstuart
I find booting, grud, uefi and related technologies are one of the most complex and hard to make sense of parts of modern systems.
xxpor
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/Devicetree is an alternative, but it's a massive pain because you lose PnP.
userbinator
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
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
> 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.
wolletd
On some devices, I see the line "EFI stub: load initrd from command line option" (or similar) as just another line on the same text screen that prints early UEFI messages.
And I'm still wondering about that and how text-mode/console output works.
I get it when I'm attached via a serial port, but... how many console rendering implementations for VGA output are on my system?
garblegarble
I think that's handled by the graphics card's EFI Graphics Output Protocol[1][2] driver
yjftsjthsd-h
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)
still_grokking
That's just how it is. Booting arbitrary hardware is an inherently complex problem.
Regarding modern PCs: Even I think UEFI is in large parts over-engineered crap it made at least booting simpler and much more sane.
c7DJTLrn
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
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-cry...
One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
sgtnoodle
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.
georgyo
The TPM api isn't disabled after boot, and things still use it the computer starts up. IE, it's possible to use the TPM for ssh/gpg keys. Other things like esims and password managers can still use them.
It also isn't something that any software can use to just spit out the secrets it stores. The whole point of the TPM is that it will only release information if the measurements of the system match. IE, if I chainload grub->window that will cause a different measurement then it the system just booted windows.
But again, secure boot will only run signed images, but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.
still_grokking
Secure Boot without enrolling your own keys and deleting the shipped ones is not more than snake oil.
In such a case you can just disable it as it doesn't provide anything than additional hassle.
cedws
Sorry, I think you misunderstand the purpose of Secure Boot.
candiddevmike
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
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
What difference does it make what boot loader cloud providers use?
pabs3
ISTR there is work on making GRUB do that.
aliqot
Can you still use LiLo these days on a systemd enabled system?
boomboomsubban
Seems like it. https://wiki.archlinux.org/title/LILO
dijit
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.
wooptoo
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.
wooptoo
I've found the answer: https://aur.archlinux.org/packages/powerofforreboot.efi This works well on my system, YMMV.
shmerl
Is there a way to use it with encryption without boot partition? GRUB is super slow decrypting LUKS.
chlorion
I think encrypting your boot partition and kernel is not very useful. The "better" (IMO), would be to sign the kernel and use secureboot, but otherwise leave it unencrypted. This way the kernel and whatnot can't be tampered with and you don't have to deal with an encrypted boot partition.
I don't think there would be anything in your kernel or bootloader that needs to be confidential!
shmerl
Well, kernel version is already some information. Whatever it gives. It's not about guessing how useful that information is. It's about minimizing it by default.
undefined
Arnavion
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
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.
michaelmrose
It's advantageous for the process of trying a passphrase to be too slow to do a million times a second but fast enough that it isn't bothersome to the user. This is a tunable parameter --iter-time given in ms when adding or modifying a passphrase to a slot.
If I understand correctly its cryptsetup luksChangeKey DEVICE --iter-time <time in ms>
Consult your manual and backup before making any changes to encrypted devices lest tragedy ensue.
2 things of note.
- Luks slots are tried in succession adding a second faster slot after a slow slot will be slower because it will try the slow one first fail then unlock with the fast slot.
- You should back up your luks header because a small amount of corruption in the right place can make the entire encrypted volume unrecoverable
Arnavion
>Hm, I don't want to put the kernel into EFI partition though.
Because?
throwawaaarrgh
At some point somebody's gonna make a distro that's just Systemd and a kernel.
still_grokking
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'".
IceWreck
> 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
Linux from scratch might be something you want to take a look at
zh3
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.
throwawaaarrgh
Systemd and a stripped down BusyBox would do it. That's what Alpine is, plus libmusl, minus Systemd.
Get the top HN stories in your inbox every day.
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://wiki.archlinux.org/title/REFInd
- https://github.com/rsyring/zfs-on-root/blob/master/zor.py