Docker: exec /usr/bin/sh: exec格式错误

Question

Docker: exec /usr/bin/sh: exec格式错误

dockergitlabgitlab-cigitlab-ci-runnerdockerhub

83

我创建了一个自定义的Docker镜像并将其推送到Docker Hub，但是当我在CI/CD中运行它时，出现了以下错误。

exec /usr/bin/sh: exec format error 错误发生在：

Dockerfile

FROM ubuntu:20.04
RUN apt-get update
RUN apt-get install -y software-properties-common
RUN apt-get install -y python3-pip
RUN pip3 install robotframework

.gitlab-ci.yml

robot-framework:
  image: rethkevin/rf:v1
  allow_failure: true
  script:
    - ls
    - pip3 --version

输出

Running with gitlab-runner 15.1.0 (76984217)
  on runner zgjy8gPC
Preparing the "docker" executor
Using Docker executor with image rethkevin/rf:v1 ...
Pulling docker image rethkevin/rf:v1 ...
Using docker image sha256:d2db066f04bd0c04f69db1622cd73b2fc2e78a5d95a68445618fe54b87f1d31f for rethkevin/rf:v1 with digest rethkevin/rf@sha256:58a500afcbd75ba477aa3076955967cebf66e2f69d4a5c1cca23d69f6775bf6a ...
Preparing environment
00:01
Running on runner-zgjy8gpc-project-1049-concurrent-0 via 1c8189df1d47...
Getting source from Git repository
00:01
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /builds/reth.bagares/test-rf/.git/
Checking out 339458a3 as main...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:00
Using docker image sha256:d2db066f04bd0c04f69db1622cd73b2fc2e78a5d95a68445618fe54b87f1d31f for rethkevin/rf:v1 with digest rethkevin/rf@sha256:58a500afcbd75ba477aa3076955967cebf66e2f69d4a5c1cca23d69f6775bf6a ...
exec /usr/bin/sh: exec format error
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1

有没有关于解决这个错误的想法？

- rkevx21

你能提供完整的作业日志输出吗？ - sytech

7

该错误意味着架构不正确，例如arm64代码试图在x86-64系统上运行。 - jordanm

7个回答

43

在我的情况下，我是使用buildx进行构建的。

docker buildx build --platform linux/amd64 -f ./Dockerfile -t image .

然而问题出在 AWS Lambda 上

- MMSA

12

在使用容器时出现错误的原因可能有很多：

使用错误的脚本头，例如在其中添加空格。
在编写脚本时使用不兼容的字符编码
不匹配的 CPU 架构
缺少文件权限

以下是使用示例演示第三个原因：

rohits-MacBook> catalog % docker version

我的笔记本电脑是 darwin/arm64 架构，并安装了相同的 Docker 引擎。

Client:
 Cloud integration: v1.0.31
 Version:           20.10.23
 API version:       1.41
 Go version:        go1.18.10
 Git commit:        7155243
 Built:             Thu Jan 19 17:35:19 2023
 OS/Arch:           darwin/arm64
 Context:           desktop-linux
 Experimental:      true

Server: Docker Desktop 4.17.0 (99724)
 Engine:
  Version:          20.10.23
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.10
  Git commit:       6051f14
  Built:            Thu Jan 19 17:31:28 2023
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.18
  GitCommit:        2456e983eb9e37e47538f59ea18f2043c9a73640
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

#################################################

在我的当前笔记本上执行

