bootc install to-existing-root fails when the target's parent mount has MS_SHARED propagation
Personne n'a encore pris cette issue.
- Langage dominant
- Rust
- Étoiles
- 2.3k
- Forks
- 230
- Merge moyen
- 3 j 3 h
- PR mergées (30 j)
- 36
Description
Summary
bootc install to-existing-root fails reproducibly with:
error: Installing to filesystem: Creating imgstorage: Initializing images: No such file or directory (os error 2)
on any host where / (or /run) has MS_SHARED mount propagation, which is systemd's default on most modern Linux distributions. mount --make-private / /run before running the install works around it completely.
Environment
- bootc 1.16.10 and 1.16.12 (both affected)
- Fedora 44 Cloud Base, reproduced identically on x86_64 (KVM) and aarch64 (TCG)
Repro
- Fresh Fedora 44 install.
dnf install -y bootc skopeotouch /etc/ostree/prepare-root.conf(workaround for #1410, unrelated to this issue)bootc install to-existing-root --bootloader none --source-imgref docker://<any image> --acknowledge-destructive- Fails with the error above, before ever reaching the image pull.
Root cause
CStorage::create() (crates/lib/src/podstorage.rs) spawns podman --root /run/bootc/storage --runroot /proc/self/fd/N images to initialize image storage. The fd is handed to the child via bind_storage_roots()'s pre_exec hook: fchdir(storage_root), unshare(CLONE_NEWNS), mount_bind(".", STORAGE_ALIAS_DIR).
The comment above that code already names the exact failure mode:
EINVAL A bind operation (MS_BIND) was requested where source referred to a mount namespace magic link, but the propagation type of the parent mount of target was MS_SHARED...
Checked /proc/self/mountinfo on a failing host:
71 1 0:34 /root / rw,relatime shared:1 - btrfs ...
49 71 0:28 / /run rw,nosuid,nodev shared:14 - tmpfs ...
Both shared. Running mount --make-private / and mount --make-private /run before bootc install makes the failure disappear. Confirmed with repeated clean installs afterward, on both bootc versions and both architectures.
Since shared is systemd's standard default, this doesn't look like an edge case specific to constrained or virtualized environments. It looks like it would affect most freshly-booted systems attempting to-existing-root.
Suggested fix
bind_storage_roots() (or CStorage::create() before calling it) could make the target's parent mount private itself before the bind-mount, rather than relying on the caller's environment already being private. Happy to help test a patch.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez dans crates/lib/src/podstorage.rs en lisant CStorage::create() et bind_storage_roots(), en particulier la séquence pre_exec qui utilise fchdir, unshare et mount_bind. Reproduisez le problème avec bootc install to-existing-root sur un hôte où / ou /run est partagé, puis comparez avec des montages privés. Le travail est terminé lorsque l’installation n’échoue plus pendant l’initialisation de imgstorage sans exiger des appelants qu’ils modifient la propagation des montages.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- linux, rust
- Domaine
- operating-systems
- Type d'issue
- Bug
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Activité
- Active
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 72/100