L'eseguibile Linux non riesce con "File not found" anche se il file è presente e in PERCORSO

Voglio avviare l' wineeseguibile (versione 2.12), ma ottengo il seguente errore ( $= prompt della 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

Tuttavia, il file è lì:

$ which wine
/usr/bin/wine

L'eseguibile è sicuramente lì e nessun link simbolico 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: -

È un ELF a 32 bit:

$ 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

Posso ottenere la sezione dinamica dell'eseguibile:

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

Tuttavia, non posso elencare le dipendenze degli oggetti condivisi usando ldd:

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

strace Spettacoli:

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

Modificato per aggiungere suggerimenti di @jww : il problema sembra verificarsi prima che vengano richieste le librerie collegate dinamicamente, poiché non ldvengono generati messaggi di debug:

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

Anche quando si stampa solo i possibili valori di LD_DEBUG, si verifica invece l'errore

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

Modificato per aggiungere il suggerimento di @Raman Sailopal: il problema sembra risiedere nell'eseguibile, poiché la copia del contenuto di /usr/bin/wineun altro file già creato produce lo stesso errore

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 è il problema o cosa posso fare per scoprire quale file o directory manca?

uname -a:

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

Questo:

$ 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

In combinazione con questo:

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

Suggerisce fortemente che il sistema non ha l' /lib/ld-linux.so.2interprete ELF. Cioè, questo sistema a 64 bit non ha alcuna libreria di compatibilità a 32 bit installata. Pertanto, la risposta di @ user1334609 è essenzialmente corretta.

OK, sono stato occupato nelle ultime otto ore per riavviare il sistema dopo lo spegnimento del surriscaldamento della CPU. Al riavvio è diventato evidente che era così incasinato che persino la console fallback di initrd non riconosceva più la mia tastiera. È un mistero per me come il sistema sia riuscito a rimanere operativo per così tanto tempo, mentre cercavo di implementare gli innumerevoli suggerimenti da te (grazie mille !!)

Problema al riavvio:

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 nessuna tastiera funziona dopo :-)

Il problema era: un aggiornamento ha sostituito il collegamento simbolico /lib -> /usr/libcon una directory. Ciò significava che /libmancavano tutte le librerie e i moduli del kernel, che dovrebbero essere presenti :-)

Quindi ho ricreato il collegamento simbolico e reinstallato il sistema di base da un CD live.

Ora che ho di nuovo Internet, ho trovato anche questa discussione

Ho anche usato il gestore dei pacchetti della mia installazione su disco bricked (chiamato pacman) dal CD live per reinstallare tutti i pacchetti del gruppo base (forse solo il kernel, quindi il pacchetto linuxsarebbe stato sufficiente, non lo so)

Per fare ciò, montare la partizione principale dell'installazione in muratura nella /mntdirectory del sistema di live CD e usare chrootper far sì pacmanche /mntsia /(inserire la partizione principale del sistema in muratura per 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

Per la cronaca: creare un relativo collegamento simbolico, così ln -s usr/lib /mnt/libe no ln -s /usr/lib /mnt/lib, perché durante l'avvio anticipato del sistema (fase iniziale) verrà montata prima la partizione principale /new_root. Se il collegamento simbolico fosse assoluto, si otterrebbe l'errore di cui sopra durante l'avvio anticipato.

Si sta tentando di eseguire un'applicazione a 32 bit su un sistema operativo a 64 bit, quindi è necessario installare librerie di compatibilità a 32 bit (glibc in particolare) prima che ciò possa funzionare.

Cordiali saluti, ho riscontrato questo stesso problema correndo in un'immagine docker con base alpina. L'eseguibile era un ELF a 64 bit e l'immagine alpina era a 64 bit e l'eseguibile funzionava in un contenitore diverso. Quindi presumibilmente le biblioteche alpine tagliate non erano compatibili con il mio eseguibile. Il Node.JS Docker pagina hub note:

L'avvertenza principale [per l'esecuzione nel contenitore basato su Alpine] è che utilizza musl libc invece di glibc e amici , quindi alcuni software potrebbero incorrere in problemi a seconda della profondità dei loro requisiti libc. Tuttavia, la maggior parte dei software non ha problemi con questo, quindi questa variante è di solito una scelta molto sicura. Vedi questo thread di commenti su Hacker News per ulteriori discussioni sui problemi che potrebbero sorgere e alcuni confronti pro / contro dell'utilizzo di immagini basate su Alpine.

La mia soluzione era quella di utilizzare un'immagine contenitore diversa (ad esempio basata su Debian Jessie).