dbhi / qus

qemu-user-static (qus) and containers, non-invasive minimal working setups

Dynamic Binary Hardware Injection (DBHI) is a workflow towards decoupled functional hardware-software co-design on SoCs with FPGA, through injection of compiled HDL designs. The design flow is constructed from existing off-the-shelf tools, and it is tested on multiple architectures (ARMv7, ARMv8 and x86-64).

Project structure

Resources, tools and examples are organized in multiple repositories:

• dbhi/dbhi: main repository, contains the documentation, publications and examples. Dependencies are included as submodules:
  • VUnit/vunit: a unit testing framework for VHDL/SystemVerilog.
  • VUnit/cosim: extends VUnit with co-simulation features.
  • beehive-lab/mambo: a low-overhead dynamic binary instrumentation and modification tool for ARM.
  • dbhi/gRPC: Go sources of the DBHI gRPC server, and common sources to embed Go gRPC clients in C applications.
• Other helper repositories:
  • dbhi/containers: sources and CI configuration to containerize open and free development tools that allow to evaluate DBHI. Images are periodically pushed to docker.io/aptman/dbhi.
  • dbhi/qus: qemu-user-static (qus) and docker, non-invasive minimal working and non-working setups. Used by dbhi/containers.

Environment setup

The list of required tools to run the examples is the following:

• GHDL
• VUnit
• Either of:
  • MAMBO (only avilable for ARM platforms)
  • DynamoRIO
• (Optional) GtkWave
• (Optional, to use gRPC) Go(lang)

---

Ready-to-use container images (for docker/podman) are available at docker.io/aptman/dbhi. These images include all the required dependencies to evaluate the design flow with lightweight, open and free tools.

Images provided by docker-library/official-images are used to build manifests for amd64, arm64v8 and arm32v7 platforms. Currently, all the images are based on Ubuntu 18.04 (bionic). See dbhi/containers for further details.

If docker|podman is available on your target platform, using the provided images is recommended, because the overhead is negligible, it helps reproducibility and it significantly reduces setup time. The following script can be used to test if a platform fulfills the requirements to run the docker daemon:

curl -fsSL https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh | bash -

---

Should you want to install the tools natively on your host, the dockerfiles at dbhi/containers can be used as a reference (i.e., the same steps can be reproduced in a shell script). Nonetheless, please read the following notes carefully:

• Ensure that all the libraries are built with -fPIC when building GHDL.
• VUnit can be installed in a default location (e.g. pip install vunit_hdl), or:
  • It must be cloned recursively, and
  • colorama must be installed (e.g. pip install colorama).
• MAMBO must be recursively cloned.
• To get DynamoRIO, a release tarball can be downloaded or it can be built from sources.

NOTE: If GHDL, VUnit and/or DynamoRIO are installed in custom locations, these can be defined through PATH, PYTHONPATH and/or DYNAMORIO_HOME, respectively.

NOTE: Building DynamoRIO with g++-8 fails on amd64. Using g++-6 or g++-7 is suggested.

qus's Issues

Better documentation on how does it work

Hello,
I'm trying to understand how the mechanism works, but I'm stuck.
My ultimate goal is to use box64 instead of qemu to get more performance on my Raspi 4, so I'd like to understand how does qus register qemu, but I can't understand one thing.

root@host:/# cat /proc/sys/fs/binfmt_misc/qemu-x86_64 
enabled
interpreter /qus/bin/qemu-x86_64-static
flags: F
offset 0
magic 7f454c4602010100000000000000000002003e00
mask fffffffffffefe00fffffffffffffffffeffffff

Where is the binary?

1. It's not in the host:

root@host:/# ls -l /qus
ls: cannot access '/qus': No such file or directory

2. It's not in the final emulated container:

pi@host:~ $ DOCKER_DEFAULT_PLATFORM=amd64 docker run -it --rm ubuntu ls -l /qus
/usr/bin/ls: cannot access '/qus': No such file or directory

docker image ls -a does not show anything related to qus.
I found the binary in docker internal folders:

root@host:/# find -mount -type f -name qemu-x86_64-static
./var/lib/docker/volumes/ff09c47b39161ce62a81f38fd8fc0ff10da5abf09b81dfeb82245d368c433b90/_data/bin/qemu-x86_64-static
./var/lib/docker/volumes/1329b9dcf2cf270f77b42c5a9360625e6babbca52cdba51ddac87d17c3a670c1/_data/bin/qemu-x86_64-static
./var/lib/docker/overlay2/16bd99024d081358190427da12fa97740fc5890b8b600ac24bea3c873da94ab3/diff/qus/bin/qemu-x86_64-static

