码头工人-/ bin / sh:< file>找不到-错误的ELF解释器-如何向Docker映像添加32位库支持 [英] Docker - /bin/sh: <file> not found - bad ELF interpreter - how to add 32bit lib support to a docker image

查看:91
本文介绍了码头工人-/ bin / sh:< file>找不到-错误的ELF解释器-如何向Docker映像添加32位库支持的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

更新 –旧问题标题:

Docker-如何在Docker构建期间执行解压缩/解压/提取的二进制文件(将文件添加至Docker构建上下文)

-

我一直在尝试(半天:P)执行一个

I've been trying (half a day :P) to execute a binary extracted during docker build.

我的dockerfile大致包含:

My dockerfile contains roughly:

...
COPY setup /tmp/setup
RUN \
unzip -q /tmp/setup/x/y.zip -d /tmp/setup/a/b
...

在目录 b 中二进制文件 imcl

我遇到的错误是:

/bin/sh: 1: /tmp/setup/a/b/imcl: not found

令人困惑的是,在尝试执行二进制文件之前,显示目录 b (在构建过程中,位于dockerfile中),显示正确的文件位置:

What was confusing, was that displaying the directory b (inside the dockerfile, during build) before trying to execute the binary, showed the correct file in place:

RUN ls -la /tmp/setup/a/b/imcl  
-rwxr-xr-x  1 root root 63050 Aug  9  2012 imcl

