install: add root_path for RootSetup

[HuijingHei]

When install to-filesystem on ostree OS, will pass root_path to bootupctl to install bootloader.

[HuijingHei]

Build the patch based on quay.io/centos-bootc/centos-bootc:stream9, run bootc install to-existing-root on rhel9.6-edge.

Check the /boot/efi/EFI/centos directory is created, bootuuid.cfg and grub.cfg is updated. Is this expected?

If I reboot, seems it still booted into old rhel9.6, how can I check if the installation is successful?

• Run bootc install

# podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
--pid=host --security-opt label=type:unconfined_t \
localhost/bootc:latest \
env BOOTC_BOOTLOADER_DEBUG=1 bootc install to-existing-root --skip-fetch-check --acknowledge-destructive --root-ssh-authorized-keys /target/root/.ssh/id_rsa.pub --karg=console=ttyS0,115200n8
...
Installing image: docker://localhost/bootc:latest
Digest: sha256:f23c996f7ef414d2a9fbfef366b1dbc513c1f564064fc687da39e793365a5ac9
Bootloader: grub
Reusing extant ostree layout
layers already present: 0; layers needed: 70 (2.2 GB)
Deploying container image...done (26 seconds)
Injected: etc/tmpfiles.d/bootc-root-ssh.conf
Installing bootloader via bootupd
[TRACE bootupd] executing cli
[INFO  bootupd::bootupd] System boot method: EFI
[DEBUG bootupd::efi] Found metadata grub2-efi-x64-1:2.06-118.el9.x86_64,shim-x64-15.8-2.el9.x86_64
[DEBUG bootupd::efi] Reusing existing mount point "/target/boot/efi"
[DEBUG bootupd::efi] Get product name: 'CentOS Stream'
Executing: "efibootmgr" "--create" "--disk" "/dev/vda" "--part" "1" "--loader" "\\EFI\\centos\\shimx64.efi" "--label" "CentOS Stream"
[DEBUG bootupd::efi] Creating new EFI boot entry using 'CentOS Stream'
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0005,0002,0003,0000,0001,0004
Boot0000* BootManagerMenuApp
Boot0001* EFI Firmware Setup
Boot0002* Red Hat Enterprise Linux
Boot0003* UEFI Misc Device
Boot0004* EFI Internal Shell
Boot0005* CentOS Stream
[INFO  bootupd::bootupd] Installed EFI grub2-efi-x64-1:2.06-118.el9.x86_64,shim-x64-15.8-2.el9.x86_64
[DEBUG bootupd::grubconfigs] root_dev=64768 boot_dev=64514
Added 01_users.cfg
Added 10_blscfg.cfg
Added 14_menu_show_once.cfg
Added 30_uefi-firmware.cfg
Added 41_custom.cfg
Installed: grub.cfg
Installed: bootuuid.cfg
[DEBUG bootupd::grubconfigs] vendordir="centos"
Installed: "centos/grub.cfg"
Installed: "centos/bootuuid.cfg"
[DEBUG bootupd::efi] Unmounting
[TRACE bootupd::efi] Unmounted
Installation complete!

• Check the /boot/efi/EFI/centos dir exists, bootuuid.cfg and grub.cfg is updated.

[root@localhost ~]# rpm-ostree status
State: idle
Deployments:
● edge:rhel/9/x86_64/edge
                  Version: 9.6 (2025-11-11T07:44:55Z)
                   Commit: e1cfc9ab4666fece360f19620d7a4afdb10905454c40c3258d5215949f2838c2

[root@localhost ~]# ls /boot/efi/EFI/*
/boot/efi/EFI/BOOT:
BOOTX64.EFI  fbx64.efi

/boot/efi/EFI/centos:
BOOTX64.CSV   grub.cfg	   mmx64.efi  shimx64-centos.efi
bootuuid.cfg  grubx64.efi  shim.efi   shimx64.efi

/boot/efi/EFI/redhat:
BOOTX64.CSV  grubx64.efi  shim.efi	      shimx64.efi
grub.cfg     mmx64.efi	  shimx64-redhat.efi

[root@localhost ~]# cat /boot/efi/EFI/centos/bootuuid.cfg 
set BOOT_UUID="9098a193-ff0f-4f34-aa2f-fcff9bb043c0"
[root@localhost ~]# blkid /dev/vda2
/dev/vda2: UUID="9098a193-ff0f-4f34-aa2f-fcff9bb043c0" TYPE="xfs" PARTUUID="1d7009d0-6e6e-4093-b35c-137e3c61531b"

[root@localhost ~]# cat /boot/efi/EFI/centos/grub.cfg 
if [ -e (md/md-boot) ]; then
  # The search command might pick a RAID component rather than the RAID,
  # since the /boot RAID currently uses superblock 1.0.  See the comment in
  # the main grub.cfg.
  set prefix=md/md-boot
