install: add `target_root_path` for `RootSetup` #1752

HuijingHei · 2025-11-11T13:36:01Z

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

HuijingHei · 2025-11-12T12:22:42Z

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 · 2025-11-13T16:17:38Z

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 · 2025-11-13T18:30:21Z

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 · 2025-11-14T09:03:26Z

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 · 2025-11-14T14:02:59Z

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.

HuijingHei · 2025-11-17T06:23:06Z

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.

Sorry that this is out of my knowledge, what I see is from clean_boot_directories() before install_to_filesystem_impl(), any pointer for this? Thank you!

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.

LGTM, have no idea where I should add this.

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

Should the new entries config and kernel file are created after running bootc install before reboot?

cgwalters · 2025-11-17T20:55:39Z

Sorry that this is out of my knowledge, what I see is from clean_boot_directories() before install_to_filesystem_impl(), any pointer for this? Thank you!

Yep that's the right place

LGTM, have no idea where I should add this.

In the logic where we have install_via_bootupd I think we'd want to instead do a bootupctl update right?

Should the new entries config and kernel file are created after running bootc install before reboot?

Yes the boot loader entries are written by the install (and upgrade) process; those should stay the same as is today. What's special cased right now is ostree-vs-non-ostree in the install to-existing-root flow, but we could change to preserve /boot/loader by default in all cases, and only prune the non-ostree boot loader entries after an install by default or so.

HuijingHei · 2025-11-18T11:36:24Z

In the logic where we have install_via_bootupd I think we'd want to instead do a bootupctl update right?

The bootupctl update is a little different as it currently reads path form / (see link), and it is running as systemd service which might not suitable in container.

Yes the boot loader entries are written by the install (and upgrade) process; those should stay the same as is today. What's special cased right now is ostree-vs-non-ostree in the install to-existing-root flow, but we could change to preserve /boot/loader by default in all cases, and only prune the non-ostree boot loader entries after an install by default or so.

With @jbtrystram 's help, do testing with change, cleanup ESP files and preserve like /boot/{loader, loader.0, ostree}, run bootc and before reboot, run ostree admin finalize-staged, check new entries are not created, and no new kernel files are installed.

[root@localhost ~]# ostree admin finalize-staged -v
OT: root_is_ostree_booted: 1
OT: remounted /sysroot writable
OT: using fuse: 0
OT: Target rootdev key backing-root-device-inode found
OT: Deployment e1cfc9ab4666fece360f19620d7a4afdb10905454c40c3258d5215949f2838c2.0 unlocked=0

After reboot, boot into the old rhel9.6-edge, directory /boot/grub2 and /boot/bootupd-state.json are missing, the new entry and kernel files are created, also get rpm-ostree error:

rpm-ostree[1273]: 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

I think what you said for the comment makes sense, but I have no idea how to fix this, any pointer is much appreciated. Copy the comment here:

The latter is likely the /boot partition (/etc/fstab ) content being lost as it's local state by default (this also relates to what we did recently by default in the still-experimental https://github.com/bootc-dev/bootc/pull/1588

HuijingHei · 2025-11-21T08:08:59Z

Check more and find that the new ostree-1.conf is created after bootc install, but put under /sysroot/boot and also the kernel files, if I copy the new entry and kernel files to physical /boot, reboot failed with:
error: ../../grub-core/fs/fshelp.c:257:file /boot/ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/vmlinuz-5.14.0-635.el9.x86_64' not found.

[root@localhost ~]# cd /sysroot/
[root@localhost sysroot]# cat boot/loader.1/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=6b3a964e-7790-4d9d-a1cf-4a7675a1fc89 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

[root@localhost sysroot]# ls boot/ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/
initramfs-5.14.0-635.el9.x86_64.img  vmlinuz-5.14.0-635.el9.x86_64

The workaround is remove /boot in the entry file like following, can boot into the new bootc image.

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=6b3a964e-7790-4d9d-a1cf-4a7675a1fc89 console=ttyS0,115200n8 ostree=/ostree/boot.1/default/abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/0
linux /ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/vmlinuz-5.14.0-635.el9.x86_64
initrd /ostree/default-abe244070c34287211ecad478d1ae50bc25a8cdfbefb55218ef19f8c3b3d4735/initramfs-5.14.0-635.el9.x86_64.img

After booted, check that /boot is bindmount with /sysroot/boot, not physical boot.

