bootloader: Run bootupctl via chroot instead of bwrap#2210
Conversation
bwrap unconditionally clones a new user namespace during sandbox setup, and clone(CLONE_NEWUSER) returns EINVAL under qemu-user-mode emulation. That breaks cross-arch installs where bwrap is used to run bootupctl from the target image. Since bootc install already runs as root, the user namespace isn't needed: an unshared mount namespace + chroot is enough to give bootupctl a view of the target image while keeping bind mounts from leaking back to the host. Introduce ChrootCmd in bootc-internal-utils as a sibling to BwrapCmd and wire it into install_via_bootupd and the --filesystem capability probe. The child runs with a cleared environment so the install is not influenced by the buildroot's locale, TMPDIR, etc.; variables it needs are passed explicitly via ChrootCmd::setenv. Fixes bootc-dev#2111 Assisted-by: Claude Code (Opus 4.7 1M) Signed-off-by: cdellacqua <carlo.dellacqua97@gmail.com>
The only consumer of BwrapCmd (install_via_bootupd in bootloader.rs) switched to ChrootCmd in the previous commit, so BwrapCmd and the bubblewrap-based execution path have no remaining callers in the workspace. Assisted-by: Claude Code (Opus 4.7 1M) Signed-off-by: cdellacqua <carlo.dellacqua97@gmail.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request replaces the bubblewrap (bwrap) based containerization with a custom ChrootCmd implementation using mount namespaces. This change resolves issues where bubblewrap would fail under qemu-user due to user namespace requirements. The BwrapCmd utility has been removed, and ChrootCmd now handles the setup of API filesystems and bind mounts within a new mount namespace via a pre_exec hook. Feedback suggests that the safe version of rustix::thread::unshare could be used instead of the unsafe variant to reduce the amount of unsafe code in the implementation.
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
Thanks! Looks sane to me.
| } | ||
|
|
||
| #[cfg(test)] | ||
| mod tests { |
There was a problem hiding this comment.
OK as is, but they don't test much. What I think we could do though is cover this in our container-based testing.
2 participants
bootloader: Run bootupctl via chroot instead of bwrap
bwrap unconditionally clones a new user namespace during sandbox setup, and clone(CLONE_NEWUSER) returns EINVAL under qemu-user-mode emulation. That breaks cross-arch installs where bwrap is used to run bootupctl from the target image.
Since bootc install already runs as root, the user namespace isn't needed: an unshared mount namespace + chroot is enough to give bootupctl a view of the target image while keeping bind mounts from leaking back to the host.
Introduce ChrootCmd in bootc-internal-utils as a replacement for BwrapCmd [1] and wire it into install_via_bootupd and the --filesystem capability probe.
Fixes #2111
Assisted-by: Claude Code (Opus 4.7 1M)
[1] BwrapCmd became dead code, removed in the second commit on this branch. If the wrapper is still needed for other unmerged (or future) features, I can drop that commit and just keep the ChrootCmd + bootloader refactor