-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error building python 3.6 slim #495
Comments
I just ran into this as well, but I had builds running just fine 3 months ago. Today I updated my code and ran my build pipeline and this error happened; nothing about my build files changed. Unfortunately in the last 3 months, I probably have ran a number of updates on my build server. I know that's not helpful sadly. In my case, it's python:3.7-slim and changing to 3.7 doesn't work because I get pip issues in my Dockerfile (I think unrelated) |
I suspect a PATH issue, but only appears to affect ARM builds? Staring on December 15th, my CI builds started failing to build ARM-based images. Using the following Dockerfile:
Then building with: results in an error:
You'll note that
Results in:
|
In my experimentations, you run into issues if you create a builder. Things work fine if you use the default builder and don't multi platform build (not that you can with the default builder anyway). Is this your experience as well? |
@fidesachates It seems to be specific to armhf (arm/v7 and arm/v8) builds. ARM64 and AMD64 build fine. I'm not sure if I understand your question enough to give you a more solid answer than that. I can say that I've been primarily using this via Github Actions (i.e., https://github.com/CommunityHoneyNetwork/rdphoney/actions/runs/418797571) and it first broke 22 days ago. The snippets I provided in the original issue came from trying to recreate the issue as simply as possible on my Macbook, which may well have had a non-default builder. |
@JesseBowling I concur arm64 builds work for me as well. I'm running builds on a ubuntu server. On that server, your examples have no problems for me with or without the PATH edit. Only when I create a docker builder in order to build for more than one platform do I run into these issues (even if I use the created builder to only build for one platform).
I tried pinning qemu docker image to 5.0.0-5 which was released 4 months ago, but that made no difference. |
Well. Not sure what this implies, but in my CI we were specifying platform targets like so:
And it was failing with the above. That was changed to this:
and all appears to be working as intended. Not sure what that means, or why things changed 22 days ago, but things are working for me now. I do wonder what changed to cause this behavior? |
Does not help building linux/arm/v7 on debian or boot2docker. Interesting that it will work on Docker Desktop 3.0.3 on MacOS BigSur. That uses buildx v0.4.2-docker. Tried this version but same error. |
The last try lead me to view the buildkitd versions. while both images showed "moby/buildkit:buildx-stable-1", the BigSur-version was loaded 3 months ago and is on version 0.7.2. |
While trying I saw that there is an update to docker 20.10.2. However in the process I also did a |
Hi everyone Got my docker updated to latest (20.10.2, Ubuntu) , did the multiarch reset thing, but still get the error... I've tried playing with the PATH, moving binaries, changing base images, then given up... Any news on this ? |
@nicobo Can you share what architectures you're trying to build for? For me, the issue went away when I switched |
I am getting the exact same problem when I # syntax=docker/dockerfile:experimental
FROM arm64v8/ubuntu:latest
RUN apt-get update
RUN apt-get install -y --no-install-recommends
RUN apt-get install -y build-essential
... which results in: ...
=> ERROR [ 4/20] RUN apt-get install -y build-essential
...
> Error while loading /usr/sbin/dpkg-split: No such file or directory
> Error while loading /usr/sbin/dpkg-deb: No such file or directory
... For the record, I am cross-building on docker buildx build --platform linux/arm64 -t user/repo --no-cache --pull . My custom builder looks like this:
Any ideas? |
What actually solved my problem after two painful days was creating the following custom builder: docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap Now I can successfully run:
on my |
@JesseBowling I'm using |
@pcko1 what is the custom part that solves the problem ? |
@nicobo |
@pcko1 OK, then I tried it already with no luck. But if I remember well in my case arm64 was not problematic, only armv7 |
We're using ubuntu xenial as base.
Won't help. I'm building linux/arm64 and linux/amd64
|
Just an update after reading though all the comments here and trying out some solutions: I am primarily using GitHub Actions to do my building with Buildx, hopefully what I was able to reproduce on my own machine closely matches what GitHub Actions was doing. I realized that the list of Buildx platforms supported in GitHub Actions did not include It's weird, because having At any rate, it seems that if I use the platforms that Buildx reports are supported, all should be good (assuming the base image also was built with it). At the time of writing, GitHub Actions |
@PhasecoreX yes I think in my case it was also an issue with the list of supported architectures that was inconsistent between the base images and the emulator's ones. |
I am also facing the same issue with ubuntu18.04 with platform linux/arm64. |
Bump on this! Worked for me. I would just recommend not using |
Also experiencing this on a daemonless build. |
Got the idea for the symlinks from docker/buildx#495
Try to fix docker buildx by using suggestion from docker/buildx#495 (comment)
I investigated a similar issue (same error message) and came to the following conclusion:
|
Some packages installed from the Dockerfile failed after #2971 was merged. Reason was it used default pre-installed version of qemu - the emulator used from amd64 architecture to build the arm64 images. Qemu is suggested by Dockerhub as well. [Dockerhub](https://docs.docker.com/build/ci/github-actions/multi-platform/) [Github Issue](docker/buildx#495 (comment)) category: fixbuild ticket: none
I have this Dockerfile:
When I run this command:
I get this output:
Some observations:
It seems like it's looking for
/usr/sbin/dpkg-split
and/usr/sbin/dpkg-deb
, even though those are located in the/usr/bin
folder.Platforms linux/arm/v7 and linux/arm/v8 both fail, however linux/amd64 does not fail.
Changing my Dockerfile to use
FROM python:3.6
(instead of slim) builds correctly for all cases (armv5, armv7, arm64v8, amd64), and manually starting a container (after doing the multiarch qemu setup) withdocker run -it --rm arm32v5/python:3.6-slim bash
allows me to installmake
just fine.I wasn't sure if this was a buildx issue or just a python-slim issue, but I was also able to do this as my Dockerfile:
and do a regular docker build:
and it builds correctly. So my guess is it has something to do with buildx? Unless
arm32v5/python:3.6-slim
is different thanpython:3.6-slim
that buildx would be pulling.This might be related to #493, not entirely sure.
The text was updated successfully, but these errors were encountered: