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

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.
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.

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.

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

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 .

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.

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

Related

make command not working in Windows WSL Ubuntu

I am trying to build a project in Ubuntu in a WSL instance. The command I'm using is from a chirpstack-simulator project: docker-compose run --rm chirpstack-simulator make clean build.
For some reason make refuses to work correctly, or at all.
I keep getting an error: "make: *** No rule to make target 'clean'. Stop."
Here is the Makefile code:
VERSION := $(shell git describe --always |sed -e "s/^v//")
build:
#echo "Compiling source"
#mkdir -p build
go build $(GO_EXTRA_BUILD_ARGS) -ldflags "-s -w -X main.version=$(VERSION)" -o build/chirpstack-simulator cmd/chirpstack-simulator/main.go
clean:
#echo "Cleaning up workspace"
#rm -rf build
#rm -rf dist
#rm -rf docs/public
The docker-compose.yml code:
services:
chirpstack-simulator:
build:
context: .
dockerfile: Dockerfile-devel
command: make
volumes:
- ./:/chirpstack-simulator
And the Docker-devel file:
FROM golang:1.13-alpine
ENV PROJECT_PATH=/chirpstack-simulator
ENV PATH=$PATH:$PROJECT_PATH/build
ENV CGO_ENABLED=0
ENV GO_EXTRA_BUILD_ARGS="-a -installsuffix TDM-GCC-64"
RUN apk add --no-cache ca-certificates tzdata make git bash
RUN mkdir -p $PROJECT_PATH
COPY . $PROJECT_PATH
WORKDIR $PROJECT_PATH
As you can see, both build and clean are defined. Has anyone encountered this issue before?
Edit:
This is the full project I am trying to build
https://github.com/brocaar/chirpstack-simulator
And further details:
I have tried doing
sudo apt-get remove make
sudo apt-get install make
then
sudo apt-get install --reinstall build-essentials
It is still giving the error.
Version of Ubuntu is 16.04 LTS if it helps narrow things down
I would at the very least replace the make command by ls -larth, just to make sure the docker-compose run ls -alrth does display a Makefile in its execution context.
If it does not, then any make command would fail with the error message you mention.

How to install Go in alpine linux

