Adding systemd-boot entry for root subvolume (sdbootutils not working)

I’m a little bit stuck at the moment after making some good progress.

I followed all the steps here to set up systemd-boot instead of grub. That is, I installed systemd-boot as well as all the packages under " Installation with full BTRFS snapshot and secure boot support". I followed all the steps in that second heading and got to a pretty good setup. I can confirm that systemd-boot is working.

My challenge is that the sdbootutil install && sdbootutil add-all-kernels does not add an entry for the root volume. “Okay,” I think, let me automatically put in an entry:

me@mine:/boot/efi/loader/entries> cat opensuse-tumbleweed-default-0.conf 
# Boot Loader Specification type#1 entry
title      openSUSE Tumbleweed
version    root@6.4.11-1-default
sort-key   opensuse-tumbleweed
options    root=UUID=xxx splash=silent resume=/dev/system/swap mitigations=auto quiet security=apparmor rootflags=subvol=/@/
linux      /opensuse-tumbleweed/6.4.11-1-default/linux-43b948a3043c437ac734a0dd55de339b4c8ab997
initrd     /opensuse-tumbleweed/6.4.11-1-default/initrd-13a170d8d0f479a6db1584148df7ec15fd009b02

me@mine:/boot/efi/loader> cat loader.conf 
timeout 3
#console-mode keep
default opensuse-tumbleweed-default-0.conf

However, when I restart after making these changes, I get a black screen saying that luks-xyz is not a valid path? I get a notice to press Ctrl+D to continue or enter my root password. This happens after I unlock the luks device.

I also tried using rootflags=subvolid=256 instead to specify the root subvolume.

Any ideas for how I can correctly configure this, or get sdbootutil to specify it for me?

Are you using luks? That doesn’t look like a valid options line for a luks setup.

If not, it doesn’t really say root=UUID=xxx does it? If so that would be wrong. You need the UUID of your root partition there.

There is a valid uuid there—I just trimmed it. I copied this line from another entry that was automatically generated, corresponding to a snapshot on the same drive. The snapshot boots perfectly, but for some reason changing from the snapshot location at /@/.snapshots/10/ to @ or /@ fails to boot.

For some extra info, here’s lsblk:

me@mine:~> lsblk
NAME                                                                                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                                                               259:0    0 931.5G  0 disk  
├─nvme0n1p1                                                                           259:1    0   512M  0 part  /boot/efi
└─nvme0n1p2                                                                           259:2    0   931G  0 part  
                                                                                      254:0    0   931G  0 crypt 
    ├─system-swap                                                                     254:1    0    31G  0 lvm   [SWAP]
    └─system-root                                                                     254:2    0   900G  0 lvm   /var

The UUID corresponds to /dev/system/root, or the LV “root” inside the LUKS encrypted container.

Just to add: here is the error I get trying to boot:

Generating /run/initramfs/rdsosreport.txt
[after running journalctl]
Starting target switch root: specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing.
initrd-switch-root.service: Failed with result 'exit-code'.

Further up in the logs it looks like btrfs successfully mounts the subvolume but for some reason initrd fails to complete the handoff?

Please be very careful doing things like that. People will loose trust in what you post. They expect unaltered copy/pasted computer text. And when you do (e.g., hiding a password), then mention that!

1 Like

That’s fair. For transparency, the only things I’ve obfuscated in this way are the uuid, username and machine name. I’ve also excerpted the log file above. I can try to capture the full log on a USB if that’s desired.

I’m not super familiar with troubleshooting these types of boot issues so anyone please correct me along the way.

If snapshots were enabled during installation, the @ subvolume is empty and the very first bootable subvolume is @/.snapshots/1/snapshot.

1 Like

Okay, this was the crucial piece. My expectation is that everything in the .snapshots subvolume would be a read-only snapshot, not a read/write image. Indeed, my assumption was wrong!

me@mine:~> sudo mount -t btrfs /dev/system/root /mnt -o subvolid=5
me@mine:~> sudo btrfs property get -ts /mnt/@
me@mine:~> sudo btrfs property get -ts /mnt/@/.snapshots/1/snapshot
me@mine:~> sudo btrfs property get -ts /mnt/@/.snapshots/2/snapshot

Now, looking back at the entries folder, I see that sdbootutil did create a root entry for this first snapshot. I’ve set up btrfs layouts in different ways in the past, but none with my “main” root image under the .snapshots directory. Thanks for the tip!

Hopefully this will help anyone else trying to setup systemd-boot on Tumbleweed when coming from other distros, or just anyone else trying to understand the opensuse btrfs layout.