Ricezione del messaggio "non trovato" durante l'esecuzione di un binario a 32 bit su un sistema a 64 bit?

Al momento 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 il /some_path/ location e ho trovato il binario "perl". file nell'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 , vim su di esso ma non appena provo ad eseguirlo – ./perl per esempio – ottengo:zsh: Not found ./perl .

Questa situazione è abbastanza comprensibile per me. Inoltre :

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

Risposta accettata:

Quando non riesci a eseguire un file che dipende da un "caricatore", l'errore che ricevi potrebbe fare riferimento al caricatore piuttosto che al file che stai eseguendo.

• Il caricatore di un eseguibile nativo collegato dinamicamente è la parte del sistema responsabile del caricamento delle librerie dinamiche. È qualcosa come /lib/ld.so o /lib/ld-linux.so.2 , e dovrebbe essere un file eseguibile.
• Il caricatore di uno script è il programma menzionato nella riga shebang, ad es. /bin/sh per 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 in quanto non indica 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 anche per indicare che l'errore riguarda in realtà un file diverso. Alcune shell fanno il lavoro da sole per gli script (leggendo il #! 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.

ldd non funzionerà nemmeno sui binari perché funziona impostando alcune variabili di ambiente speciali e quindi eseguendo il programma, lasciando che il caricatore faccia il lavoro. strace non fornirebbe nemmeno informazioni significative, dal momento che non riporterebbe più di quanto riportato dal kernel e, come abbiamo visto, il kernel non può riportare tutto ciò che sa.

Correlati:modo per determinare il valore ottimale per il parametro bs su dd?

Questa situazione si verifica spesso quando si tenta di eseguire un binario per il sistema (o la famiglia di sistemi) e la superarchitettura corretti ma per la sottoarchitettura errata. Qui hai binari ELF su un sistema che si aspetta 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 il file output indica), cercando il caricatore a 32 bit /lib/ld-linux.so.2 e presumibilmente hai installato solo il caricatore a 64 bit /lib64/ld-linux-x86-64.so.2 nel chroot.

È necessario installare il sistema di runtime a 32 bit nel chroot:il caricatore e tutte le librerie necessarie ai programmi. Da Debian wheezy in poi, se vuoi il supporto sia per i386 che per x86_64, inizia con un'installazione amd64 e attiva il supporto multiarch:esegui dpkg --add-architecture i386 quindi apt-get update e apt-get install libc6:i386 zlib1g:i386 … (se vuoi generare un elenco delle dipendenze del pacchetto perl di Debian, per vedere quali librerie potrebbero essere necessarie, puoi usare aptitude search -F %p '~Rdepends:^perl$ ~ri386' ). Puoi estrarre una raccolta di librerie comuni installando ia32-libs pacchetto (è necessario prima abilitare il supporto multiarch). Su Debian amd64 fino a wheezy, il caricatore a 32 bit è nella libc6-i386 pacchetto. Puoi installare un set più ampio di librerie a 32 bit installando ia32-libs .