My Dockerfile works on x86 machine, but fails on the machine with arm64 architecture; specifically on a1.2xlarge (an aws EC2-instance).
Error on running docker compose up -d
#0 0.462 exec /bin/sh: exec format error
------
failed to solve: executor failed running [/bin/sh -c apt-get update]: exit code: 1
Dockerfile looks like this
FROM phusion/passenger-ruby27
ENV HOME /root
RUN apt-get update
docker -v
Docker version 20.10.17, build 100c701
uname -a
Linux Ubuntu SMP Thu Jun 9 13:06:11 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
lsb_release -a
Ubuntu 20.04.4 LTS
phusion/passenger-ruby27 repository separates the arm64-based images via tags (as of Nov-2022).
I.e. 2.3.1 and 2.3.1-arm64
Assuming that you want to build an arm64 image on your arm64 instance, a simple way to resolve this is to pass the tag as a build argument.
Dockerfile:
ARG BASE_TAG
FROM phusion/passenger-ruby27:$BASE_TAG
ENV HOME /root
RUN apt-get update
Build examples:
# on arm
$ docker build --build-arg BASE_TAG=2.3.1-arm64 .
# on amd
$ docker build --build-arg BASE_TAG=2.3.1 .
Related
My server and docker info. are as follows:
Linux xxx 3.10.0-1160.66.1.el7.x86_64 #1 xxx x86_64 x86_64 x86_64 GNU/Linux
Docker version 20.10.17
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Server Version: 20.10.17
Kernel Version: 3.10.0-1160.66.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
I want to build a docker container by QEMU. I followed the instructions from the official QEMU github. But it gave errors.
$ uname -m
x86_64
$ docker run --rm -t arm64v8/ubuntu uname -m
WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
exec /usr/bin/uname: exec format error
Then I found a similar docker problem on stackoverflow. I tried both docker build and docker buildx, and it still doesn't work.
$ docker build --platform linux/arm64/v8 .
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /work/home/chenning/Dockerfile: no such file or directory
$ docker buildx build --push --platform linux/amd64,linux/arm64 -t <tag> .
-bash: tag: No such file or directory
I also tried the following instruction, but it still reported errors.
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
sh: write error: Invalid argument
Setting /usr/bin/qemu-alpha-static as binfmt interpreter for alpha
Setting /usr/bin/qemu-arm-static as binfmt interpreter for arm
sh: write error: Invalid argument
Setting /usr/bin/qemu-armeb-static as binfmt interpreter for armeb
sh: write error: Invalid argument
Setting /usr/bin/qemu-sparc-static as binfmt interpreter for sparc
sh: write error: Invalid argument
...
I followed the guide from this link
it works when I try
docker run --rm --privileged multiarch/qemu-user-static:register
I have qemu interpreters (including qemu-aarch64) in /proc/sys/fs/binfmt_misc
My qemu-aarch64 is like this
enabled
interpreter /usr/bin/qemu-aarch64-static
flags:
offset 0
magic 7f454c460201010000000000000000000200b700
mask ffffffffffffff00fffffffffffffffffeffffff
but I don't have the permission to change flags, I also don't have interpreter /usr/bin/qemu-aarch64-static.
Can I get some help, pls?
I got the same error, but executing this command fixed the issue:
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
So I can even spawn a shell:
$ docker run -it arm64v8/ubuntu /bin/bash
root#0b6162g03ka5:/# uname -m
aarch64
If it doesn't work take a look at this issue, otherwise you should create a new issue on github
hi following are my docker file commands
ARG debianVersion=10.2
FROM debian:${debianVersion}
ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG AGENT_WORKDIR=/home/${user}/agent
USER root
RUN apt-get update
RUN groupadd -g ${gid} ${group}
RUN useradd -c "Jenkins user" -d /home/${user} -u ${uid} -g ${gid} -m ${user}
I am using rancher desktop on mac m1 chip.
On executing following command I a getting error
docker build -t test --platform linux/x86_64 .
Error message is as follows
[Warning] The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
---> Running in 7778b2303192
-c: 0: Can't open apt-get update
The command '/bin/sh -c apt-get update' returned a non-zero code: 127
Found that none of the shell commands are working getting error a non-zero code: 127 how to fix this?
Using rancher version 1.5.0
Using container runtime dockerd(moby)
Using Kubernetes version v1.21.14
Downgrade to Rancher Desktop 1.4.1.
This works but if downgrading is not an option there are workarounds on the Rancher Desktop Issues site for similar problems like this:
qemu workaround
As a temporary workaround, as root in the VM:
Create /etc/conf.d/qemu-binfmt, with contents binfmt_flags="POCF"
Run rc-update --update
Run rc-service qemu-binfmt restart
Easy way to connect to the VM and run those commands is (source):
docker run -it --rm --privileged --pid=host justincormack/nsenter1
Dockerfile:
…
FROM --platform=linux/arm64 debian:${debianVersion}
…
Build command:
docker build -t test --platform linux/arm64 .
As far as I understand it dockerd runtime can only emulate other platform types (in the above case --platform=linux/amd64) on the m1 chip macs using Docker Desktop.
Try using the built in nerdctl that comes packaged with Rancher Desktop:
nerdctl build -t test --platform linux/amd64 .
nerdctl build -t test --platform linux/x86_64 .
N.B. I have found that even with emulation, some --platform linux/x86_64 (linux/amd64) images still cannot be built, recently experienced that with official selenium set, but had no problem with wso2 & mailcatcher images
my Server is :
3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014
and my docker version is :
Docker version 18.06.3-ce, build d7080c1
I got this error after my simple code docker run hello-world why ?
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:348: starting container process caused
"process_linux.go:297: copying bootstrap data to pipe caused \"write
init-p: broken pipe\"": unknown.
I find solution , and i want to share it, If you’re using Docker CE on Ubuntu, take Docker back one patch version (if you’re on Debian, replace debian for ubuntu):
$ sudo apt-get install docker-ce=18.06.1~ce~3-0~ubuntu
If you’re using Docker EE, you can downgrade with something like this:
$ sudo apt-get install docker-ee=18.09.1~ee-0~ubuntu
For Docker CE on CentOS 7 (Docker EE and/or Fedora are similar):
$ sudo curl -SsL https://download.docker.com/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo
$ sudo yum --showduplicates list docker-ce
$ sudo yum install docker-ce-18.06.1.ce-3-0.el7.centos
recently encountered similar problem
just updated the linux kernel from 3.x version to 4.x version
$ apt-get install --install-recommends linux-generic-lts-xenial
then try docker run commands
to know the current linux kernel version
$ uname -a
I have a simple docker file:
FROM ubuntu:16.04
MAINTAINER T-vK
RUN useradd -m -s /bin/bash -g dialout esp
USER esp
WORKDIR /home/esp
COPY ./entrypoint_script.sh ./entrypoint_script.sh
ENTRYPOINT ["/home/esp/entrypoint_script.sh"]
when I run docker build . followed by docker run -t -i ubuntu and look for the directory /home/esp it is not there! The whole directory including it's files seem to be gone.
Though, when I add RUN mkdir /home/esp to my docker file, it won't build telling me mkdir: cannot create directory '/home/esp': File exists.
So what am I misunderstanding here?
I tested this on Debian 8 x64 and Ubuntu 16.04 x64.
With Docker version 1.12.2
Simply change you Docker build command to:
docker build -t my-docker:dev .
And then to execute:
docker run -it my-docker:dev
Then you'll get what you want. you didn't tag docker build so you're actually running Ubuntu image.
I am creating a very basic image on my debian wheezy host machine. This is the Dockerfile:
FROM ubuntu:trusty
USER root
# Activate multiverse repos
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty universe multiverse' >> /etc/apt/sources.list
RUN echo 'deb http://security.ubuntu.com/ubuntu trusty-security universe multiverse' >> /etc/apt/sources.list
RUN echo 'deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe multiverse' >> /etc/apt/sources.list
RUN apt-get update
RUN apt-get install -y supervisor
WORKDIR /
CMD ["/usr/bin/supervisord", "-n"]
To build the image, I used docker build -t basic-ubuntu .
To run the container, I used docker run -d basic-ubuntu
To go into the container, I used docker exec -i -t <container_id> bash
When I am into the container, what I see is that the container's root directory / has the same content as the host. When I create a file on the container, it's also created on the host. Even when I add in the Dockerfile a RUN apt-get install -y of some package I don't have on the host, then I don't find it on the container. Actually even the $PATH variable on the container is the same as the host.
Here are some info on my env
host$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
host$ docker version
Client:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:20:12 2016
OS/Arch: linux/amd64
Server:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:20:12 2016
OS/Arch: linux/amd64
The mounts shown by docker inspect
"Mounts": []
For the full docker inspect trace: http://pastebin.com/t4uSu4ZH
I think that the problem comes from the docker exec step. Because the build and run seem to work correctly.
I think that the problem comes from the docker exec step
That is certainly the case, considering a container is there to isolate you from the host.
(different filesystem, process, root, user, ...)
When you "exec bash" to a container, you should see a prompt:
root#<short_container_id>
If you don't see that, it is because somehow your docker exec did not execute properly.
If you do see that, then what you think is on the host is actually still the container content.
Also relevant, there is a potential bug around -i (interactive) when used with docker exec.
See "Why do there exist “-i” and “-t” options for the “docker exec” command?".
The OP amine confirms it is the case in the comments:
Issue 8755 ("Docker tty is not a tty with docker exec") means -t (tty) does not correctly opens a tty on centos7 (not centos6).
This happens even if TERM is set to xterm (don't forget issue 9299: docker exec does not set TERM env when -t passed)
The other issue mentioned by the Op is:
When I went back to the howto install docker in debian, I found that in the prerequisites: "kernel must be 3.10 at minimum" and "These older versions are known to have bugs".
And my debian's kernel version is 3.2.
The solution was to upgrade to a newer debian version, with a kernel version above 3.10.
I met the same issue where docker volume mount function was not working correctly . And this turned out to be the kernel version issue. After I upgrade my Debian kernel from 3.2 up to 3.16, everything works fine.
$ uname -a
Linux 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3~bpo70+1 (2016-01-19) x86_64 GNU/Linux