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

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

install: empty /boot & /boot/efi
When install to-filesystem on ostree OS, will pass target_root_path to bootupctl to install bootloader.
install: should remove the empty dir under /boot
install: mount esp part before clean_boot_directories()

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 <hhei@redhat.com> Co-worked by: Jean-Baptiste Trystram <jbtrystram@redhat.com>

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

cgwalters · 2025-12-15T18:20:17Z

readdir: Too many open files

I think this is a generic virtiofs flake. There's also bootc-dev/bcvk#157 which is a different error - but might be related, I haven't dug enough into it. You can try to restart to see if it is a flake.

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 <hhei@redhat.com>

HuijingHei · 2025-12-18T07:25:11Z

Finally the test is passed (see https://github.com/bootc-dev/bootc/actions/runs/20326393875/job/58393662760), ready for reviewing now, thank you so much @cgwalters for the pointer.

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 <hhei@redhat.com>

When running `install to-filesystem` on ostree OS, should use `target_root_path` for bootupctl to install bootloader. Signed-off-by: Huijing Hei <hhei@redhat.com>

Fix what we did in bootc-dev@92d9d38 Signed-off-by: Huijing Hei <hhei@redhat.com>

cgwalters

Thanks for the hard work on this! There's so many subtleties here. I think this looks right, but I would like to spend some time looking more carefully after break too.

cgwalters · 2025-12-18T23:02:35Z

Justfile

+# Build test container image for testing on coreos with SKIP_CONFIGS=1,
+# without configs and no curl container image
+build-testimage-coreos PATH:
+    @just build-from-package {{PATH}}


Ah it looks like this is going to conflict with #1864

But it's ok if this goes in first I can rebase

cgwalters · 2025-12-18T23:04:34Z

tmt/tests/install/test-on-ostree/test-install-on-ostree.sh

+#   adjust:
+#     - when: VARIANT_ID != coreos
+#       enabled: false
+#       because: this needs to start an ostree OS firstly


Hum. But what does "ostree OS" mean here that's different from the other tests which start via bcvk libvirt run?

Doesn't this relate more to just the /boot partition setup?

If it's about having a separate /boot on an ostree based OS then note we should also be able to easily replicate this with Anaconda-based installs too (or bootc-image-builder).

I think this is more related to esp partition and a separate /boot on existing ostree OS, like edge and FCOS/RHCOS.

Maybe I should use coreos here, as it is testing on FCOS. In this case, just use bcvk libvirt run to start fedora-coreos:testing-devel and then do testing.
I can try later if can use Anaconda, thank you for your pointer!

crates/xtask/src/tmt.rs

crates/lib/src/bootloader.rs

cgwalters · 2025-12-18T23:13:54Z

crates/xtask/src/tmt.rs

                );
            }
-
+            // Add --filesystem=xfs by default on fedora-coreos


OK as is but I think we should just put that in the default FCOS container image. As is done in https://gitlab.com/redhat/centos-stream/containers/bootc/-/commit/cfafc9e78a0c9cbdb016113edd6a5dd35d87ab8b
Then we can drop it here.

cgwalters · 2025-12-18T23:22:40Z

crates/lib/src/install.rs

        }
-        Some(ReplaceMode::Alongside) => clean_boot_directories(&rootfs_fd, is_already_ostree)?,
+        Some(ReplaceMode::Alongside) => {
+            // On existing ostree OS like FCOS, esp is not mounted after booted,


That's not strictly true, Anaconda writes the ESP into /boot/efi and it is mounted by default I think.

I'd probably just drop the comment

For Anaconda yes, but on booted FCOS, the ESP part is not mounted, and /boot/efi will be removed in clean_boot_directories(), so need to mount ESP before clean_boot_directories().

Move crate::bootloader::mount_esp_part() to clean_boot_directories()

crates/lib/src/install.rs

On FCOS, esp is not mounted after booted, need to find esp and mount before cleaning, or `/boot/efi` will be removed. Signed-off-by: Huijing Hei <hhei@redhat.com>

To workaround bootc-dev/bcvk#174, will build `bootc-integration-coreos` container firstly and save it to `bootc.tar`, then load it to install. Signed-off-by: Huijing Hei <hhei@redhat.com>

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 2 times, most recently from 753d5b7 to 9074ef8 Compare December 15, 2025 15:15

HuijingHei force-pushed the target-bootupd branch from 9074ef8 to f62e5d3 Compare December 16, 2025 01:31

HuijingHei force-pushed the target-bootupd branch 3 times, most recently from a3de335 to cd6699e Compare December 16, 2025 13:57

HuijingHei force-pushed the target-bootupd branch 2 times, most recently from 735ece3 to 498f92a Compare December 17, 2025 03:48

HuijingHei force-pushed the target-bootupd branch 2 times, most recently from ed86df0 to e7f2b8e Compare December 18, 2025 03:51

HuijingHei force-pushed the target-bootupd branch 2 times, most recently from f6760e9 to b313845 Compare December 18, 2025 07:22

HuijingHei marked this pull request as ready for review December 18, 2025 07:25

bootc-bot bot requested a review from ckyrouac December 18, 2025 07:25

HuijingHei requested a review from cgwalters December 18, 2025 07:32

HuijingHei added 3 commits December 18, 2025 18:02

install: add target_root_path for RootSetup

f3f1c54

When running `install to-filesystem` on ostree OS, should use `target_root_path` for bootupctl to install bootloader. Signed-off-by: Huijing Hei <hhei@redhat.com>

install: should remove the empty dir under /boot

3c93ab1

Fix what we did in bootc-dev@92d9d38 Signed-off-by: Huijing Hei <hhei@redhat.com>

HuijingHei force-pushed the target-bootupd branch from b313845 to 914710a Compare December 18, 2025 10:03

cgwalters approved these changes Dec 18, 2025

View reviewed changes

HuijingHei added 2 commits December 19, 2025 17:28

install: mount esp in clean_boot_directories()

d4e52b6

On FCOS, esp is not mounted after booted, need to find esp and mount before cleaning, or `/boot/efi` will be removed. Signed-off-by: Huijing Hei <hhei@redhat.com>

tests: Add test test-tmt-on-coreos

fecf28b

To workaround bootc-dev/bcvk#174, will build `bootc-integration-coreos` container firstly and save it to `bootc.tar`, then load it to install. Signed-off-by: Huijing Hei <hhei@redhat.com>

HuijingHei force-pushed the target-bootupd branch from 914710a to fecf28b Compare December 19, 2025 09:31

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!

cgwalters commented Dec 15, 2025

Uh oh!

HuijingHei commented Dec 18, 2025

Uh oh!

cgwalters left a comment

Choose a reason for hiding this comment

Uh oh!

cgwalters Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

cgwalters Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

HuijingHei Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cgwalters Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

cgwalters Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

HuijingHei Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

HuijingHei Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

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