When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you’re executing.
- The loader of a dynamically-linked native executable is the part of the system that’s responsible for loading dynamic libraries. It’s something like
/lib/ld-linux.so.2, and should be an executable file.
- The loader of a script is the program mentioned on the shebang line, e.g.
/bin/shfor a script that begins with
#!/bin/sh. (Bash and zsh give a message “bad interpreter” instead of “command not found” in this case.)
The error message is rather misleading in not indicating that the loader is the problem. Unfortunately, fixing this would be hard because the kernel interface only has room for reporting a numeric error code, not for also indicating that the error in fact concerns a different file. Some shells do the work themselves for scripts (reading the
#! line on the script and re-working out the error condition), but none that I’ve seen attempt to do the same for native binaries.
ldd won’t work on the binaries either because it works by setting some special environment variables and then running the program, letting the loader do the work.
strace wouldn’t provide any meaningful information either, since it wouldn’t report more than what the kernel reports, and as we’ve seen the kernel can’t report everything it knows.
This situation often arises when you try to run a binary for the right system (or family of systems) and superarchitecture but the wrong subarchitecture. Here you have ELF binaries on a system that expects ELF binaries, so the kernel loads them just fine. They are i386 binaries running on an x86_64 processor, so the instructions make sense and get the program to the point where it can look for its loader. But the program is a 32-bit program (as the
file output indicates), looking for the 32-bit loader
/lib/ld-linux.so.2, and you’ve presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the loader, and all the libraries the programs need. From Debian wheezy onwards, if you want both i386 and x86_64 support, start with an amd64 installation and activate multiarch support: run
dpkg --add-architecture i386 then
apt-get update and
apt-get install libc6:i386 zlib1g:i386 … (if you want to generate a list of the dependencies of Debian’s perl package, to see what libraries are likely to be needed, you can use
aptitude search -F %p '~Rdepends:^perl$ ~ri386'). You can pull in a collection of common libraries by installing the
ia32-libs package (you need to enable multiarch support first). On Debian amd64 up to wheezy, the 32-bit loader is in the
libc6-i386 package. You can install a bigger set of 32-bit libraries by installing
ldd(1) on your
perl binary. Often the seemingly confusing
Not found error on a file that is clearly there is because one of the shared libraries used by the program is not found.
So it is possible that your chroot is incomplete with respect to the shared libraries needed by your binaries.