[root@localhost ~]# bootc status
● Booted image: localhost/bootc:latest
        Digest: sha256:b66719ea7fb1c4d520eb6e3af22b2e6e72c9d4c0437bd4c692aff1cfd0c25c2e (amd64)
       Version: 9 (2025-11-21T03:31:40Z)


[root@localhost ~]# findmnt /boot 
TARGET SOURCE                            FSTYPE OPTIONS
/boot  /dev/mapper/rootvg-lv_root[/boot] xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

Edit:
Copy the claude summary here, let me know if I misunderstood this.
The key points we clarified:

bootc correctly detects the ostree environment and uses /sysroot as the physical root
Bootloader entries ARE created during installation to /sysroot/boot/loader.*/entries/
initramfs creates bind mounts to expose them
/etc/fstab boot entry is ignored due to ostree's bind mount happening first in ostree-prepare-root

This explains why the mount shows as /dev/mapper/rootvg-lv_root[/boot] instead of the separate boot partition

HuijingHei · 2025-11-21T12:13:42Z

Based on the above comment, one workaround is

clean all files under /boot & /boot/efi in clean_boot_directories()
copy /sysroot/boot/loader* to /boot if /boot is separate partition (this need do some change like remove /boot in linux & initrd commands)
copy /sysroot/boot/ostree to /boot
But not sure if this would make other side effects. Any other concerns for this?

Edit:
A better workaround is Injecting kernel arguments using systemd.mount-extra, see https://bootc-dev.github.io/bootc/man/bootc-install-to-existing-root.8.html#injecting-kernel-arguments-for-local-state

Get pointer from bootc-dev#1752 (comment) On Ostree OS, should empty the complete ESP and everything in `/boot` but preserve `/boot/loader`. Signed-off-by: Huijing Hei <[email protected]> Co-worked by: Jean-Baptiste Trystram <[email protected]>

HuijingHei · 2025-11-24T07:20:39Z

Do some testing based on PR,

Before reboot:

[root@localhost ~]# bootc status
[ 4705.559201] SELinux:  Context unconfined_u:object_r:invalid_bootcinstall_testlabel_t:s0 is not valid (left unmapped).
● Booted ostree
           Commit: 524dddce375eb37d24ef040decf165e475f395e9a32399345bf9200ae836d268

   Other image: localhost/bootc:latest
        Digest: sha256:e30a9a716f4ac09cc9eda2eaf03016d3a1d93a5898521997c707be1e980c0512 (amd64)
       Version: 9 (2025-11-24T05:11:22Z)

After reboot and check

[systemd]
Failed Units: 1
  bootc-publish-rhsm-facts.service
[root@localhost ~]# bootc status
● Booted image: localhost/bootc:latest
        Digest: sha256:e30a9a716f4ac09cc9eda2eaf03016d3a1d93a5898521997c707be1e980c0512 (amd64)
       Version: 9 (2025-11-24T05:11:22Z)

 Other ostree
       Commit: 524dddce375eb37d24ef040decf165e475f395e9a32399345bf9200ae836d268

Set the feature on if detect rhel >= 9.6, also centos >= 9 and fedora > 41 Refer to Colin's pointer bootc-dev#1752 (comment) Signed-off-by: Huijing Hei <[email protected]>

Set the feature on if detect rhel >= 9.6 or fedora Refer to Colin's pointer bootc-dev#1752 (comment) Signed-off-by: Huijing Hei <[email protected]>

Get pointer from Colin's comment bootc-dev#1752 (comment) - Empty the complete ESP - On ostree OS, empty `/boot` but preserve `/boot/loader` - On none ostree OS, the loader is directory that needs to be removed. Signed-off-by: Huijing Hei <[email protected]>

Set the feature on if detect rhel >= 9.6 or fedora Refer to Colin's pointer bootc-dev#1752 (comment) Signed-off-by: Huijing Hei <[email protected]>

Get pointer from Colin's comment bootc-dev#1752 (comment) - Empty the complete ESP - On ostree OS, empty `/boot` but preserve `/boot/loader` - On none ostree OS, the loader is directory that needs to be removed. Signed-off-by: Huijing Hei <[email protected]>

Set the feature on if detect rhel >= 9.6 or fedora Refer to Colin's pointer bootc-dev#1752 (comment) Signed-off-by: Huijing Hei <[email protected]>

HuijingHei · 2025-12-09T12:51:12Z

