3

I recently installed an dynamic binary translation program to run x86_64 binary on my ARMv8 server. After I uninstall the DBT tool, I found some weird error messages and it is very comfusing.

A little bit background information, using DBT tool, I am able to enter an bash (compiled for x86_64) and run tests just like on a x86_64 machine.

And the problem happens, after I finished my tests and decided to uninstall the program.

Occasionally, On the ARM server(where I have installed the DBT before using rpm packages), if I run a x86_64 statically linked helloworld binary, the output message is

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

But when I use file and ls, the binary existed.

file ./helloworld

./helloworld: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=465941947d84d055552ea628720b94096516c3a7, with debug_info, not stripped

However, to run the same binary on another ARM server that I did not installed the DBT tool before. The output message is

-bash: ./helloworld: cannot execute binary file: Exec format error

The error message is what I want to receive since it points out the problem of unmatched binary clearly.

My concern is

I might not completely uninstall the DBT tool but I can not find any leftovers after carefully examining the files that are added by the rpm packages.

I have read posts such as https://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-file-exists, and others. They seems to run into the same problemsm but those information are not useful in my case.

Any help would be appreciate.

Billy
  • 131
  • 1
    @terdon doesn't the same message sometimes indicate a problem with the loader - as for example Getting “Not found” message when running a 32-bit binary on a 64-bit system – steeldriver Feb 26 '21 at 20:28
  • yes, that's what the askubuntu q there also says. execve() also errors ENOENT if you have a script with a hashbang pointing to a nonexisting file. Similarly you could get a "Permission denied" if the interpreter isn't executable, even if the script is. Though the case of a script, it looks like Bash opens the file itself to figure out what's going on and gives a better error message. – ilkkachu Feb 26 '21 at 20:30
  • That's what the Linux manpage for execve() says too (and I'm assuming it's Linux, somehow): "ENOENT The file filename or a script or ELF interpreter does not exist, or a shared library needed for the file or interpreter cannot be found.", similar for EACCES. Though this one is a static executable, so??? – ilkkachu Feb 26 '21 at 20:33
  • Post output of readelf -a ./helloworld | grep "program interpre" (it can be empty) just to make sure that your copy of file isn't buggy. – Arkadiusz Drabczyk Feb 26 '21 at 23:17
  • @ArkadiuszDrabczyk The grep command does not give any output. This happen for other x86_64 binary as well. I am using helloworld as the simplest example – Billy Feb 26 '21 at 23:48
  • @steeldriver well dang. Yes indeed. I hadn't known that and assumed that since the error was bash: blah blah the binary had never been launched. Thanks! And thank you Billy for the edit making it clear that the file does indeed exist. – terdon Feb 27 '21 at 16:05
  • 2
    Do the two servers have different contents in /proc/sys/fs/binfmt_misc ? – Mark Plotnick Feb 27 '21 at 22:41
  • @MarkPlotnick The two servers are set up identically. – Billy Feb 28 '21 at 17:08

0 Answers0