install: Enable installing to multi device parents

[ckyrouac]

When the root filesystem spans multiple backing devices (e.g., LVM across multiple disks), discover all parent devices and find ESP partitions on each. For bootupd/GRUB, install the bootloader to all devices with an ESP partition, enabling boot from any disk in a multi-disk setup. systemd-boot and zipl only support single-device configurations.

This adds a new integration test validating both single-ESP and dual-ESP multi-device scenarios.

Fixes: #481

Assisted-by: Claude Code (Opus 4.5)

[gemini-code-assist]

Code Review

This pull request successfully enables installing to multi-device parent filesystems, such as LVM spanning multiple disks. It correctly discovers all parent devices and, for bootupd/GRUB, installs the bootloader to all devices with an ESP partition. For bootloaders that only support single-device configurations like systemd-boot and zipl, the implementation correctly defaults to using the first available device. The changes are well-architected, adapting data structures and logic to handle multiple devices. A new, thorough integration test validates both single and dual ESP scenarios. Overall, this is a solid enhancement with good error handling and logging. I have one suggestion to further improve the robustness of ESP detection.

[ckyrouac]

waiting to merge until the patch release goes out

[HuijingHei]

Maybe this PR could help to consider #1916 ? @ckyrouac

[HuijingHei]

How about add another test scenario like RAID1 that using the whole disks (see coreos/bootupd#1059), for example:

root@localhost-live:/home/fedora# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
vda         253:0    0   30G  0 disk  
└─md126       9:126  0   30G  0 raid1 
  ├─md126p1 259:0    0  477M  0 part  
  ├─md126p2 259:1    0  954M  0 part  /boot
  └─md126p3 259:2    0 28.6G  0 part  /
vdb         253:16   0   30G  0 disk  
└─md126       9:126  0   30G  0 raid1 
  ├─md126p1 259:0    0  477M  0 part  
  ├─md126p2 259:1    0  954M  0 part  /boot
  └─md126p3 259:2    0 28.6G  0 part  /

To create RAID1 using command:
sudo mdadm -CR /dev/md126 -e 1 -l1 -n 2 /dev/loop0 /dev/loop1 --assume-clean

[cgwalters]

Looks sane to me, I have just nits really that are nonblocking, we can fix in followups too.

[cgwalters]

Let's use a shared const for this or perhaps better have set_default_path() on BwrapCmd

[cgwalters]

This is a bit tricky as we probably also want to CI test the case without the new bootupd too...

I know, another matrix entry in theory...

I guess it'll be tested in post submits by the workflow test.

[cgwalters]

We're just testing installation to loopback, AFAICS there's no reason to reboot the host.

That said what would be a stronger test here is for us to test these setups probably via Anaconda where we boot into a guest VM with that. I tried to streamline this in bootc-dev/bcvk#202 but yeah it needs a bit of work.

I guess one thing we could do is extend the anaconda stuff we already have here in our integration tests.

Yet a different alternative is we ask tmt to directly support kickstart (and copy over some of the bcvk smarts there re mounting host container storage via virtiofs etc).