Suggestion: use "options" to identify boot stanza instead of "volume"

[psfloyd]

TL;DR: use root= kernel parameter in options token to find proper boot stanza, instead of volume token.

Looking at older issues and experimenting with my own layout I have noticed that the refind-btrfs has problems with partition layouts that have a separate boot partition.

In my case the general layout is as follows:

NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1        259:0    0 931.5G  0 disk  
├─nvme0n1p1    259:1    0   300M  0 part  /efi
├─nvme0n1p2    259:2    0     1G  0 part  /boot
├─nvme0n1p3    259:3    0   800G  0 part  
│ └─kstar-root 254:0    0   800G  0 crypt /home/.snapshots
│                                         /home
│                                         /swap
│                                         /.snapshots
│                                         /

As you can see there are 3 main partitions:

• An EFI partition
• A boot partition
• A root partition

The problem is that for the system to properly boot the volume token in the manual stanza in refind.conf has to point to the boot partition. Otherwise refind does not find the kernel images. The stanza I normally use looks like this:

menuentry "archlinux" {
    icon /EFI/refind/themes/black/icons/os_arch.png
    volume   kstar-boot
    loader   /vmlinuz-linux
    initrd   /initramfs-linux.img
    options  "root=/dev/mapper/kstar-root rw rootflags=subvol=@ initrd=\intel-ucode.img resume=/dev/mapper/kstar-root resume_offset=16400 quiet splash"
    submenuentry "Boot using fallback initramfs" {
        initrd /initramfs-linux-fallback.img
    }
}

In this case refind-btrfs errors out with Could not find a boot stanza matched with the root partition!. Because it is searching in the volume token, and this token is not pointing to the root partition.

Because of this I think searching for the appropriate boot stanza by looking at the options token would work better and encompass a wider range of partition layouts.

For this to work the tool would have to search for the root= kernel parameter in the options token and use that parameter to match the proper boot stanza. This would be using the appropriate form of the name (block device name, PARTLABEL, PARTUUID).

In my case it would match by block device name. But the root= kernel parameters also accepts the other naming schemes (and even more if it is an initrams with udev). The parameters would look like this in each case:

root=/dev/block
root=UUID=filesystem_uuid
root=LABEL=filesystem_label
root=PARTLABEL=partition_label
root=PARTUUID=partition_uuid

What do you think of this idea? Does it sound possible to implement?

[Venom1991]

Sure, I could add this comparison as a fallback one in case the volume comparison evaluates to False.
I don't think that this would required much work at all, just by looking at how the code works. It's been a while since I've looked at it so I have to remember a few bits, here and there. Hopefully, the "root" option's possible formats you've listed here are exactly those or are at least finite.

The thing is that I don't have a separate /boot partition on my system, but I'll just have to mock this kind of layout somehow. I hope that these changes will be helpful for future users who are using similar layouts.

Thank you for the suggestion.

[psfloyd]

I found the possible formats for "root" in the archwiki: Persistent block device naming. The only one I left out is "Disk ID" because it is not currently supported by refind-btrfs.

For testing you could create a fake refind.conf with the volume set to an arbitrary value different than your root partition. Then run refind-btrfs with refind_config set to that fake file. I have been testing in that way as to not break my bootloader.

If you need to do any testing in a live system I would be willing to run some tests for you.

[Venom1991]

I'll create a fake file, like you've mentioned, with the "wrong" volume value but I'll use the correct "root" flag so that I can trigger the fallback matching mechanism. I'll have to take care of this bug before working on this, though.

Regarding the disk id pattern, I suppose that lsblk and/or findmnt can provide these values and if so, I could support it as well.

[Venom1991]

Implemented in release 0.3.9.