Standard init linux go 211 exec user process caused exec format error

GitLab

• omnibus-gitlab
• Project information
  • Project information
  • Activity
  • Labels
  • Members
• Repository
  • Repository
  • Files
  • Commits
  • Branches
  • Tags
  • Contributors
  • Graph
  • Compare
  • Locked Files
• Issues 912
  • Issues 912
  • List
  • Boards
  • Service Desk
  • Milestones
  • Iterations
  • Requirements
• Merge requests 68
  • Merge requests 68
• Deployments
  • Deployments
  • Environments
  • Releases
• Monitor
  • Monitor
  • Incidents
• Packages & Registries
  • Packages & Registries
  • Container Registry
• Analytics
  • Analytics
  • Code review
  • Insights
  • Issue
  • Repository
  • Value stream
• Activity
• Graph
• Create a new issue
• Commits
• Issue Boards

Collapse sidebar Close sidebar

docker image error: standard_init_linux.go:211: exec user process caused “exec format error”

Summary

I run the command sudo docker run —detach \ —hostname xxx \ —publish 443:443 —publish 80:80 —publish 22:22 \ —name gitlab \ —restart always \ —volume /srv/gitlab/config:/etc/gitlab \ —volume /srv/gitlab/logs:/var/log/gitlab \ —volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest

It turns docker image error: standard_init_linux.go:211: exec user process caused “exec format error”

Steps to reproduce

Run sudo docker run —detach \ —hostname xxx \ —publish 443:443 —publish 80:80 —publish 22:22 \ —name gitlab \ —restart always \ —volume /srv/gitlab/config:/etc/gitlab \ —volume /srv/gitlab/logs:/var/log/gitlab \ —volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest

What is the current bug behavior?

Docker container cannot be created

What is the expected correct behavior?

Docker container can be created

Relevant logs

docker image error: standard_init_linux.go:211: exec user process caused “exec format error”

Details of package version

gitlab/gitlab-ce:lastest Image ID: 083c1c4f3b8e

Environment details

Configuration details

I don’t have my own sh files. Looks like adding #!/bin/bash to the top of the sh file can fix this problem

Источник

standard_init_linux.go:211: exec user process caused «exec format error» #410

Comments

JonasVautherin commented Dec 20, 2019

I cannot reopen #406, but I believe I have the exact same problem.

I try to run the following:

And I get the following output:

I am running on Arch Linux, on Docker version 19.03.5-ce, build 633a0ea838 .

Any idea where that error may come from?

The text was updated successfully, but these errors were encountered:

JonasVautherin commented Jan 8, 2020 •

For the record, this issue shows the exact same error message, but for a completely different image ( gitlab/gitlab-ce , nothing to do with manylinux).

The gitlab/gitlab-ce container is built for x86_64 architecture. You will need to run the container on system that has the x86_64 architecture.

Hence my question: who can run quay.io/pypa/manylinux2014_aarch64 , and on which architecture are you running it?

@hrw: wondering if you can run this image on your side?

hrw commented Jan 8, 2020

exec user process caused «exec format error» means «you are trying to run container for other architecture.

«quay.io/pypa/manylinux2014_aarch64» can be run on aarch64:

JonasVautherin commented Jan 8, 2020

Oh, I thought I could use it for cross-compiling, actually. I guess I got confused because I’m using dockcross, and I’m not used to running Docker on arm devices 😆 .

hrw commented Jan 8, 2020

@JonasVautherin and I am not used to running Docker on x86 ;D

JonasVautherin commented Jan 8, 2020

@hrw: I am now wondering how one would create a dockcross/manylinux2014-aarch64 image (i.e. one that would actually cross-compile). I opened an issue in the dockcross repo, if you (or somebody else) have insights.

My understanding is that pypa/manylinux2014-aarch64 uses CentOS 7 as a base image, but if I wanted to cross-compile, I would need to import a toolchain from that, somehow.

hrw commented Jan 8, 2020

I never heard of dockcross before.

There are several CI options available with AArch64 support. AWS has EC2 instances etc.

storkinsj commented May 26, 2020

Hey folks, FYI I saw an answer on stackexchange recently that seemed to nail this redherring error message. In their case, and in my case, the problem was that the execute permission was not set on the execution target. You may want to chmod+x to the execution target in your Dockerfile/Docker build and try again.

formigone commented Jun 29, 2020

Hey folks, FYI I saw an answer on stackexchange recently that seemed to nail this redherring error message. In their case, and in my case, the problem was that the execute permission was not set on the execution target. You may want to chmod+x to the execution target in your Dockerfile/Docker build and try again.

To build off that, if your execution target happens to be a shell script of the likes, be sure that you also have a shebang appropriate to that.

JonasVautherin commented Jun 29, 2020

ShaneHarvey commented Jul 23, 2020

exec user process caused «exec format error» means «you are trying to run container for other architecture. «quay.io/pypa/manylinux2014_aarch64» can be run on aarch64

@hrw this cannot be true, can it? I can run the manylinux2014_aarch64 image successfully on my macOS which is x86_64 not aarch64:

I can also run manylinux2014_ppc64le and manylinux2014_s390x too:

rehadiri commented Aug 16, 2020

I am trying to install Mavsdk on Raspberry pi 4 Raspberry OS Buster Lite. I have installed and checked the docker. It works fine . After that i entered the following command

docker run —rm dockcross/linux-armv7 > ./dockcross-linux-armv7

It installed the dockcross/linux-armv7 image on the docker
But at the end i have got «standard_init_linux.go:211: exec user process caused «exec format error»