I am trying to install Go inside an Alpine Docker image. For that I downloaded tar file from here inside my alpine docker image, untar it using following command:
tar -C /usr/local -xzf go1.10.3.linux-amd64.tar.gz
exported PATH to have go binary as:
export PATH=$PATH:/usr/local/go/bin
However, when I say go version then it says that sh: go: not found. I am quite new to alpine. Does anyone know, what I am missing here?
Steps to reproduce-
$ docker run -it alpine sh
$ wget https://dl.google.com/go/go1.10.3.linux-amd64.tar.gz
$ tar -C /usr/local -xzf go1.10.3.linux-amd64.tar.gz
$ export PATH=$PATH:/usr/local/go/bin
$ go version
I just copied it over using multi stage builds, seems to be ok so far
FROM XXX
COPY --from=golang:1.13-alpine /usr/local/go/ /usr/local/go/
ENV PATH="/usr/local/go/bin:${PATH}"
The following Dockerfile worked for me. Simpler and more abstract.
FROM alpine:latest
RUN apk add --no-cache git make musl-dev go
# Configure Go
ENV GOROOT /usr/lib/go
ENV GOPATH /go
ENV PATH /go/bin:$PATH
RUN mkdir -p ${GOPATH}/src ${GOPATH}/bin
# Install Glide
RUN go get -u github.com/Masterminds/glide/...
WORKDIR $GOPATH
CMD ["make"]
source: https://raw.githubusercontent.com/mickep76/alpine-golang/master/Dockerfile
Thanks BMitch.
I compiled the go source code and performed the below steps inside alpine image container.
echo "installing go version 1.10.3..."
apk add --no-cache --virtual .build-deps bash gcc musl-dev openssl go
wget -O go.tgz https://dl.google.com/go/go1.10.3.src.tar.gz
tar -C /usr/local -xzf go.tgz
cd /usr/local/go/src/
./make.bash
export PATH="/usr/local/go/bin:$PATH"
export GOPATH=/opt/go/
export PATH=$PATH:$GOPATH/bin
apk del .build-deps
go version
With Alpine, you have libmusl instead of glibc. Alpine's libmusl is not a 1 for 1 replacement. Code linked against glibc will show a not found error which is actually from the dynamic linker. You can see what libraries are linked to the binary with ldd:
/ # ldd /usr/local/go/bin/go
/lib64/ld-linux-x86-64.so.2 (0x7f63ceed1000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f63ceed1000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f63ceed1000)
There are two options. The preferred option, and one used by docker's go images on Alpine, is to compile the go binaries on Alpine. You can see this in the Dockerfile for the golang image: https://github.com/docker-library/golang/blob/69f2d2a132565bf60afc91813801a3bdcc981526/1.10/alpine3.8/Dockerfile
The other option is to install glibc on Alpine, but once you start doing things like that, I'd question why use Alpine at all, and whether Debian or CentOS would be a more appropriate base image for you. Alpine has a wiki topic on this and there are third parties that have created glibc packages for alpine.
I found the best way to get golang up running in alpine linux is to install it from source. This is also way followed in the official alpine go docker images.
FROM alpine:3.12
ARG GOLANG_VERSION=1.14.3
#we need the go version installed from apk to bootstrap the custom version built from source
RUN apk update && apk add go gcc bash musl-dev openssl-dev ca-certificates && update-ca-certificates
RUN wget https://dl.google.com/go/go$GOLANG_VERSION.src.tar.gz && tar -C /usr/local -xzf go$GOLANG_VERSION.src.tar.gz
RUN cd /usr/local/go/src && ./make.bash
ENV PATH=$PATH:/usr/local/go/bin
RUN rm go$GOLANG_VERSION.src.tar.gz
#we delete the apk installed version to avoid conflict
RUN apk del go
RUN go version
If the basic requirement is to have specific go version installed inside alpine based docker image then refer these images available on official golang dockerhub account.
docker pull golang:1.12-alpine
docker pull golang:1.11-alpine
Just in case someone encounters the same issue with me.
I was able to install the golang1.17.6 ion Alpine3.15 by following #Yogesh Jilhawar 's answer.
When I ran the command apk add --no-cache --virtual .build-deps bash gcc musl-dev openssl go, I got
ERROR: unable to select packages:
go (no such packages):
required by: world[go]
Then I tried to install the "gcc-go", it installs. After that, I can build the golang from the source successfully.
There Is the Alpine package, with the latest versione of golang:
pkg --update add go

Error in building docker image with perl installation