I tried creating a container and inspecting, but no volumes are used and i couldn't see anything relevant.

So I do not understand: How does docker "apply" the /qus/bin/qemu-x86_64-static in the way that the binfmt_misc system can read from that path, while not apparently appearing anywhere? Because (supposedly) the kernel does not know anything about docker, so it should just try to read it from the host path (?). Or, if it tries to read it from the namespaced path, than the emulator should exist inside the container.

What am I missing?

(how can I make docker use my binary (box64) to transparently run x86_64 container on arm64 like qus does?).

Not able to run x86_64 image on arm32 machine using qus

Hi,

I am attempting to run an x86_64 image on an arm32 machine with dbhi/qus. Following the documentation, I ran the command:

docker run --rm --privileged aptman/qus -s -- -p x86_64
but encountered the error:
sh: /sbin/modprobe: not found

I then attempted to run our x86_64 image, but received the error:
standard_init_linux.go:228: exec user process caused: exec format error

I have tried previously tried multiarch/qemu-user-static as well but it doesn't seems to support arm32 host and was getting similar error.

I would appreciate any assistance in resolving this issue and successfully running the x86_64 image on our arm32 machine using dbhi/qus. And I am open to other suggestions as well in case its not possible with dbhi/qus.

Running arm32/v7 containers on an aarch64-only host

Hello,

Coming here from multiarch/qemu-user-static#77, it looks like qus works for i386, x84_64 but not arm:

gitlab-runner@docker-emacs:~$ uname -a
Linux docker-emacs 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:21:09 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

gitlab-runner@docker-emacs:~$ docker run --rm --privileged aptman/qus -- -r
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -r

gitlab-runner@docker-emacs:~$ docker run --rm --privileged aptman/qus -s -- -p
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p --suffix -static
Setting /qus/bin/qemu-i386-static as binfmt interpreter for i386
Setting /qus/bin/qemu-i386-static as binfmt interpreter for i486
Setting /qus/bin/qemu-alpha-static as binfmt interpreter for alpha
Setting /qus/bin/qemu-armeb-static as binfmt interpreter for armeb
Setting /qus/bin/qemu-sparc-static as binfmt interpreter for sparc
Setting /qus/bin/qemu-sparc32plus-static as binfmt interpreter for sparc32plus
Setting /qus/bin/qemu-sparc64-static as binfmt interpreter for sparc64
Setting /qus/bin/qemu-ppc-static as binfmt interpreter for ppc
Setting /qus/bin/qemu-ppc64-static as binfmt interpreter for ppc64
Setting /qus/bin/qemu-ppc64le-static as binfmt interpreter for ppc64le
Setting /qus/bin/qemu-m68k-static as binfmt interpreter for m68k
Setting /qus/bin/qemu-mips-static as binfmt interpreter for mips
Setting /qus/bin/qemu-mipsel-static as binfmt interpreter for mipsel
Setting /qus/bin/qemu-mipsn32-static as binfmt interpreter for mipsn32
Setting /qus/bin/qemu-mipsn32el-static as binfmt interpreter for mipsn32el
Setting /qus/bin/qemu-mips64-static as binfmt interpreter for mips64
Setting /qus/bin/qemu-mips64el-static as binfmt interpreter for mips64el
Setting /qus/bin/qemu-sh4-static as binfmt interpreter for sh4
Setting /qus/bin/qemu-sh4eb-static as binfmt interpreter for sh4eb
Setting /qus/bin/qemu-s390x-static as binfmt interpreter for s390x
Setting /qus/bin/qemu-aarch64_be-static as binfmt interpreter for aarch64_be
Setting /qus/bin/qemu-hppa-static as binfmt interpreter for hppa
Setting /qus/bin/qemu-riscv32-static as binfmt interpreter for riscv32
Setting /qus/bin/qemu-riscv64-static as binfmt interpreter for riscv64
Setting /qus/bin/qemu-xtensa-static as binfmt interpreter for xtensa
Setting /qus/bin/qemu-xtensaeb-static as binfmt interpreter for xtensaeb
Setting /qus/bin/qemu-microblaze-static as binfmt interpreter for microblaze
Setting /qus/bin/qemu-microblazeel-static as binfmt interpreter for microblazeel
Setting /qus/bin/qemu-or1k-static as binfmt interpreter for or1k
Setting /qus/bin/qemu-x86_64-static as binfmt interpreter for x86_64

