Not finding root subvolume on vanilla Fedora 43

[Schroedingers-Cat]

On a vanilla Fedora 43 installed with default settings, atomic-rollback check, setup or migrate fail the "Root filesystem" check. I've tested this in a VM using Boxes/virt-io and Hyper-V.

The strace shows it execs mount -o ro e8edee18-e4ad-40fd-8733-5cd5fb403093 /tmp/atomic-rollback-probe-... instead of using UUID=e8edee18-e4ad-40fd-8733-5cd5fb403093 or /dev/vda3. That causes:

fsconfig() failed: ... Can't lookup blockdev

Atomic-rollback then states the misleading error "Btrfs subvolume 'root' not found", even though btrfs subvolume list / shows path root:

user@fedora:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/vda3[/root]
         / b rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,s
user@fedora:~$ lsblk -f
NAME   FSTYPE FSVER LABEL             UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0  swap   1     zram0             bdbc4de2-c32d-409e-b409-88b60e8d7046                [SWAP]
vda                                                                                       
├─vda1 vfat   FAT32                   7C8B-1182                             579,5M     3% /boot/efi
├─vda2 ext4   1.0                     a58b1d68-70f2-4c87-92ed-0c1dd589378f    1,4G    21% /boot
└─vda3 btrfs        fedora            e8edee18-e4ad-40fd-8733-5cd5fb403093   24,4G    15% /home
                                                                                          /
user@fedora:~$ sudo btrfs subvolume list /
ID 256 gen 161 top level 5 path root
ID 257 gen 162 top level 5 path home
ID 258 gen 152 top level 256 path var/lib/machines

It works when I prefix the uuid string with UUID=: Schroedingers-Cat@8e4584e

Any idea why this fails for me without those changes?

[jacksnodgrass]

I get the same thing with a Fedora 43 virt-install I am doing.

[root@testvm ~]# atomic-rollback check
atomic-rollback: checking system bootability

  PASS  EFI boot files
  PASS  GRUB configuration
  PASS  Kernel boot entry
  FAIL  Root filesystem
        Btrfs subvolume 'root' not found: mount -o ro 96316bca-465d-4def-9411-101de4824cb9 /tmp/atomic-rollback-probe-e4824cb9: mount: /tmp/atomic-rollback-probe-e4824cb9: fsconfig() failed: 96316bca-465d-4def-9411-101de4824cb9: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

and

[root@testvm ~]#  sudo btrfs subvolume list /
ID 256 gen 54 top level 5 path home
ID 257 gen 58 top level 5 path root
ID 258 gen 54 top level 257 path var/lib/portables

and my /etc/fstab file has:

UUID=96316bca-465d-4def-9411-101de4824cb9 / btrfs subvol=root,compress=zstd:1 0 0

[rocketman-code]

Thanks for the detailed report. The fstab and btrfs subvolume list output made this straightforward to trace.

Root cause: the check command extracts the bare UUID from the BLS boot entry (root=UUID=...) but passes it to the mount probe without the UUID= prefix. mount receives 96316bca-... as a device path instead of UUID=96316bca-... and can't resolve it.

Stock Fedora 43 uses UUID= in fstab, so this hits every vanilla install. Fix is one line. Will be in 0.3.3 shortly.

[rocketman-code]

Fixed in v0.3.3. Once the COPR build finishes:

sudo dnf update atomic-rollback

[rocketman-code]

Build is live. You should be able to update now.

[Schroedingers-Cat]

@rocketman-code thanks for looking into this! When I fixed this locally, I wondered how it didn't happen for you?

[rocketman-code]

v0.3.2 generalized device handling from UUID-only to all fstab formats, but the root subvolume check was the one caller that still passed a bare UUID instead of UUID= prefixed. I didn't run check against a clean install before shipping. v0.3.1 worked fine.

Since then, v0.3.5 made bare UUIDs and device specs separate types, so this specific class of mismatch is now a compile error. Working on VM integration testing in the release process for the gaps the type system can't cover.

Your reports on both issues shaped how the release process is evolving. Appreciate it.