Ld linux x86 64 so 2 bad elf interpreter

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/lib64/ld-linux-x86-64.so.2: bad ELF interpreter in (rootless) Docker containers #1220

/lib64/ld-linux-x86-64.so.2: bad ELF interpreter in (rootless) Docker containers #1220

Comments

Trying to use appimagetool in Docker containers (not sure if it’s because I’m running a rootless setup) shows a weird message: /bin/sh: ./appimagetool: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory . /lib64/ld-linux-x86-64.so.2 is a valid symlink to an existing file.

I can’t find anything on this issue, so I’m at a bit of a loss.

cat HEREDOC > ./Dockerfile FROM centos:centos7 RUN yum install -y curl RUN uname -a RUN curl -L https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage > appimagetool RUN chmod +x ./appimagetool RUN ls -l /lib64/ld-linux-x86-64.so.2 RUN ls -l /lib64/ld-2.17.so RUN ./appimagetool --appimage-extract HEREDOC docker build . --no-cache

Step 3/8 : RUN uname -a ---> Running in 6129f14a4b5c Linux 6129f14a4b5c 5.15.65-1-MANJARO #1 SMP PREEMPT Mon Sep 5 10:15:47 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Removing intermediate container 6129f14a4b5c ---> 1f64db8c7403 Step 4/8 : RUN curl -L https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage > appimagetool ---> Running in da8031e10cdc % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 8605k 100 8605k 0 0 3195k 0 0:00:02 0:00:02 --:--:-- 4565k Removing intermediate container da8031e10cdc ---> 826adff75225 Step 5/8 : RUN chmod +x ./appimagetool ---> Running in 2c9a5c57d419 Removing intermediate container 2c9a5c57d419 ---> 471a0cc22b28 Step 6/8 : RUN ls -l /lib64/ld-linux-x86-64.so.2 ---> Running in b4954282f0bd lrwxrwxrwx 1 root root 10 Nov 13 2020 /lib64/ld-linux-x86-64.so.2 -> ld-2.17.so Removing intermediate container b4954282f0bd ---> a267226f2667 Step 7/8 : RUN ls -l /lib64/ld-2.17.so ---> Running in 57edd3e4b516 -rwxr-xr-x 1 root root 163312 Sep 30 2020 /lib64/ld-2.17.so Removing intermediate container 57edd3e4b516 ---> 63b4b56d3936 Step 8/8 : RUN ./appimagetool --appimage-extract ---> Running in 3121b9e497af /bin/sh: ./appimagetool: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory The command '/bin/sh -c ./appimagetool --appimage-extract' returned a non-zero code: 126 

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

Источник

«/usr/bin/javac: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory»

I installed jdk1.8.0_161 in linux server RHEL 7.. I am not able to check java version due to «/usr/bin/javac: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory» below are the steps i followed to install jdk,

cd /opt/jdk1.8.0_161/ alternatives --install /usr/bin/java java /opt/jdk1.8.0_161/bin/java 2 alternatives --config java There is 1 program that provides 'java'. Selection Command ----------------------------------------------- *+ 1 /opt/jdk1.8.0_161/bin/java Enter to keep the current selection[+], or type selection number: 1 alternatives --install /usr/bin/jar jar /opt/jdk1.8.0_161/bin/jar 2 alternatives --install /usr/bin/javac javac /opt/jdk1.8.0_161/bin/javac 2 alternatives --set jar /opt/jdk1.8.0_161/bin/jar alternatives --set javac /opt/jdk1.8.0_161/bin/javac java -version -bash: /usr/bin/java: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory export JAVA_HOME=/opt/jdk1.8.0_161 export JRE_HOME=/opt/jdk1.8.0_161/jre export PATH=$PATH:/opt/jdk1.8.0_161/bin:/opt/jdk1.8.0_161/jre/bin 

1 Answer 1

Looks like you unpacked a tar.gz file in /opt/. This version is obviously trying to use the 32bits /lib/ld-linux.so.2 . (The 64bits linker is /usr/lib64/ld-linux-x86-64.so.2 -> ld-2.17.so )

# cd Downloads/ && yum install ./jdk-8u162-linux-x64.rpm

# alternatives --install /usr/bin/java java /usr/java/jdk1.8.0_162/bin/java 2 # alternatives --install /usr/bin/javac javac /usr/java/jdk1.8.0_162/bin/javac 2 # alternatives --config java # alternatives --config javac 

Источник

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

When I exectued command to install application following error accured: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory I was not aware of how to fix this problem, to find out resolution I searched for solotutions on net and found following resolution:

yum install glibc.i686 or yum install glibc.i386 

Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile Setting up Install Process No package glibc.i686 available. Error: Nothing to do 

Download glibc rpm packge for centos 6 and install them. 

glibc-2.12-1.80.el6.i686.rpm glibc-common-2.12-1.80.el6.i686.rpm glibc-devel-2.12-1.80.el6.i686.rpm glibc-headers-2.12-1.80.el6.i686.rpm glibc-static-2.12-1.80.el6.i686.rpm glibc-utils-2.12-1.80.el6.i686.rpm 

yum install glibc.i686 rpm -U glibc-2.12-1.80.el6.i686.rpm rpm -ivh glibc-2.12-1.80.el6.i686.rpm 

