install : run bootupd with ` --src-root` pointing to the deployed container

[jbtrystram]

Currently the bootc install makes assumptions about being run from the container. It mostly work outside of it, but also assume the buildroot is the same as the container content. (see #1438 and #1410).

the bootloader setup runs into the same pitfall : it expects /usr/lib/bootupd/updates/<component> to exists, but it may not if we are using a different buildroot.
If i understand correctly, the call to bootupd is done after the container content is deployed, so bootupd could be pointed to the deployment.
The docs even outline the ostree use case :

https://github.com/coreos/bootupd/blob/3acb6742f74be63c655c64c6adff57b2c2fb93cc/README-devel.md?plain=1#L44-L53

In CoreOS builds through osbuild we chroot before calling bootupd to work around this:

https://github.com/osbuild/osbuild/blob/841e89fe08cb80d115871aa45696e37fae41cf23/stages/org.osbuild.bootupd#L67-L72

Related discussion in #879

[jbtrystram]

I tried something naive to see if that would work :

diff --git a/crates/lib/src/bootloader.rs b/crates/lib/src/bootloader.rs
index fe7aa46d..fd67e4aa 100644
--- a/crates/lib/src/bootloader.rs
+++ b/crates/lib/src/bootloader.rs
@@ -20,10 +20,19 @@ pub(crate) fn install_via_bootupd(
     let bootupd_opts = (!configopts.generic_image).then_some(["--update-firmware", "--auto"]);
 
     let devpath = device.path();
+    let srcroot = format!(
+        "{}/deploy/{}/deploy/<ostree-ref>/",
+        rootfs.as_str(),
+        configopts
+            .stateroot
+            .clone()
+            .unwrap_or("default".to_string())
+    );
     let args = ["backend", "install", "--write-uuid"]
         .into_iter()
         .chain(verbose)
         .chain(bootupd_opts.iter().copied().flatten())
+        .chain(["--src-root", srcroot.as_str()])
         .chain(["--device", devpath.as_str(), rootfs.as_str()]);
     Task::new("Running bootupctl to install bootloader", "bootupctl")
         .args(args)

but i don't know how I can resolve the ostree deployment ID

[cgwalters]

OK yes, I added the source-imageref label which we should use to track these ones.

Yes we need to fix this in general.

but i don't know how I can resolve the ostree deployment ID

See use of crate::utils::deployment_fd

[jbtrystram]

See use of crate::utils::deployment_fd

Thanks ! I made something that worked in #1460