Linux executable fails with "File not found" even though the file is there and in PATH

Question

I want to launch the wine executable (Version 2.12), but I get the following error ($=shell prompt):

$ wine
bash: /usr/bin/wine: No such file or directory
$ /usr/bin/wine
bash: /usr/bin/wine: No such file or directory
$ cd /usr/bin
$ ./wine
bash: ./wine: No such file or directory

However, the file is there:

$ which wine
/usr/bin/wine

The executable definitely is there and no dead symlink:

$ stat /usr/bin/wine
  File: /usr/bin/wine
  Size: 9712            Blocks: 24         IO Block: 4096   regular file
Device: 802h/2050d      Inode: 415789      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-07-13 13:53:00.000000000 +0200
Modify: 2017-07-08 03:42:45.000000000 +0200
Change: 2017-07-13 13:53:00.817346043 +0200
 Birth: -

It is a 32-bit ELF:

$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

I can get the dynamic section of the executable:

$ readelf -d /usr/bin/wine
Dynamic section at offset 0x1efc contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libwine.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000001d (RUNPATH)                    Library runpath: [$ORIGIN/../lib32]
 0x0000000c (INIT)                       0x7c000854
 0x0000000d (FINI)                       0x7c000e54
 [more addresses without file names]

However, I cannot list the shared object dependencies using ldd:

$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory

strace shows:

execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
getpid()                                = 23783
exit_group(1)                           = ?
+++ exited with 1 +++

Edited to add suggestion by @jww: The problem appears to happen before dynamically linked libraries are requested, because no ld debug messages are generated:

$ LD_DEBUG=all wine
bash: /usr/bin/wine: No such file or directory

Even when only printing the possible values of LD_DEBUG, the error occurs instead

$ LD_DEBUG=help wine
bash: /usr/bin/wine: No such file or directory

Edited to add suggestion of @Raman Sailopal: The problem seems to lie within the executable, as copying the contents of /usr/bin/wine to another already created file produces the same error

root:bin # cp cat testcmd    

root:bin # testcmd --help
Usage: testcmd [OPTION]... [FILE]...
Concatenate FILE(s) to standard output.
[rest of cat help page]

root:bin # dd if=wine of=testcmd  
18+1 records in
18+1 records out
9712 bytes (9.7 kB, 9.5 KiB) copied, 0.000404061 s, 24.0 MB/s

root:bin # testcmd
bash: /usr/bin/testcmd: No such file or directory

What is the problem or what can I do to find out which file or directory is missing?

uname -a:

Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux

I think this indicates the problem: ***`Library runpath: [$ORIGIN/../lib32]`*** and ***`x86_64 GNU/Linux`***. Does Arch do multilib? If so, are the packages installed? — , Jul 13 '17 at 12:19
Arch is multilib-capable. Multilib repository is enabled in `/etc/pacman.conf`. All dependencies of the `wine` package are installed. However, reinstalling them just to make sure... — akraf, Jul 13 '17 at 12:32
@jww: It is a 32-bit executable on 64-bit Arch. I think that's usual for wine. I am not aware of any problems running a 32-bit executable on a 64-bit system (question edited)? — akraf, Jul 13 '17 at 12:37
Well, maybe your next step is enable loader debugging. There's a few questions to choose from: [ld loader debugging site:stackoverflow.com](https://www.google.com/search?q=ld+loader+debugging+site%3Astackoverflow.com) and [ld environmental variables linux](https://www.google.com/search?q=ld+environmental+variables+linux) and the [`ld.so`](http://man7.org/linux/man-pages/man8/ld.so.8.html) man page. The `ld.so` man page documents envars like `LD_DEBUG`. I don't know which one to recommend because I've never needed it. — , Jul 13 '17 at 12:41
Get an executable that currently works fine and copy it to another command i.e. testcommand. Then "dd if=/usr/bin/wine of=/usr/bin/testcommand" Run /usr/bin/testcommand and see if you have the same issue. This will decipher whether it is a problem with the actual file or the permissions on the file — , Jul 13 '17 at 12:44
Thank you very much, @jww. The execution seems to fail before linking or at least before debug messages can be printed. Question edited — akraf, Jul 13 '17 at 13:03
Thanks for your suggestion, @RamanSailopal. The problem seems to be related to the executable content, rather than to the file system, as the error "travels" with the copied executable content. Question edited. — akraf, Jul 13 '17 at 13:03
Try `LD_DEBUG=files /usr/bin/wine` or `LD_DEBUG=all /usr/bin/wine`. Help is supposed to print the help message. — , Jul 13 '17 at 13:14
I did that. It is written just above the section with `LD_DEBUG=help` — akraf, Jul 13 '17 at 13:15
I think you are better off just uninstalling and re-install Wine. — , Jul 13 '17 at 14:17
Is `/lib/ld-linux.so.2` present on your system? All symptoms point to it being missing, just checking. — n. m. could be an AI, Jul 13 '17 at 14:22
@n.m. Yes, you were right. In fact, the whole directory `/lib` was missing :-) — akraf, Jul 14 '17 at 10:01
@n.m. - Forgive my ignorance... How did you determine it was `/lib/ld-linux.so.2`? — , Jul 14 '17 at 12:20
Experience ;) when you try to run an executable and get a "file not found" error while the file is obviously right here, it's the interpreter missing. Your `file` command shows what interpreter is set for this executable. — n. m. could be an AI, Jul 14 '17 at 17:09
@n.m You have provided the real answer to the question what was the cause of the error. Post it and I'll accept it. — akraf, Jul 15 '17 at 09:42