gitlab-runner@docker-emacs:~$ docker run --rm -it i386/ubuntu bash -c 'uname -m'
i686

gitlab-runner@docker-emacs:~$ docker run --rm -it amd64/ubuntu bash -c 'uname -m'
x86_64

gitlab-runner@docker-emacs:~$ docker run --rm -it arm32v7/ubuntu bash -c 'uname -m'
standard_init_linux.go:211: exec user process caused "exec format error"
failed to resize tty, using default size

Any idea of what I should do? On https://askubuntu.com/questions/1090351/can-i-run-an-arm32-bit-app-on-an-arm64bit-platform-which-is-running-ubuntu-16-04 they suggest adding armhf as a foreign architecure but it looks random, I prefer to ask here first.

No matching manifest for linux/arm64/v8

Hello,

Could you counsel me what am I doing wrong?

~$ uname -a
Linux ubuntu 5.4.0-1030-raspi Ubuntu aarch64 aarch64 aarch64 GNU/Linux

~$ docker run --rm --privileged aptman/qus -s -- -p x86_64
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p x86_64 --suffix -static
Setting /qus/bin/qemu-x86_64-static as binfmt interpreter for x86_64

~$ docker run --rm -it odoo
docker: no matching manifest for linux/arm64/v8 in the manifest list entries.

Support OpenRC distros

Distros like Alpine Linux (on baremetal or a full VM), binfmt is provided by openrc package.

Is it possible to support such distros to get qus?

Mount permission denied

I am new to Docker, but I tried to create a container on Docker for Windows and it gives this error when I run it:

2022-11-14 19:43:22 mount: permission denied (are you root?)
2022-11-14 19:43:22 cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin

I tried running as administrator, and it gave the same result. I also tried setting it up on a Raspberry Pi 3, and the same thing happened (using root and sudo).

sh: /sbin/modprobe: not found

我是在树莓派上运行，报错：sh: /sbin/modprobe: not found

是不是缺少依赖镜像呢？貌似这个aptman不支持x86-64

Release, publish and document how to use the Action in GitHub Actions workflows

https://github.com/dbhi/qus/tree/main/action

    - uses: dbhi/qus@action-v0

    - uses: dbhi/qus@action-v0
      with:
        targets: >
          arm
          aarch64

When running x86 docker image on an arm64 host, the PS command cannot be used in the container

1.HOST

# uname -m
aarch64

# lscpu
架构：                           aarch64
CPU 运行模式：                   64-bit
字节序：                         Little Endian
CPU:                             8
在线 CPU 列表：                  0-7
每个核的线程数：                 1
每个座的核数：                   1
座：                             8
NUMA 节点：                      1
厂商 ID：                        
型号：                           0
型号名称：                       
步进：                           0x1
CPU 最大 MHz：                   2600.0000
CPU 最小 MHz：                   2600.0000
BogoMIPS：                       200.00
L1d 缓存：                       512 KiB
L1i 缓存：                       512 KiB
L2 缓存：                        4 MiB
L3 缓存：                        256 MiB
NUMA 节点0 CPU：                 0-7
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
标记：fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

2. container

# uname -m
x86_64

# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             8
NUMA node(s):          1
Model:                 0
Model name:            ARMv8 CPU
CPU max MHz:           2600.0000
CPU min MHz:           2600.0000
BogoMIPS:              200.00
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
L3 cache:              32768K
NUMA node0 CPU(s):     0-7
Flags:  fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

3. Execute PS command in container

# ps
/usr/bin/ps: error while loading shared libraries: libsystemd.so.0: ELF load command alignment not page-aligned

# ss
Netid State      Recv-Q Send-Q                                  Local Address:Port                                                   Peer Address:Port                
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported
Cannot open netlink socket: Protocol not supported

License

See: https://choosealicense.com/no-permission

Can I run aarch64 containers on an arm32/v7 host?

Running docker image on Chrome OS on ARM64 host

Trying to run this docker image on this host. Details are as follows:

OS details:
Google Chrome: Version 81.0.4044.94 (Official Build) (32-bit)
Platform: 12871.67.0 (Official Build) stable-channel elm
Channel: stable-channel
Firmware Version: Google_Elm.8438.184.0
ARC enabled: true
ARC: 6357842
Enterprise enrolled: false
Developer mode: false

