Enhancement: Allow Systemd-boot to deal with multiple ESPs

[brittyazel]

This is a request for enhancement to what is now the current 229 version of Systemd found in the Archlinux repositories.

I recognize that "proper" protocol is to only have a single EFI system partition on a single system, however there are multiple reasons that this is not ideal for many users. One major issue being that any secondary drive will always be a slave to the drive with the ESP, thus if that drive crashes and/or is removed, no drive can be booted.
Further, for those of us with Windows dual-booted, Windows is often unpredictable with updates and sharing a ESP with Linux can often result in the LinuxOS being treated as a second class citizen. One major issue is with Windows' "fastboot" option, which can leave the ESP unwritable for any other OS. This is a major bummer, and causes serious issue.

That being said, as I don't want my Linux SSD slaved to my Windows SSD, I have an ESP partition on each drive. This setup, which functional (as I can switch between each OS from my bios boot menu) is not ideal, as systemd-boot can only see the boot options within 'its' ESP.

I propose, if it is technically feasible, that systemd-boot be able to recognize and be able to boot from foreign ESPs to the one currently housing the bootloader. This would allow a Windows drive and a Linux drive to stay fully isolated from one another while still retaining a working and unified boot experience.

This would be akin to how the legacy-bios method of booting a system functioned. And, while I am not 100% sure, I believe that the uefi variant of Grub2 has the aforementioned request already integrated.

sorry for any mistakes in my bug report, this is the first one I have posted to the systemd community. Cheers!

[prodrigestivill]

I added documentation on ArchLinux Wiki about how to perform this using an external edk2-shell script.

[Vladimir-csp]

How about a situation with multiple equivalent redundant internal disks?
On my laptop setup I have two nvme drives with btrfs raid and two ESPs mounted at /boot/efi and /boot/efi.1. Data and EFI boot entries are duplicated with a custom script that supports duplication to any /boot/efi.N mountpoints.

[Vladimir-csp]

Hacked existing hooks a bit to support my /boot/efi.N efi duplicate scheme. As long as bootctl --esp-path=/boot/efi.N install was performed, these seem to work:

/etc/initramfs/post-update.d/systemd-boot-duplicate

#!/bin/sh

set -eu

test -x /usr/bin/bootctl || exit 0

for EFI_DUPE in $(findmnt -lno TARGET | grep -E "$(bootctl -p)\.[0-9]+")
do
	if mountpoint -q $EFI_DUPE && bootctl --esp-path=$EFI_DUPE --quiet is-installed
	then
		echo "Updating kernel version $1 in systemd-boot on $EFI_DUPE..."
		export BOOT_ROOT=$EFI_DUPE
		kernel-install add "$1" "/boot/vmlinuz-$1" "$2"
	else
		echo "Found duplicate $EFI_DUPE, but sd-boot is not installed there"
        fi
done

/etc/kernel/postinst.d/zz-systemd-boot-duplicate

#!/bin/sh

set -e

test -x /usr/bin/bootctl || exit 0

for EFI_DUPE in $(findmnt -lno TARGET | grep -E "$(bootctl -p)\.[0-9]+")
do
	if mountpoint -q $EFI_DUPE && bootctl --esp-path=$EFI_DUPE --quiet is-installed
	then
		echo "Installing kernel version $1 in systemd-boot on $EFI_DUPE..."
		export BOOT_ROOT=$EFI_DUPE
		kernel-install add "$1" "$2"

	else
		echo "Found duplicate $EFI_DUPE, but sd-boot is not installed there"
        fi
done

/etc/kernel/postrm.d/zz-systemd-boot-duplicate

#!/bin/sh

set -e

test -x /usr/bin/bootctl || exit 0

for EFI_DUPE in $(findmnt -lno TARGET | grep -E "$(bootctl -p)\.[0-9]+")
do
	if mountpoint -q $EFI_DUPE && bootctl --esp-path=$EFI_DUPE --quiet is-installed
	then
		echo "Removing kernel version $1 from systemd-boot on $EFI_DUPE..."
		export BOOT_ROOT=$EFI_DUPE
		kernel-install remove "$1"
	else
		echo "Found duplicate $EFI_DUPE, but sd-boot is not installed there"
        fi
done

[Vladimir-csp]

I still use this configuration, made it through countless kernel upgrades without any issue.

[TriMoon]

