`blsforme` does not handle btrfs partitions in LVM correctly

[cuddleworks]

During my adventures with installing AerynOS on LVM on LUKS, I encountered very funky kernel cmdlines, for example:

Global cmdline : ["rd.luks.uuid=fbaac6bf-0475-4caf-83a6-a8a8961d5be8 root=UUID=9e6f6ed6-1c16-4c0d-b407-2dba3a620c13 root=UUID=9b7772ad-7783-4525-9646-baa3d2a1e6b9   rd.luks.uuid=fbaac6bf-0475-4caf-83a6-a8a8961d5be8 root=UUID=9b7772ad-7783-4525-9646-baa3d2a1e6b9", "rw"]

This is because blsforme adds all the logical volumes and as custodials of the root partition, leading blsforme into being a bit confused.

Duplicate entries for the correct root and luks uuids are technically fine, however if an auxiliary partition is btrfs, it is included in the kernel cmdline as a root filesystem, and that can lead to a system that cannot get past initrd, because it tries to use an auxiliary partition as sysroot.

This happens because of this block of code, where you can see that the superblock::Kind::Btrfs always adds a btrfs block as a root device:

// crates/topology/src/disk/device.rs:99-127
let local = if let Some(kind) = &self.kind {
    match kind {
        superblock::Kind::Btrfs => {
            let uuid = self.uuid.as_ref().expect("cannot have btrfs without uuid..");
            if let Some(subvol) = mount_options.get("subvol") {
                format!("root=UUID={uuid} rootfsflags=subvol={subvol}")
            } else {
                format!("root=UUID={uuid}")
            }
        }
        superblock::Kind::Luks2 => {
            let uuid = self.uuid.as_ref().expect("cannot have luks2 without uuid");
            format!("rd.luks.uuid={uuid}")
        }
        _ => {
            if let Some(guid) = self.guid.as_ref() {
                format!("root=PARTUUID={guid}")
            } else if let Some(uuid) = self.uuid.as_ref() {
                format!("root=UUID={uuid}")
            } else {
                String::new()
            }
        }
    }
} else if !self.aux {
    format!("root={}", &self.path)
} else {
    String::new()
};

PS: I only tested this on a setup with LVM Thin Provisioning, however I am fairly certain that this issue would occur even without it