-bash: ./flume: No such file or directory BUT flume is there and works elsewhere

We have a product built on CentOS 4 32-bit Linux that runs unmodified on 32- and 64-bit CentOS/RHEL 4 and 5 and SLES 10. It also runs unmodified on SLES 9 64-bit. [SLES 9 32-bit requires a different libstdc++.

The name of the main binary executable is 'flume'

Yesterday we tried to put this on 64-bit Ubuntu 10 and, even though the file is there and the right size, we get:

-bash: ./flume: No such file or directory

file flume shows it to be a 32-bit ELF (can't remember the exact output and the system is on an isolated network)

If put into /usr/local/bin, then which flume /usr/local/bin/flume

I did not try ldd flume yet.

I now suspect that some library is not there.

This is a profoundly unhelpful message and one I have never seen before.

Is this peculiar to Ubuntu or perhaps just to this installation.

We gave up and moved to a RHEL 4 system and everything is fine. But I sure would like to know what causes this.

From serverfault lcbrevard

• Did you try to give execute rights to the file?

  chmod +x ./flume 
  

  basvdlei : That would give "Permission denied" instead of "No such file or directory"

  SvenW : Yep, you are right.

  lcbrevard : Sorry, I should have made clear that the mode bits showed as executable - i.e., chmod +x flume was done at the very beginning. I also checked with lsattr to see if anything was funny there but that was OK too. I have not had a chance to try ldd or strace because the server room had an air conditioning failure and everything is powered off!
  From SvenW

• You can get this message if flume exists but its “loader” doesn't exist, where

  • the loader of a native executable is its dynamic loader, for example /lib/ld-linux.so.2;
  • the loader of a script is the program mentioned on its shebang line, e.g., /bin/sh if the script begins with #!/bin/sh.

  In your case, it looks like you don't have the 32-bit dynamic loader installed on the 64-bit Ubuntu system. It's in the libc6-i386 package.

  strings ./flume | head -n 1 will display the path to the dynamic loader that flume requires. This is one of those rare cases where strace ./flume is completely unhelpful.

  I consider this situation to be Unix's most misleading error message. Unfortunately fixing it would be hard: the kernel can only report a numeric error code to the caller of the program, so it only has room for “command not found” and not for the name of the loader it's looking for.

  From Gilles