[Tutorial] Convert to systemd-boot

[anon13373109]

Speeding up the Boot Process
           If you want to speed up the boot process, you can specify as much information for dracut on the kernel command as possible. For example, you can tell
           dracut, that you root partition is not on a LVM volume or not on a raid partition, or that it lives inside a specific crypto LUKS encrypted volume. By
           default, dracut searches everywhere. A typical dracut kernel command line for a plain primary or logical partition would contain:

               rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0

           This turns off every automatic assembly of LVM, MD raids, DM raids and crypto LUKS.

So for a basic setup I’ll have to add those options to /etc/kernel/cmdline right?

[dalto]

@anon13373109

So for a basic setup I’ll have to add those options to /etc/kernel/cmdline right?

Yes. As long as you don’t use any of those things…

[anon49550872]

@dalto

Yes. As long as you don’t use any of those things…

After adding those options in /etc/kernel/cmdline, should I run a reinstall-kernels?

Obs: Tried to run a dracut-rebuild and got some errors:

$ LANG=C sudo dracut-rebuild 
Running dracut for linux-6.1.9-arch1-1
/usr/bin/dracut-rebuild: line 31: dracut --force --hostonly --no-hostonly-cmdline /efi/51a4e829c2284d2da77af088ba80b92f/6.1.9-arch1-1/initrd 6.1.9-arch1-1: No such file or directory
/usr/bin/dracut-rebuild: line 32: dracut --force --no-hostonly /efi/51a4e829c2284d2da77af088ba80b92f/6.1.9-arch1-1/initrd-fallback 6.1.9-arch1-1: No such file or directory
Running dracut for linux-hardened-6.1.9-hardened1-1-hardened
/usr/bin/dracut-rebuild: line 31: dracut --force --hostonly --no-hostonly-cmdline /efi/51a4e829c2284d2da77af088ba80b92f/6.1.9-hardened1-1-hardened/initrd 6.1.9-hardened1-1-hardened: No such file or directory
/usr/bin/dracut-rebuild: line 32: dracut --force --no-hostonly /efi/51a4e829c2284d2da77af088ba80b92f/6.1.9-hardened1-1-hardened/initrd-fallback 6.1.9-hardened1-1-hardened: No such file or directory
Running dracut for linux-lts-5.15.91-1-lts
/usr/bin/dracut-rebuild: line 31: dracut --force --hostonly --no-hostonly-cmdline /efi/51a4e829c2284d2da77af088ba80b92f/5.15.91-1-lts/initrd 5.15.91-1-lts: No such file or directory
/usr/bin/dracut-rebuild: line 32: dracut --force --no-hostonly /efi/51a4e829c2284d2da77af088ba80b92f/5.15.91-1-lts/initrd-fallback 5.15.91-1-lts: No such file or directory

$ ls /efi/51a4e829c2284d2da77af088ba80b92f/6.1.9-hardened1-1-hardened
initrd  initrd-fallback  linux

[dalto]

@anon49550872

After adding those options in /etc/kernel/cmdline, should I run a reinstall-kernels?

Yes.

[BS86]

I am currently trying to understand the process of the conversion following the new information found here so that I can try it sometime later this week.
This part here:

@dalto

Now we remount the EFI partition to /efi.

I don’t understand why this step is necessary. The default of systemd-boot is /boot/efi and in the kernel-install-for-dracut package, specifically in dracut-rebuild, we dynamically look for the ESP partition:

ESP=$(bootctl --print-esp-path)

The

initial Setup Script

@dalto

#!/usr/bin/env bash

# Find the configured esp
esp=$(bootctl -p)

# Prepare the efi partition for kernel-install
machineid=$(cat /etc/machine-id)
if [[ ${machineid} ]]; then
    mkdir ${esp}/${machineid}
else
    echo "Failed to get the machine ID"
fi

# Run kernel install for all the installed kernels
reinstall-kernels

also dynamically checks for it:

@dalto

esp=$(bootctl -p)

The Arch wiki also states:

