Thursday, May 2, 2024
Homepage · boot
 Popular · Latest · Hot · Upcoming
0
rated 0 times [  0] [ 0]  / answers: 1 / hits: 1455  / 2 Years ago, thu, september 1, 2022, 12:56:33

I am replacing GRUB with systemd-boot on a multiboot system with several instances of Ubuntu 20.04 and 22.04 on discrete partitions because the instances are competing for control of the bootloader grubx64.efi and systemd-boot apparently manages this better.


The installation is failed and resisting configuration. In particular, systemd-boot ignores configured boot entries and often the system boots to the grub shell, requiring manual boot.


The process I followed was as recommended. The ESP is /dev/sda1 and by default is mounted to /boot/efi. Boot partitions are /dev/sda2-7, with 2, 4, and 7 the most relevant and the others only provisionally configured. First, I ran:


# bootctl install

I then configured /boot/efi/loader/loader.conf:


#       /boot/efi/loader/loader.conf

#       systemd-boot configuration file    

timeout 5

#default 4fa9a5bf4498415ead7dea7c2724e90a-*

#       From man loader.conf, Options, default, at https://www.freedesktop.org/software/systemd/man/loader.conf.html:

default @saved

console-mode keep

I then configured the boot entries in .conf files in /boot/efi/loader/entries, all of which are in the form of:


#       /boot/efi/loader/entries/sdx4.conf

#       Boot entry configuration file.    

title sdx4 - Ubuntu Desktop 22.04

linux ../vmlinuz

initrd ../initrd.img

options root=PARTUUID=9d1de6a4-452c-42d2-bf18-acee90032326 rw

Then, on the recommended reboot, systemd-boot presents a menu with options only for the default boot loader, which boots to the GRUB shell, and to boot into the EFI configuration utility.


Kernel files remain in /boot because linux-update-symlinks creates the symlinks initrd.img and vmlinuz in /boot and FAT32 does not support symlinks.


bootctl status

returns


System:

     Firmware: n/a (n/a)

  Secure Boot: disabled

   Setup Mode: user

 TPM2 Support: no

 Boot into FW: supported



Current Boot Loader:

      Product: n/a

     Features: ✗ Boot counting

               ✗ Menu timeout control

               ✗ One-shot menu timeout control

               ✗ Default entry control

               ✗ One-shot entry control

               ✗ Support for XBOOTLDR partition

               ✗ Support for passing random seed to OS

               ✗ Boot loader sets ESP information

          ESP: n/a

         File: └─n/a



Random Seed:

 Passed to OS: no

 System Token: set

       Exists: yes



Available Boot Loaders on ESP:

          ESP: /boot/efi (/dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7)

         File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 249.11-0ubuntu3.1)

         File: └─/EFI/BOOT/BOOTX64.EFI



Boot Loaders Listed in EFI Variables:

        Title: ubuntu

           ID: 0x0000

       Status: active, boot-order

    Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7

         File: └─/EFI/ubuntu/shimx64.efi



        Title: ubuntu

           ID: 0x0002

       Status: active, boot-order

    Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7

         File: └─/EFI/debian/shimx64.efi



        Title: Linux Boot Manager

           ID: 0x0001

       Status: active, boot-order

    Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7

         File: └─/EFI/systemd/systemd-bootx64.efi



        Title: UEFI OS

           ID: 0x0005

       Status: active, boot-order

    Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7

         File: └─/EFI/BOOT/BOOTX64.EFI



        Title: ubuntu

           ID: 0x0006

       Status: active, boot-order

    Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7

         File: └─EFI/Ubuntu/grubx64.efi



Boot Loader Entries:

        $BOOT: /boot/efi (/dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7)



Default Boot Loader Entry:

        title: sdx7 - Ubuntu Desktop 22.04

           id: sdx7.conf

       source: /boot/efi/loader/entries/sdx7.conf

        linux: ../vmlinuz

       initrd: ../initrd.img

      options: root=PARTUUID=67027db9-885b-471b-9c01-4b2108e6f7e9 rw



tree /boot/efi

returns


/boot/efi/EFI

├── BOOT

│   ├── BOOTX64.EFI

│   ├── fbx64.efi

│   └── mmx64.efi

├── debian

│   ├── BOOTX64.CSV

│   ├── grub.cfg

│   ├── grubx64.efi

│   ├── mmx64.efi

│   └── shimx64.efi

├── Linux

├── systemd