RUN file /tmp/setup/a/b/imcl  
ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped` 

最初是Unix菜鸟我以为这是一个权限问题(主机的根与容器的根或其他东西不同),但是在检查后,两者的UID均为0,因此更奇怪。

Being a Unix noob at first I thought it was a permission issue (root of the host being different than root of the container or something) but, after checking, the UID was 0 for both so it got even weirder.

Docker要求不使用 sudo,所以我尝试了与su组合:

Docker asks not to use sudo so I tried with su combinations:

su - -c "/tmp/setup/a/b/imcl"
su - root -c "/tmp/setup/a/b/imcl"

以下两个均返回:

stdin: is not a tty
-su: /tmp/setup/a/b: No such file or directory

好吧,我什至去挑战了Docker的建议并改变了我从debian:jessie到 bloatish ubuntu:14.04的基本图像,所以我可以尝试使用sudo:D

Well heck, I even went and defied Docker recommendations and changed my base image from debian:jessie to the bloatish ubuntu:14.04 so I could try with sudo :D

猜猜结果如何?

sudo: unable to execute /tmp/setup/a/b/imcl: No such file or directory

随机搜索我偶然发现了一块Docker文档我认为这是所有原因的原因:
注意:如果文件或目录在上载的上下文中不存在,则docker build将不会返回此类文件或目录错误。如果没有上下文,或者您指定了主机系统上其他位置的文件,则可能会发生这种情况。出于安全原因,上下文仅限于当前目录(及其子目录),并确保在远程Docker主机上可重复构建。这也是添加../file无法正常工作的原因。

Randomly googling I happened upon a piece of Docker docs which I believe is the reason to all this head bashing: "Note: docker build will return a no such file or directory error if the file or directory does not exist in the uploaded context. This may happen if there is no context, or if you specify a file that is elsewhere on the Host system. The context is limited to the current directory (and its children) for security reasons, and to ensure repeatable builds on remote Docker hosts. This is also the reason why ADD ../file will not work."

所以我的问题是:


  • 是否有解决方法?

  • 是否有一种方法可以在提取过程中将提取的文件添加到docker build上下文中构建(在dockerfile中)?

哦,我正在构建的机器未连接到互联网...

Oh and the machine I'm building this is not connected to the internet...

我想我要问的与此类似(尽管我看不到答案):

如何在Docker构建上下文之外包含文件?

I guess what I'm asking is similar to this (though I see no answer):
How to include files outside of Docker's build context?

所以我不走运吗?

在将构建上下文发送到Docker守护程序之前,是否需要使用shell脚本解压缩,以便所有文件都被正确使用

Do I need to unzip with a shell script before sending the build context to Docker daemon so all files are used exactly as they were during build command?

更新:

Meh,实际上不是问题所在。我对此进行了测试,并能够在docker build期间执行解压缩的二进制文件。

UPDATE:
Meh, the build context actually wasn't the problem. I tested this and was able to execute unpacked binary files during docker build.

我的问题实际上是这个:
CentOS 64位糟糕的ELF解释器

My problem is actually this one: CentOS 64 bit bad ELF interpreter

使用debian:jessie和ubuntu:14.04作为基础图像仅给出没有这样的文件或目录错误,但尝试使用centos:7和fedora:23给出了更好的错误消息:

Using debian:jessie and ubuntu:14.04 as base images only gave No such file or directory error but trying with centos:7 and fedora:23 gave a better error message:

/bin/sh: /tmp/setup/a/b/imcl: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

因此,我得出的结论是,这实际上是在64位计算机上运行32位应用程序的问题位系统。

So that led me to the conclusion that this is actually the problem of running a 32-bit application on a 64-bit system.

现在,如果启用了Internet访问和回购协议,解决方案将很简单:

Now the solution would be simple if I had internet access and repos enabled:

apt-get install ia32-libs

Or

yum install glibc.i686

但是,我不...:[

所以问题就变成了:


  • 那会是什么在没有回购协议或互联网连接的情况下达到相同结果的最佳方法?

根据 IBM ,我需要的确切库是gtk2.i686和libXtst.i686,可能还有libstdc ++

According to IBM, the precise libraries I need are gtk2.i686 and libXtst.i686 and possibly libstdc++

[root@localhost]# yum install gtk2.i686
[root@localhost]# yum install libXtst.i686
[root@localhost]# yum install compat-libstdc++


推荐答案


更新:

所以问题就变成了:


  • 在没有回购或互联网连接的情况下达到相同结果的最佳方法是什么?

您可以使用DockerHub上可用的各种非官方32位映像,搜索 debian32 ubuntu32 fedora32 等。

You could use various non-official 32-bit images available on DockerHub, search for debian32, ubuntu32, fedora32, etc.

如果不能相信他们,您可以自己构建这样的映像,也可以在DockerHub上找到说明,例如:

If you can't trust them, you can build such an image by yourself, and you can find instruction on DockerHub too, e.g.:


  • f69m / ubuntu32 主页,有指向<一个用于生成图像的href = https://github.com/f69m/docker-ubuntu32 rel = nofollow noreferrer> GitHub存储库;
  • $ a $ b
  • hugodby / fedora32 主页,

  • 等等。

  • on f69m/ubuntu32 home page, there is a link to GitHub repo used to generate images;
  • on hugodby/fedora32 home page, there is an example of commands used to build the image;
  • and so on.

或者,您可以根据一些官方映像准备自己的映像,并向其中添加32位软件包。

Alternatively, you can prepare your own image based on some official image and add 32-bit packages to it.

说,您可以使用 Dockerfile 像这样:

Say, you can use a Dockerfile like this:

FROM debian:wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -y ia32-libs

...并使用生成的映像作为基础(带有 FROM 指令)来构建您无法访问互联网的图像。

...and use produced image as a base (with FROM directive) for images you're building without internet access.

您甚至可以创建在DockerHub上自动构建,当 Dockerfile (例如在GitHub上发布)或主线图像(在上面的示例中为 debian )更改。

You can even create an automated build on DockerHub that will rebuild your image automatically when your Dockerfile (posted, say, on GitHub) or mainline image (debian in the example above) changes.

无论您如何获取具有32位支持的映像(使用现有的非官方映像还是自己构建),然后都可以使用 docker save将其存储到tar存档中命令,然后使用 docker load 命令导入。

No matter how did you obtain an image with 32-bit support (used existing non-official image or built your own), you can then store it to a tar archive using docker save command and then import using docker load command.

这篇关于码头工人-/ bin / sh:&lt; file&gt;找不到-错误的ELF解释器-如何向Docker映像添加32位库支持的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