El ejecutable de Linux falla con "Archivo no encontrado" aunque el archivo esté allí y en RUTA

Quiero iniciar el wineejecutable (Versión 2.12), pero aparece el siguiente error ( $= solicitud de 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

Sin embargo, el archivo está ahí:

$ which wine
/usr/bin/wine

El ejecutable definitivamente está ahí y no hay un enlace simbólico muerto:

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

Es un 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

Puedo obtener la sección dinámica del ejecutable:

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

Sin embargo, no puedo enumerar las dependencias de objetos compartidos usando ldd:

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

strace muestra:

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 agregar sugerencias por @jww : El problema parece suceder antes de solicitar bibliotecas vinculadas dinámicamente, porque no ldse generan mensajes de depuración:

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

Incluso cuando solo imprime los valores posibles de LD_DEBUG, el error ocurre en su lugar

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

Editado para agregar una sugerencia de @Raman Sailopal: el problema parece estar dentro del ejecutable, ya que copiar el contenido de /usr/bin/wineotro archivo ya creado produce el mismo error

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

¿Cuál es el problema o qué puedo hacer para averiguar qué archivo o directorio falta?

uname -a:

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

Esta:

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

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

Sugiere fuertemente que el sistema no tiene el /lib/ld-linux.so.2intérprete ELF. Es decir, este sistema de 64 bits no tiene ninguna biblioteca de compatibilidad de 32 bits instalada. Por lo tanto, la respuesta de @ user1334609 es esencialmente correcta.

OK, estuve ocupado durante las últimas ocho horas para volver a poner en funcionamiento mi sistema después de que la CPU se sobrecalentara. Al reiniciar se hizo evidente que estaba tan jodido que incluso la consola de respaldo de initrd ya no reconocía mi teclado. Para mí es un misterio cómo el sistema logró mantenerse operativo durante tanto tiempo, mientras intentaba implementar las innumerables sugerencias que hizo (¡muchas gracias!)

Problema al reiniciar:

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

y ningún teclado funciona después :-)

El problema era: una actualización reemplazó el enlace simbólico /lib -> /usr/libcon un directorio. Eso significaba que /libfaltaban todas las bibliotecas y módulos del núcleo, que se espera que estén en :-)

Así que recreé el enlace simbólico y reinstalé el sistema base desde un CD en vivo.

Ahora que tengo internet nuevamente, también encontré este hilo

También utilicé el administrador de paquetes de mi instalación en disco bloqueada (llamada pacman) desde el CD en vivo para reinstalar todos los paquetes del grupo base (tal vez solo el núcleo, por lo que el paquete linuxhabría sido suficiente, no lo sé)

Para lograr eso, montar la partición principal de la instalación ladrillera al /mntdirectorio del sistema de CD en vivo y el uso chrootpara hacer pacmanpensar /mntes /(insertar partición principal de su sistema de ladrillera 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 el registro: cree un enlace simbólico relativo, así ln -s usr/lib /mnt/liby no ln -s /usr/lib /mnt/lib, porque durante el arranque inicial del sistema (etapa initrd), la partición principal se montará primero /new_root. Si el enlace simbólico fuera absoluto, obtendría el error mencionado anteriormente durante el arranque temprano.

Está intentando ejecutar una aplicación de 32 bits en un sistema operativo de 64 bits, por lo que necesita instalar bibliotecas de compatibilidad de 32 bits (glibc en particular) antes de que esto pueda funcionar.

Para su información, me encontré con este mismo problema que se ejecuta en una imagen acoplable alpina. El ejecutable era un ELF de 64 bits, y la imagen alpina era de 64 bits, y el ejecutable funcionaba en un contenedor diferente. Entonces, presumiblemente, las bibliotecas alpinas recortadas no eran compatibles con mi ejecutable. Las notas de la página del concentrador de Docker de node.js :

La advertencia principal [para ejecutarse en el contenedor basado en Alpine] es que usa musl libc en lugar de glibc y amigos , por lo que cierto software podría tener problemas dependiendo de la profundidad de sus requisitos de libc. Sin embargo, la mayoría del software no tiene un problema con esto, por lo que esta variante suele ser una opción muy segura. Consulte este hilo de comentarios de Hacker News para obtener más información sobre los problemas que pueden surgir y algunas comparaciones pro / con del uso de imágenes basadas en Alpine.

Mi solución fue utilizar una imagen de contenedor diferente (por ejemplo, basada en Debian Jessie).