Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

auto-updates fail with `opendir(boot): Operation not permitted` when /boot is a systemd automount that has idled out

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#2,402 9 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Une pull request liée a déjà été fusionnée.

  • #2411 par @Johan-Liebert1 — fusionnée

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
70/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
linux, rust
Domaine
devops, operating-systems

Piste de recherche

Commencez par l’unité bootc-fetch-apply-updates.service et examinez la façon dont ses dépendances systemd sont définies. Vérifiez que le service déclare la dépendance requise envers /boot, puis utilisez systemctl pour confirmer que boot.mount est tiré et ordonnancé avant le service ; le cas de reproduction consiste à avoir /boot non monté, puis à exécuter bootc status ou le service de mise à jour.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

triaged

⚠️ DISCLAIMER. Report is generated by Claude Code while it was troubleshooting one of my bench systems.
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: sda1 BIOS boot, sda2 vfat ESP (unused), sda3 xfs 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 permitted

Note 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   # succeeds

Root cause

Two generators both claim /boot:

  • ostree-system-generator -> /run/systemd/generator/boot.mount (What=/sysroot/boot, Options=bind) — the real mount
  • systemd-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=/boot

Verified as effective here via a drop-in: systemd then pulls in boot.mount and orders the service after it.

Two secondary suggestions:

  1. opendir(boot): Operation not permitted is opaque for what is really "/boot is not mounted". A dedicated check with a clearer message would save a lot of digging.
  2. 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

  • 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/systemd#13099 — gpt-auto generates boot.automount despite an existing boot.mount
  • systemd/systemd#35017 — gpt-auto with overlay roots
Langage dominant
Rust
Étoiles
2.3k
Forks
230
Merge moyen
3 j 31 min
PR mergées (30 j)
48

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de bootc-dev/bootc

Toutes les issues de bootc-dev/bootc

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.