│   └── systemd-bootx64.efi

└── ubuntu

    ├── BOOTX64.CSV

    ├── grub.cfg

    ├── grubx64.efi

    ├── mmx64.efi

    └── shimx64.efi



5 directories, 14 files

This is a disaster. None of the documentation provides a clue, nor does Google. Any constructive thoughst about how to get systemd-boot to work would be appreciated.


More From » boot
 Answers
0

It turns out that systemd-boot does not implement 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/efi/loader/entries/sdx3.conf

    linux: ../vmlinuz

   initrd: ../initrd.img

  options: root=PARTUUID=[UUID 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=[UUID 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.


Someone besides me has wasted a lot of effort.


Das Gummiboot wird gesunken.


The way to float the wreck is not to conform with the Boot Loader Specification, the syntax checker, or any of the other documentation but instead, as @PonJar has noted, to move the kernel files to the ESP.


This requires a cascade of reconfigurations including hand-writing a number of installation scripts to overhaul the kernel installation / upgrade process, and actually uprooting the kernel files for transplant to the ESP (huh?). The tail wags the dog.


Conforming systemd-boot with the Boot Loader Specification, specifically by enabling it to read kernel files wherever located including on the filesystem of the partition being booted, would make the entirety of the foregoing unnecessary.


Indeed, systemd-boot seems to be architecturally flawed and tries to do too much. The kernel-install command and its related bootctl options all exist simply to compensate for systemd-boot's execution limitations or those of systemd-bootx64.efi. It is a boot loader, after all, and its entire purpose is execute a kernel on another partition but it cannot and this complexity is the consequence.


If systemd-boot could execute a kernel where and as installed, all the configuration necessary would be loader.conf and the /loader/entries .conf files.


The procedure, which I gleaned directly and otherwise from this post, and with thanks to the poster dalto, involves:



  • Mount the ESP to /boot/efi



  • Install efibootmgr; Remove grub*



  • Remove all instances of zz-update-grub from subdirectories of /etc/kernel



  • Copy all kernel command lines otherwise appearing in /etc/default/grub under GRUB_CMDLINE_LINUX_DEFAULT to /etc/kernel/cmdline



  • Do # bootctl install



  • Create and mark as executable /etc/kernel/postinst.d/zz-systemd-boot:


    #!/bin/sh -e
    

    
version="$1"
    
bootopt=""
    

    
# passing the kernel version is required    
    
if [ -z "${version}" ]; then
    
        echo >&2 "W: kernel-install: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number"
    
        exit 2
    
fi
    

    
# exit if kernel does not need an initramfs
    

    
if [ "$INITRD" = 'No' ]; then
    
        exit 0
    
fi
    

    
# avoid running multiple times
    

    
if [ -n "$DEB_MAINT_PARAMS" ]; then'
    

    
        eval set -- "$DEB_MAINT_PARAMS"
    

    
        if [ -z "$1" ] || [ "$1" != "configure" ]; then
    

    
                exit 0
    

    
        fi
    
fi
    

    
kernel-install add "$version" "/boot/vmlinuz-$version"


  • Create and mark as executable /etc/kernel/postrm.d/zz-systemd-boot:


    #!/bin/sh -e
    

    
version="$1"
    
bootopt=""
    

    
# passing the kernel version is required
    
if [ -z "${version}" ]; then
    

    
        echo >&2 "W: kernel-install: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number"
    

    
        exit 2
    
fi
    

    
kernel-install remove "$version"


  • Do:


    sudo mkdir -p /etc/initramfs/post-update.d
    

    
cd /etc/initramfs/post-update.d/ && sudo ln -s ../../kernel/postinst.d/zz-systemd-boot zz-systemd-boot


  • Finally run kernel-install for the current kernel.




Pending the next rev of systemd-boot, may the Force be with you.


[#414] Thursday, September 1, 2022, 2 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
eighethod
Add To Favorites
Follow
Total Points: 358
Total Questions: 112
Total Answers: 119
Location: Cayman Islands
Member since Fri, Mar 4, 2022
2 Years ago
eighethod questions
Sun, Nov 6, 22, 16:24, 2 Years ago
Sat, Dec 3, 22, 21:31, 1 Year ago
Wed, May 24, 23, 07:59, 1 Year ago
Thu, Feb 10, 22, 01:13, 2 Years ago
Thu, Oct 28, 21, 14:51, 3 Years ago
View All
;