Messaggio "Non trovato" quando si esegue un file binario a 32 bit su un sistema a 64 bit

Attualmente ho uno strano problema su debian (wheezy / amd64).

Ho creato un chroot per installare un server (non posso fornire ulteriori dettagli a riguardo, mi dispiace). Chiamiamo il suo percorso /chr_path/. Per semplificare le cose, ho inizializzato questo chroot con un debootstrap (anche wheezy / amd64).

Tutto sembrava funzionare bene all'interno del chroot ma quando ho avviato lo script di installazione del mio server ho ottenuto: zsh: Not found /some_path/perl(il programma di installazione include un binario perl per alcuni motivi)

Naturalmente, ho controllato la /some_path/posizione e ho trovato il binario "perl". filenell'ambiente chroot restituisce:

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

Il file esiste, sembra ok, ha i diritti corretti. Posso usare file, ls, vimsu di essa ma non appena provo ad eseguirlo - ./perlper esempio - ottengo: zsh: Not found ./perl.

Questa situazione è abbastanza comprensibile per me. Inoltre :

Posso eseguire altri file binari di base (/ bin / ls, ...) nel chroot senza ottenere errori
Ho gli stessi problemi per altri file binari forniti con il progetto
Quando provo ad eseguire il binario dalla radice principale ( /chr_path/some_path/perl), funziona.
Ho provato a mettere uno dei binari con una mia copia ls. Ho verificato che i diritti di accesso fossero gli stessi, ma ciò non ha cambiato nulla (uno funzionava e l'altro no)

— Elenaher
fonte

Questo è lo stesso problema di "Nessun file o directory" si trova nei file binari installati di Optware . Nota che il tuo Perl è un eseguibile a 32 bit. Ti manca il sistema di runtime a 32 bit ( libc6-i386pacchetto o ia32-libsse vuoi molte librerie).

— Gilles 'SO- smetti di essere malvagio'

@Gilles: grazie mille! Un'installazione aptitude ia32-libs ha risolto il problema !! Avevo visto che il perl era di 32 bit ma dato che stava lavorando sul sistema principale (stesso distrib) avevo appena pensato che non fosse collegato. In realtà, devo aver installato il sistema di runtime a 32 bit sul sistema principale ad un certo punto.

— Elenaher,

@Gilles: penso che aggiungerei questa come una risposta concisa invece di contrassegnarla come una domanda duplicata. L'ambiente è abbastanza diverso che, anche se il problema è lo stesso, è più probabile che le persone che effettuano ricerche colpiscano l'uno o l'altro.

— Caleb,

@Caleb Non cancelliamo i duplicati proprio per questo motivo; i ricercatori che trovano questo seguiranno semplicemente il link duplicato all'altro post. Se questo è lo stesso problema, probabilmente dovrebbe essere chiuso

— Michael Mrozek

@MichaelMrozek Ho cambiato idea su questa domanda: mentre il problema di fondo è lo stesso, il rimedio concreto è un po 'diverso (non mescolare ABI ARM in un caso, abilitando il supporto a 32 bit su una distribuzione Linux amd64 nell'altro) . Quindi suppongo che questa domanda sia aperta dopo tutto.

— Gilles 'SO- smetti di essere malvagio' il

Risposte:

Quando non si riesce a eseguire un file che dipende da un "caricatore", l'errore che si ottiene può riferirsi al caricatore anziché al file che si sta eseguendo.

Il caricatore di un eseguibile nativo collegato dinamicamente è la parte del sistema che è responsabile del caricamento delle librerie dinamiche. È qualcosa di simile /lib/ld.soo /lib/ld-linux.so.2e dovrebbe essere un file eseguibile.
Il caricatore di uno script è il programma menzionato sulla riga shebang, ad esempio /bin/shper uno script che inizia con #!/bin/sh. (Bash e zsh danno un messaggio "cattivo interprete" invece di "comando non trovato" in questo caso.)

