Systemd-boot: some new-beginner's questions

General system Newbie
1

I have recently installed/converted two Arch and EnOS systems using systemd-boot. It all works just fine. Since this is a new concept and practice for me, I am having some initial questions.

Here is the disk layout from one system:

Model: Samsung SSD 970 EVO 500GB (nvme)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1075MB  1074MB  fat32              boot, esp
 2      1075MB  492GB   490GB   btrfs

And here is the output of efibootmgr -v

efibootmgr -v
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0002
Boot0002* UEFI: Samsung SSD 970 EVO 500GB, Partition 1	HD(1,GPT,f5a13bd0-6f3b-4b16-b537-de566d9dbbe8,0x800,0x200000)/File(\EFI\Boot\BootX64.efi)..BO
Boot0005* Linux Boot Manager	HD(1,GPT,f5a13bd0-6f3b-4b16-b537-de566d9dbbe8,0x800,0x200000)/File(\EFI\systemd\systemd-bootx64.efi)

What is the difference between systemd-bootx64.efi (default boot option) and bootX64.efi? Is the latter kind of a fallback boot option or is it for compatibility boot for other systems like Windows?

2

As far as I know, they are identical. The same file is installed to two locations.

I am not an expert but my understanding is that \EFI\Boot\BootX64.efi is the default path the UEFI firmware looks for when you select the block device to boot from.

1 Like
3

Thanks for the reply!

When I brought up the on-shot boot menu and chose to boot from the disk (Boot 0002 above), the system booted up just fine. That’s why I I wondered what the difference was. Searching the web mostly pointed to BootX64.efi being a Microsoft file, for example here. My assumption was that it is for compatibility reason that it is there if one wants to dualboot with Windows. But perhaps not.

Yes, I understand. That explains it.

My second question :blush: is regarding to the folders I have under /boot and /boot/EFI:

ls /boot
e4cf6982eb6f4e1785da72ca8e94beee  initramfs-linux-zen.img
EFI                               intel-ucode.img
initramfs-linux-lts-fallback.img  loader
initramfs-linux-lts.img           vmlinuz-linux-lts
initramfs-linux-zen-fallback.img  vmlinuz-linux-zen

ls /boot/EFI
BOOT  Dell  Linux  systemd

Both e4cf6982eb6f4e1785da72ca8e94beee and Linux are empty. Do you know what they are for? Is there any specific use they could be put in to?

4

That is your machine ID. The boot loader specification(BLS) states that kernels/initrds should live in certain places, the most common one being $esp/<machine-id>/<kernel version>. Since you are not following that specification, you can either remove it or ignore it.

As a side note, kernel-install does follow that specifcation which makes multi-booting much cleaner. That is one of the reasons I use it and created a framework for it on Arch.

That is for unified kernel images which most distros don’t use by default. At least, I have never seen one yet.

5

Great explanations as always @dalto! Thank you so much!

https://systemd.io/

And I who was just getting comfortable with Grub and multi-booting and all…

This is where I want to go next. Learning how to multi-boot using systemd-boot. Can I read more about this in the tutorial you have written about converting a grub-boot system to a systemd-boot one?

And another question: if not following the BLS, do I need to rename my kernels/initrds in case, let’s say, I want to dual-boot with another Arch (-based) system that uses the same names?

Edit- I have been reading you tutorial. I need to digest the whole thing a bit more since the approach is new to me. I think for now, I am more comfortable to do things manually to get the hang of it before handing it over to to an automated process.

6

The tutorial just explains how to install it. It doesn’t really explain what I did to create it.

Kernel name collision is the issue. If you want to continue with the manual approach, a common work-around is to mount your ESP at /efi, create a subfolder for each distro and then symlink or bind mount that subfolder to /boot.

So, for example you efi might look like:

/efi/arch-gnome
/efi/eos
/efi/arch-budgie

Then in each distro /boot would be connected to the appropriate subdirectory. Of course, you need to change your entries to reflect that.

The reason for this is that renaming kernels and initrds in Arch is a pain because they are generated based on a template which is also generated. That is what a substantial portion of the framework I built for kernel-install does.

1 Like
7

I am just starting to distinguish ( through the thick of my ignorance in much of things Linux) the contours of the kind and amount of the work you must have done to make this framework for kernel-install. That’s awesome!

I have tried to do a fresh install of Arch(again!) which is, for the moment, unbootable due surely to lack of my own knowledge to get everything right. Although, I don’t think that it is beyond hope to repair. Here is what I have done so far:

