Regenerating systemd-boot entries using a live environment

By on

My computer froze. At the worst possible time. While I was performing this command:

sudo pacman -Syu

That's the command to upgrade your Endeavour/Arch Linux installation. And my computer froze just while it was generating the systemd-boot entries.

So I had no other choice but to forcefully restart the system. When it came back up, I was greeted with the boot manager with no entries in it.

That sucks. But luckily I had a good idea how to fix it. It's not that this happens a lot, but over the years I have fixed it a handful of times.

The idea in my mind was:

  • Boot into the Live ISO environment using a USB key (the one I used to install Endeavour)
  • Mount the drives correctly
  • Chroot into the environment and trigger a regeneration

Not that hard. Though this was the first time that I used encrypted partitions (encrypted btrfs partitions at that, with subvolumes) and systemd-boot , where I used to use Grub.

Luckily this didn't prove to make anything harder.

Booting the Live ISO

Of course, you need to have a USB key with the Live ISO written to it. If this laptop is your only device, you're out of luck. And you should really have a backup USB key for these situations 😬

When you do: plug it in, boot it up and open the terminal.

Mounting the root filesystem

First, make a directory somewhere you can mount this to. Doesn't really matter where. Then mount the root filesystem.

Let's become root first and create our temporary mount point:

sudo -s
mkdir -r /home/liveuser/temp/root

Since I was using subvolumes, I had to tell the mount command which subvolume to mount.

mount -o subvol=@ /dev/dm-2 /home/liveuser/temp/root
cd /home/liveuser/temp/root

In my case, the /boot folder was also on a separate partition (EFI reasons and all that), so that had to be mounted on top of this too:

mount /dev/nvme0n1p1 /home/liveuser/temp/root/boot/

Now we can chroot into the system. This basically means we'll switch into our installed system as if we booted into it normally:

arch-chroot /home/liveuser/temp/root/

Now you're chrooted into the actual system.

The easiest way to trigger a regeneration of the boot entries is to just reinstall the kernel. I'm using linux-zen, so I had to do:

pacman -S --force linux-zen

The --force flag ensures the kernel gets reinstalled even if it's already at the latest version.

You'll see some output like:

(2/5) Updating module dependencies...
(3/5) Running kernel-install...
:: kernel-install installing kernel 6.9.3-zen1-1-zen
dracut[I]: Executing: /usr/bin/dracut --no-hostonly --force /boot/d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/initrd-fallback 6.9.3-zen1-1-zen
dracut[E]: Module 'systemd-pcrphase' depends on 'tpm2-tss', which can't be installed
dracut[E]: Module 'systemd-pcrphase' depends on 'tpm2-tss', which can't be installed
dracut[I]: *** Including module: systemd ***
[...trimmed for brevity...]
dracut[I]: *** Including modules done ***
dracut[I]: *** Installing kernel module dependencies ***
dracut[I]: *** Installing kernel module dependencies done ***
dracut[I]: *** Resolving executable dependencies ***
dracut[I]: *** Resolving executable dependencies done ***
dracut[I]: *** Hardlinking files ***
dracut[I]: *** Hardlinking files done ***
dracut[I]: *** Generating early-microcode cpio image ***
dracut[I]: *** Constructing AuthenticAMD.bin ***
dracut[I]: *** Store current command line parameters ***
dracut[I]: *** Stripping files ***
dracut[I]: *** Stripping files done ***
dracut[I]: *** Creating image file '/boot/d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/initrd' ***
dracut[I]: *** Creating initramfs image file '/boot/d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/initrd' done ***
Running in a chroot, skipping cmdline generation
(4/5) Check if user should be informed about rebooting after certain system package upgrades.
(5/5) Checking which packages need to be rebuilt
fatal library error, lookup self

Don't worry about the fatal library error at the end - it's harmless as long as the initramfs generation completed successfully.

You can make sure the entries were regenerated with the following command:

bootctl list

And then you get something like this:

/boot/loader/loader.conf:5: Unknown line 'reboot-for-bitlocker', ignoring.
         type: Boot Loader Specification Type #1 (.conf)
        title: EndeavourOS (6.9.3-zen1-1-zen) (default) (not reported/new)
           id: d53c3a4f4b184012ae7b717ec29b17bf-6.9.3-zen1-1-zen.conf
       source: /boot//loader/entries/d53c3a4f4b184012ae7b717ec29b17bf-6.9.3-zen1-1-zen.conf
     sort-key: endeavouros-6.9.3-zen1-1-zen
      version: 6.9.3-zen1-1-zen
   machine-id: d53c3a4f4b184012ae7b717ec29b17bf
        linux: /boot//d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/linux
       initrd: /boot//d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/initrd
      options: nvme_load=YES nowatchdog rw rootflags=subvol=/@ rd.luks.uuid=47abf630-0efa-4e7a-ae67-f294496b60c7 root=/dev/mapper/luks-47abf630-0efa-4e7a-ae67-f2>

         type: Boot Loader Specification Type #1 (.conf)
        title: EndeavourOS (6.9.3-zen1-1-zen-fallback) (not reported/new)
           id: d53c3a4f4b184012ae7b717ec29b17bf-6.9.3-zen1-1-zen-fallback.conf
       source: /boot//loader/entries/d53c3a4f4b184012ae7b717ec29b17bf-6.9.3-zen1-1-zen-fallback.conf
     sort-key: endeavouros-6.9.3-zen1-1-zen-fallback
      version: 6.9.3-zen1-1-zen-fallback
   machine-id: d53c3a4f4b184012ae7b717ec29b17bf
        linux: /boot//d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/linux
       initrd: /boot//d53c3a4f4b184012ae7b717ec29b17bf/6.9.3-zen1-1-zen/initrd-fallback
      options: nvme_load=YES nowatchdog rw rootflags=subvol=/@ rd.luks.uuid=47abf630-0efa-4e7a-ae67-f294496b60c7 root=/dev/mapper/luks-47abf630-0efa-4e7a-ae67-f2>
[...]

Perfect! The entries are back. You can safely reboot your system now and enjoy a working boot manager again.

Comments

Name
Email
Website
Body
submit error done Busy
Jelle De Loecker