When running bootctl install, systemd-boot will try to locate the ESP at /efi, /boot, and /boot/efi

So could we skip the step of remounting the ESP partition and the rest will still work? The reason is that without remounting, the system is kept closer to Arch documentation and the way back involves one less step in case I want to go back to grub or refind.

[dalto]

@BS86

The default of systemd-boot is /boot/efi

That definitely is not the default for systemd-boot. That is the default for grub.

@BS86

So could we skip the step of remounting the ESP partition and the rest will still work?

It should still work although /boot/efi may be deprecated by systemd-boot at some point. There were several conversations about removing support.

@BS86

the system is kept closer to Arch documentation

Hmm. Here is what the Arch wiki says:

/efi is a replacement[5] for the historical and now discouraged ESP mountpoint /boot/efi.

That being said, it should work fine if that is where you would like to mount your EFI partition. It is just very non-standard for systemd-boot.

[BS86]

@dalto

Here is what the Arch wiki says:

/efi is a replacement[5] for the historical and now discouraged ESP mountpoint /boot/efi.

I can’t find that information in the systemd-boot wiki entry xD But I found it in the EFI - wiki entry.

But I found another issue while looking through the systemd-boot wiki entry:

Boot from another disk

systemd-boot cannot launch binaries from partitions other than the ESP or the XBOOTLDR partition, but it can run an external script to do so. 

My Windows - ESP partition is on another drive together with the Windows install while my EndeavourOS ESP is on the same drive like my EndeavourOS install (I like to keep my systems separate, never had to reinstall my Linux ESP after a Windows - update ) so it seems I have to create another config to be able to dualboot with my Windows installation.

[Boe]

Need some help. Chrooted into my existing install using cassini neo iso. Mounted the necessary btrfs sub volumes and then converted from grub to systemd-boot. Can choose my kernels on boot.

.
Edit: my efi partition is too small. Going to backup my data and reinstall EndeavourOS

[BS86]

So I converted my system to systemd-boot now, and while it generates an entry for Windows when you share your esp - Partition with Windows, it does not do that when you have separate ESP partitions for Windows and Linux.

So here’s a tutorial on how to get a Windows-entry in that case, with help taken from the Arch Systemd Boot Wiki entry.

1. Install edk2-shell:
   sudo pacman -S edk2-shell

2. copy that to your esp-partition:
   sudo cp /usr/share/edk2-shell/x64/Shell.efi ESP/shellx64.efi (replace ESP with the path to your esp, usually /efi)

3. Retrieve the PARTUUID for your Windows-esp Partition - for example the KDE Partition Manager shows it as UUID in the Partition Details, but you can also do in command line:
   sudo blkid | grep vfat
   Usually, the Windows EFI Partiton is labelled “EFI system partition”, you should get a line that looks like that:
   /dev/nvme1n1p2: UUID="52CC-E135" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="e2cc5bf0-9654-4ba3-bdc7-cdb1c2db2c3b"

You will want to remember/take a picture/write down the PARTUUID - depending on how many partitions you have in your system, you will see a lot of such strings in the following steps - check sudo blkid for how many you will see.

4. The next part gets a lot easier if you set your systemd-boot resolution to max with adding
   console-mode max to your esp/loader/loader.conf but this step is optional. (Adding that will also enable the OEM boot logo for Windows)

5. Reboot and choose EFI shell in the loader screen which gets autocreated if you did step 2 correct.
   It should now display a list of Aliases following that Aliases partition details. If it does not, enter the command map
   You can scroll with Page Up / Down if it does not fit on your screen (it should when setting the console-mode max Parameter)

6. Take note of the FS Alias that contains the PARTUUID you got in the above step. For me the Alias was HD2c but it can also look like HD0a66666a2:
   Enter the exit command and boot into your Linux installation again.

7. Create a file in your esp - Partition (usually /efi) called windows.nsh and give it the following content:

HD2c:EFI\Microsoft\Boot\Bootmgfw.efi

