systemd version the issue has been seen with

249

Used distribution

Ubuntu 22.04

Linux kernel version used

5.15.0-40-generic; 5.15.0-37-generic

CPU architectures issue was seen on

x86_64

Component

bootctl

Expected behaviour you didn't see

Boot entries conforming with the Boot Loader Specification according to (a) its language; and (b) the output of bootctl list, which according to its documentation returns conforming entries, would be observed and appear in the list on the systemd-boot screen.

Unexpected behaviour you saw

Conforming entries do not appear in the systemd-boot list.

Specifically, systemd-boot, perhaps relying on systemd-bootx64.efi, does not recognize paths to kernel files on the file system of the EFI mount point or otherwise not on the ESP, e.g., ../vmlinuz or ../initrd.img.

It is elementary that the entire purpose of any boot loader (and therefore systemd-boot, perhaps in conjunction with systemd-bootx64.efi), after all, is simply to hand off execution to kernel files on another partition and file system. systemd-boot seems incapable, however, of reading them.

Indeed, the entire construct of kernel-install and its related bootctl options, appears designed to compensate for the absence of this capability. It attempts too much. Das Gummiboot wird gesunken. Establish this fundamental read capability and none of this is necessary. Kernel files can remain encapsulated on the partitions they boot and kernel installation and update procedures can be left intact.

Steps to reproduce the problem

This is a multiboot Linux system, chiefly with different versions and flavours of Ubuntu installed on discrete partitions, all on a single volume. The ESP is /dev/sda1, /dev/sda2-7 are bootable, /dev/sda8 is swap, and /dev/sda9 is data. The installations were competing for control over the GRUB boot loader, prompting an attempt to replace it with systemd-boot.

The base configuration is a conventional Ubuntu Desktop 22.04 installation:

• Kernel files are located in /boot, along with the symlinks vmlinuz and initrd.img, which reference the latest versions.
• The ESP is mounted to /boot/efi via fstab.

/boot/efi/loader/loader.conf is:

#	/boot/efi/loader/loader.conf
#	systemd-boot configuration file

timeout 5
#default [machine-id redacted]-*
#	From man loader.conf, Options, default, at https://www.freedesktop.org/software/systemd/man/loader.conf.html:
#default @saved
default sdx4.conf
console-mode keep

/boot/efi/loader/entries/sdx3.conf is:

#	/boot/efi/loader/entries/sdx3.conf
#	Boot entry configuration file.

title sdx3 - Ubuntu Desktop 22.04
linux ../vmlinuz
initrd ../initrd.img
options root=PARTUUID=[PARTUUID redacted] rw

# bootctl list returns:

        title: sdx3 - Ubuntu Desktop 22.04
           id: sdx3.conf
       source: /boot/efi/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/efi/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.

Additional program output to the terminal or log subsystem illustrating the issue

No response