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

Question

Eu quero lançar o executável wine (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á links simbólicos mortos:

$ 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 acontecer antes de as bibliotecas vinculadas dinamicamente serem solicitadas, porque nenhuma mensagem de depuração ld é gerada:

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

Mesmo quando apenas imprimir os valores possíveis de LD_DEBUG , o erro ocorre em vez disso

$ 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 dentro do executável, já que copiar o conteúdo de /usr/bin/wine para outro 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

    

Answer 1

Isto:

$ 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 que o sistema não tenha o intérprete /lib/ld-linux.so.2 ELF. Ou seja, esse sistema de 64 bits não possui bibliotecas de compatibilidade de 32 bits instaladas. Assim, a resposta do @ user1334609 é essencialmente correta.

    

Answer 2

OK, eu estava ocupado durante as últimas oito horas para colocar meu sistema em funcionamento novamente após o desligamento do superaquecimento da CPU. Na reinicialização, ficou evidente que estava tão estragado que até mesmo o console de inicialização do initrd não reconhecia mais meu teclado. É um mistério para mim como o sistema conseguiu permanecer operativo por tanto tempo, enquanto eu estava tentando implementar as inúmeras sugestões por você (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 foi: Uma atualização substituiu o link simbólico /lib -> /usr/lib por um diretório. Então isso significava que todas as bibliotecas e módulos do kernel, que devem estar em /lib , estavam faltando: -)

Então eu recriou o link simbólico e reinstalei o sistema básico de um live CD.

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

Eu também usei o gerenciador de pacotes da minha instalação bricked em disco (chamada pacman ) do live CD para reinstalar todos os pacotes do grupo base (talvez apenas o kernel, então o pacote linux teria sido suficiente, não sei)

Para isso, monte a partição principal da instalação em brick no diretório /mnt do live CD system e use chroot para fazer pacman think /mnt is / (insira o principal do seu sistema bricked) partição 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, então ln -s usr/lib /mnt/lib e 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 em /new_root . O link simbólico seria absoluto, você receberia o erro acima mencionado durante a inicialização antecipada.

    

Answer 3

Você está tentando executar o aplicativo de 32 bits em um sistema operacional de 64 bits, portanto, é necessário instalar bibliotecas de compatibilidade de 32 bits (especialmente o glibc) antes que isso funcione.