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)
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
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?
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.
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.
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 I will.
I will.