I want to build a multi-platform image of a little python app on my Windows 11 PC. I am running Docker Desktop 4.10.1 (82475) and the commands in Windows PowerShell. I have no idea what this error means or why it is crashing or just not running there in an endless loop. I cannot find anything about target signal 7 on the internet which is weird.
Does anybody have an idea?
docker buildx ls shows me:
NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS
build docker-container
build npipe:////./pipe/docker_engine running linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
mybuilder * docker-container
mybuilder0 npipe:////./pipe/docker_engine running linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
desktop-linux docker
desktop-linux desktop-linux running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
default docker
default default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
I created build and mybuilder.
The command I’m trying to run is:
docker buildx build --platform linux/arm/v7,linux/arm64/v8,linux/amd64 --tag username/imagename:latest .
The building logs:
[+] Building 67.2s (16/18)
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.22kB 0.0s
=> [linux/arm/v7 internal] load metadata for docker.io/library/python:alpine 0.9s
=> [linux/arm64 internal] load metadata for docker.io/library/python:alpine 0.9s
=> [linux/amd64 internal] load metadata for docker.io/library/python:alpine 0.9s
=> [linux/arm/v7 1/4] FROM docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> => resolve docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 94B 0.0s
=> [linux/arm64 1/4] FROM docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> => resolve docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> [linux/amd64 1/4] FROM docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> => resolve docker.io/library/python:alpine@sha256:4543fd9295d8d4f7a61c80d8e490de0f1cb0b37b022dbc1dd92537101a81d149 0.0s
=> CACHED [linux/arm64 2/4] WORKDIR /app 0.0s
=> CACHED [linux/arm64 3/4] COPY . . 0.0s
=> CACHED [linux/amd64 2/4] WORKDIR /app 0.0s
=> CACHED [linux/amd64 3/4] COPY . . 0.0s
=> CACHED [linux/amd64 4/4] RUN pip3 install python-tado 0.0s
=> CACHED [linux/arm/v7 2/4] WORKDIR /app 0.0s
=> CACHED [linux/arm/v7 3/4] COPY . . 0.0s
=> [linux/arm64 4/4] RUN pip3 install python-tado 66.3s
=> => # qemu: uncaught target signal 7 (Bus error) - core dumped
=> [linux/arm/v7 4/4] RUN pip3 install python-tado 66.3s
=> => # qemu: uncaught target signal 7 (Bus error) - core dumped
And last but not least my Dockerfile:
#Deriving the latest base image
FROM python:alpine
# Any working directory can be chosen as per choice like '/' or '/home' etc
WORKDIR /app
#to COPY the remote file at working directory in container
COPY . .
# has to be after WORKDIR because Python will only have all files within its path
RUN pip3 install python-tado
ENV USERNAME=username
ENV PASSWORD=password
CMD ["python", "-u", "script.py"]
2
Answers
I guess I can answer the question myself. On my main PC with Windows 11 it worked without a problem. So it makes sense that my ARM device can only build an image for arm64 and not also for amd64 as the PC can.
Rookie mistake I guess.
TL;DR: I restarted my Docker Desktop Host machine and it was fixed (maybe restarting all docker-related services would have fixed it also).
I just now had the exact same problem, i ran a multiplatform build using a custom qemu builder instance on my windows machine. I was building for
linux/arm64,linux/amd64,linux/arm/v6,linux/arm/v7which my builder was compatible with. At the first Dockerfile instruction (apart from WORKDIR/FROM) the builder failed with the error:failed to solve: process "..." exit code 135and that qemu got an unexpected signal 7. Seems like somehow my running instance of builder was corrupted and a restart fixed the issue.