Voglio avviare leseguibile wine (Versione 2.12), ma ricevo 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 

Leseguibile è sicuramente presente e nessun collegamento 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 delleseguibile:

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

Modificato per aggiungere un suggerimento di @jww : il problema sembra verificarsi prima del collegamento dinamico biblioteche sono richiesti, perché non vengono generati ld messaggi di debug:

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

Anche quando si stampano solo i possibili valori di LD_DEBUG, lerrore si verifica invece

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

Modificato per aggiungere suggerimento di @Raman Sailopal: Il problema sembra risiedere nelleseguibile, poiché la copia del contenuto di /usr/bin/wine in un 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 

Commenti

  • fa ./wine in / usr / bin funziona?
  • Arch è compatibile con multilib. Il repository Multilib è abilitato in /etc/pacman.conf. Tutte le dipendenze del pacchetto wine vengono installate. Tuttavia, reinstallarli solo per assicurarti …
  • /lib/ld-linux.so.2 presente sul tuo sistema? Tutti i sintomi indicano che manca, basta controllare.
  • @ n.m. Sì, avevi ragione. In effetti, lintera directory /lib mancava 🙂
  • Experience;) quando provi a eseguire un eseguibile e ottieni un ” file non trovato ” errore mentre il file è ovviamente qui, è ‘ linterprete mancante. Il comando file mostra quale interprete è impostato per questo eseguibile.

Risposta

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 

Combinato con questo:

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

Suggerisce vivamente che il sistema non dispone dellinterprete ELF /lib/ld-linux.so.2. Cioè, questo sistema a 64 bit non dispone di librerie di compatibilità a 32 bit installate. Pertanto, la risposta di @ user1334609 è essenzialmente corretta.

Commenti

  • Qualcuno parlerà del messaggio di errore fuorviante?

Risposta

OK, sono stato impegnato nelle ultime otto ore per rimettere in funzione il mio sistema dopo lo spegnimento per surriscaldamento della CPU Al riavvio è diventato evidente che era così incasinato che anche la console di fallback di initrd non riconosceva più la mia tastiera. È un mistero per me come il sistema sia riuscito a rimanere operativo così a lungo, 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 successivamente nessuna tastiera funzionante 🙂

Il problema era: un aggiornamento ha sostituito il collegamento simbolico /lib -> /usr/lib con una directory. Quindi ciò significava che mancavano tutte le librerie e i moduli del kernel, che dovrebbero essere in /lib 🙂

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

Ora che ho di nuovo Internet, ho anche trovato questo thread

Ho anche usato il gestore di pacchetti del mio installazione su disco bloccata (chiamata pacman) dal CD live per reinstallare tutti i pacchetti del gruppo di base ( forse solo il kernel, quindi il pacchetto linux sarebbe stato sufficiente, non lo so)

Per farlo, monta la partizione principale dellinstallazione in brick su la directory /mnt del sistema Live CD e utilizza chroot per fare in modo che pacman pensi /mnt è / (inserisci la partizione principale del tuo sistema in mattoni 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: crea un link simbolico relativo, quindi ln -s usr/lib /mnt/lib e non ln -s /usr/lib /mnt/lib, perché durante lavvio iniziale del sistema (fase initrd) la partizione principale verrà montata per prima a /new_root.Se il collegamento simbolico fosse assoluto, si otterrebbe lerrore sopra menzionato durante lavvio iniziale.

Commenti

  • Piccolo suggerimento: quando si usa systemrescuecd, spesso si ripete solo su proc / sys / dev (per il percorso in proc sys dev; do mount -obind / $ path / mnt / $ path; done) prima di eseguire il chroot. Tuttavia, se ‘ stai usando arch install iso, è molto più semplice eseguire leseguibile arch-chroot fornito in quanto fa tutto per te. È nel pacchetto arch-install-scripts se qualcuno vuole curiosare. 🙂

Risposta

Stai tentando di eseguire unapplicazione a 32 bit su un sistema operativo a 64 bit, quindi devi installare le librerie di compatibilità a 32 bit (glibc in particolare) prima che possa funzionare.

Commenti

  • Per favore, chiarisci come la tua soluzione risolve il caso e rispondi alla domanda
  • Cosa ha detto Romeo; eseguiresti apt-get su un sistema arch-linux, invece di pacman? E in che modo le librerie di compressione e ncurses li aiuterebbero?

Risposta

Cordiali saluti, mi sono imbattuto nello stesso problema in esecuzione in unimmagine docker basata su alpini. Leseguibile era un ELF a 64 bit e limmagine alpine era a 64 bit e leseguibile funzionava in un contenitore diverso. Quindi presumibilmente le librerie alpine tagliate non erano compatibili con il mio eseguibile. La node.js Docker hub page osserva:

Lavvertenza principale [per essere eseguito 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 sul problemi che potrebbero sorgere e alcuni confronti pro / contro dellutilizzo di immagini basate su Alpine.

La mia soluzione era usare un diverso (ad es. basato su Debian Jessie) immagine del contenitore.

Commenti

  • Grazie per aver collegato questo problema originario dellamministratore di sistema al ” nuovo ” mondo di contenitori!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *