Add support for installing to devices with multiple parents

[ckyrouac]

See individual commits for details. Generally, this migrates to using the new blockdev crate funtions and standardize on the Device struct operating on block devices. On top of this, handle the --filesystem and multiple --device flags to install the bootloader to multiple devices, e.g. a /dev/md0 RAID1 device backed by 3 physical disks, each with an ESP partition.

Keeping this as a draft because it will break older bootc versions prior to bootc-dev/bootc#2048.

Leaving the TEMP code in to validate CI passes (previously validated on my fork).

[openshift-ci]

Hi @ckyrouac. Thanks for your PR.

I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[gemini-code-assist]

Code Review

This pull request is a significant and well-executed refactoring to support installing bootloaders to multiple devices, such as in a RAID setup. The migration to the bootc-internal-blockdev crate and the Device struct is consistently applied across the codebase. The new CLI options --device and --filesystem are sensible additions. The logic for handling multiple devices, especially for EFI where it filters for ESPs, is robust. I've also noticed some nice correctness improvements, like verifying that a VFAT partition is a true mount point. I have a couple of suggestions to fix a potential panic when dealing with relative paths, and one for code simplification.

[gemini-code-assist]

There's a potential panic here. path.parent() can return Some("") if path is a relative path without a directory separator (e.g., "efi"). This would cause std::fs::metadata("") to be called, which fails. This can happen if root is relative. To make this more robust, you should handle the empty path case, for example by treating it as the current directory ..

[gemini-code-assist]

Similar to a previous comment, there's a potential panic here. mnt.parent() can result in an empty path, which will cause std::fs::metadata to fail. Handling this case by defaulting to the current directory . would make the code more robust against different path structures.

[gemini-code-assist]

This block of code can be made more concise by using filter_map to combine the filtering and mapping operations into a single step. This can improve readability.

Suggested change

	let with_esp: Vec<Option<&Device>> = devices
	.iter()
	.filter(|dev| match dev.find_partition_of_esp() {
	Ok(_) => true,
	Err(e) => {
	log::warn!("Skipping device {} for EFI: {:#}", dev.path(), e);
	false
	}
	})
	.map(|dev| Some(dev))
	.collect();
	let with_esp: Vec<Option<&Device>> = devices
	.iter()
	.filter_map(|dev| match dev.find_partition_of_esp() {
	Ok(_) => Some(Some(dev)),
	Err(e) => {
	log::warn!("Skipping device {} for EFI: {:#}", dev.path(), e);
	None
	}
	})
	.collect();