– partitions:
1-1.5 GB vfat mountpoint /efi
the rest of the disk a btrfs partition where I create subvolumes for root, home etc mounted at their proper mountpoints

I have followed then the installation instructions literally. bootctl install ran it’s course without any complains and created its folders and files under /efi. The kernels etc remain under /boot.

My uncertainty is now how I should properly edit the loader entries. I made first something like:

title    Arch-Gnome-zen
linux   /vmlinuz-linux-zen
initrd  /intel-ucode.img
initrd  /initramfs-linux-zen.img
options rw root=UUID=1d9646ea-0edf-423b-85a7-88a429c6314b rootflags=subvol=@arch-gnome-root

but after reboot, I only got “boot to firmware” option. I then changed the conf file and specified the path to the kernels etc, like: linux /boot/vmlinuz-linux-zen but it didn’t work. There is something escaping me.

8

If you entries don’t show up it usually means one of the files is missing or the path is wrong. The path should be relative to the ESP so if your ESP is mounted at /boot and your kernel is at /boot/vmlinuz the entry should be /vmlinuz

Can you share an ls of /boot?

1 Like
9

Thanks for your help!
Just give a minute or two to boot up that machine from a live iso.

10

Here comes some info:

cat /etc/fstab

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

# /dev/nvme0n1p1 LABEL=ESP
UUID=4698-98C7      	                    /efi      	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2


# /dev/nvme0n1p2
UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef	/         	btrfs     	rw,noatime,compress=lzo,ssd,discard=async,space_cache,subvolid=256,subvol=/@arch-gnome-root	0 0


# /dev/nvme0n1p2
UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef	/home     	btrfs     	rw,noatime,compress=lzo,ssd,discard=async,space_cache,subvolid=257,subvol=/@arch-gnome-home	0 0

# /dev/nvme0n1p2
UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef	/var/cache	btrfs     	rw,noatime,compress=lzo,ssd,discard=async,space_cache,subvolid=258,subvol=/@arch-gnome-cache	0 0


# /dev/nvme0n1p2
UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef	/var/log  	btrfs     	rw,noatime,compress=lzo,ssd,discard=async,space_cache,subvolid=259,subvol=/@arch-gnome-log

ls /boot

amd-ucode.img initramfs-linux-zen-fallback.img initramfs-linux-zen.img vmlinuz-linux-zen

cat /efi/loader/loader.conf

timeout 3
#console-mode keep
default *.conf
editor yes 
auto-firmware 1

cat /efi/loader/entries/arch-gnome-zen.conf

title   ArchGnome-zen
linux   /boot/vmlinuz-linux-zen
initrd  /boot/initramfs-linux-zen.img
initrd  /boot/amd-ucode.img
options root=UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef rootflags=subvol=@arch-gnome-root rw

I suspect I got it all wrong in the arch-gnome-zen.conf.

ps- I know I should be removing editor yes. I thought I might need it while I am getting this to work

11

You definitely need to remove /boot from the front of everything.

I don’t know if it is required but I have always put the ucode image above the initramfs.

Setting default to *.conf is fairly pointless but it shouldn’t hurt anything.

1 Like
12

That’s how I had it art first. I remove it again and see.

Ok, i’ll change that too.

I think I read that somewhere on the wiki page. But I get what you mean.

13

Wait. Your ESP is mounted at /efi. That means everything will be relative to the root of /efi, not /boot. Is /boot a symlink of a subdirectory of /efi?

14

No. I didn’t make any such.

15

Well, that is your problem. That means your kernels and initrams aren’t in your ESP.

16

No they aren’t! I was unsure a bit if I needed to move them manually or there was something else I should be doing.

Should I create now a folder “arch-gnome” in ESP and put everything inside that for this install?

17

You should create that folder, then mv all the files from /boot into it, then rmdir /boot and make a symlink from that folder to /boot

Arch is going to keep putting those files in /boot so having it be a symlink to a subfolder of your ESP should make it “just work” without you having to manually move files around every time an update occurs.

1 Like
18

OK. Also those files and folders from bootctl install go into this folder?

19

No, leave those alone.

1 Like
20

You also have to change your entries to look like this:

title   ArchGnome-zen
linux   /arch-gnome/vmlinuz-linux-zen
initrd  /arch-gnome/amd-ucode.img
initrd  /arch-gnome/initramfs-linux-zen.img
options root=UUID=400a15cd-f695-4984-ad3d-8b8fad9003ef rootflags=subvol=@arch-gnome-root rw
1 Like