Il messaggio di errore è piuttosto fuorviante nel non indicare che il caricatore è il problema. Sfortunatamente, risolvere questo problema sarebbe difficile perché l'interfaccia del kernel ha spazio solo per segnalare un codice di errore numerico, non per indicare anche che l'errore riguarda effettivamente un file diverso. Alcune shell eseguono il lavoro autonomamente per gli script (leggendo la #!riga sullo script e rielaborando la condizione di errore), ma nessuno di quelli che ho visto tenta di fare lo stesso per i binari nativi.

lddnon funzionerà sui binari perché funziona impostando alcune variabili d'ambiente speciali e quindi eseguendo il programma, lasciando che il caricatore faccia il lavoro. stracenon fornirebbe alcuna informazione significativa, dal momento che non riferirebbe più di quello che riporta il kernel, e come abbiamo visto il kernel non può riportare tutto ciò che sa.

Questa situazione si presenta spesso quando si tenta di eseguire un binario per il sistema giusto (o la famiglia di sistemi) e la superarchitettura ma la sottoarchitettura errata. Qui hai binari ELF su un sistema che prevede binari ELF, quindi il kernel li carica bene. Sono binari i386 in esecuzione su un processore x86_64, quindi le istruzioni hanno senso e portano il programma al punto in cui può cercare il suo caricatore. Ma il programma è un programma a 32 bit (come fileindica l' output), cercando il caricatore a 32 bit /lib/ld-linux.so.2e presumibilmente hai installato solo il caricatore /lib64/ld-linux-x86-64.so.2a 64 bit nel chroot.

Devi installare il sistema di runtime a 32 bit nel chroot: il caricatore e tutte le librerie di cui i programmi hanno bisogno. Da Debian wheezy in poi, se si desidera sia il supporto i386 che x86_64, iniziare con un'installazione amd64 e attivare il supporto multiarch : eseguire dpkg --add-architecture i386quindi apt-get updatee apt-get install libc6:i386 zlib1g:i386 …(se si desidera generare un elenco delle dipendenze del pacchetto perl di Debian, per vedere quali librerie sono probabili essere necessario, è possibile utilizzare aptitude search -F %p '~Rdepends:^perl$ ~ri386'). Puoi inserire una raccolta di librerie comuni installando il ia32-libspacchetto (devi prima abilitare il supporto multiarch). Su Debian amd64 fino a wheezy, il caricatore a 32 bit è nel libc6-i386pacchetto. È possibile installare un set più grande di librerie a 32 bit installando ia32-libs.

— Gilles 'SO- smetti di essere malvagio'
fonte

È l'unica cosa che può attivare il messaggio di errore? Ho installato le librerie a 32 bit ed ecco l'output dildd ma ho ancora lo stesso errore.

— Nathan Osman,

@NathanOsman Probabilmente unix.stackexchange.com/questions/76490/…

— Gilles 'SO- smetti di essere malvagio'

Ho provato a installare lsb-corema questo non sembra aiutare. Penso che sia meglio aprire una nuova domanda per questo.

— Nathan Osman,

Grazie per questo, hai appena finito due giorni di grattarsi la testa. Pensavo che tutto fosse stato compilato staticamente ma non lo era!

— Finn O'leary,

Esegui ldd(1)sul tuo perlbinario. Spesso l' Not founderrore apparentemente confuso su un file chiaramente presente è dovuto al fatto che non è stata trovata una delle librerie condivise utilizzate dal programma.

Quindi è possibile che il chroot sia incompleto rispetto alle librerie condivise necessarie ai tuoi binari.

— CAMH
fonte

In realtà ottengo: perl is not a dynamic executablequando sono nella chroot e ottengo l'elenco corretto delle dipendenze dall'esterno. Attualmente sto controllando se c'è qualcosa di strano ma ho usato un debootstrap per evitare questo tipo di mancanza e ho già molte librerie in atto (c'è un eseguibile perl nel sistema chroot che funziona bene ma è una versione diversa; forse ne farò solo un po ' link simbolico?)

— Elenaher,

Ad essere sincero, mi sarei aspettato che debootstrap avesse prodotto un chroot completo, quindi non mi sarei aspettato che la mia risposta fosse corretta al riguardo. Ma ho già incontrato la libreria mancante nel problema chroot prima, quindi ho pensato di vedere se la mia risposta sarebbe volata.

— Camh,

cf. commento a Gilles sul post principale: avevi ragione. Mancavano alcune librerie. Il vantaggio principale di debootstrap è che potrei risolvere il problema con un'installazione aptitude di base :)

— Elenaher,