O executável do Linux falha com "Arquivo não encontrado", mesmo que o arquivo esteja lá e no PATH

Desejo iniciar o wineexecutável (versão 2.12), mas recebo o seguinte erro ( $= prompt do 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

No entanto, o arquivo está lá:

$ which wine
/usr/bin/wine

O executável definitivamente está lá e não há um link simbólico morto:

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

É um ELF de 32 bits:

$ 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

Eu posso obter a seção dinâmica do executável:

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

No entanto, não consigo listar as dependências de objetos compartilhados usando ldd:

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

strace mostra:

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

Editado para adicionar sugestão por @jww : o problema parece ocorrer antes que as bibliotecas vinculadas dinamicamente sejam solicitadas, porque nenhuma ldmensagem de depuração é gerada:

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

Mesmo ao imprimir apenas os valores possíveis de LD_DEBUG, o erro ocorre

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

Editado para adicionar sugestão de @Raman Sailopal: O problema parece estar no executável, pois copiar o conteúdo de /usr/bin/wineoutro arquivo já criado produz o mesmo erro

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

Qual é o problema ou o que posso fazer para descobrir qual arquivo ou diretório está faltando?

uname -a:

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

Este:

$ 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

Combinado com isso:

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

Sugere fortemente que o sistema não tenha o /lib/ld-linux.so.2intérprete ELF. Ou seja, esse sistema de 64 bits não possui nenhuma biblioteca de compatibilidade de 32 bits instalada. Assim, a resposta de @ user1334609 está essencialmente correta.

OK, fiquei ocupado nas últimas oito horas para colocar meu sistema em funcionamento novamente após o superaquecimento da CPU. Na reinicialização, ficou claro que ele estava tão danificado que nem o console substituto do initrd não reconheceu mais o meu teclado. É um mistério para mim como o sistema conseguiu permanecer operacional por tanto tempo, enquanto eu tentava implementar as inúmeras sugestões de vocês (muito obrigado !!)

Problema na reinicialização:

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

e nenhum teclado funcionando depois :-)

O problema era: Uma atualização substituiu o link simbólico /lib -> /usr/libpor um diretório. Então isso significava que todas as bibliotecas e módulos do kernel, que devem estar /libausentes, estavam ausentes :-)

Então, recriei o link simbólico e reinstalei o sistema básico a partir de um CD ao vivo.

Agora que tenho internet novamente, também encontrei este tópico

Eu também usei o gerenciador de pacotes da minha instalação em disco emparelhada (chamada pacman) a partir do CD ao vivo para reinstalar todos os pacotes do grupo base (talvez apenas o kernel, portanto, o pacote linuxteria sido suficiente, não sei)

Para fazer isso, monte a partição principal da instalação em blocos no /mntdiretório do sistema do Live CD e use-o chrootpara fazer pacmanpensar /mnt: /(insira a partição principal do sistema em blocos para 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

Para o registro: crie um link simbólico relativo, sim ln -s usr/lib /mnt/libe não ln -s /usr/lib /mnt/lib, porque durante a inicialização inicial do sistema (estágio initrd), a partição principal será montada primeiro /new_root. Se o link simbólico fosse absoluto, você obteria o erro mencionado acima durante a inicialização antecipada.

Você está tentando executar aplicativos de 32 bits em um sistema operacional de 64 bits, portanto, é necessário instalar bibliotecas de compatibilidade de 32 bits (glibc em particular) antes que isso possa funcionar.

Para sua informação, encontrei o mesmo problema em uma imagem de janela de encaixe baseada em alpinos. O executável era um ELF de 64 bits, a imagem alpina era de 64 bits e o executável funcionava em um contêiner diferente. Portanto, presumivelmente, as bibliotecas alpinas cortadas não eram compatíveis com o meu executável. A página do hub do node.js Docker observa:

A principal advertência [para rodar no contêiner baseado no Alpine] é que ele usa musl libc em vez de glibc e amigos , para que certos softwares possam ter problemas dependendo da profundidade de seus requisitos de libc. No entanto, a maioria dos softwares não tem problema com isso, portanto essa variante geralmente é uma opção muito segura. Consulte este tópico de comentários do Hacker News para obter mais discussões sobre os problemas que podem surgir e algumas comparações pró / contra do uso de imagens baseadas em Alpine.

Minha solução foi usar uma imagem de container diferente (por exemplo, baseada no Debian Jessie).