where HD2c is the exact FS Alias you got from the EFI shell in step 6 and the part after the : is the exact path in your Windows esp Partition (in most cases the path should be exactly like in my example)

8. Now create a loader entry for that Windows Installation by creating a file windows.conf in your esp/loader/entries directory (usually /efi/loader/entries/) containing the following:

title  Windows
efi     /shellx64.efi
options -nointerrupt -noconsolein -noconsoleout windows.nsh

The name of the .nsh file in the entry has to match the one you created in step 7, and the shellx64.efi also has to be in your esp and at that location where you created it in step 2.

Congratulations, you now have a working entry for your Windows - Installation on a different ESP partition in your Loader Menu.

Edit: If you don’t want to have the Shell - entry in your Loader Menu permanently, you can easily move it into a subfolder after doing all the steps above (for example tools) and modify the windows.conf file accordingly (for example to read efi /tools/shellx64.efi).

@dalto: This is a bit more complex because one can not simply read everything needed with a script, but I guess it should at least be mentioned somewhere in the wiki that booting Windows from another ESP Partition requires some extra steps.

@android

This confirms it I guess that systemd-boot does NOT detect Windows if it’s on a different disk but you can just copy the EFI files from one disk to another.

Now I am happy, everything is working! Thank you again for your help.

While that will also work, in case your Windows updates the entries in its ESP Partition, it won’t update the actually used files in your Linux ESP partition - which means you will have to copy them again or set up the config like mentioned above to let systemd-boot use the original files of your Windows ESP.

[android]

Nice, thanks this is definitely a better method than the one I used.
And more detailed than the Arch Wiki entry!

Maybe this could become an EndeavourOS Wiki topic (with some slight cleanup I guess)?

[LamnaNasus]

I agree, this is very useful info.

I’ll have to give it a try later. What about when you have Windows and Linux on seperate drives, with no relations, and you just go into the EFI/Bios to boot from one of them, does the steps above need much adjustement?

[android]

Isn’t that the exact use case for this tutorial?

So separate drives, with no relations.
And you want to boot via systemd-boot from the other drive (relatively speaking).

[BS86]

@android

Maybe this could become an EndeavourOS Wiki topic (with some slight cleanup I guess)?

Yeah, unfortunately, the formatting options in the forum are limited, they would make it a bit more readable, and yes, I tried to keep the tutorial universal and with some explanations and additional information contained, but it could also be written with the default esp - Location /efi being the only location and without additional information (personally I kept my esp mounted in /boot/efi/)

@LamnaNasus

What about when you have Windows and Linux on seperate drives, with no relations, and you just go into the EFI/Bios to boot from one of them, does the steps above need much adjustement?

it is exactly the same steps. systemd-boot can only autodetect stuff (Windows) if it is in the same ESP partition. If it is in another ESP partition, it doesn’t matter where that partition is, the steps are identical.

[LamnaNasus]

@android

Isn’t that the exact use case for this tutorial?

OK! I tried half-heartedly to get it to work a few days ago, with little success. I figured that was because I have them on seperate drives. I’ll read the instructions above more carefully when I’m at my Linux, and give it a try.

[BS86]

I think that the tutorial actually has it’s right to get a own topic, so I posted it here without the thread-specific parts:

[Tutorial] Add a systemd-boot loader Menu entry for a Windows installation using a separate ESP Partition

here’s a tutorial on how to get a Windows-entry in systemd-boot in case you use separate ESP partitions for Windows and Linux, with help taken from the Arch Systemd Boot Wiki entry. It is recommended that Fast Boot is disabled in UEFI as it can lead to several issues especially when dual booting - at least for me, it has no influence on boot time anyway. Install edk2-shell: sudo pacman -S edk2-shell copy that to your esp-partition: sudo cp /usr/share/edk2-shell/x64/Shell.efi ESP/shellx6…

[RaptaG]

Hello, I have two questions:

1. How can I display the size of my EFI partition?
2. How can I know if I run mkinitcpio or dracut?

Thanks in advance

[dalto]

