Add suport for QemuUserEmulation

[jneuhauser]

This allows running containers and binaries for other archs,
like armhf, aarch64 and others without using qemu explicit.

For example run a armhf docker container:
docker run -i -t --rm arm32v7/debian:stable /bin/bash

The full list of supported host emulators is:

$ ls -1 /proc/sys/fs/binfmt_misc | grep qemu
qemu-aarch64
qemu-alpha
qemu-arm
qemu-armeb
qemu-cris
qemu-hppa
qemu-m68k
qemu-microblaze
qemu-mips
qemu-mips64
qemu-mips64el
qemu-mipsel
qemu-ppc
qemu-ppc64
qemu-ppc64abi32
qemu-ppc64le
qemu-riscv32
qemu-riscv64
qemu-s390x
qemu-sh4
qemu-sh4eb
qemu-sparc
qemu-sparc32plus
qemu-sparc64
qemu-xtensa
qemu-xtensaeb

Signed-off-by: Johann Neuhauser [email protected]

[jneuhauser]

Added check for fixed binary in binfmt_misc

[umarcor]

For completeness, dbhi/qus is an alternative solution that works on either GNU/Linux or Windows (Docker for Windows) hosts. Precisely, the feature provided by this PR is equivalent to test r in https://github.com/dbhi/qus/blob/master/docs/tests.md. The advantage of dbhi/qus is that multiple target platforms are supported. Therefore, it might be useful for user that need to run containers for other architectures (e.g. arm64v8/*).

[jneuhauser]

The advantage of dbhi/qus is that multiple target platforms are supported. Therefore, it might be useful for user that need to run containers for other architectures (e.g. arm64v8/*).

Why do you think we can not run a arm64 container with this PR?
I´m only checking for qemu-arm... But this means not that the other emulators are working too.
The full list of emulators is:

$ ls -1 /proc/sys/fs/binfmt_misc | grep qemu
qemu-aarch64
qemu-alpha
qemu-arm
qemu-armeb
qemu-cris
qemu-hppa
qemu-m68k
qemu-microblaze
qemu-mips
qemu-mips64
qemu-mips64el
qemu-mipsel
qemu-ppc
qemu-ppc64
qemu-ppc64abi32
qemu-ppc64le
qemu-riscv32
qemu-riscv64
qemu-s390x
qemu-sh4
qemu-sh4eb
qemu-sparc
qemu-sparc32plus
qemu-sparc64
qemu-xtensa
qemu-xtensaeb

[umarcor]

Why do you think we can not run a arm64 container with this PR?
I´m only checking for qemu-arm... But this means not that the other emulators are working too.

My bad. Since you check(ed) a single target platform, I thought you are/were not interested on others. In this context, advantages of dbhi/qus are;

• Being able to register a subset of target archs only, instead of registering all of them at once.
• Being able to register versions of QEMU which are different from the one in the package manager.
• Not requiring QEMU or any other tool to be installed on the host. Actually, it works already.

Overall, I think this PR/feature is ok. The point of referencing dbhi/qus is for users to be aware of other alternatives when this PR falls short.

[zhangyoufu]

I have a repo demonstrate how to build alpine packages for {amd64, i386, arm64v8, arm32v6, arm32v7, ppc64le, s390x} using multiarch/qemu-user-static from Docker Hub.

During my test, I found that the qemu-user package from Ubuntu 18.04 is too old (or have some bug), and cannot build s390x packages correctly. While the qemu-user from multiarch/qemu-user-static works correctly.

IMHO, two years between Ubuntu LTS releases is too long for something like qemu-user. It is not that fundamental for CI environment either (qemu-user is super SLOW). I would prefer not including qemu-user into base image.

[umarcor]

@zhangyoufu, you will find that multiarch/qemu-use-static is, actually, a sibling project of dbhi/qus. Precisely, the idea to support in-memory loading and to support multiple host architectures was borrowed from qus; see dbhi/qus#2 and multiarch/qemu-user-static#77.

It is not that fundamental for CI environment either (qemu-user is super SLOW).

I beg to disagree. Using DBM is the only solution to currently build non-amd64 images in GitHub Actions (or other amd64-only CI services). I do use this to generate multiarch/manifest images from GitHub Actions and/or Travis. See, for example, dbhi/docker.

However, I agree that it is not a requirement to have qemu-user installed in the base image.