Detected boot files required by the 'Arch Linux' boot stanza which are not matched with the '@' subvolume

[QuarkZ26]

Hello,

when running refind-btrfs, I end up with this error

ERROR (refind_btrfs.state_management.conditions/conditions.py/check_matched_boot_stanzas): None of the matched boot stanzas are usable!

Here is my refind.conf entry

    icon     /EFI/refind/icons/os_arch.png
    volume   "15893a4f-4744-4d40-aea8-e1ee8c2e5033"
    loader    /dfde5d2c71e8487c9d478296a80d9940/6.5.9-arch2-1/linux
    initrd   /dfde5d2c71e8487c9d478296a80d9940/6.5.9-arch2-1/initrd
    options  "nvme_load=YES nowatchdog rw root=UUID=15893a4f-4744-4d40-aea8-e1ee8c2e5033 rootflags=subvol=@ nvidia-drm.modeset=1 systemd.machine_id=dfde5d2c71e8487c9d478296a80d9940"
    submenuentry "Boot using fallback initramfs" {
        initrd /dfde5d2c71e8487c9d478296a80d9940/6.5.9-arch2-1/initrd-fallback
    }
    submenuentry "Boot to terminal" {
        add_options "systemd.unit=multi-user.target"
    }
}

and my fstab

UUID=15893a4f-4744-4d40-aea8-e1ee8c2e5033   /                btrfs           subvol=@,noatime,autodefrag,compress-force=zstd                                 0 0 
UUID=15893a4f-4744-4d40-aea8-e1ee8c2e5033   /home            btrfs           subvol=@home,noatime,autodefrag,compress-force=zstd                             0 0 
tmpfs                                       /tmp             tmpfs           noatime,mode=1777                                                               0 0 

Any idea as to why I'm getting that error?

[Venom1991]

Please check whether your boot stanza fulfills the last requirement which can be found here.

This command could help you figure it out: findmnt --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS

[Venom1991]

Hm, upon further inspection it seems that there are boot files defined as part of your stanza that cannot be matched with the root subvolume's logical path. Please provide refind-btrfs's whole output.

I think that the problem is the format of the "loader" and "initrd" boot stanza's properties. I don't really expect them to be prefixed with Systemd's "machine-id" option but instead with the root subvolume's logical path. See the example of a working boot stanza.

[QuarkZ26]

I was using systemd-boot, indeed, this is how the system was installed. It also defaults with dracut, and it seems whenever i do a kernel update, it defaults to that folder, I would have to look further how to change that. It also goes to /efi by default, /boot isn't used anymore.

Here's the whole output

Initializing the block devices using lsblk.
Initializing the physical partition table for device '/dev/sda' using lsblk.
Initializing the live partition table for device '/dev/sda' using findmnt.
Initializing the physical partition table for device '/dev/sdb' using lsblk.
Initializing the live partition table for device '/dev/sdb' using findmnt.
Initializing the physical partition table for device '/dev/sdc' using lsblk.
Initializing the live partition table for device '/dev/sdc' using findmnt.
Initializing the physical partition table for device '/dev/sdd' using lsblk.
Initializing the live partition table for device '/dev/sdd' using findmnt.
Initializing the physical partition table for device '/dev/sde' using lsblk.
Initializing the live partition table for device '/dev/sde' using findmnt.
Initializing the physical partition table for device '/dev/sdf' using lsblk.
Initializing the live partition table for device '/dev/sdf' using findmnt.
Initializing the physical partition table for device '/dev/nvme0n1' using lsblk.
Initializing the live partition table for device '/dev/nvme0n1' using findmnt.
Found the ESP mounted at '/efi' on '/dev/nvme0n1p7'.
Found the root partition on '/dev/nvme0n1p8'.
Searching for snapshots of the '@' subvolume in the '/.snapshots' directory.
Found subvolume '@' mounted as the root partition.
Found 16 snapshots of the '@' subvolume.
Searching for the 'refind.conf' file on '/dev/nvme0n1p7'.
Analyzing the 'refind.conf' file.
ANTLR runtime and generated code versions disagree: 4.13.1!=4.12.0
ANTLR runtime and generated code versions disagree: 4.13.1!=4.12.0
Found 1 boot stanza matched with the root partition.
WARNING: Detected boot files required by the 'Arch Linux' boot stanza which are not matched with the '@' subvolume: /dfde5d2c71e8487c9d478296a80d9940/6.5.9-arch2-1/initrd, /dfde5d2c71e8487c9d478296a80d9940/6.5.9-arch2-1/linux!
ERROR (refind_btrfs.state_management.conditions/conditions.py/check_matched_boot_stanzas): None of the matched boot stanzas are usable!

I change the stanza to the recommended paths, after copying the loader and initrs to /boot, and now it ends with

Initializing the live partition table for device '/dev/nvme0n1' using findmnt.
Found the ESP mounted at '/efi' on '/dev/nvme0n1p7'.
ERROR (refind_btrfs.state_management.conditions/conditions.py/check_filtered_block_devices): Could not find the root partition!

[QuarkZ26]

Also, to add, after changing my stanza to the recommended, Refind quit working and complained about an invalid loader.

Edit: So, I rebooted and the last error went away, refind-btrfs finished without error, however, since refind can't boot anymore, it doesn't help my case! Any pointers would be appreciated as my config was the only was I would have refind work, also I suspect that future kernel updates will update those files, as it's what always happens

Edit2: I completely removed systemd from the picture, recreated the loader and initrd, which properly went in the boot folder. However, whenever I use the /@/boot... path, refind stops working, it seems it's maybe looking into the path /efi/@/boot... and not the root directly. My previous stanza does that, is there anything that says the path is absolute instead of relative?

[Venom1991]

Hm, the only thing that comes to mind is that the root subvolume does not contain the /boot directory. Other than that, I'd try asking here. I'd also try setting rEFInd's "log_level" config option to 1.

[QuarkZ26]

It was indeed an issue with my stanza. It turns out that you can't apparently use the UUID for the volume, you have to use the label or PARTUUID.

Per their site "For EFI boot loaders, you can identify a volume by its filesystem label, partition name, or partition unique GUID value." Once I modified that, everything started working.

Thanks for your time!