I have looked at the dockcross-linux-armv7 in the MAVSDK folder . Its empty , 0 bytes.

What can go wrong here ?
Thanks
Best Regards
Reha

tedz2usa commented Jul 20, 2021 •

I’m new to making Docker containers work cross-platform, especially using an Apple M1-chip laptop for development. But so far what worked for me is to specify the platform linux/amd64 during the build step.

Even better, to help me know that a build is for that platform, I’ll give this specific image a tag of the string «amd64»:

My comment is not necessarily related to the pypa project, but just wanted to mention how I solved (worked around) the standard_init_linux.go:211: exec user process caused «exec format error» error.

I’m able to then run MY_IMAGE_NAME:amd64 on my laptop (I have rosetta enabled in my laptop’s terminal) and on standard x86 cloud servers.

Источник

standard_init_linux.go:211:exec user process caused «no such file or directory» with alpine linux and python

I have a directory which contains the docker file, a attack.py and a requirements.txt.

Using that, I created the following dockerfile:

However, the pip install line throws: standard_init_linux.go:211:exec user process caused «no such file or directory»

I can’t figure out why. Using commands like ls, pwd and so on in an attempt to debug this yields the same error.

Can anyone explain what exactly I am doing wrong?

1 Answer 1

I guess you are trying to build the docker image on a non-arm64v8 platform. I would assume that for the rest of the answer.

The solution provided will be specific for Ubuntu distribution (host), but I guess it should be similar on other linux distribution.

SOLUTION 1 [working on Ubuntu 18.04]

From https://github.com/docker/for-linux/issues/56 we can see that there is bug currently in the packages for Debian (and thus Ubuntu?).

This will remove the qemu-user-binfmt method from solution 2. However in that package the provided configuration files are not in the folder, and missconfigured, to be used by systemd-binfmt .

Also, we get the configuration files from a git repository and place them in a folder where the systemd-binfmt looks into: /lib/binfmt.d/ (not /var/lib/binfmts/ as install by qemu-user-static)

Then check the status:

And try to compile your docker again. It should work!

SOLUTION 2 [not currently working on Ubuntu 18.04]

It used to be a manually configuration process on previous, but now it is supported via a apt package:

With that it will create the binfmt configuration for all platforms under /proc/sys/fs/binfmt_misc/qemu-* . And when your system detects that the executable is for arm, it will call qemu instead of trying to execute directly.

To understand how it works, it is good to the following paragraph:

The kernel recognizes the ARM ELF magic, and uses the interpreter /usr/bin/qemu-arm-static , which is the correct QEMU binary for the architecture. 0x7F ‘ELF’ in hexadecimal is 7f 45 4c 46 , so we can see how the magic and the mask work together, considering the structure of the ELF header

Note that the binfmt configuration is shared by docker, therefore it will trying to get the /usr/bin/qemu-arm-static inside the container. And that is the reason you still need to copy the /usr/bin/qemu-arm-static.

Источник

standard_init_linux.go:211: exec user process caused «exec format error»

I am running the same Dockerfile on two basically identical Linux machines. It works on one side, it fails on the other, with the message:

I reduced the Dockerfile to a minimum:

The system information of machine 1:

docker version

docker system info

Further information

The system information of machine 2:

docker version

docker system info

Further information:

The first one (on a Jenkins server) is working correctly, while the second one fails with the given error. What could be the issue? I am out of ideas! Thanks!

1 Answer 1

From the tag on your image, it looks like you are trying to run ARM based binaries on a x86 based host. This typically won’t work without something to interpret the binary. On Linux there’s Qemu plus the binfmt_misc kernel module that provides this support. You also need the various static binfmt binaries from qemu to enable this per architecture.

On Debian the static binaries are available in the qemu-user-static package with one catch. At last check in stable, Debian doesn’t load these binaries in a way that supports a chroot type of environment like you have in Debian, it will look for the qemu static binaries inside the container rather than using the files on the host. See this issue and consider installing the binaries in a different way or use an unstable version.

When you have everything configured correctly, you should see the following:

Two important things to look for, first that the binfmt_misc and qemu-arm directory and file exist. And second, that the flags section includes a F to indicate the binaries is fixed and won’t be affected by the container root filesystem changing.

Источник

Docker buildx with node app on Apple M1 Silicon — standard_init_linux.go:211: exec user process caused «exec format error

I am trying to deploy a docker image to a kuebernetes clusters. No problem until I switched to new Macbook Pro with M1.

Once I build the image on the m1 machine and deploy I get the following error from the kuebernetes pod: standard_init_linux.go:211: exec user process caused «exec format error»

After doing some research, I followed this medium post on getting docker buildx added and set up.

Once I build a new image using the new buildx and run it locally using the docker desktop (the m1 compatible preview version), it runs without issue. However the kubernetes pod still shows the same error. standard_init_linux.go:211: exec user process caused «exec format error»

My build command
docker buildx use m1_builder && docker buildx build —platform linux/amd64,linux/arm64,linux/arm/v7,linux/arm/v6 -f Dockerfile -t $ —push . ‘
During the build I see each platform logging out that it is running the commands from my Dockerfile.

My push command
docker push $ One odd thing to note is the sha256 digest in the docker push command response does not change.

Here is my docker file:

I am no docker expert, clearly. Started with a full head of hair. Down to 3 strands. Please save those 3 strands.

I appreciate all help and advice!

Update

I have pulled the image built by the M1 macbook down to my other macbook and could run the image locally via docker desktop. I am not sure what this means. Could it be just a kuebernetes setting?

Источник