Linux実行可能ファイルは、ファイルがPATHに存在していても「File not found」で失敗します

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の過熱によるシャットダウンの後、システムを再起動して稼働させるために、過去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から基本システムを再インストールしました。

再びインターネットを利用できるようになったので、このスレッドも見つけました

また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、初期システムブート（initrdステージ）中にメインパーティションが最初にマウントされるため/new_rootです。シンボリックリンクが絶対リンクである場合、初期ブート中に上記のエラーが発生します。

64ビットオペレーティングシステムで32ビットアプリケーションを実行しようとしているため、これが機能する前に32ビット互換性ライブラリ（特にglibc）をインストールする必要があります。

参考までに、私はこの同じ問題に遭遇して、高山ベースのdockerイメージで実行しています。実行可能ファイルは64ビットELFで、高山イメージは64ビットで、実行可能ファイルは別のコンテナで機能しました。したがって、おそらく、トリミングされたアルパインライブラリは、私の実行可能ファイルと互換性がありませんでした。ドッカーハブページNode.jsのノートは：

[Alpineベースのコンテナで実行する場合]の主な注意点は、glibcやfriendsの代わりにmusl libcを使用するため、libc要件の深さによっては特定のソフトウェアで問題が発生する可能性があることです。ただし、ほとんどのソフトウェアにはこれに関する問題がないため、このバリアントは通常非常に安全な選択肢です。発生する可能性のある問題の詳細と、Alpineベースの画像の使用に関する賛否両論の比較については、このハッカーニュースのコメントスレッドを参照してください。

私の解決策は、異なる（たとえば、Debian Jessieベースの）コンテナイメージを使用することでした。