Linux実行可能ファイルは、ファイルが存在し、PATHにあるにもかかわらず、「ファイルが見つかりません」で失敗する
wine実行可能ファイル（バージョン2.12）を起動したいのですが、次のエラー（$ = 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
しかし、ファイルはそこにあります：
$ 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.2 ELFインタープリターがないことを強くお勧めします。つまり、この64ビットシステムには32ビット互換ライブラリがインストールされていません。したがって、@ user1334609の答えは基本的に正しいです。
OK、CPUの過熱によるシャットダウン後、システムを稼働させるために過去8時間忙しかった。再起動すると、非常にねじ込まれていることが明らかになり、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から基本システムを再インストールしました。
私は再びインターネットに接続したので、私は this thread も見つけました
私はまた、ライブCDからブリックされたディスク上のインストール（pacmanと呼ばれる）のパッケージマネージャーを使用して、 base group のすべてのパッケージを再インストールしました（おそらくカーネルのみなので、パッケージlinuxで十分だったでしょう、わかりません）
そのためには、ブリックインストールのメインパーティションをライブCDシステムの_/mnt_ディレクトリにマウントし、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）をインストールする必要があります。
ちなみに、私はAlpineベースのDockerイメージで実行されている同じ問題に遭遇しました。実行可能ファイルは64ビットELFで、Alpineイメージは64ビットであり、実行可能ファイルは別のコンテナーで動作しました。したがって、おそらくトリミングされたAlpineライブラリは私の実行可能ファイルと互換性がありませんでした。 node.js Dockerハブページ のメモ：
主な注意点[アルパインベースのコンテナで実行する場合]は、 musl libc を使用することです glibc and friends の代わりに、特定のソフトウェアがlibc要件の深さによっては問題が発生する可能性があります。ただし、ほとんどのソフトウェアにはこれに関する問題がないため、このバリアントは通常非常に安全な選択です。発生する可能性のある問題の詳細と、アルパインベースのイメージを使用した場合の賛否両論の比較については、 このハッカーニュースのコメントスレッド を参照してください。
私の解決策は、異なる（たとえば、Debian Jessieベースの）コンテナイメージを使用することでした。