score 25 · Accepted Answer · answered Jul 17 '17 at 16:52

This:

$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

Combined with this:

$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory

Strongly suggests that the system does not have the /lib/ld-linux.so.2 ELF interpreter. That is, this 64-bit system does not have any 32-bit compatibility libraries installed. Thus, @user1334609's answer is essentially correct.

Is anyone going to talk about the misleading error message? – Rolf Apr 22 '20 at 10:55 — Rolf, Apr 22 '20 at 10:55

score 5 · Answer 2 · edited Jul 17 '17 at 18:13

5

You are trying to run 32-bit application on a 64 bit operating system, so you need to install 32-bit compatibility libraries (glibc in particular) before this can work.

edited Jul 17 '17 at 18:13

Community

1

answered Jul 14 '17 at 10:02

user1334609

171
2

1

Please clarify how your solution resolve the case and answer the question – Romeo Ninov Jul 14 '17 at 10:35
What Romeo said; you would run apt-get on an arch-linux system, instead of pacman? And how would compression libraries and ncurses help them? – Jeff Schaller Jul 14 '17 at 10:41

akraf · Answer 3 · 2017-07-15T09:15:40.227

OK, I was busy for the last eight hours to get my system up and running again after CPU overheating shut-down. On reboot it became apparent that it was so screwed up that even the fall-back console of initrd didn't recognize my keyboard anymore. It is a mystery for me how the system managed to stay operative for so long, while I was trying to implement the countless suggestions by you (thank you a lot!!)

Problem on reboot:

Warning: /lib/modules/4.11.3-1-ARCH/modules.devname not found - ignoring
ERROR: device 'UUID=...' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=...'.
You are being dropped to a recovery shell
Type 'exit' to try and continue booting
sh: can't access tty: job control turned off

and no keyboard working afterwards :-)

The Problem was: An update replaced the symlink /lib -> /usr/lib with a directory. So that meant all libraries and kernel modules, which are expected to be in /lib were missing :-)

So I recreated the symlink and reinstalled the base system from a live CD.

Now that I have internet again, I also found this thread

I also used the package manager of my bricked on-disk installation (called pacman) from the live CD to reinstall all the packages of the base group (maybe only the kernel, so package linux would have been enough, I don't know)

To accomplish that, mount the main partition of the bricked installation to the /mnt directory of the live CD system and use chroot to make pacman think /mnt is / (insert your bricked system's main partition for sdXXX)

mount /dev/sdXXX /mnt
# Recreate the /lib -> usr/lib symlink
ln -s usr/lib /lib  
# Mount essential system folders also to the respective subfolders of /mnt
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
# Fake /mnt to be /, so that pacman installs the packages to the correct  places
chroot /mnt
# Reinstall the Arch Linux base system
pacman -Sy base

For the record: create a relative symlink, so ln -s usr/lib /mnt/lib and not ln -s /usr/lib /mnt/lib, because during early system boot (initrd stage) the main partition will be mounted first to /new_root. Would the symlink be absolute, you would get the above-mentioned error during early boot.

Small hint: When using systemrescuecd, I often just iterate over proc/sys/dev (for path in proc sys dev ; do mount -obind /$path /mnt/$path ; done) before doing the chroot. However if you're using the arch install iso, much easier to just run the provided arch-chroot executable as it does everything for you. Its in the arch-install-scripts package if someone wants to poke around. :) — zaTricky, Jul 15 '17 at 09:42

score 4 · Answer 4 · answered Nov 29 '19 at 20:32

FYI, I ran into this same issue running in an alpine-based docker image. The executable was a 64-bit ELF, and the alpine image was 64-bit, and the executable worked in a different container. So presumably the trimmed alpine libraries were not compatible with my executable. The node.js Docker hub page notes:

The main caveat [to running in the Alpine-based container] is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

My solution was to use a different (e.g. Debian Jessie-based) container image.

Thanks for connecting this originally sysadmin problem to the "new" world of containers! — akraf, Nov 30 '19 at 23:29

score 0 · Answer 5 · answered Mar 16 '23 at 02:06

For me, I was trying to run 32-bit application on a 64 bit operating system as mentioned by user1334609, so I needed to install 32-bit compatibility libraries. I'm on Ubuntu, so I did this:

dpkg --add-architecture i386
apt update
apt install libc6-i386

It worked and my elf file was able to find ld-linux. It then failed loading some libs, which I troubleshooted one by one.

Linux executable fails with "File not found" even though the file is there and in PATH

5 Answers5

Linked

Related