Getting “Not found” message when running a 32-bit binary on a 64-bit system

I have currently a strange problem on debian (wheezy/amd64).

I have created a chroot to install a server (i can't give any more detail about it, sorry). Let's call its path/chr_path/. To make things easy, I have initialized this chroot with a debootstrap (also wheezy/amd64).

All seemed to work well inside the chroot but when I started the installer script of my serveur I got :zsh: Not found /some_path/perl (the installer includes a perl binary for some reasons)

Naturally, I checked the /some_path/ location and I found the "perl" binary. file in chroot environment returns :

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

The file exists, seems ok, has correct rights. I can use file, ls, vim on it but as soon as I try to execute it - ./perl for example - I get : zsh: Not found ./perl.

This situation is quite ununderstable for me. Moreover :

• I can execute other basic binaries (/bin/ls,...) in the chroot without getting errors
• I have the same problems for other binaries that came with the project
• When I try to execute the binary from the main root (/chr_path/some_path/perl), it works.
• I have tried to put one of the binaries with a copy of my ls. I checked that the access rights were the same but this didn't change anything (one was working, and the other wasn't)

ANSWER:-

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.so or /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/sh for 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. On Debian amd64, the 32-bit loader is in the libc6-i386 package. You can install a bigger set of 32-bit libraries by installing ia32-libs.