17.10.2023 06:22, Daniel Richard G.:
Package: qemu-user-static Version: 1:8.1.1+ds-2 Severity: wishlistI am using qemu-user-static in conjunction with binfmt-support and Docker/Podman to allow running foreign-arch containers on amd64. This approach works quite well, once you get past the speed hit. The main step involved is making the appropriate static interpreter executable available at the same path location within the container as on the host system (because the kernel's binfmt support does not differentiate between the two environments). For example, the aarch64 interpreter lives on the host at /usr/libexec/qemu-binfmt/aarch64-binfmt-P so when I create an arm64 container, I need to copy in the interpreter executable to that same location, so that the kernel can find it whenever it is asked to run an arm64 binary inside the container.
This is incorrect. When qemu binfmt is installed, it is registered in the kernel in a way which does *not* require the binary to be present in containers, - see the "O" flag at https://docs.kernel.org/admin-guide/binfmt-misc.html . This flag is enabled for more than 2 debian releases already, i.e. for quite some time. There's no need to make the interpreter binary to be available inside containers. If it doesn't work for you, please find out what's wrong - it works for a lot of systems, it's used this way on numerous cross-architecture build an testing hosts 1000s times a day, and this is a primary mode of operation everywhere. This is the reason why I made it a symlink initially and why it is named in this funny way, - because no one should care how it is named and where it is to begin with. Also, this binfmt-P thing is temporary, - I wanted to drop it for bookworm but kept it in because some environments still use older (pre-oldstable) host kernel which lacks proper support for another binfmt-misc flag, "P". I'll drop it for trixie for sure. /mjt
