Add an argument `boot-uuid` to bootupctl install

[HuijingHei]

With bootc-dev/bootc#1816, bootc install on existing FCOS test failed.

When running bootc install without separate /boot, if chroot to the ostree deployment, the write_uuid will fail as inspected the / filesystem as it is not mounted.

Copy failed log from https://github.com/bootc-dev/bootc/actions/runs/20912844659/job/60080780702?pr=1816

                        content: Installed: grub.cfg
                        content: error: boot data installation failed: Installing static GRUB configs: Inspecting filesystem ".": Subprocess failed: ExitStatus(unix_wait_status(256))
                        content: 
                        content: error: Installing to filesystem: Installing bootloader: Failed to run command: Command {
                        content:     program: "chroot",
                        content:     args: [
                        content:         "chroot",
                        content:         "/target/ostree/deploy/default/deploy/e1522e8dbaa55a684e1906a1ef7e91ea7f3014db86c25f84e3ab31be356eb247.0",
                        content:         "bootupctl",
                        content:         "backend",
                        content:         "install",
                        content:         "--write-uuid",
                        content:         "--update-firmware",
                        content:         "--auto",
                        content:         "--device",
                        content:         "/dev/vda",
                        content:         "/",
                        content:     ],
                        content:     env: CommandEnv {
                        content:         clear: false,
                        content:         vars: {
                        content:             "PATH": Some(
                        content:                 "/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin",
                        content:             ),
                        content:         },
                        content:     },
                        content:     create_pidfd: false,
                        content: }

To workaround, one option is pass boot-uuid to bootupctl as it already detect in bootc (https://github.com/bootc-dev/bootc/blob/main/crates/lib/src/install.rs#L1568)

[HuijingHei]

CC @jbtrystram

@cgwalters If we could pass boot-uuid, then bootupd will not retrieve it again. WDYT?

[jbtrystram]

as inspected the / filesystem as it is not mounted.

well in this case / is /target/ostree/deploy/default/deploy/e1522e..., so it is mounted ? Except if the chroot makes findmnt calls to not work because the mount table paths don't make sense in the chroot ?

To workaround, one option is pass boot-uuid to bootupctl as it already detect in bootc (bootc-dev/bootc@main/crates/lib/src/install.rs#L1568)

[cgwalters]

well in this case / is /target/ostree/deploy/default/deploy/e1522e..., so it is mounted ?

Are you making that dir a mount point? If not then it's not mounted. Adding that bind mount would likely be the simplest change.

For the composefs case we'll need to make a mount point anyways.

[jbtrystram]

well in this case / is /target/ostree/deploy/default/deploy/e1522e..., so it is mounted ?

Are you making that dir a mount point? If not then it's not mounted. Adding that bind mount would likely be the simplest change.

/target/ostree/deploy/default/deploy/e1522 contains the deployed tree on the target disk, and we chroot in there, so it becomes /. Why would I make it a mount point ? I am not following.

[cgwalters]

Why would I make it a mount point ? I am not following.

Because then findmnt on it will work. Look at what ostree-prepare-root.c does - it's made into a bind mount (to itself).

For the composefs case we'll need to make a mount point anyways.

That said, there's the next problem in that in order for bootupd+grub+composefs to work we'll actually need to ensure we "peel" the deployment root mount in order to get the real underlying filesystem. This relates to composefs/composefs#420 and others.

@cgwalters If we could pass boot-uuid, then bootupd will not retrieve it again. WDYT?

Mmmm...I think what we really want to do here is twofold:

• Also ensure that /sysroot is set up to be the physical root
• Ensure that bootupd is always (just like bootc!) able to detect and always understand the "deployment /" vs "physical root" (same as thread in install: add target_root_path for RootSetup bootc-dev/bootc#1752 (comment) )

[jbtrystram]

Because then findmnt on it will work. Look at what ostree-prepare-root.c does - it's made into a bind mount (to itself).

I just tried :

root@cosa-devsh:/var/home/core# deploy=/sysroot/ostree/deploy/fedora-coreos/deploy/36ff46d732a070a1bf10f7157f764e316f99a836dcdbf56702798e5042411fe9.0
root@cosa-devsh:/var/home/core# findmnt $deploy
<no result>
root@cosa-devsh:/var/home/core# mount --bind $deploy $deploy
root@cosa-devsh:/var/home/core# findmnt $deploy
TARGET                                                                                 SOURCE                                  FSTYPE OPTIONS
/sysroot/ostree/deploy/fedora-coreos/deploy/36ff46d732a070a1bf10f7157f764e316f99a836dcdbf56702798e5042411fe9.0
                                                                                       /dev/vda4[/ostree/deploy/fedora-coreos/deploy/36ff46d732a070a1bf10f7157f764e316f99a836dcdbf56702798e5042411fe9.0]

🤯 TIL, thanks!

[HuijingHei]

• Also ensure that /sysroot is set up to be the physical root
• Ensure that bootupd is always (just like bootc!) able to detect and always understand the "deployment /" vs "physical root"

Will look at this firstly, then the boot-uuid argument looks useless.