rohits-MacBook> catalog % make image

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build  -ldflags="-X github.ibm.com/cloud-sre/version.Major= -X github.ibm.com/cloud-sre/version.Minor= -X github.ibm.com/cloud-sre/version.Build= -X github.ibm.com/cloud-sre/version.Timestamp=202303170049" -o osscatimporter ./cmd/osscatimporter
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build  -ldflags="-X github.ibm.com/cloud-sre/version.Major= -X github.ibm.com/cloud-sre/version.Minor= -X github.ibm.com/cloud-sre/version.Build= -X github.ibm.com/cloud-sre/version.Timestamp=202303170049" -o osscatpublisher ./cmd/osscatpublisher
jq: error: Could not open file metadata.json: No such file or directory
docker buildx build --platform=linux/amd64 -t api-osscatalog:latest .
[+] Building 153.2s (11/11) FINISHED                                                                                                                         
 => [internal] load build definition from Dockerfile                                                                                                    0.0s
 => => transferring dockerfile: 560B                                                                                                                    0.0s
 => [internal] load .dockerignore                                                                                                                       0.0s
 => => transferring context: 2B                                                                                                                         0.0s
 => [internal] load metadata for docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7                                            34.2s
 => [auth] ubi8/ubi-minimal:pull token for docker-virtual.artifactory.swg-devops.com                                                        0.0s
 => [1/5] FROM docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7@sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e1625  91.3s
 => => resolve docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7@sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e16251  0.0s
 => => sha256:0214a28336e387c66493c61bb394e86a18f3bea8dbc46de74a26f173ff553c89 429B / 429B                                                              0.0s
 => => sha256:591670a5d6a620931ec51c1e7436300894f5320e76e9737f0366fc62114addd4 6.23kB / 6.23kB                                                          0.0s
 => => sha256:d7c06497d5cebd39c0a4feb14981ec940b5c863e49903d320f630805b049cbff 39.28MB / 39.28MB                                                       90.8s
 => => sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e16251f3c6dee087a 1.47kB / 1.47kB                                                          0.0s
 => => extracting sha256:d7c06497d5cebd39c0a4feb14981ec940b5c863e49903d320f630805b049cbff                                                               0.4s
 => [internal] load build context                                                                                                                       0.2s
 => => transferring context: 23.77MB                                                                                                                    0.2s
 => [2/5] RUN microdnf update && microdnf install procps ;                                                                                             27.5s
 => [3/5] COPY osscatimporter /                                                                                                                         0.0s
 => [4/5] COPY mailtemplate.tmpl /                                                                                                                      0.0s
 => [5/5] COPY osscatpublisher /                                                                                                                        0.0s 
 => exporting to image                                                                                                                                  0.1s 
 => => exporting layers                                                                                                                                 0.1s 
 => => writing image sha256:8af2a24809c709c2ea80b1f3ed0c0d1dc1381c84219e0e779be43ab8542e8c0d                                                            0.0s 
 => => naming to docker.io/library/api-osscatalog:latest                                                                                                0.0s

##############################

rohits-MacBook> catalog % docker images

罗希特的MacBook>目录％docker镜像

REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
api-catalog     latest    8af2a24809c7   9 seconds ago   140MB

######################################

rohits-MacBook> osscatalog％docker image inspect api-catalog

罗希特的MacBook> osscatalog％docker镜像检查api目录


        "Architecture": "arm64",
        "Os": "linux",
        "Size": 148693891,
        "VirtualSize": 148693891,

生成一个 arm64 镜像

########################################

运行实例后出现的问题，其日志文件显示如下：

rohits-MacBook> api-osscatalog % kubectl -n api logs -f catimporter-rohit-gst45

exec /bin/sh: exec format error
rohits-MacBook> api-catalog %

这种情况通常发生在你正在使用ARM架构的系统上开发项目，比如新的Apple M系列芯片。当你将代码推送到使用x86系统的生产环境时，就会出现“exec user process caused：exec format error”的错误。这是因为每个代码在转换为低级指令时，在ARM和x86上都不同。Docker将Apple M1 Pro平台检测为“linux/arm64/v8”。

################## 解决方案 ########################

1. /cloud-sre/catalog/Makefile 更改： docker build -t $(IMAGE_NAME):latest . 为： docker buildx build --platform=linux/amd64 -t $(IMAGE_NAME):latest .

但是要使上述方法生效，还需要更改Dockerfile /cloud-sre/catalog/Dockerfile 更改： FROM docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7 为： FROM --platform=linux/amd64 docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7

#################### 测试 ######################

rohits-MacBook> catalog % docker images

REPOSITORY   TAG       IMAGE ID   CREATED   SIZE

删除了所有图片

#####################################

rohits-MacBook> catalog % rohits-MacBook> catalog % make image

