error while loading shared libraries: libc.so.6: cannot open shared object file

Question

I have a Linux kernel and I chroot it on /var/chroot:

I added bash dependencies like so:

ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fff9a373000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f24d57af000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f24d55ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f24d51eb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f24d59f8000)

Then I did:

# cd /var/chroot/
# mkdir bin/ lib64/ lib/
# cp /lib/x86_64-linux-gnu/libtinfo.so.5 lib/
# cp /lib/x86_64-linux-gnu/libdl.so.2 lib/
# cp /lib/x86_64-linux-gnu/libc.so.6 lib/
# cp /lib64/ld-linux-x86-64.so.2 lib64/
# cp /bin/bash bin/

after that:

# chroot /var/chroot

After that I copied /bin/ls and the libraries shown by ldd ls. But when I run ls I have the following error:

ls: error while loading shared libraries: libpthread.so.0: wrong ELF class: ELFCLASS32

Solution 1

Since you were apparently able to launch bash, you have the basics right: you need to copy all the libraries listed by ldd /bin/command to a directory on the library load path, plus the loader itself (/lib64/ld-linux-x86-64.so.2) which needs to be at the location hard-coded in the executables.

If you get the error

error while loading shared libraries: libc.so.6: cannot open shared object file

then you're missing the library indicated here. Check that you put it in the correct directory under its correct name. Check that you copied the library file and not just a symbolic link to it.

If you get the error

ls: error while loading shared libraries: libpthread.so.0: wrong ELF class: ELFCLASS32

then you copied a library for the wrong architecture — you must have copied a 32-bit libpthread.so.0, but you're running a 64-bit library.

If you're having further issues, it may help to find out exactly where the loader attempts to find libraries. Put an strace binary in the chroot (either a statically-compiled one, or a dynamically-compiled one plus all the libraries it needs), and run chroot ls and see what exactly is failing. Or run strace chroot ls to use the strace binary that's outside the chroot.

Solution 2

Careful. Shared library files are usually symlinked. This way the current version can be changed and all the installed applications can still find it. For instance, on my system:

ls -l /usr/lib/libc.so.6
lrwxrwxrwx 1 root root 12 dec 27 03:13 /usr/lib/libc.so.6 -> libc-2.20.so*

So libc.so.6 actually points to the current libc version, and when I update the system, it will point to the new version, whatever it is. There are frequenly multiple levels of linking.

You need to copy the actual libraries, not just links.

Solution 3

try

mkdir lib/x86_64-linux-gnu
cp /lib/x86_64-linux-gnu/libtinfo.so.5  /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 lib/x86_64-linux-gnu

If you whish to use commands like ls, you also have to ldd /bin/ls and copy library file.

by the way, cp will copy the content of a symbolic link.

Comments

[Alen Milakovic]

There are standard ways to create chroots. I recommend you use them. The details depend to some extent on your distribution, which you have not stated.

[yorkshiredev]

It would probably be more useful to have the ldd output of the chrooted executable instead, since it's the one which is causing trouble... Besides, there doesn't seem to be any "no such file in directory" error involved.

[MLSC]

Thank you... I copied the output of ldd /bin/ls but I can't run ls command... :(

[MLSC]

The error: ls: error while loading shared libraries: libpthread.so.0: wrong ELF class: ELFCLASS32

[Gilles 'SO- stop being evil']

cp copies the link target, so that part's ok.