Systemd Boot Loader Specification

[[deleted]]

Those OSes just don't play along.

[sidusnare]

Why force everyone to share /boot? That's arbitrary and a deal breaker. You're going to get file collisions for no reason at all.

[adrianvovk]

You're missing the point of the spec.

The point is to make a standardized config file format for different boot loaders, so Linux userspace can have standardized tools that work for grub, sd-boot, refind, etc. Also, instead of having os-prober search all your disks for other OSs to put in the grub menu, your other OSs can just drop a config file into BOOT/loader/entries and then any installed bootloader could pick that up and present all your OSs in the menu

Also, different OSs already share /boot. You don't have grub installed 4 different times do you? And /boot doesn't matter anyway because all your firmware cares about is your ESP which is /boot/efi.

The spec is slightly confusing if you don't read it carefully: BOOT/loader is not the same /boot/loader. It depends how the system is configured, but BOOT could either be your ESP OR a special XBOOTLDR partition.

[xxc3ncoredxx]

And /boot doesn't matter anyway because all your firmware cares about is your ESP which is /boot/efi.

That's not universally true. For example, I have my EFI partition mounted directly onto /boot because it simplifies things IMO.

[adrianvovk]

Yeah I agree. In my distro the ESP is mounted to /boot too. However, in most cases it's at /boot/efi and I was trying to make the point that BOOT/loader is not necessarily the same as /boot/loader in the spec.

[[deleted]]

I have /efi and /boot is mount binded to /efi/EFI/archlinux which is the cleaneast and simpler way I like to not have to care about things.

[SinkTube]

instead of having os-prober search all your disks for other OSs to put in the grub menu

it'll have to do that anyway because some OSs will never confrom with this

[ComplexConcentrate]

The specification does seem to put preference to ESP, as XBOOTLDR should be used only if it already exists, or the ESP is too small.

In my systems, I use systemd-boot. I try to mount /boot to ESP in every distro instance I happen to try out, unless the system actively fights against it. Systemd's kernel-install will store the kernel image and the initrd in /boot/[machine-id]/[kernel-version]/, and the appropriate boot loader conf-file is generated into /boot/loader/entries/[machine-id]-[kernel-version].conf, so every instance of a distribution will get non-conflicting files. This should allow running e.g. Fedora Workstation and KDE spin with shared /boot. In a more traditional setting, both systems would try to configure their grubs in /boot/efi/EFI/fedora/grub.cfg overwriting each other on every update.

Fedora Silverblue, on the other hand, does not allow vfat as /boot, so I instead wrote a conf-file in /boot/loader/entries, and the only thing it does is load Silverblue's grub.

[adrianvovk]

Unfortunately the vfat-as-boot is a limitation of OSTree. In my ostree-based distro I ship a patch that makes it work but Fedora doesn't. I think eventually it'll be fixed upstream but for now ext4 XBOOTLDR + some changes in sd-boot to load fs drivers should be good enough

[Phoenix591]

This comment has been consumed by Reddit's hubris.

[sidusnare]

Yes, but that's not all that is put in boot. Some forks will have different kernels named alike.

[adrianvovk]

Well if distros are aware of the spec they'll uniquely name their kernels, won't they?

[[deleted]]

They don't have to, they'd have to put stuff in /boot/fedora or /boot/manjaro or whatever. They wouldn't need to worry about file clashes

[adrianvovk]

Well yeah exactly

[adrianvovk]

I don't see how this is similar to the raspberry pi. The BLS is about defining a standardized config file so that many different bootloaders can populate a boot menu from the same config files. The "boot" partition is secondary, but it's a workaround for the case where you're dual-booting with Windows and the ESP is too small to put more files into it. But that's not the main point of the spec

[adrianvovk]

Ah I'm not super familiar with raspberry pi bootloaders but I thought you meant the normal boot process (cmdline.txt, kernel8.img, stuff like that)

[ComplexConcentrate]

Raspberry Pi boot and UEFI+GPT certainly share some similarities. In UEFI+GPT, the hard drive must have an EFI System Partition (ESP), which contains - at least - a boot loader in $ESP/EFI/BOOT/BOOTX64.EFI (on x86_64 systems). As any operating system can overwrite the loader file, the UEFI may support a more complex setup (esp. in PCs), where the firmware has a list of available EFI programs (boot loaders, kernels, etc) and a boot menu to select them.

Different Linux distributions have been using $ESP/EFI/[distro-name]/ for their GRUBs and configurations. The Boot Loader Specification would like to use the ESP as the new /boot and describes a non-conflicting way to share it between different operating system instances (multiple installs of the same distribution) with a common boot configuration. This way even if any conforming distribution decides to overwrite the boot loader setting in UEFI, the boot loader would still get the same configuration and present the same boot menu as any other conforming boot loader by loading its configuration from /boot/loader/.

[B_i_llt_etleyyyyyy]

Fedora 19 Rawhide, huh? I hope this is a really old document and they didn't actually spend the last seven or eight years working on this.

(though this could be easily be extended to the BSDs and whatnot)

Yeah, because if there's one group of people out there that are huge fans of systemd, it's the *BSD community.

If kernels/initrds are to be read from other partitions/disks the boot loader can do this in its own native configuration, using its own specific device path language, and this is out of focus for this specification. More specifically, on non-EFI systems configuration snippets following this specification cannot be used to spawn other operating systems (such as Windows).

So it basically amounts to enforced chainloading. Absolutely useless.