罗希特的MacBook>目录% 罗希特的MacBook>目录%制作图像

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build  -ldflags="-X github.ibm.com/cloud-sre/version.Major= -X github.ibm.com/cloud-sre/version.Minor= -X github.ibm.com/cloud-sre/version.Build= -X github.ibm.com/cloud-sre/version.Timestamp=202303170049" -o osscatimporter ./cmd/osscatimporter
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build  -ldflags="-X github.ibm.com/cloud-sre/version.Major= -X github.ibm.com/cloud-sre/version.Minor= -X github.ibm.com/cloud-sre/version.Build= -X github.ibm.com/cloud-sre/version.Timestamp=202303170049" -o osscatpublisher ./cmd/osscatpublisher
jq: error: Could not open file metadata.json: No such file or directory
docker buildx build --platform=linux/amd64 -t api-osscatalog:latest .
[+] Building 153.2s (11/11) FINISHED                                                                                                                         
 => [internal] load build definition from Dockerfile                                                                                                    0.0s
 => => transferring dockerfile: 560B                                                                                                                    0.0s
 => [internal] load .dockerignore                                                                                                                       0.0s
 => => transferring context: 2B                                                                                                                         0.0s
 => [internal] load metadata for docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7                                            34.2s
 => [auth] ubi8/ubi-minimal:pull token for docker-virtual.artifactory.swg-devops.com                                                        0.0s
 => [1/5] FROM docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7@sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e1625  91.3s
 => => resolve docker-virtual.artifactory.swg-devops.com/ubi8/ubi-minimal:8.7@sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e16251  0.0s
 => => sha256:0214a28336e387c66493c61bb394e86a18f3bea8dbc46de74a26f173ff553c89 429B / 429B                                                              0.0s
 => => sha256:591670a5d6a620931ec51c1e7436300894f5320e76e9737f0366fc62114addd4 6.23kB / 6.23kB                                                          0.0s
 => => sha256:d7c06497d5cebd39c0a4feb14981ec940b5c863e49903d320f630805b049cbff 39.28MB / 39.28MB                                                       90.8s
 => => sha256:65a240ad8bd3f2fff3e18a22ebadc40da0b145616231fc1e16251f3c6dee087a 1.47kB / 1.47kB                                                          0.0s
 => => extracting sha256:d7c06497d5cebd39c0a4feb14981ec940b5c863e49903d320f630805b049cbff                                                               0.4s
 => [internal] load build context                                                                                                                       0.2s
 => => transferring context: 23.77MB                                                                                                                    0.2s
 => [2/5] RUN microdnf update && microdnf install procps ;                                                                                             27.5s
 => [3/5] COPY osscatimporter /                                                                                                                         0.0s
 => [4/5] COPY mailtemplate.tmpl /                                                                                                                      0.0s
 => [5/5] COPY osscatpublisher /                                                                                                                        0.0s 
 => exporting to image                                                                                                                                  0.1s 
 => => exporting layers                                                                                                                                 0.1s 
 => => writing image sha256:8af2a24809c709c2ea80b1f3ed0c0d1dc1381c84219e0e779be43ab8542e8c0d                                                            0.0s 
 => => naming to docker.io/library/api-osscatalog:latest                                                                                                0.0s

##############################################

rohits-MacBook> catalog % docker images

罗希特的MacBook>目录％docker镜像

REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
api-catalog   latest    8af2a24809c7   9 seconds ago   140MB

################################################ rohits-MacBook> catalog % docker image inspect api-catalog:latest

################################################ rohits-MacBook>目录％docker image inspect api-catalog：latest


        "Architecture": "amd64",
        "Os": "linux",
        "Size": 140425582,

这是我以前的笔记本电脑经常使用的。

############################################

现在正在检查新实例的日志：

rohits-MacBook> api-ocatalog % kubectl -n api logs -f catimporter-rohit-9bzk9

INFO  19:53:29 osscatimporter Version: .. - 202303170049
INFO  19:53:29 sending *osscatimporter* Starting Run osscatimporter using the slack-webhook-url Slack webhook key.
Test COS connection passed: oss-rmc-data-test
Test COS connection passed: oss-rmc-emergency-test
AUDIT 19:53:30 Operating in read-only mode on all services and components found from all sources (with visibility=private and above)
INFO  19:53:30 Forcing -check-owner=true
INFO  19:53:30 Optional run action ENABLED:  Services
INFO  19:53:30 Optional run action ENABLED:  Tribes
INFO  19:53:30 Optional run action ENABLED:  Environments
INFO  19:53:30 Optional run action ENABLED:  Deployments
INFO  19:53:30 Optional run action ENABLED:  Monitoring
INFO  19:53:30 Optional run action ENABLED:  RMC
INFO  19:53:30 Optional run action ENABLED:  RMC-Rescan
INFO  19:53:30 Optional run action DISABLED: Environments-Native
INFO  19:53:30 Optional run action DISABLED: ProductInfo-Parts
INFO  19:53:30 Optional run action DISABLED: ProductInfo-Parts-Refresh
INFO  19:53:30 Optional run action DISABLED: ProductInfo-ClearingHouse
INFO  19:53:30 Optional run action DISABLED: Dependencies-ClearingHouse
INFO  19:53:30 Optional run action DISABLED: ScorecardV1
INFO  19:53:30 Optional run action DISABLED: Doctor
INFO  19:53:30 Skip reloading Segment and Tribe Info from ScorecardV1

