"No such file or directory" lies on Optware installed binaries

Question

I've been using Optware to install packages on my ARM-based NAS for a while - the usual stuff like Transmission, Samba and others. However, I'd been having problems with Transmission hanging not long after starting up. I looked around for a solution for a while and finally discovered that the Optware feed I was using wasn't the one that had been set up for my NAS box. I switched the feeds and reinstalled all the packages but now I'm getting the following error when I try and run anything that was reinstalled:

$ smbd
-bash: /opt/sbin/smbd: No such file or directory
$ transmission-daemon
-bash: /opt/bin/transmission-daemon: No such file or directory
$ unrar
-bash: /opt/bin/unrar: No such file or directory

I checked /opt/bin and /opt/sbin and the executables are definitely there - so what's the real problem?

$ ldd /opt/bin/transmission-daemon
/usr/bin/ldd: line 116: /opt/bin/transmission-daemon: No such file or directory

$ file /opt/bin/transmission-daemon
/opt/bin/transmission-daemon: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped

$ readelf - l /opt/sbin/smbd
readelf: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory

$ cat /proc/$$/maps
…
40084000-4019e000 r-xp 00000000 09:01 112594 /lib/libc-2.7.so
…

I'm not sure what any of that means but it proves the file is there, right? Or is this something to do with the shared libs?

Answer 1

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.

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 isn't working 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.

Here your reinstalled executables (smbd, transmission-daemon, etc) are requesting a loader that isn't present on your system. So your new feed isn't right for your system either.

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 ARM binaries running on an ARM processor, so the instructions make sense and get the program to the point where it can look for its loader. But it's the wrong loader.

Now I'm getting into conjecture, but I suspect your new feed is for the wrong ARM ABI. The ABI is the common language for making inter-procedure calls, and in particular for calling library functions. On some processor architectures, there are several possible ABI choices, and you need to pick one and use it consistently. There are two ARM ABIs with Linux distributions out there: the traditional arm-elf ABI, and the newer EABI (arm-eabi). You can't mix ABIs on the same system, so you need to find a source of packages for your ABI (or reinstall your system for a different ABI).