The original issue in the OP is actually something that the UEFI-BIOS needs to support, and AFAIK already does by adding entries that reside in other ESP's from other disks in the UEFI-Boot menu.

For the functionality with systemd, the user just needs to install sd-boot on the other ESP's also with it's own loader entries that point to kernels on that ESP.

sd-boot is not an UEFI-Boot menu, it is just a bootloader that creates a menu to choose EFI-bnaries to startup from a text file: https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-entry-keys

That Specification doesn't have entries that specify which Disk/partition the efi-binaries reside on, because it uses the ESP where the boot-loader was loaded from.

So the only way to use multiple ESP's in combination with sd-boot is to:

1. Install multiple sd-boot's, one per ESP you want and add that sd-boot to the UEFI-Boot menu.
2. Petition for the The Boot Loader Specification(@ UAPI Group Specifications) to be enhanced/changed to add optional device/partition info for the entries in their specification.
3. Buy the maintainer(s) of sd-boot enough gifts to persuade them to enhance sd-boot in such a way that it automatically parses loader-entries in other ESP's and add the device info itself internally for those. 😼

I'm sure that (3) wouldn't be so hard to implement, but not sure if the maintainers are willing to spend time on implementing this.
What do you think @poettering 😉

[poettering]

I think the only reasonable way to address systems which want to boot from multiple equivalent/redundant disks is to install the boot loader + kernels on all of them in parallel. i.e. maintain one separate ESP for each disk, and make sure that "bootctl install"/"bootctl update" will install/update the boot loader on each simultaneously. Similar, the "kernel-install" infra structure should also replicate the kernels it installs onto all ESPs.

This replication should happen on the fs level – not the block level – though, since sd-boot/sd-stub form uefi mode will also write to the fs (to maintain boot counters, random seed, …) and thus the raid structures would be constantly out of sync.

And it does not come without limitations, as precisely those boot counters, random seeds are maintained per ESP: thus if you switch between disks, the boot counters will continue at different points.

Anyway, this all requires primarily somebody to write the necessary code for bootctl/kernel-install, in particular shoehorn this in without making the code terrible to read.

Also, this would require some policy decisions as to where to look for such ESPs, and also how to handle software that looks for just "the ESP", and suddenly will be confused by multiple of them.

[TriMoon]

@poettering i think you misunderstood the use-case that was asked, at least so far i could deduct.

AFAIK they don't want to maintain duplicate kernels on different ESP's, they just want sd-boot to recognize and be able to boot entries in other ESP's, with their own loader entries on that ESP...

Thus the following scenario will be the use-case:

1. ESP A has it's own sd-boot and loader entries.
2. ESP X has it's own sd-boot and loader entries.
3. sd-boot, no matter which one is started by the UEFI-BIOS, would be able to read all loader entries from all ESP's and start the efi binaries on those ESP's using internal disk/part info.

Thus sd-boot is asked tobe able to "find" ESP's on multiple disks, fe using the PART-TYPE in the GPT tables, and use the info of the loader entries if any...

This means there is no need, although it would be a recommendation, to sync the sd-boot binaries on all ESP's but not the kernel's / initrd's / UKI's.
And there would not be a need to worry about boot counters etc etc on the different ESP's as they are all separate and autonomous, they could be used according to the loader entry that is selected to boot.

[tesfabpel]

I have a friend that's using multiple OSes on different disks and he uses GRUB and there he can select other OSes in the GRUB's boot menu (I tell him that he can press F8 during boot to choose the OS to start but I admit myself that's not really user friendly).

With GRUB, this is done via os-prober, a tool that's launched during grub-mkconfig (often invoked during a system update) that scans other disks and emits entries in the grub.cfg file.

To replicate the same behaviour here, two different ways could be explored:

• a similar tool could be used that scans for other systemd-boot instances in other disks' ESPs that's invoked either automatically by the system during updates or manually by the user;
• alternatively (maybe under a config option), populating the systemd-boot menu at boot-time with other systemd-boot instances by scanning the ESPs of attached disks. Maybe under a sub-menu so that faulty disks don't hang the main boot menu itself (eg. a "Other Disks >" entry in the main menu)?

BTW, doing it at runtime would allow the user to choose a USB live disk or a system installed in a portable USB HDD.
The runtime option is similar to what rEFInd and macs do when started with Option (Alt) pressed.