Rebase main branch and doing testing, see this when booting the bootc image. Maybe we do not need the kernel argument for boot mount?

[    6.692668] systemd-fstab-generator[754]: Failed to create unit file '/run/systemd/generator/boot.mount', as it already exists. Duplicate entry in '/proc/cmdline'?
[    6.830908] systemd[743]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

HuijingHei · 2025-12-09T15:02:19Z

Hold on and will do more testing for this.

cgwalters · 2025-12-09T18:49:37Z

crates/lib/src/install.rs

+        };
+
+        // Only preserve loader on ostree
+        if is_ostree && file_name.starts_with("loader") {


This also relates to an issue (TODO link) where we should support preserving basically everything (including the bootloader entries on non-ostree) by default until the very end of the install. And ideally make the "commit" phase an optional step after.

This one also textually conflicts with #1727

This also relates to an issue (TODO link) where we should support preserving basically everything (including the bootloader entries on non-ostree) by default until the very end of the install. And ideally make the "commit" phase an optional step after.

I think you meant preserve everything under /boot & /boot/efi, then clean them before install bootloader, is this right?

This one also textually conflicts with #1727

A little confused, this requires empty rootfs when --replace is not set, but when using to-existing-root it is using ReplaceMode::Alongside by default, maybe I misunderstood this?

Get pointer from Colin's comment bootc-dev#1752 (comment) - Empty the complete ESP - On ostree OS, empty `/boot` but preserve `/boot/loader` - On none ostree OS, the loader is directory that needs to be removed. Signed-off-by: Huijing Hei <[email protected]>

When running `install to-filesystem` on ostree OS, should use `target_root_path` for bootupctl to install bootloader. Signed-off-by: Huijing Hei <[email protected]>

If we're installing alongside existing ostree and there's a separate boot partition, we need to mount it to the sysroot's /boot so ostree can write bootloader entries there. Signed-off-by: Huijing Hei <[email protected]>

Signed-off-by: Huijing Hei <[email protected]>

HuijingHei · 2025-12-10T13:21:45Z

Test locally using tmt -vvvvv run --environment running_env=existing-ostree plans -n /tmt/plans/tests-install/plan-bootc-install-on-ostree --debug, after reboot, get error, will look more about this.

plan failed.

The exception was caused by 1 earlier exceptions

Cause number 1:

    execute step failed

    The exception was caused by 1 earlier exceptions

    Cause number 1:

        Failed to push workdir to the guest. This usually means that login as 'root' to the guest does not work.

        The exception was caused by 1 earlier exceptions

        Cause number 1:

            Command 'rsync --chmod=755 -s -p -e 'ssh -oForwardX11=no -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oConnectionAttempts=5 -oConnectTimeout=60 -oServerAliveInterval=5 -oServerAliveCountMax=60 -oIdentitiesOnly=yes -p10022 -i /var/tmp/tmt/run-003/tmt/plans/tests-install/plan-bootc-install-on-ostree/provision/default-0/id_ecdsa -oPasswordAuthentication=no -S/var/tmp/tmt/run-003/ssh-sockets/127.0.0.1-10022-root.socket' /var/tmp/tmt/run-003/tmt/plans/tests-install/plan-bootc-install-on-ostree/discover/default-0/tests/tmt/tests/tmt-test-wrapper-inner.sh-tmt-tests-install-test-bootc-install-on-ostree-1-default-0-default-0 [email protected]:/var/tmp/tmt/run-003/tmt/plans/tests-install/plan-bootc-install-on-ostree/discover/default-0/tests/tmt/tests/tmt-test-wrapper-inner.sh-tmt-tests-install-test-bootc-install-on-ostree-1-default-0-default-0' returned 3.

            # stderr (3 lines)
            # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Warning: Permanently added '[127.0.0.1]:10022' (ED25519) to the list of known hosts.
            rsync: [Receiver] change_dir#3 "/var/tmp/tmt/run-003/tmt/plans/tests-install/plan-bootc-install-on-ostree/discover/default-0/tests/tmt/tests" failed: No such file or directory (2)
            rsync error: errors selecting input/output files, dirs (code 3) at main.c(818) [Receiver=3.2.5]
            # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

github-actions bot added the area/install Issues related to `bootc install` label Nov 11, 2025

bootc-bot bot requested a review from gursewak1997 November 11, 2025 13:36

HuijingHei force-pushed the target-bootupd branch 6 times, most recently from 01ff672 to 0830023 Compare November 12, 2025 10:06

HuijingHei force-pushed the target-bootupd branch 3 times, most recently from 25cf806 to 4c8db70 Compare November 16, 2025 13:56

HuijingHei force-pushed the target-bootupd branch from 13f3c22 to 41935bb Compare November 19, 2025 07:17

HuijingHei force-pushed the target-bootupd branch 2 times, most recently from 5e2338b to e5a6ba4 Compare November 24, 2025 05:47

HuijingHei marked this pull request as ready for review November 24, 2025 06:39

bootc-bot bot requested a review from jmarrero November 24, 2025 06:39

HuijingHei changed the title ~~install: add root_path for RootSetup~~ install: add target_root_path for RootSetup Nov 24, 2025

HuijingHei force-pushed the target-bootupd branch from e5a6ba4 to 0e61edd Compare November 24, 2025 10:10

HuijingHei force-pushed the target-bootupd branch from fc94a9e to 87d0938 Compare December 5, 2025 09:05

HuijingHei force-pushed the target-bootupd branch from 87d0938 to f00d1aa Compare December 5, 2025 09:29

HuijingHei force-pushed the target-bootupd branch from f00d1aa to 8c974dd Compare December 5, 2025 12:30

HuijingHei force-pushed the target-bootupd branch from 8c974dd to 8395701 Compare December 5, 2025 12:51

HuijingHei force-pushed the target-bootupd branch from 8395701 to 2d9ab89 Compare December 7, 2025 05:13

HuijingHei force-pushed the target-bootupd branch from 2d9ab89 to eeb92f4 Compare December 7, 2025 06:44

HuijingHei force-pushed the target-bootupd branch from eeb92f4 to 57baa18 Compare December 9, 2025 07:51

HuijingHei marked this pull request as draft December 9, 2025 15:02

HuijingHei force-pushed the target-bootupd branch from 57baa18 to 6e74964 Compare December 9, 2025 15:03

cgwalters reviewed Dec 9, 2025

View reviewed changes

HuijingHei added 3 commits December 10, 2025 09:52

install: add target_root_path for RootSetup

02542f8

When running `install to-filesystem` on ostree OS, should use `target_root_path` for bootupctl to install bootloader. Signed-off-by: Huijing Hei <[email protected]>

install: mount separate boot partition to /sysroot/boot on ostree

fa5ce7e

If we're installing alongside existing ostree and there's a separate boot partition, we need to mount it to the sysroot's /boot so ostree can write bootloader entries there. Signed-off-by: Huijing Hei <[email protected]>

HuijingHei force-pushed the target-bootupd branch 4 times, most recently from ae0a194 to b2e796f Compare December 10, 2025 12:10

tmt: add test test-bootc-install-on-ostree on FCOS

bd0513c

Signed-off-by: Huijing Hei <[email protected]>

HuijingHei force-pushed the target-bootupd branch from b2e796f to bd0513c Compare December 10, 2025 13:07

install: add target_root_path for RootSetup #1752

Are you sure you want to change the base?

install: add target_root_path for RootSetup #1752

Uh oh!

Conversation

HuijingHei commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HuijingHei commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters commented Nov 13, 2025

Uh oh!

cgwalters commented Nov 13, 2025

Uh oh!

HuijingHei commented Nov 14, 2025

Uh oh!

cgwalters commented Nov 14, 2025

Uh oh!

HuijingHei commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters commented Nov 17, 2025

Uh oh!

HuijingHei commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HuijingHei commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HuijingHei commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HuijingHei commented Nov 24, 2025

Uh oh!

HuijingHei commented Dec 9, 2025

Uh oh!

HuijingHei commented Dec 9, 2025

Uh oh!

cgwalters Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

HuijingHei Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HuijingHei commented Dec 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

install: add `target_root_path` for `RootSetup` #1752

install: add `target_root_path` for `RootSetup` #1752

HuijingHei commented Nov 11, 2025 •

edited

Loading

HuijingHei commented Nov 12, 2025 •

edited

Loading

HuijingHei commented Nov 17, 2025 •

edited

Loading

HuijingHei commented Nov 18, 2025 •

edited

Loading

HuijingHei commented Nov 21, 2025 •

edited

Loading

HuijingHei commented Nov 21, 2025 •

edited

Loading

HuijingHei Dec 10, 2025 •

edited

Loading