else
  if [ -f ${config_directory}/bootuuid.cfg ]; then
    source ${config_directory}/bootuuid.cfg
  fi
  if [ -n "${BOOT_UUID}" ]; then
    search --fs-uuid "${BOOT_UUID}" --set prefix --no-floppy
  else
    search --label boot --set prefix --no-floppy
  fi
fi
if [ -d ($prefix)/grub2 ]; then
  set prefix=($prefix)/grub2
  configfile $prefix/grub.cfg
else
  set prefix=($prefix)/boot/grub2
  configfile $prefix/grub.cfg
fi
boot

• Reboot and check rpm-ostreed.service failed

[root@localhost ~]# journalctl -u rpm-ostreed.service --no-page
Nov 12 12:19:11 localhost.localdomain systemd[1]: Starting rpm-ostree System Management Daemon...
Nov 12 12:19:11 localhost.localdomain rpm-ostree[951]: Reading config file '/etc/rpm-ostreed.conf'
Nov 12 12:19:11 localhost.localdomain rpm-ostree[951]: error: Couldn't start daemon: Error setting up sysroot: loading sysroot: Unexpected state: /run/ostree-booted found and in / sysroot, but bootloader entry not found
Nov 12 12:19:11 localhost.localdomain systemd[1]: rpm-ostreed.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 12:19:11 localhost.localdomain systemd[1]: rpm-ostreed.service: Failed with result 'exit-code'.
Nov 12 12:19:11 localhost.localdomain systemd[1]: Failed to start rpm-ostree System Management Daemon.

[cgwalters]

This is a complex topic. A first thing here is that bootc install is always destructive with respect to /boot and the ESP. We definitely need to avoid that in the case where the system is already managed via bootupd. I think that's causing part of the problem here.

This issue also relates to #820

I think at the current time it's expected that to-existing-root in this scenario does wipe things, but I think we're also missing cleanup of the prior deployments by default.

If I reboot, seems it still booted into old rhel9.6, how can I check if the installation is successful?

That is strange; what does bootc status say in this setup before reboot?

[cgwalters]

One issue also related to this is that some of the install integration tests are still mostly orchestrated via the GHA test-install and haven't been lowered into a more rigorous/reproducible setup.

I think we should likely switch them over to tmt. Although it gets subtle as reproducing the Edge starting state via tmt will require some work, but we can do that as a followup.

[HuijingHei]

This is a complex topic. A first thing here is that bootc install is always destructive with respect to /boot and the ESP. We definitely need to avoid that in the case where the system is already managed via bootupd. I think that's causing part of the problem here.

Actually on ostree OS, it only removes bootupd-state.json (see https://github.com/bootc-dev/bootc/blob/main/crates/lib/src/install.rs#L1845), and keep all the other files, but maybe cleanup some files later?
If I boot rhel-edge and bootc install centos, then there are 2 vendors under /boot/efi, maybe useful to keep the dual OS?

That is strange; what does bootc status say in this setup before reboot?

[root@localhost ~]# bootc status
● Booted ostree
           Commit: e1cfc9ab4666fece360f19620d7a4afdb10905454c40c3258d5215949f2838c2

Run bootc install, before boot, not found new /boot/loader/entries/ostree-2.conf and the new default kernel file under /boot/ostree, are the files created during boot?

[root@localhost ~]# ls /boot/loader/entries/
ostree-1.conf
[root@localhost ~]# ls /boot/ostree/
rhel-73943340a8bb027bb3783557749af43d3b71ed9c720166c7431b08d8845d392c

After reboot, boot into the old rhel9.6-edge, find directory /boot/grub2 and /boot/bootupd-state.json are missing, the new entry config and kernel files are created.
The workaround is to install bootloader again to bootinto the the bootc image.

# ls /boot/
boot  efi  loader  loader.1  ostree

# ls /boot/ostree/
default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735
# cat /boot/loader/entries/ostree-1.conf 
title CentOS Stream 9 (ostree:0)
version 1
options root=/dev/mapper/rootvg-lv_root rd.lvm.lv=rootvg/lv_root rd.lvm.lv=rootvg/lv_swap rw boot=UUID=715f41aa-99c5-42b1-8072-2f73a6600c27 console=ttyS0,115200n8 ostree=/ostree/boot.1/default/abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/0
linux /boot/ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/vmlinuz-5.14.0-635.el9.x86_64
initrd /boot/ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/initramfs-5.14.0-635.el9.x86_64.img

[cgwalters]

Actually on ostree OS, it only removes bootupd-state.json

You're right! And that's one of the issues here - this system is ostree but not bootupd, and that's one of the problem roots - I think in this case we'll just not change the bootloader state at all which is not expected.

I think basically if we detect ostree but not bootupd, then we should proceed by wiping out the complete ESP as before alongside everything in /boot except /boot/loader or so.

---

Now...there is a related but distinct thing here which is that if we detect bootupd, we should also forcibly do a bootupctl update instead of an install.