Skip to content

Conversation

@HuijingHei
Copy link
Contributor

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

@github-actions github-actions bot added the area/install Issues related to `bootc install` label Nov 11, 2025
@bootc-bot bootc-bot bot requested a review from gursewak1997 November 11, 2025 13:36
@HuijingHei HuijingHei force-pushed the target-bootupd branch 5 times, most recently from 408e6d8 to 01ff672 Compare November 12, 2025 09:33
When `install to-filesystem` on ostree OS, will pass `root_path`
to bootupctl to install bootloader.

Signed-off-by: Huijing Hei <[email protected]>
@HuijingHei
Copy link
Contributor Author

HuijingHei commented Nov 12, 2025

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/install Issues related to `bootc install`

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants