# Unexpected state: /run/ostree-booted found, but no /boot/loader directory

**URL:** <https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489>\
**Category:** General\
**Created:** [January 11, 2026, 10:59am UTC](https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489 "2026-01-11T10:59:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![adam](https://avatars.discourse-cdn.com/v4/letter/a/4af34b/32.png) [@adam](https://universal-blue.discourse.group/u/adam)\
**Post date:** [January 11, 2026, 10:59am UTC](https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489/1 "2026-01-11T10:59:56Z")

</div>

Unexpected state: /run/ostree-booted found, but no /boot/loader directory

Hi all,

I realise this isnt ublue related but I know this community does a lot with bootc so I am hoping someone can point out the issue.

I am creating a derived bootc image using RHEL10 in my homelab. The container itself builds without error and the QCOW2 created using bootc-image-builder also completes without error however the /boot/loader directory is empty. I identified the issue when running `sudo bootc status’` at which point I get the error `Unexpected state: /run/ostree-booted found, but no /boot/loader directory`.

The only difference I see from my deployment and online examples is that I am running bootc-image-builder on Fedora Silverblue. I have installed the `osbuild-selinux` the bootc-image-builder prerequisites .

The containerfile looks as follows;

```auto
FROM registry.example.com.au/rhel10/rhel-bootc:latest

ARG TIMEZONE='Australia/Sydney'
# policycoreutils-python-utils is required to SELinux labelling
ARG INSTALL_PACKAGES='restic tmux policycoreutils-python-utils cloud-init firewalld tuned bash-completion just'
ARG REMOVE_PACKAGES='subscription-manager'

COPY ./bin/install /usr/local/bin/
COPY ./system-files/ /tmp/system-files/

RUN <<EOF
	set -xeuo pipefail
	
	#################################################
	# Configure Local Yum Repositories
	#################################################
	install -D --group=root --owner=root --mode=0644 /tmp/system-files/yum.repos.d/*.repo --target-directory=/etc/yum.repos.d/
	dnf remove --assumeyes ${REMOVE_PACKAGES}
	dnf install --assumeyes ${INSTALL_PACKAGES}
	

	#################################################
	# Configure Private Registry and Pull Secret
	#################################################
	install -D --group=root --owner=root --mode=0644 /tmp/system-files/podman/registry.example.com.au.conf /etc/containers/registries.conf.d/
	# Note: The pull secret is a pre-autheticated token for reguser to registry.example.com.au
	install -D --group=root --owner=root --mode=0600 /tmp/system-files/podman/auth.json /usr/lib/ostree/

	#################################################
	# Configure Transient / and /etc Partitions
	#################################################
	sed -Ezi '/(\n|^)\[root\]\ntransient = true/!s/$/[root]\ntransient = true\n/' /usr/lib/ostree/prepare-root.conf
	sed -Ezi '/(\n|^)\[etc\]\ntransient = true/!s/$/[etc]\ntransient = true\n/' /usr/lib/ostree/prepare-root.conf
	# Configure the initramfs to apply transient / and /etc
	set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kver

	#################################################
	# BootC Workarounds and Fixes
	#################################################
	# rpm-ostree-fix-shadow is a unit created in response to a bug in rpm-ostree where the /etc/shadow, /etc/shadow-,
	# /etc/gshadow and /etc/gshadow files in have the world-readable bit set as per CVE-2024-2905. Reviewing the
	# files idenitifed that the default state is to have permissions zeroed out which is correct. The unit was 
	# failing at boot time. The presence of the follow file is a condition that prevents the service running, i.e;
	# ConditionPathExists=!/etc/.rpm-ostree-shadow-mode-fixed2.stamp
	install -D --group=root --owner=root --mode=0644 /dev/null /etc/.rpm-ostree-shadow-mode-fixed2.stamp

	# Service published bootc facts to Red Hat Subscription Manager, we are not using Red Hat Subscription Manager
	# and therefore disabling the service
	systemctl disable bootc-publish-rhsm-facts.service

	#########################################
	# Post Build Clean Up Tasks
	########################################
	# Remove uneeded build binaries
	rm -rf /tmp/system-files /usr/local/bin/install
	# Clean dnf cache
	dnf clean all
	# Remove caches and build logs
	rm -rf /var/{cache,log} /var/lib/{dnf,rhsm}
	# Commit ostree changes
	ostree container commit
	# Run a linter over the container file
	bootc container lint	
EOF

```

I have tried with both transient root and etc and without (so I am not rebuilding initramfs.

I am not using a config.toml file, or cloud-init to modify the partition layout.

Has anyone come across this issue?

Thanks,

Adam

---

<div class="post-metadata">

**Author:** ![adam](https://avatars.discourse-cdn.com/v4/letter/a/4af34b/32.png) [@adam](https://universal-blue.discourse.group/u/adam)\
**Post date:** [January 13, 2026, 10:42am UTC](https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489/2 "2026-01-13T10:42:19Z")

</div>

The workaround I have identified is to mount boot again

```auto
sudo mount /dev/disk/by-label/boot /boot

```

This then resolves the issue but my concern is this may be symptomatic of another larger issue.

A simpler containerfile to replicate the problem is;

This occurs with RHEL, CentOS and Fedora bootc images.

```auto
FROM quay.io/centos-bootc/centos-bootc:stream9

RUN useradd adamRUN echo “adam:password” | chpasswd

RUN echo -e ‘[etc]\ntransient=true’ >> /usr/lib/ostree/prepare-root.conf && set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kver

```

The qcow is being generated as follows. I have tried this on my Fedora Silverblue 43 system and a RHEL 10 virtual machine

```auto
 podman run \
    --rm \
    -it \
    --privileged \
    --pull=newer \
    --security-opt label=type:unconfined_t \
    -v ./output:/output \
    -v /var/lib/containers/storage:/var/lib/containers/storage \
    quay.io/centos-bootc/bootc-image-builder:latest \
    --type qcow2 \
    --use-librepo=True \
  https://my-private-repo/bootc-test

```

I am hoping I am just making a silly mistake otherwise I assume everyone playing with bootc would be experiencing this.

---

<div class="post-metadata">

**Author:** ![Danathar](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/danathar/32/7758_2.png) [@Danathar](https://universal-blue.discourse.group/u/Danathar)\
**Post date:** [January 17, 2026, 8:42pm UTC](https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489/3 "2026-01-17T20:42:26Z")

</div>

Are you sure you need to run dracut? I’m not an expert, but I did some digging; it seems like that is taken care of by other processes (bootc-image-builder).

I actually find what you are doing interesting. It’s just slightly beyond my current competency level. I’ve been wanting to try doing a customized RHEL10 image for ARM. Why transient /etc?

You might want to post this question over in the Fedora/RHEL forums. You might get better expertise than me 😉

---

<div class="post-metadata">

**Author:** ![adam](https://avatars.discourse-cdn.com/v4/letter/a/4af34b/32.png) [@adam](https://universal-blue.discourse.group/u/adam)\
**Post date:** [January 18, 2026, 2:14am UTC](https://universal-blue.discourse.group/t/unexpected-state-run-ostree-booted-found-but-no-boot-loader-directory/11489/4 "2026-01-18T02:14:17Z")

</div>

Thanks for replying @Danathar ,

If you dont run dracut the transient nature of the mounts does not become active. The transient root and /etc is really just an insurance policy against local drift. My home network has a lot of production services for my family and is reasonable extensive. I came to the realization that rebuilding my environment is time intensive and complex. In order for a quick recovery and just generally applying polish to all my systems I need an approach where I can be assured as mush as possible can be rebuilt from code and the state of the environment is known.

Bootc has actually been tons of fun, forced me learn a lot more about systemd; highly recommend.