It might surprise you to know this but systemd-boot does not support, among other things: "BIOS"/MBR boot, EXT4, XFS, mdraid, LUKS (hidden boot), OPAL (aka hardware FDE, self-encrypting drives) or even btrfs!
mdraid being pretty critical to a lot of server work.
Then there's the topic of altering bootloaders for distro's which value stability, it wouldn't happen in a point release.
That's a feature :). Unless your firmware doesn't have UEFI support (I'm looking at you, Gen8 Proliants...), you should use UEFI.
> EXT4, XFS, mdraid, LUKS (hidden boot),
It doesn't support ANY filesystem (does it defer to builtin UEFI filesystem drivers?); it loads kernel and initramfs from the EFI partition itself. You can then have whatever you want compiled in.
Grub, on the other hand, has read-only drivers, so it will load your kernel and initramfs from any /boot partion you want (except zfs pool with some features enabled).
> OPAL (aka hardware FDE, self-encrypting drives)
Now this could be a problem, however, normal UEFI has to work somehow.
> mdraid being pretty critical to a lot of server work.
Many servers boot from internal sd-card or usb, and if they have local drives, they are put into use when whatever system from the sd-card or usb boots.
Why is that? It's a serious question. I use BIOS boot on all my systems after failing to install Linux (Qubes, Arch, Fedora) on several machines until I switched to BIOS boot.
Is there anything I'm missing out on by using BIOS?
The legacy BIOS way is basically that the BIOS will read the first sector on the first disk, check the magic bytes and if are OK match, jumps to it (executes it). All this in 16-bit real mode. For runtime services (sleep, hibernate, display backlight, etc), BIOS32/ACPI entry points are used. The services are more limited than the UEFI versions, no Secure Boot for example. For preparing/installing such a boot sequence, you need special tools, and hope, that it won't clash with anything - eventually filesystems learned not to use first few megabytes of their partition.
If you have multiple operating systems, they might not play nice with each other and each might fight for the ownership of this magic sector.
For network boot, PXE is used. Basically DHCP request, with reply containing TFTP server and image name. BIOS will then download that using tftp and execute it (still 16-bit real mode). To avoid the limits, many use iPXE - basically download more advanced loader over tftp and hand over control to it.
For UEFI, there is no magic. There is a partition formatted with FAT32 filesystem (some implementations support also other filesystem, i.e. Intel supports NTFS and Apple has also their own; but the specification makes only FAT mandatory), called ESP - it has specific GUID, though - where operating systems place files that they want the boot manager to find. Boot manager is an integral part of the firmware, so if you have multiple operating systems, you can choose which one to boot even if the operating systems (or their bootloaders) do not cooperate and do not allow booting other operating systems on your machine. For OEMs, it allows placing system tools, like diagnostics or system restore, into ESP partition too. For power users, you can place UEFI shell (if your firmware doesn't include it) here. Boot happens in protected/32-bit mode, and the runtime services are much more advanced - maybe too much, the specification has several hundred pages and many consider it bloated. A thing that might interest some, that you can instruct the firmware, how it is supposed to boot next time - you can reboot from operating system into firmware configuration without pressing magic keys at boot at the right time (`systemctl reboot --firmware-setup`). There's also standardized way to update the firmware itself ("UEFI capsule"), so there's no problem updating it, even if you are not running Windows, which used to be a problem in the past. The network boot can happen via http, including DNS resolving, where the DHCP will return URL and the firmware will fetch it. And other many quality-of-life improvements.
There have been some machines, that had their firmware thrown over the wall (mostly those cheap netbooks and tablets), where if it booted the supplied system, it was considered ready to ship. On normal, business class laptops, enthusiast desktop motherboards or server machines, I've never had a problem (except that unfortunate gen8 proliants, where HP doesn't support UEFI intentionally and limits you to legacy BIOS). The important thing to avoid having problems with UEFI is to treat is as UEFI, not as legacy BIOS.
As I wrote elsewhere on HN, Intel had a roadmap wrt UEFI, where since 2020 they wanted to go UEFI class 3 only (that means no CSM - legacy BIOS - support, UEFI only). Presentation on this should be findable on the interwebs.
* systemd-boot doesn't support those filesystems as the /boot partition, all of those things for your / are totally fine. For most people having your /boot partition be XFS vs FAT32 is firmly in the "who cares?" realm.
* Nobody really supports OPAL, even grub. The only reliable solution is using https://github.com/sedutil/sedutil to unlock the disk and then soft reboot into any normal bootloader.
* You can do mdraid, you just have to stick the metadata at the end of the drive rather than the beginning. The utilities that set up your raid even warn you about this because this setup is so standard.
XFS is also not supported. But yes, your /boot can be fat32, but saying "nobody cares" is just needlessly dismissive, I can think of many reasons to care at least a little. Primary of which is lack of encryption and ability to mirror easily, another can be the possible corruption of /boot (FAT is not typically used for it's data consistency properties)
> Nobody really supports OPAL, even grub. The only reliable solution is using https://github.com/sedutil/sedutil to unlock the disk and then soft reboot into any normal bootloader.
I guess this is a fair statement, if you ignore that the "PBA" is actually using grub itself, but yes, the PBA is non-encrypted and usually lives as a separate partition, making it functionally equivalent between systemd-boot and grub2.
> You can do mdraid, you just have to stick the metadata at the end of the drive rather than the beginning. The utilities that set up your raid even warn you about this because this setup is so standard.
You can't boot to an mdraid device with systemd-boot, you can only have a separate (non mirrored or raid'd) partition on a drive, and point to that drive to boot.
Sorta kinda true in theory but not in practice. Yes systemd-boot isn't raid aware but if you configure mdraid to store its metadata at the end of the drive then you wind up with a, say, mirrored disk that to the firmware doesn't look like it's mirrored at all. And since the firmware just reads the partition it's safe and works.
So yes, you have to configure your firmware to look at both drives in a mirrored setup as a fallback but you can boot.
> but saying "nobody cares" is just needlessly dismissive
Fair, I'm more saying that having firmware that only supports a small set of simple filesystems is the usually the more normal situation, the fact that GRUB comes with all the drivers makes it the weird one.
You're screwed when the firmware decides to write to the ESP though.
It's hardware RAID or nothing, at least for the ESP for me!
I think this is the perfect analogy why systemd-boot is better: you don't want to use a truck to get to your local bakery, it is going to be either a walk (ESP boot directly with kernel anyone?) or with a bicycle.
No, mdraid is not critical for server work. Never run mdraid for production, it will fail, you will lose data.
Servers use hardware RAID, either on a dedicated card or integrated into the MB.
Is it able to use serial console for remote control?
Can it boot non-Linux non-systemd OSes?
Does it handle encrypted disks better than GRUB2 does?
Does it work well if I prefer bios/dos/mbr mode?
Yes, just press 'e' as long as editor=yes in the loader config.
> Can it boot non-Linux non-systemd OSes?
Yes, auto-entries will find Windows automatically and other EFI images can be set up through loader configs. Not sure why it wouldn't work with non-systemd systems considering that's an init system and it's a bootloader.
> Does it handle encrypted disks better than GRUB2 does?
Doesn't the initramfs handle decryption of disks?
> Does it work well if I prefer bios/dos/mbr mode?
No, it doesn't support BIOS boot.
This is also used for boot time or boot repair tools. UEFI shell for example is just another EFI image.
https://superuser.com/questions/1278841/bitlocker-asking-for...
I cant find the reference I'm looking for which was a decent explanation about why the days of traditional style dual booting where the Linux boot loader let's you choose between Linux or Windows using GRUB to choose between Linux and Windows were over, but that question basically covers the same ground.
Systemd also supports using kexec to reboot a machine booted with systemd-boot for faster OS updates. Of course you can use kexec without all of that, but anyone who has knows that it's not exactly streamlined whereas with systemd-boot it'll use the kernel image, initrd, and kernel cmdline straight from what the bootloader is configured for. For UEFI it really is great, only thing "missing" IMHO is support for adding boot entries for EFI stub kernels directly to skip the bootloader entirely for the fast path and rely on the UEFI bootloader if you need access to systemd-boot or an older kernel. Not too relevant for servers where it shaves off like 700 ms or so but still a neat trick and I like my desktop booting without an extraneous extra bootloader when it's not needed.
Can distros maybe consider moving to systemd-boot at some point? Systemd is already built in and can handle things like mounting pretty easily and simply.
It is a hell of a lot leaner than grub, doesn't use a billion superfluous modules. That and it is a lot easier to prevent tampering compared with the cumbersome nonsense that is grub passwords.
Oh and it enables distros to gather accurate boot times and enables booting into UEFI direct from the desktop.
It works with secureboot/shim/Hashtool. Also each distro has it's bootloader entries in separate folders to avoid accidental conflicts.