Docker version:
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:28:15 2019
OS/Arch: linux/arm64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:26:47 2019
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683

Docker image:
https://github.com/pauleve/docker-mtgo.git

Old version of QEMU

It looks like QUS is pointing to a fork of QEMU which hasn't caught up with the main repo in 3 years:

https://github.com/dbhi/qus/blob/f79aa71b04f5b1bfc98769edbf9a7a10659708fe/register.sh#L117C86-L117C150

Restarting containers

How do I restart a stopped container? I tried docker restart <container_name> but the container exits immediately with the following error in the log:

standard_init_linux.go:219: exec user process caused: exec format error

Tried docker restart --platform <platfrom> <container_name> only to be greeted with unknown flag.

Thanks for this project! Greeting from mutliarch project

Hi the project maintainer!
Thank your for developing this great inspirational project!
The implemented features and CI pipeline are amazing!

I am Jun Aruga. I recently became a member of "multiarch" project.
I just want to share you that as I was inspired from this project, I sent PR to "multiarch/qemu-user-static.
multiarch/qemu-user-static#75

Kind regards,
Jun

Question: qus after `docker system prune`

Hi! As far as I understood I have to call docker run --rm --privileged aptman/qus -s -- -p after I do docker system prune -af. Is that correct? Is there a way to make qus "survive" a system prune or have it restart automatically?

Btw thanks everyone for this extremely useful piece of software!

Execution hangs on arm (while success on real raspberry pi)

Hi,
I am trying to compile bdwgc (for crystal lang on rpi).
But it hangs on make check step. I was trying the same on real raspberry pi (armv7), and it executes successfully.

My steps :

1. Run aptman/qus

docker run --rm --privileged aptman/qus -s -- -p arm

2. Build dockerfile :

FROM --platform=linux/arm/v5 debian

ENV DEBIAN_FRONTEND=noninteractive
ENV TZ=Europe/Kiev
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt update && apt-get install -y \
    automake build-essential git libbsd-dev libedit-dev \
    libevent-dev libgmp-dev libgmpxx4ldbl libpcre3-dev \
    libssl-dev libtool libxml2-dev libyaml-dev \
    lld llvm llvm-dev

RUN git clone -b v8.0.6 https://github.com/ivmai/bdwgc.git && \
    cd bdwgc && \
    git clone https://github.com/ivmai/libatomic_ops.git && \
    autoreconf -vif && \
    ./configure --enable-static --disable-shared && \
    make -j && \
    make check

It hangs forever on make check step (host system x86_64).

ng -o disclaim_weakmap_test tests/disclaim_weakmap_test.o  ./.libs/libgc.a -lpthread -ldl
make[2]: 'libstaticrootslib_test.la' is up to date.
make[2]: 'libstaticrootslib2_test.la' is up to date.
make[2]: Leaving directory '/bdwgc'
/usr/bin/make  check-TESTS
make[2]: Entering directory '/bdwgc'
make[3]: Entering directory '/bdwgc'
PASS: cordtest

Not sure if this is bug in https://github.com/ivmai/bdwgc.git or in quemu. But on raspberrypi it works (both on host and using the same dockerfile)

Reproduced also via github actions : https://github.com/alexkutsan/arm_actions/runs/5584613559?check_suite_focus=true

Add branch/version with packages from Fedora

Fedora packages are updated faster than Debian packages, but the list of supported architectures is shorter (arm32v6 is missing): https://kojipkgs.fedoraproject.org/packages/qemu/4.0.0/5.fc31/x86_64/

It would be interesting to publish images with Fedora binaries too. In order to do this, several changes are required:

• Introduce image versioning. Currently all the images/manifests are 'rolling'.
• Adapt run.sh to support two source URL and filename formats.

---

Extract binaries from Fedora packages:

sudo apt-get install rpm2cpio cpio

