bwrap: Fall back to direct invocation on namespace creation failure#2209
bwrap: Fall back to direct invocation on namespace creation failure#2209cdellacqua wants to merge 1 commit into
Conversation
cdellacqua
force-pushed
the
bwrap-fallback
branch
from
b617233 to
a066256
Compare
![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 implements a fallback mechanism for bwrap commands to handle cases where namespace creation fails, such as under QEMU user-mode emulation. It introduces BwrapCmdWithFallback, which monitors stderr for a specific error marker and transparently executes a direct fallback command if necessary. Review feedback suggests optimizing the error detection logic by performing a byte-level search on stderr to avoid unnecessary string allocations and improving code clarity by binding the stderr handle to a local variable.
Under QEMU user-mode emulation the host kernel can return EINVAL from clone(CLONE_NEWUSER) on bwrap's sandbox setup, and bwrap aborts before spawning the child. This trips bootc install on cross-architecture builds (see issue bootc-dev#2111), where bwrap is used to make bootupctl run from the target image, not the buildroot. Workaround until the upstream qemu-user/kernel/bwrap interaction is resolved: detect the "Creating new namespace failed" prefix on bwrap's stderr and re-run the target program directly. A `eprintln!` fires on every fallback so the behaviour is visible in logs. Both bootupctl sites in bootloader opt in: the `--filesystem` capability probe and `backend install`. Assisted-by: Claude Code (Opus 4.7 1M) Signed-off-by: cdellacqua <carlo.dellacqua97@gmail.com>
cdellacqua
force-pushed
the
bwrap-fallback
branch
from
a066256 to
fdf5630
Compare
|
I get the pain here, but it's not viable in the general case. What we can do here is special case just when However, another fallback path that would likely be quite viable here is to just do a "simple container" where we just set up some mount points directly and |
|
Thanks! Implemented the chroot approach in #2210 and confirmed it fixes the original qemu-user case on real hardware (building a bootc image for an aarch64 Raspberry Pi 4 from an amd64 laptop). Closing as superseded. |
2 participants
Under QEMU user-mode emulation the host kernel can return EINVAL from clone(CLONE_NEWUSER) on bwrap's sandbox setup, and bwrap aborts before spawning the child. This trips bootc install on cross-architecture builds (see issue #2111), where bwrap is used to make bootupctl run from the target image, not the buildroot.
Workaround until the upstream qemu-user/kernel/bwrap interaction is resolved: detect the "Creating new namespace failed" prefix on bwrap's stderr and re-run the target program directly. A
eprintln!fires on every fallback so the behaviour is visible in logs. Both bootupctl sites in bootloader opt in: the--filesystemcapability probe andbackend install.Assisted-by: Claude Code (Opus 4.7 1M)