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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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.
Method 2
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.
Method 3
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.
Method 4
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0