@RaptaG

How can I display the size of my EFI partition?

findmnt /boot/efi -o size

@RaptaG

How can I know if I run mkinitcpio or dracut?

pacman -Q | grep -E "(dracut|mkinitcpio)"

[BS86]

For some reason, since the migration to systemd-boot (already had migrated to dracut last year) kernels that are removed by upgrade or deinstallation have remains in /lib/modules:

 /lib/modules  >>> ll
total 28
drwxr-xr-x 2 root root 4096 Feb 17 18:13 5.15.94-1-lts
drwxr-xr-x 2 root root 4096 Feb 22 23:31 6.1.12-1-ck
drwxr-xr-x 2 root root 4096 Feb 21 17:41 6.1.12-arch1-1
drwxr-xr-x 2 root root 4096 Feb 17 19:46 6.1.12-zen1-1-zen
drwxr-xr-x 5 root root 4096 Feb 22 23:31 6.1.13-1-ck
drwxr-xr-x 5 root root 4096 Feb 22 17:02 6.1.13-1-lts
drwxr-xr-x 5 root root 4096 Feb 22 17:57 6.2.0-arch1-1

5.15.94-1-lts, 6.1.12-1-ck, 6.1.12-arch1-1 are upgraded to their newer kernel releases, 6.1.12-zen1-1-zen was removed with pacman -R linux-zen linux-zen-headers, but all of them still have an initrd in the respective folder:

 /lib/modules  >>> ll 5.15.94-1-lts                                         
total 14252
-rw------- 1 root root 14590020 Feb 16 18:08 initrd

Is that something remaining from eos-dracut?
The newer folders don’t even contain an initrd:

 /lib/modules  >>> ll 6.2.0-arch1-1
total 18732
drwxr-xr-x 21 root root     4096 Feb 22 17:57 build
drwxr-xr-x 13 root root     4096 Feb 21 17:41 kernel
-rw-r--r--  1 root root  1530755 Feb 22 17:57 modules.alias
-rw-r--r--  1 root root  1509514 Feb 22 17:57 modules.alias.bin
-rw-r--r--  1 root root     9494 Feb 22 16:44 modules.builtin
-rw-r--r--  1 root root     7191 Feb 22 17:57 modules.builtin.alias.bin
-rw-r--r--  1 root root    11541 Feb 22 17:57 modules.builtin.bin
-rw-r--r--  1 root root    73489 Feb 22 16:44 modules.builtin.modinfo
-rw-r--r--  1 root root   776838 Feb 22 17:57 modules.dep
-rw-r--r--  1 root root  1029078 Feb 22 17:57 modules.dep.bin
-rw-r--r--  1 root root      455 Feb 22 17:57 modules.devname
-rw-r--r--  1 root root   235315 Feb 22 16:44 modules.order
-rw-r--r--  1 root root     1808 Feb 22 17:57 modules.softdep
-rw-r--r--  1 root root   663982 Feb 22 17:57 modules.symbols
-rw-r--r--  1 root root   808214 Feb 22 17:57 modules.symbols.bin
-rw-r--r--  1 root root        6 Feb 22 16:44 pkgbase
drwxr-xr-x  3 root root     4096 Feb 22 17:57 updates
-rw-r--r--  1 root root 12476832 Feb 22 16:44 vmlinuz

[dalto]

@BS86

For some reason, since the migration to systemd-boot (already had migrated to dracut last year) kernels that are removed by upgrade or deinstallation have remains in /lib/modules:

Are you sure that is caused by systemd-boot and not by when you were using eos-dracut with grub?

It looks like eos-dracut does that. eos-dracut started life as a copy of dracut-hook and that is from the original code for that.

[BS86]

@dalto

It looks like eos-dracut does that. eos-dracut started life as a copy of dracut-hook and that is from the original code for that.

That’s what I also suspected:

@BS86

Is that something remaining from eos-dracut?
The newer folders don’t even contain an initrd:

I will delete those leftover folders manually and check with the next updates if the issue is still there.