Setup systemd-boot on btrfs

Ok, so, I’ve made some days ago a new installation using btrfs as filesystem. I’ve not created particular subvolumes so I only have the default one that calamares create on installation. Because the system was working too well i decided to brake it. I so had the great idea to switch from grub to systemd-boot because generally i prefer it between the two. I’ve read around and followed the great tutorial dalto made (as already done other times on ext4 filesystem) and add to the options in my eos.conf entry subvol=@…and then rebooted…and my system doesn’t boot at all. I’ve tried to modify the entry for example adding rootflags=subvol=@ in options but the only thing that i manage to do is almost boot. In the last case (which I’m right now) the system try to boot but stop saying that it can’t mount /efi, which is where the various vmlinuz images are and if I try to mount it manually is says to me that the filesystem for /efi is unknown (it is a standard EFI partition, windows boot fine from there, and eos too before I broke it).
Also I’ve noticed that trying to chroot from live iso give me an error saying that the @ is not a valid mount point. To do it I’ve followed this step in a live environment

sudo mount /dev/sda1 /mnt
sudo mount /dev/nvme0n1p1 /mnt/@/efi
sudo arch-chroot /mnt/@

Last command because if I try to chroot on /mnt it simply doesn’t do it (I don’t know if it’s normal for it being a btrfs filesystem instead of a ext one)

Any advice?

Thanks for your time.

Can we see two things:

sudo btrfs subvolume list /mnt
sudo lsblk -o name,fstype,size,uuid

PS. What you did there isn’t really the way I would recommend.

I imagine from the arch-chroot even if it warn me when I do it?

You don’t need to be in a chroot for that.

We are also going to need to see the contents of you entries.

1 Like
ID 256 gen 6405 top level 5 path @
ID 257 gen 6367 top level 5 path @home
ID 258 gen 6384 top level 5 path @cache
ID 259 gen 6388 top level 5 path @log
ID 262 gen 25 top level 256 path @/var/lib/portables
ID 263 gen 26 top level 256 path @/var/lib/machines
ID 269 gen 6392 top level 256 path @/.snapshots
ID 270 gen 164 top level 269 path @/.snapshots/1/snapshot
ID 271 gen 212 top level 269 path @/.snapshots/2/snapshot
ID 289 gen 1198 top level 269 path @/.snapshots/14/snapshot
ID 321 gen 1941 top level 269 path @/.snapshots/24/snapshot
ID 337 gen 3625 top level 269 path @/.snapshots/37/snapshot
ID 358 gen 5273 top level 269 path @/.snapshots/50/snapshot
ID 382 gen 6111 top level 269 path @/.snapshots/57/snapshot
ID 383 gen 6274 top level 269 path @/.snapshots/58/snapshot
loop0       squashfs   1.7G 
sda                  931.5G 
└─sda1      btrfs    931.5G 23539706-dc93-4182-bc08-9f77a17e75d8
sdb         iso9660   14.5G 2021-04-17-11-08-44-00
├─sdb1      iso9660    1.9G 2021-04-17-11-08-44-00
└─sdb2      vfat        68M 0749-E1B8
nvme0n1              931.5G 
├─nvme0n1p1 vfat       500M AAA5-AE9A
├─nvme0n1p2             16M 
├─nvme0n1p3 ntfs     929.4G DCC2B221C2B20036
├─nvme0n1p4 ntfs       557M 12C0BE14C0BDFDD3
└─nvme0n1p5 ntfs       1.1G D4A83012A82FF222
title	EndeavourOS
linux	/vmlinuz-linux
initrd	/intel-ucode.img
initrd	/initramfs-linux.img
options	root=UUID="23539706-dc93-4182-bc08-9f77a17e75d8" subvol=@ rw

here all requested.

Thanks a lot

Your entry needs to be rootflags=subvol=@

I am not sure you need to chroot in right now, but if you do, I would do it like this:

sudo mount /dev/sda1 /mnt -o subvol=@
sudo mount /dev/nvme0n1p1 /mnt/efi
sudo arch-chroot /mnt

Also, if you are using /efi, how are you getting the kernels in there?

For now, to get your system booting edit /etc/fstab and comment out the entry for the EFI partition. Once you are in it, we can figure out what is wrong there and address it.

Ok with your help I think I’ve manage to solve it. Other than what suggested I’ve recreated the simlink between /efi and /boot (probably the first time something went wrong and I didn’t noticed it before rebooting).

As for this

The first time I’ve manually copied then from /boot to /efi before the cleaning up and then I’ve created a systemd hook to make the process automatic, as indicated here
I think is good now. The system boots correctly adding as suggested rootflags= before subvol=@.
There are any other steps to follow or something to verify the situation or, as i think, now is all setup correctly?

1 Like

The systemd hook just updates the bootloader when systemd updates. It doesn’t do anything with the kernel.

However, this will do the trick:

If /boot is a symlink to /efi then when kernels are installed to /boot, they will really be in the efi partition.

Once it is working, there shouldn’t be anything else to do. The first real test is when you get your next kernel update.

Great! So the systemd hook is needed for systemd updates and not for kernel updates. Ok. Tonight I’ll try to install the lts kernel (I was already planning to do it either way) and will see if everything works correctly after adding the entry for it too.

1 Like

With systemd-boot is the format of the partition mounted at /efi still vfat?

Yes, it has to be for the UEFI to be able to read it.

1 Like

Alright. And if I install the system with systemd-boot at the outset, do I need still the linking to /boot?

That depends how you configure it. If you do a manual systemd-boot install as described in the Arch wiki, then you will either need a symlink to /boot or to mount your ESP at /boot. If you use the kernel-install framework I built, you will not need that.

1 Like

This is how I understood it as well if I were to install it according to the Wiki in order to skip the linking.
So I can go with a vfat partition mounted at /boot and the rest as usual?

I haven’t looked at your kernel-install yet :blush: I will.

Yes, just remember to make the esp partition large enough to hold all the kernels you are planning to put in there.

1 Like

Great! This will be my weekend project. Thank you!

1 Like

I’m back to confirm that the problem is solved. Installed lts kernel, added the entry for it and the system boot correctly on lts.

Thanks again @dalto


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.