即使文件存在并且在PATH中，Linux可执行文件也会失败并显示“找不到文件”

我想启动wine可执行文件（版本2.12），但是出现以下错误（$= shell提示符）：

$ 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

但是，文件在那里：

$ which wine
/usr/bin/wine

可执行文件肯定在那里，并且没有死的符号链接：

$ 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: -

它是32位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

我可以得到可执行文件的动态部分：

$ 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]

但是，我无法使用列出共享对象的依赖关系ldd：

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

strace 显示：

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 +++

通过@jww进行编辑以添加建议：由于未ld生成调试消息，因此在请求动态链接的库之前似乎发生了此问题：

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

即使仅打印的可能值LD_DEBUG，也会出现错误

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

编辑以添加@Raman Sailopal的建议：问题似乎出在可执行文件内，因为将内容复制/usr/bin/wine到另一个已创建的文件时会产生相同的错误

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

有什么问题，或者我该怎么办才能找出缺少的文件或目录？

uname -a：

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

这个：

$ 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

与此结合：

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

强烈建议该系统没有/lib/ld-linux.so.2ELF解释器。也就是说，此64位系统没有安装任何32位兼容性库。因此，@ user1334609的答案本质上是正确的。

好的，在过去的八个小时中，我忙于在CPU过热关闭后重新启动系统并重新运行。在重新启动时，很明显它被弄砸了，以至于initrd的后备控制台也不再能识别我的键盘。在我尝试实施您的无数建议时（我非常感激！），这对我来说是个谜，

重新启动时出现问题：

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

而且之后没有键盘可以工作:-)

问题是：更新用/lib -> /usr/lib目录替换了符号链接。因此，这意味着所有期望包含的库和内核模块都将/lib丢失:-)

因此，我重新创建了符号链接，并从实时CD重新安装了基本系统。

现在我又可以上网了，我也找到了这个线程

我还使用了pacman实时CD 上的砖砌磁盘安装程序（称为）的程序包管理器来重新安装基本组的所有程序包（也许只有内核，所以程序包linux就足够了，我不知道）

为了实现这个目标，安装砖砌安装的主分区的/mnt现场CD系统和使用的目录chroot，使pacman想/mnt是/（插入您的砖砌系统的主分区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

记录一下：创建一个相对的符号链接，ln -s usr/lib /mnt/lib而不是这样ln -s /usr/lib /mnt/lib，因为在系统早期启动（初始阶段）期间，主分区将首先安装到/new_root。如果符号链接是绝对的，则在早期启动期间会出现上述错误。

您试图在64位操作系统上运行32位应用程序，因此您需要先安装32位兼容性库（尤其是glibc），然后才能运行。

仅供参考，我在基于阿尔卑斯的docker映像中遇到了同样的问题。可执行文件是64位ELF，高山映像是64位，并且可执行文件在其他容器中工作。因此大概是经过修剪的高山库与我的可执行文件不兼容。在Node.js的泊坞窗枢纽页笔记：

[要在基于Alpine的容器中运行]的主要警告是，它确实使用了musl libc而不是glibc和friends，因此某些软件可能会遇到问题，具体取决于其libc要求的深度。但是，大多数软件对此没有问题，因此，此变体通常是非常安全的选择。请参阅此Hacker News评论主题，以获取有关可能出现的问题的更多讨论以及使用基于Alpine的图像的一些优缺点的比较。

我的解决方案是使用其他（例如，基于Debian Jessie的）容器图像。