bootc install to-existing-root fails when run on ostree based system

[dustymabe]

I was poking around with bootc trying to do something akin to a "factory reset". I know this might not be the particular use case of to-existing-root, but I hit this issue anyway and figured it would be worth a report:

[core@cosa-devsh ~]$ sudo RUST_LOG=debug bootc install to-existing-root --source-imgref docker://quay.io/fedora/fedora-coreos:rawhide
DEBUG argv0="bootc"
DEBUG exec: "ostree" "--repo=/ostree/repo" "rev-parse" "--single"
error: Multiple commit objects found
ERROR Installing to filesystem: Creating source info from a given imageref: Task Reading ostree commit failed: ExitStatus(unix_wait_status(256))

It seems the use of "ostree" "--repo=/ostree/repo" "rev-parse" "--single" causes some problems because that will fail if there are multiple commits on the system as are there by default on our CoreOS OSTree systems we ship.

[core@cosa-devsh ~]$ rpm-ostree status 
State: idle
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:testing-devel
                   Digest: sha256:be7bf296a0d9d0b35085365b34b9ce711aeef3adc9b5e908c0a3663873e4d888
                  Version: 42.20250525.dev.0 (2025-05-25T12:56:02Z)
[core@cosa-devsh ~]$ ostree refs | wc -l
53

I was running a locally built bootc from git main:

$ bootc --version
bootc 1.3.0

Note that I was able to workaround this by:

for ref in $(ostree refs | grep -v 'ostree/1/1/0'); do sudo ostree refs --delete $ref; done
sudo ostree prune --refs-only

But then fail at:

[core@cosa-devsh ~]$ sudo bootc install to-existing-root --source-imgref docker://quay.io/fedora/fedora-coreos:rawhide
ERROR Installing to filesystem: Ensuring selinux install_t type: Failed to enter install_t (running as unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023) - use BOOTC_SETENFORCE0_FALLBACK=1 to override

So I then try with that recommendation:

[core@cosa-devsh ~]$ sudo BOOTC_SETENFORCE0_FALLBACK=1 RUST_LOG=debug bootc install to-existing-root --source-imgref docker://quay.io/fedora/fedora-coreos:rawhide
DEBUG argv0="bootc"
DEBUG exec: "ostree" "--repo=/ostree/repo" "rev-parse" "--single"
DEBUG Target image reference: ostree-unverified-registry:quay.io/fedora/fedora-coreos:rawhide
DEBUG Already mounted from host: /dev
DEBUG Already mounted from host: /var/lib/containers
DEBUG Already mounted from host: /var/tmp
DEBUG Setting up sys mounts
DEBUG Target has SELinux, host=true
DEBUG Setting up sys mounts
DEBUG Current security context is unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
DEBUG Lacking install_t capabilities; copying self to temporary file for re-exec
DEBUG Created "/tmp/.tmp2aZ2KM"
DEBUG exec: _bootc_selinuxfs_mounted="/tmp/.tmp2aZ2KM" "/tmp/.tmp2aZ2KM" "install" "to-existing-root" "--source-imgref" "docker://quay.io/fedora/fedora-coreos:rawhide"
DEBUG argv0=".tmp2aZ2KM"
DEBUG exec: "ostree" "--repo=/ostree/repo" "rev-parse" "--single"
DEBUG Target image reference: ostree-unverified-registry:quay.io/fedora/fedora-coreos:rawhide
DEBUG Already mounted from host: /dev
DEBUG Already mounted from host: /var/lib/containers
DEBUG Already mounted from host: /var/tmp
DEBUG Setting up sys mounts
DEBUG Target has SELinux, host=true
DEBUG Setting up sys mounts
DEBUG Current security context is unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
DEBUG Removing temporary file
 WARN Failed to enter install_t; temporarily setting permissive mode
DEBUG Set SELinux mode: permissive
DEBUG SELinux state: Enabled(Some(SetEnforceGuard(Some(()))))
Installing image: docker://quay.io/fedora/fedora-coreos:rawhide
DEBUG No install configuration found
DEBUG Mounting host / to /target
DEBUG Set SELinux mode: enforcing
ERROR Installing to filesystem: Read-only file system (os error 30)

I think what I have here is maybe a fundamental misunderstanding of how to-existing-root is supposed to work.

[cgwalters]

I was poking around with bootc trying to do something akin to a "factory reset".

That's in #404

I think we basically don't really support to-existing-root outside of a container at all.

But yes, the goal is definitely that bootc install is the entrypoint to factory reset; there's some work to make that happen.

[dustymabe]

I think we basically don't really support to-existing-root outside of a container at all.

OK. Switched to run from a container (but noting here that it's using rawhide which only has bootc-1.2.0-1.fc43.x86_64):

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
           --pid=host --security-opt label=type:unconfined_t                                      \
           quay.io/fedora/fedora-coreos:rawhide                                                   \
           bootc install to-existing-root
Trying to pull quay.io/fedora/fedora-coreos:rawhide...
Getting image source signatures
Copying blob 103be7f8a1ef done   | 
Copying blob 28a0e3eef0da done   | 
Copying blob 08fd6087b477 done   | 
Copying blob 484eddb82ed5 done   | 
Copying blob 4cf26efb3fdf done   | 
Copying blob 27607552bf2d done   | 
Copying blob 9dad063a624b done   | 
Copying config dd9e5733e0 done   | 
Writing manifest to image destination
Installing image: docker://quay.io/fedora/fedora-coreos:rawhide
Digest: sha256:059c9c98f899a4ecbf872f711b49da0285f6716b59fd897e3b081e9c25cd2c95
----------------------------
WARNING: This operation will OVERWRITE THE BOOTED HOST ROOT FILESYSTEM and is NOT REVERSIBLE.
Waiting 20s to continue; interrupt (Control-C) to cancel.
----------------------------
ERROR Installing to filesystem: Removing boot directory content: removing bootupd-state.json: Read-only file system (os error 30)

[cgwalters]

Yeah we are not testing this at all yet; it's a bit ironic but the to-existing-root logic was previously designed only for non-ostree systems and we have only partially implemented support for this type of "factory reset". Omer was previously working on it in e.g. #617 and has landed some other PRs, but more work remains.

[dustymabe]

Yeah we are not testing this at all yet; it's a bit ironic but the to-existing-root logic was previously designed only for non-ostree systems and we have only partially implemented support for this type of "factory reset". Omer was previously working on it in e.g. #617 and has landed some other PRs, but more work remains.

Sounds fair. I'm happy to have this issue closed in favor of other tracker issues already documenting the work.