4

I am puzzled by the following sequence of commands.

sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1)                           = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux

How is this possible?

willardthor
  • 281
  • 2
  • 6
  • Someone is fooling you and quickly removed the file between the second and the third command you executed? (I cannot reproduce it using Ubuntu) – Veger Jan 23 '13 at 14:03
  • eek... what's the output of `ls f` before and after? – Davide Berra Jan 23 '13 at 14:06
  • does this happen consistently? or was this a one time thing? –  Jan 23 '13 at 14:15
  • @davide-berra : Added the `ls f` (with a "-l" to show permissions), and a command showing my kernel version. @aaron-waibel : This has never happened to me before. A friend of mine tried executing the binary on his Debian machine (from what I understand), and the file executes just fine. I am running a 64-bit OS, and the file is a 32-bit binary, but I do not believe this to be an issue, as my friend is also running a 64-bit OS. I haven't rebooted my computer for 3 months, and in the meantime, I have (almost certainly) fetched a new kernel through pacman. You think rebooting would help? – willardthor Jan 23 '13 at 14:21

2 Answers2

4

I found someone having the same problem (with relative explanation)

Running 32bit binary on a 64bit system

Quoting the most important sentences:

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.

I bet there's a better way to verify this but i'd try to exec

ldd ./f

and search in the output which loader is needed to exec'it

Community
  • 1
  • 1
Davide Berra
  • 6,387
  • 2
  • 29
  • 50
1

man 2 execve:

ENOENT The file filename or a  script  or  ELF  interpreter  does  not
       exist,  or a shared library needed for file or interpreter can‐
       not be found.

You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.

t-8ch
  • 2,583
  • 14
  • 18