I am new to docker and i am trying to build the docker image with the perl installation but not sure exactly how to fix this error.
Dockerfile:
FROM amazonlinux
RUN mkdir /shared
RUN cd /shared
RUN yum -y install sudo
RUN cd /shared
RUN echo "Installing Perl."
RUN sudo yum -y update; yum -y install gcc
RUN yum -y install wget
RUN wget http://www.cpan.org/src/5.0/perl-5.22.1.tar.gz
RUN tar -xzf perl-5.22.1.tar.gz
RUN cd perl-5.22.1
RUN /shared/perl-5.22.1/Configure -des -Dprefix=/opt/perl-5.22.1/localperl
RUN make
RUN make test
RUN make install
RUN echo "Perl installation complete."
instead of /shared/perl-5.22.1/Configure i tried to give ./configure as well but i get the same error No such file or directory
Error:
/bin/sh: /shared/perl-5.22.1/Configure: No such file or directory
The command '/bin/sh -c /shared/perl-5.22.1/Configure -des -Dprefix=/opt/perl-5.22.1/localperl' returned a non-zero code: 127
ish-mac:testanalyse ish$
Can anyone tell me how to fix this issue.
Each Dockerfile RUN command runs in its own shell. So, when you do something like RUN cd /shared, the subsequent RUN commands will not be run inside that working directory.
What you want to use in this case is the WORKDIR instruction (https://docs.docker.com/engine/reference/builder/#workdir). You can also combine and shorten some things by taking advantage of the ADD instruction. A more concise Dockerfile to do what you are after might be:
FROM amazonlinux
WORKDIR /shared
RUN yum -y install gcc
ADD http://www.cpan.org/src/5.0/perl-5.22.1.tar.gz /shared
RUN tar -xzf perl-5.22.1.tar.gz
RUN /shared/perl-5.22.1/Configure -des -Dprefix=/opt/perl-5.22.1/localperl
RUN make -C /shared/perl-5.22.1
RUN make -C /shared/perl-5.22.1 test
RUN make -C /shared/perl-5.22.1 install
For example, the build context is already running as root so there is no need for sudo. With ADD we can add directly from URLs and no wget is required. And the make utility has a -C option to specify the working directory for make.
This should get you closer to what you are after. But the build still fails for other reasons (which you should probably open another question for if you are stuck).

Use STDIN during docker build from a Dockerfile

I'm trying to install Miniconda in a docker image as a first step, right now this is what I have:
FROM ubuntu:14.04
RUN apt-get update && apt-get install wget
RUN wget *miniconda download URL* && bash file_downloaded.sh
When I try to build the image, it goes well until it starts popping the following message continously:
>>> Please answer 'yes' or 'no'
At that point I need to stop docker build. How can I fix it? Should I include something in the dockerfile?
You can't attach interactive tty during image build. If it is asking for 'yes' or 'no' during package installation, wget in your case, you can replace the corresponding line with RUN apt-get update -qq && apt-get install -y wget. If it is bash file_downloaded.sh, check if file_downloaded.sh accepts 'yes' or 'no' as a command line argument.
If file_downloaded.sh doesn't have that option, create a container from ubuntu:14.04 image, install wget and run your commands manually there. Then, you can make an image of the container by committing your changes like: docker commit <cotainer_id> <image_name>.
I believe you can pass -b flag to miniconda shell script to avoid manual answering
Installs Miniconda3 4.0.5
-b run install in batch mode (without manual intervention),
it is expected the license terms are agreed upon
-f no error if install prefix already exists
-h print this help message and exit
-p PREFIX install prefix, defaults to $PREFIX
something like that:
RUN wget http://......-x86_64.sh -O miniconda.sh
RUN chmod +x miniconda.sh \
&& bash ./miniconda.sh -b

Identical dockerfiles giving different behaviours

I am using the following dockerfile taken from (http://txt.fliglio.com/2013/11/creating-a-mysql-docker-container/):
FROM ubuntu
RUN dpkg-divert --local --rename --add /sbin/initctl
RUN ln -s /bin/true /sbin/initctl
RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get -y install mysql-client mysql-server
RUN sed -i -e"s/^bind-address\s*=\s*127.0.0.1/bind-address = 0.0.0.0/"
/etc/mysql/my.cnf
ADD ./startup.sh /opt/startup.sh
EXPOSE 3305
CMD ["/bin/bash", "/opt/startup.sh"]
This works with no errors when I build on Docker version 0.8 on my local machine.
I have been experimenting with trusted builds:
https://index.docker.io/u/hardingnj/sqlcontainer/
however on the docker servers I get an error with the second RUN command:
[91mln: failed to create symbolic link `/sbin/initctl': File exists
[0m
Error: build: The command [/bin/sh -c ln -s /bin/true /sbin/initctl] returned a non-zero code: 1
I was under the impression that Dockerfiles should work identically independently of context? Perhaps the versions of ubuntu that I am pulling aren't identical?
It is possible that the versions of the ubuntu image are different. To be extremely precise you could give the full image id that you want in the FROM statement, e.g.
# This is the id of the current Ubuntu 13.10 image.
# The tag could move to a different image at a later time.
FROM 9f676bd305a43a931a8d98b13e5840ffbebcd908370765373315926024c7c35e
RUN dpkg-divert --local --rename --add /sbin/initctl
...

Resources