[root@demo tmp_glibc]# rpm -ivh glibc-2.12-1.80.el6.i686.rpm error: Failed dependencies: glibc-common = 2.12-1.80.el6 is needed by glibc-2.12-1.80.el6.i686 libfreebl3.so is needed by glibc-2.12-1.80.el6.i686 libfreebl3.so(NSSRAWHASH_3.12.3) is needed by glibc-2.12-1.80.el6.i686 

To resolve dependency problem tried to install «glibc-common-2.12-1.80.el6.i686.rpm», but again bad luck runs and gives error:

[root@demo tmp_glibc]# rpm -ivh glibc-common-2.12-1.80.el6.i686.rpm error: Failed dependencies: glibc = 2.12-1.80.el6 is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6 is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.0) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.1) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.1.1) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.1.3) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.10) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.2) is needed by glibc-common-2.12-1.80.el6.i686 libc.so.6(GLIBC_2.3) is needed by glibc-common-2.12-1.80.el6.i686 libcap.so.2 is needed by glibc-common-2.12-1.80.el6.i686 libdl.so.2 is needed by glibc-common-2.12-1.80.el6.i686 libdl.so.2(GLIBC_2.0) is needed by glibc-common-2.12-1.80.el6.i686 libdl.so.2(GLIBC_2.1) is needed by glibc-common-2.12-1.80.el6.i686 

Can anyone please help me figure out how to resolve this? More Details: Operating System: centos 6.3 Yum installed packege list:

[root@demo tmp_glibc]# yum list installed glibc Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile Installed Packages glibc.x86_64 

Источник

CentOS 64 bit bad ELF interpreter

I have just installed CentOS 6 64bit version, I’m trying to install a 32-bit application on a 64-bit machine and got this error:

9 Answers 9

You’re on a 64-bit system, and don’t have 32-bit library support installed.

To install (baseline) support for 32-bit executables

(if you don’t use sudo in your setup read note below)

Most desktop Linux systems in the Fedora/Red Hat family:

Possibly some desktop Debian/Ubuntu systems?:

Fedora or newer Red Hat, CentOS:

 sudo dnf install glibc.i686 

 sudo yum install glibc.i686 

 sudo yum install glibc.i386 

 sudo apt-get install ia32-libs 

should grab you the (first, main) library you need.

Once you have that, you’ll probably need support libs

Anyone needing to install glibc.i686 or glibc.i386 will probably run into other library dependencies, as well. To identify a package providing an arbitrary library, you can use

if you’re not sure it’s in /usr/bin you can also fall back on

The output will look like this:

 linux-gate.so.1 => (0xf7760000) libpthread.so.0 => /lib/libpthread.so.0 (0xf773e000) libSM.so.6 => not found 

Check for missing libraries (e.g. libSM.so.6 in the above output), and for each one you need to find the package that provides it.

Commands to find the package per distribution family

Fedora/Red Hat Enterprise/CentOS:

 dnf provides /usr/lib/libSM.so.6 

 yum provides /usr/lib/libSM.so.6 

first, install and download the database for apt-file

 sudo apt-get install apt-file && apt-file update 

Note the prefix path /usr/lib in the (usual) case; rarely, some libraries still live under /lib for historical reasons … On typical 64-bit systems, 32-bit libraries live in /usr/lib and 64-bit libraries live in /usr/lib64 .

(Debian/Ubuntu organise multi-architecture libraries differently.)

Installing packages for missing libraries

The above should give you a package name, e.g.:

libSM-1.2.0-2.fc15.i686 : X.Org X11 SM runtime library Repo : fedora Matched from: Filename : /usr/lib/libSM.so.6 

In this example the name of the package is libSM and the name of the 32bit version of the package is libSM.i686 .

You can then install the package to grab the requisite library using pkcon in a GUI, or sudo dnf/yum/apt-get as appropriate…. E.g pkcon install libSM.i686 . If necessary you can specify the version fully. E.g sudo dnf install ibSM-1.2.0-2.fc15.i686 .

Some libraries will have an “epoch” designator before their name; this can be omitted (the curious can read the notes below).

Notes

Warning

Incidentially, the issue you are facing either implies that your RPM (resp. DPkg/DSelect) database is corrupted, or that the application you’re trying to run wasn’t installed through the package manager. If you’re new to Linux, you probably want to avoid using software from sources other than your package manager, whenever possible.

If you don’t use «sudo» in your set-up

every time you see sudo , eg,

su -c dnf install glibc.i686 

About the epoch designator in library names

The “epoch” designator before the name is an artifact of the way that the underlying RPM libraries handle version numbers; e.g.

2:libpng-1.2.46-1.fc16.i686 : A library of functions for manipulating PNG image format files Repo : fedora Matched from: Filename : /usr/lib/libpng.so.3 

Here, the 2: can be omitted; just pkcon install libpng.i686 or sudo dnf install libpng-1.2.46-1.fc16.i686 . (It vaguely implies something like: at some point, the version number of the libpng package rolled backwards, and the “epoch” had to be incremented to make sure the newer version would be considered “newer” during updates. Or something similar happened. Twice.)

Updated to clarify and cover the various package manager options more fully (March, 2016)

Источник