Summary: | sys-apps/portage regression causes qemu-user failure launch process (qemu_thread_create: Invalid argument) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ed Wildgoose <gentoo> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ed Wildgoose
2024-07-25 10:36:00 UTC
I think this might be a regression in a bizarre way. Before, we gave up early for musl, and now we try harder. So it ends up exposing the existing incompatibility with qemu-user+sandboxes on musl targets too. Hmm, curious. So this means that the sandbox wasn't previously functional for qemu-user?? I concede I hadn't actually noticed that! I do see some warnings, but thought I had seem some build failures which appeared to demonstrate that it was functioning? (I had some issues building custom kernel module ebuilds, which would get caught by sandbox alike violations, although often when I had made a mistake and they were trying to tramble stuff) Please note that sandbox and network/ipc/pid-sandbox are very different features. sandbox uses an LD_PRELOAD hack and works just fine with qemu-user. The other sandboxes require Linux namespaces, which probably do not work with qemu-user’s syscall emulation. |