Repository navigation
auto-updates fail with opendir(boot): Operation not permitted when /boot is a systemd automount that has idled out #2402
Description
I've read the report and indeed seems to be true.
If you don't want to read an LLM report, please stop here. Feel free to close the report.
Summary
bootc-fetch-apply-updates.service does not declare RequiresMountsFor=/boot. On systems where /boot is a systemd-gpt-auto-generator automount with TimeoutIdleSec=120, /boot unmounts ~2 minutes after boot and the update timer then fires against an unmounted /boot, failing with:
error: Initializing storage: opendir(boot): Operation not permitted
The same failure hits bootc status and bootc upgrade run manually.
ostree hardened its own units against this exact hazard in ostreedev/ostree#2544; bootc's updater unit never got the equivalent.
Environment
- bootc
1.16.7-1.fc44 - ostree
2026.3-1.fc44 - systemd
259.8-1.fc44 - Base image
quay.io/fedora/fedora-bootc:44 - BIOS/GRUB boot:
sda1BIOS boot,sda2vfat ESP (unused),sda3xfs root /is a composefs overlay; no/etc/fstab
Symptom
Aug 21 18:40:55 systemd[1]: Starting bootc-fetch-apply-updates.service - Apply bootc updates...
Aug 21 18:40:56 bootc[2194]: error: Initializing storage: opendir(boot): Operation not permitted
Aug 21 18:40:56 systemd[1]: bootc-fetch-apply-updates.service: Failed with result 'exit-code'.
Repeats on every timer firing. opendir(...) is libostree's glnx_throw_errno_prefix style, i.e. EPERM from openat(sysroot_fd, "boot").
Reproducer
Deterministic on an affected system:
$ sudo umount /boot # simulate the automount idling out
$ sudo bootc status
error: Status: opendir(boot): Operation not permittedNote bootc's access does not trigger the automount — /boot remains unmounted afterwards. (I suspect this is because bootc re-execs under unshare -m and autofs won't service the request from that private mount namespace, but I haven't confirmed that.)
Touch /boot by any other means and bootc works again:
$ ls /boot >/dev/null && sudo bootc status # succeedsRoot cause
Two generators both claim /boot:
ostree-system-generator->/run/systemd/generator/boot.mount(What=/sysroot/boot,Options=bind) — the real mountsystemd-gpt-auto-generator->/run/systemd/generator.late/boot.automount(Where=/boot,TimeoutIdleSec=120, described as "EFI System Partition Automount") — targeting the otherwise-unused ESP
When the autofs idle timer fires it tears down ostree's /boot bind mount. The ostree units survive this because they declare the dependency:
$ systemctl show boot.mount -p RequiredBy
RequiredBy=ostree-finalize-staged.service ostree-boot-complete.service \
ostree-finalize-staged-hold.service rpm-ostree-fix-shadow-mode.service local-fs.target
$ systemctl show bootc-fetch-apply-updates.service -p RequiresMountsFor
RequiresMountsFor=Why this is newly visible
This system ran fine for two weeks on ostree 2026.2 and broke on upgrade to 2026.3, with bootc, systemd and the kernel at identical versions across both deployments. The behaviour change is ostreedev/ostree@62109dca ("prepare-root: create /run/systemd/volatile-root for composefs"), whose commit message states:
With composefs enabled both are overlayfs mounts with an anonymous
st_dev… As a result systemd-gpt-auto-generator silently skips all partition discovery: the ESP is never automounted on /boot
Before 2026.3, gpt-auto could not resolve the composefs root's block device and skipped partition discovery entirely, so boot.automount was never generated. Journal evidence — Set up automount boot.automount appears only in deployments running 2026.3:
boot -3: ostree 2026.2 automount=0
boot -2: ostree 2026.3 automount=1 <- /boot unmounted 2m41s after boot
boot -1: ostree 2026.2 automount=0
boot 0: ostree 2026.3 automount=1
So ostree 2026.3 makes gpt-auto work as intended, which in turn exposes the missing dependency in bootc. I'd expect this to affect any composefs-based bootc system with a discoverable ESP as 2026.3 rolls out.
Proposed fix
Mirror what ostree does — add to bootc-fetch-apply-updates.service:
[Unit]
RequiresMountsFor=/bootVerified as effective here via a drop-in: systemd then pulls in boot.mount and orders the service after it.
Two secondary suggestions:
opendir(boot): Operation not permittedis opaque for what is really "/boot is not mounted". A dedicated check with a clearer message would save a lot of digging.- Any other bootc command touching
/boot(bootc status,bootc upgrade,bootc switch) has the same exposure when run from an idle shell, and can't be fixed by unit dependencies. Triggering the automount explicitly, or reporting a clear error, would help.
References
- finalize-staged: Ensure /boot and /sysroot automounts don't expire ostreedev/ostree#2544 — ostree's fix for the same hazard on its own units
- ostreedev/ostree@62109dca — the change that makes gpt-auto discover partitions on composefs roots
- systemd-gpt-auto-generator ignores existing mount units systemd/systemd#13099 — gpt-auto generates
boot.automountdespite an existingboot.mount - systemd-gpt-auto-generator can't find ESP because it can't detect blockdev of / if composefs is used systemd/systemd#35017 — gpt-auto with overlay roots
Activity
ldobbelsteen commentedon Aug 23, 2026
Just chipping in to say I'm running into the exact same issue under the same environment.
cgwalters commentedon Aug 24, 2026
This is at least the second regression from this change. The blast radius there is much larger than I realized; apologies.
Hmm yes, this sounds like a pretty bad bug.
Actually, one thing intermixed with this is that really our base images should have
/efias a directory, which I think the systemd generator would prefer, and that would help fix this I believe.cgwalters commentedon Aug 25, 2026
@stavros-k @ldobbelsteen can you guys post the output of
lsblk? I especially want to know in this setup if you actually have a separate/bootpartition or not, and whether it matches the XBOOTLDR partuuid.ldobbelsteen commentedon Aug 25, 2026
Sure, see my output below. Note that I'm running Fedora Bootc (version
44.20260824.0to be exact) with minimal changes layered on top that I don't think should affect this (except that I explicitly disabled SELinux). My/bootseems to be on the same partition.Johan-Liebert1 commentedon Aug 26, 2026
This seems to be the same issue I faced while working on #2323
unshare: Propagate /boot automount to mount ns
Johan-Liebert1 commentedon Aug 27, 2026
Reopening because #2411 does not solve the competing boot mount issue
ignitedPotato commentedon Sep 13, 2026
I ran into this issue as well.
Unfortunately after applying the fix suggested by @stavros-k now
ostree-finalize-staged.servicefails with:clement-dufour commentedon Sep 13, 2026
I have been observing the same behavior for a few weeks now. In the meantime, I update manually.
I would be happy to help with logs or testing if needed. 😊
Install the smoke VM from an OCI layout and keep /boot mounted
cgwalters commentedon Sep 14, 2026
cc #2440 which is in this space
tmt: Add test switching to a zstd:chunked image
tmt: Add test switching to a zstd:chunked image
generator: Mask gpt-auto's boot.automount over our /boot bind mount