Question 84661 in Docker Question posted in
The official documentation can be found here.

qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory – Docker

I have a Rancher Deskop(dockerd) on M1 MacOS and when I am trying to build below dockerfile I am getting an error such as below. Here is the command how I am trying to build the image docker build -t te-grafana-dashboards-toolchain --no-cache .

I tried to change the platforms but nonae of them worked for me. I am a bit lost about this platform issue for M1 but any help will be appreciated, What I am doing wrong? What might the root cause of this?

Removing intermediate container 70af516d5d6b
 ---> a69229847153
Step 5/6 : RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb; ln -s $(go env GOPATH)/bin/jb /usr/bin/jb
 ---> Running in 13545862fffe
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
Removing intermediate container 13545862fffe

Dockerfile

FROM --platform=linux/amd64 ubuntu:focal
RUN apt update; apt install -y curl jq build-essential python3.8 python3-pip docker-compose jsonnet bison mercurial
RUN ln -s /usr/bin/python3.8 /usr/bin/python
RUN curl -OL https://golang.org/dl/go1.17.linux-amd64.tar.gz; mkdir /etc/golang; tar -xvzf go1.17.linux-amd64.tar.gz -C /etc/golang; ln -s /etc/golang/go/bin/go /usr/bin/go; rm -f go1.17.linux-amd64.tar.gz
RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb; ln -s $(go env GOPATH)/bin/jb /usr/bin/jb
WORKDIR /workspace
Tags:

7

Answers


  1. Chosen as BEST ANSWER
    0

    this resolved my issue.

    FROM ubuntu:focal
RUN apt update; apt install -y curl jq build-essential python3.8 python3-pip docker-compose jsonnet bison mercurial
RUN ln -s /usr/bin/python3.8 /usr/bin/python
RUN curl -OL https://golang.org/dl/go1.17.linux-arm64.tar.gz; mkdir /etc/golang; tar -xvzf go1.17.linux-arm64.tar.gz -C /etc/golang; ln -s /etc/golang/go/bin/go /usr/bin/go; rm -f go1.17.linux-arm64.tar.gz
RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb@latest; ln -s /root/go/bin/jb /usr/bin/jb
WORKDIR /workspace

  2. 0

    Incidentally, in case it’s helpful to another who lands here, I have the same issue on an M1 Max MacBook Pro laptop attempting to do a docker build from a company repo that should be a pretty well traveled path, but I might be the only one (it’s a small company) that has an ARM64 M1 "Apple Silicon" Mac. However I found the solution (well, a solution) to my situation was exactly the opposite of the solution to the OP’s, and that was to add --platform=linux/amd64 to the FROM line of the docker file.

    Example:

    FROM --platform=linux/amd64 ubuntu:20.04

    Otherwise it was using an ARM64 image to start from without me being the wiser but then later in the Dockerfile the build attempts to install and execute code compiled for x86_64. Starting the build process by requesting the base image be linux/amd64 ends up with then the base image having /lib64/ld-linux-x86-64.so.2. This probably means everything is being emulated as x86_64 on the ARM64 CPU via qemu-x86_64 and so if you have the option to start from an ARM64 image and can compile within the container during build time any software you can’t install as ARM64 binaries, it’ll probably go faster when you later run the container on the M1 based Mac. I’m not able to try that myself just yet for this case.

    Login or Signup to reply.
  3. 0

    Passing following flag to C preprocessor as CPPFLAGS solved similar issue in my M1

    -DPNG_ARM_NEON_OPT=0

    Pass the value as env var with key CPPFLAGS to relevant service.

    Login or Signup to reply.
  4. 0

    Modifying Dockerfile seems to be the most popular answer but you can also set the DOCKER_DEFAULT_PLATFORM environment variable to linux/amd64.

    export DOCKER_DEFAULT_PLATFORM=linux/amd64

    The cause seems to reside in the AArch64 image.

    Login or Signup to reply.
  5. 0

    Provided the base image includes the target architecture, another option that might work in your case is using Docker’s built-in TARGETARCH build arg. This works for me on macOS M1.

    FROM ubuntu:focal
ARG TARGETARCH
RUN apt update; apt install -y curl jq build-essential python3.8 python3-pip docker-compose jsonnet bison mercurial
RUN ln -s /usr/bin/python3.8 /usr/bin/python
RUN curl -OL https://golang.org/dl/go1.17.linux-${TARGETARCH}.tar.gz; mkdir /etc/golang; tar -xvzf go1.17.linux-${TARGETARCH}.tar.gz -C /etc/golang; ln -s /etc/golang/go/bin/go /usr/bin/go; rm -f go1.17.linux-${TARGETARCH}.tar.gz
RUN GO111MODULE="on" go get github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb; ln -s $(go env GOPATH)/bin/jb /usr/bin/jb
WORKDIR /workspace
    Login or Signup to reply.
  6. 0

    Instead of editing the Dockerfile, as suggested in this answer, or setting an environment variable, as suggested in this answer, I prefer to pass the platform as an argument to the docker build command, with the --platform flag. The command used by the OP would then be:

    docker build --platform linux/amd64 -t te-grafana-dashboards-toolchain --no-cache .
    Login or Signup to reply.
  7. 0

    I have a Mac M1 Max computer and encountered an error when attempting to install Camunda Platform 8 using Helm on a Kubernetes cluster running on a KIND node. The error occurred in the Camunda Operate pod. However, after changing the default image using the ‘–platform linux/amd64’ option, I was able to start the container successfully.

    Specifically, I ran the following commands:

    docker pull camunda/operate:8.1.6 --platform linux/amd64
kind load docker-image --name camunda-platform-local camunda/operate:8.1.6
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search