没有错误

- Rohit Basu

6

对于在AWS codebuild上遇到类似错误的开发人员 -

当我使用AWS codebuild时出现了这个错误，问题在于在构建阶段和部署阶段使用了不同的架构。我的构建阶段正在使用arm64架构构建Docker镜像，并将它们部署在EC2上，而该EC2是在_x8664架构下运行的。将构建架构更改为_x8664就解决了这个问题。

- Deepanshu Narwat

4

你还应该确保你所调用的是可执行文件。我们曾经犯过这个错误：

COPY --from=build /usr/src/service/serviceExec /bin/service 
COPY --from=build /usr/config/file.txt /bin/service
RUN chmod a+x service
CMD ["./service"]

错误信息为：

exec ./service: exec format error

操作系统无法执行txt文件，抛出了类似架构的错误。

- RicHincapie

3

我之所以出现这个错误，是因为我试图在顶部执行一个没有shebang行的Bash脚本。

我通过在文件顶部添加shebang行来解决了这个问题：

#!/bin/bash
...

- Stanley Ulili

0

如果您在使用运行在arm64架构上的GitLab Runner时遇到此错误，这里有一个使用arm64二进制文件的GitLab CI/CD流水线的解决方案。

release-tag:
  stage: release
  tags:
    - my-runner
  rules:
    - if: $CI_COMMIT_TAG
  environment: production
  before_script:
    - 'command -v wget >/dev/null || ( apt-get update -y && apt-get install wget -y )'
    - wget -O release-cli https://gitlab.com/gitlab-org/release-cli/-/releases/v0.16.0/downloads/bin/release-cli-linux-arm64
    - chmod +x release-cli
  script:
    - echo "Creating release for tag $CI_COMMIT_TAG"
    - >
      ./release-cli
      --job-token=$CI_JOB_TOKEN
      --project-id $CI_PROJECT_ID
      --server-url https://gitlab.com
      create
      --name "Release $CI_COMMIT_TAG"
      --description "Version $CI_COMMIT_TAG released on $(date '+%m-%d-%Y at %H:%M:%S') from pipeline $CI_PIPELINE_ID details $CI_PIPELINE_URL"
      --tag-name $CI_COMMIT_TAG
      --released-at $(date -u +"%Y-%m-%dT%H:%M:%SZ")

- tchartron

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- sytech · Accepted Answer

问题是你为arm64/v8构建了这个镜像，但是你的运行环境使用了不同的架构。

如果你运行：

docker image inspect rethkevin/rf:v1

你将在输出中看到这个：

...
        "Architecture": "arm64",
        "Variant": "v8",
        "Os": "linux",
...

尝试从GitLab CI runner构建和推送您的镜像，以便镜像的架构与runner的架构相匹配。

或者，您可以使用docker buildx来构建多个架构。另外，您还可以在ARM架构上运行一个GitLab runner，以便它可以在您构建的架构上运行镜像。

使用现代版本的Docker，您还可以明确控制Docker使用的平台。如果指定的平台与您的本机平台不同，Docker将使用平台仿真。

例如：

使用DOCKER_DEFAULT_PLATFORM环境变量：

DOCKER_DEFAULT_PLATFORM="linux/amd64" docker build -t test .

使用--platform参数，无论是在命令行界面还是在您的dockerfile中：

docker build --platform="linux/amd64" -t test .

FROM --platform=linux/amd64 ubuntu:jammy

如果您的系统已安装了Docker Desktop，那么应该已经可以执行此操作了。如果您的系统使用的是没有Docker Desktop的Docker版本，您可能需要显式地安装docker-buildx插件。

Docker: exec /usr/bin/sh: exec格式错误

运行实例后出现的问题，其日志文件显示如下：

评论：