curl -fsSL "$PACKAGE_URI" | rpm2cpio - | cpio -dimv "*usr/bin*qemu-*-static"
mv ./usr/bin/* ./
rm -rf ./usr/bin

Wrong date?

Using Raspbian 32bit on a Pi 4, the date inside the docker does not match the system date.

pi@rpi:~ $ docker run --rm --privileged aptman/qus -s -- -p i386
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p i386 --suffix -static
Setting /qus/bin/qemu-i386-static as binfmt interpreter for i386

pi@rpi:~ $ docker run --rm -it debian /bin/bash
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
5c0fdcca2cbb: Pull complete
Digest: sha256:8414aa82208bc4c2761dc149df67e25c6b8a9380e5d8c4e7b5c84ca2d04bb244
Status: Downloaded newer image for debian:latest
root@1b8f5ee7c679:/# date
Sun Nov  1 19:48:44 UTC 2020
root@1b8f5ee7c679:/# exit

pi@rpi:~ $ docker run --rm -it i386/debian /bin/bash
Unable to find image 'i386/debian:latest' locally
latest: Pulling from i386/debian
c303ed7c76e7: Pull complete
Digest: sha256:c0a5cdcd732dba815f37c0942c668b299b9a80cef949e1e4e6d3401faa5b8d8f
Status: Downloaded newer image for i386/debian:latest
root@6bf30e989f54:/# date
Sat Oct 30 08:53:36 UTC 2004

Can I run x86 docker images on Raspberry Pi 4 with this?

Hi,

I'm Mr. Hologram, a very friendly guy.

Can I run x86 docker images on Raspberry Pi 4 with this?

You don't mention aarch64 in the supported systems list but you suggest using qus here:

https://forums.raspberrypi.com/viewtopic.php?t=281532

When I run amd64/ubuntu on the arm64 host , it warn me The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Host info

root@armbian:~/olbat# uname -a
Linux armbian 5.10.215-ophub #1 SMP PREEMPT Thu Apr 25 11:22:33 EDT 2024 aarch64 aarch64 aarch64 GNU/Linux

root@armbian:~/olbat# lscpu
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: ARM
Model name: Cortex-A53
Model: 4
Thread(s) per core: 1
Core(s) per cluster: 4
Socket(s): -
Cluster(s): 1
Stepping: r0p4
CPU(s) scaling MHz: 60%
CPU max MHz: 2016.0000
CPU min MHz: 100.0000
BogoMIPS: 48.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Not affected
Spectre v1: Mitigation; __user pointer sanitization
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected

root@armbian:~/olbat# docker run --rm --privileged aptman/qus -s -- -p x86_64
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p x86_64 --suffix -static
Setting /qus/bin/qemu-x86_64-static as binfmt interpreter for x86_64
sh: write error: File exists

root@armbian:~/olbat# cat /proc/sys/fs/binfmt_misc/qemu-x86_64
enabled
interpreter /qus/bin/qemu-x86_64-static
flags: F
offset 0
magic 7f454c4602010100000000000000000002003e00
mask fffffffffffefe00fffffffffffffffffeffffff

Issues:

Then I run

root@armbian:~/olbat# docker run --rm -it amd64/ubuntu:bionic bash
Unable to find image 'amd64/ubuntu:bionic' locally
bionic: Pulling from amd64/ubuntu
7c457f213c76: Pull complete
Digest: sha256:dca176c9663a7ba4c1f0e710986f5a25e672842963d95b960191e2d9f7185ebe
Status: Downloaded newer image for amd64/ubuntu:bionic
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

I can not run the amd64 on my arm64 hosts through aptman/qus

Question
PS: I notice the README of the aptman/qus Setup notice following info , So I did not install the qemu-user-static in my host , Is it need to install the qemu-user-static in my host ?
`
The required qemu-*-static binaries (which are all included in the image) will be loaded and registered. The container will then exit. From there on, images and/or binaries for foreign architectures can be executed.

Optional argument TARGET_ARCH is the target architecture to be translated through QEMU. If it is omitted, all available targets will be registered and loaded. The supported values are the following:
`

Working on docker + dotnet builds with both QUS and setup-qemu-action. Qus throws segmentation fault.

Hey,

I'm currently trying to setup some builds for quite a complex thing I'm working on (an image optimizer which runs x86 windows applications in an ARM linux container).

I actually managed to get it all working. The strange thing is though that for some reason I can only get the build to work with the github actions task named: setup-qemu-action. Whereas I can only get running the container working with qus.

If I build the container using qus then I run into a Segmentation fault. If I run the container with setup-qemu-action I also run into a segmentation fault.

This issue I'd like to focus on building the container is not working with qus but it is working with the github task setup-qemu-action.

Here's the build where you can see it going wrong:
https://github.com/devedse/DeveImageOptimizer/runs/2343006390?check_suite_focus=true

The yaml:

  build_docker_linux_qusbuild:
    needs: generate_version_number
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Login to Docker Hub
      uses: docker/login-action@v1
      with:
        username: devedse
        password: ${{ secrets.DOCKERHUBTOKEN }}
    - name: Setup qus
      run: |
        docker run --rm --privileged aptman/qus -s -- -p
    - name: Set up Docker Buildx
      id: buildx
      uses: docker/setup-buildx-action@v1
    - name: Builder instance name
      run: echo ${{ steps.buildx.outputs.name }}
    - name: Available platforms
      run: echo ${{ steps.buildx.outputs.platforms }}
    - name: Run Buildx
      run: |
        export VERSION=1.0.${{needs.generate_version_number.outputs.build_number}}
        echo Version: $VERSION
        docker buildx build -f DeveImageOptimizer.ConsoleApp/Linux.Dockerfile --build-arg BUILD_VERSION=$VERSION --platform linux/arm64,linux/amd64 -t devedse/deveimageoptimizerconsoleapp:${{needs.generate_version_number.outputs.build_number}} -t devedse/deveimageoptimizerconsoleapp:latest --push .

Build output:

#24 [linux/arm64 build 9/9] RUN dotnet build "DeveImageOptimizer.ConsoleApp.csproj" -c Release -o /app/build
#24 sha256:448b9fe5ecc129143fcabee60dc530e38619eb2a6a7b5413e1edebca8e4afd0f
#24 67.45 /usr/share/dotnet/sdk/5.0.202/Roslyn/Microsoft.CSharp.Core.targets(71,5): error : qemu: uncaught target signal 11 (Segmentation fault) - core dumped [/src/DeveImageOptimizer/DeveImageOptimizer.csproj]
#24 68.04 
#24 68.04 Build FAILED.
#24 68.04 
#24 68.04 /usr/share/dotnet/sdk/5.0.202/Roslyn/Microsoft.CSharp.Core.targets(71,5): error : qemu: uncaught target signal 11 (Segmentation fault) - core dumped [/src/DeveImageOptimizer/DeveImageOptimizer.csproj]
#24 68.04     0 Warning(s)
#24 68.04     1 Error(s)
#24 68.05 
#24 68.05 Time Elapsed 00:00:47.97
#24 ERROR: executor failed running [/bin/sh -c dotnet build "DeveImageOptimizer.ConsoleApp.csproj" -c Release -o /app/build]: exit code: 1

#9 [linux/arm64 base  5/10] RUN if [ "linux/arm64" = "linux/arm64" ]; then         git clone --depth 1 --recurse-submodules -j8 https://github.com/devedse/hangover.git /root/hangover ;     fi
#9 sha256:98348fc916409de984e4adf6413ee670780870ea54fca0ab5a77b62aa1eecdc6
#9 CANCELED
------
 > [linux/arm64 build 9/9] RUN dotnet build "DeveImageOptimizer.ConsoleApp.csproj" -c Release -o /app/build:
------
Linux.Dockerfile:91
--------------------
  89 |     COPY . .
  90 |     WORKDIR "/src/DeveImageOptimizer.ConsoleApp"
  91 | >>> RUN dotnet build "DeveImageOptimizer.ConsoleApp.csproj" -c Release -o /app/build
  92 |     
  93 |     FROM build AS publish
--------------------
error: failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c dotnet build "DeveImageOptimizer.ConsoleApp.csproj" -c Release -o /app/build]: exit code: 1
Error: Process completed with exit code 1.

How to turn off core dump

Hello,

I'm running an amd64 container on Raspberry 4 (armv7l).
Running a particular binary in that container raises a "Segmentation fault" which is the same running it in a native amd64 environment.
Each time the "Segmentation fault" occurs, a core dump is created for that binary:
Segmentation fault (core dumped) e.g. qemu_L_H0JDGCZAZ_20220817-085108_146.core

Can I configure qus in a way not to create those core dumps?

Thanks in advance

Best

Sascha

No such file or directory

I want to run another docker container with x86_64 on my aarch64 machine.

When running sudo docker run --rm --privileged aptman/qus -- -p x86_64 it prints me the following error:

cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p x86_64
Setting /qus/bin/qemu-x86_64 as binfmt interpreter for x86_64
sh: write error: No such file or directory

Running any x86 container then will still not work.