Open ebsf1 opened 2 years ago
Further work and research reveals that the issue is that systemd-boot does not support the Boot Loader Specification. The command bootctl list
is the syntax checker for boot loader entries conforming with the latter according to its documentation and returns:
title: sdx3 - Ubuntu Desktop 22.04
id: sdx3.conf
source: /boot/loader/entries/sdx3.conf
linux: ../vmlinuz
initrd: ../initrd.img
options: root=PARTUUID=[PARTUUID redacted] rw
title: sdx4 - Ubuntu Desktop 22.04
id: sdx4.conf
source: /boot/loader/entries/sdx4.conf
linux: /vmlinuz (No such file or directory)
initrd: /initrd.img (No such file or directory)
options: root=PARTUUID=[PARTUUID redacted] rw
So it is that we see that specifying the kernel files' location as being in the parent directory of the EFI System Partition's mount point by using the ../ path conforms not only with the language of the Boot Loader Specification (which I should hasten to add contains no language requiring kernel files to be located on the ESP) but also with the code that implements it.
Sadly, the only consequence of installing and configuring systemd-boot on a machine in a multiboot Linux configuration is that it boots to the GRUB shell, i.e.,
grub>
Exiting the GRUB shell takes one to yet another GRUB shell. Exiting those in succession eventually returns the message (capitalization and spacing as in the original):
StartImage failed: Load Error
which leaves the system unresponsive to keyboard input, including Ctrl+Alt+Del. The only recovery is from a hard system reset or power cycle.
In previous iterations of configuration (I've been through dozens over the past eight days), exiting the initial GRUB shell would take one to the systemd-boot menu, albeit with none of its configured boot entries. The only menu entries were for the default Linux boot loader and system firmware, and often only the latter.
A brief synopsis of the configuration:
There is one volume, /dev/sda. For reference, this becomes /dev/sdb when backup media is installed. It hasn't been during this process, and so isn't relevant to this problem, but this must be anticipated.
The ESP is /dev/sda1. It is mounted to /boot/efi via fstab:
UUID=D69D-D8D4 /boot/efi vfat umask=0077 0 1
A variety of Linux versions and flavors in various stages of configuration are installed on /dev/sda2-7. Swap is on /dev/sda8 and data are on /dev/sda9.
The boot manager / loader heretofore has been GRUB2. The reason to switch to systemd-boot is competition among the systems for control of the boot loader.
tree -pugsDF
returns:A comparison of file dates and times tells me that
bootctl install
failed to write systemd-bootx64.efi to anywhere but /EFI/systemd/.Also, note that additions and deletions to boot entries by
efibootmgr
selectively fail to persist over reboot, especially if the motherboard firmware utility is accessed.loader.conf is:
The files in /EFI/loader/entries are in the form of:
bootctl status returns:
This begs many questions including:
Any thoughts about how to get systemd-boot to observe its configuration would be especially welcome.