chroot: impossibile eseguire il comando '/ bin / bash': nessun file o directory

55

Quando eseguo il chrootcomando viene visualizzato un errore:

failed to run command ‘/bin/bash’: No such file or directory

executable chroot

— USER3254789
fonte

1

La domanda può essere considerata un puro duplicato di unix.stackexchange.com/questions/76490/… ? Le risposte alle domande rappresentano una possibile soluzione al problema che merita sicuramente un collegamento, ma ciò non ne fa un duplicato.

— Karl Richter,

1

Il problema per me era che stavo usando un Live CD a 32 bit per montare un disco del sistema operativo a 64 bit e chroot su di esso. Un kernel a 32 bit non può eseguire bash a 64 bit. La soluzione era ottenere un Live CD a 64 bit. (Il duplicato collegato non è del tutto correlato.)

— Leons

Questo non è un duplicato, nonostante la spiegazione della fonte del problema sia applicabile a entrambe le domande. La domanda contrassegnata come duplicata riguarda le librerie mancanti su un'installazione generica, mentre questa domanda riguarda in particolare un errore che si verifica in un ambiente chroot.

— bschlueter,

34

Questo errore indica che non esiste alcuna /bin/bashdirectory all'interno di chroot . Assicurati di indicarlo dove bash(o altra shell) l'eseguibile è nella chrootdirectory.

Se hai /mnt/somedir/usr/bin/bashquindi eseguirechroot /mnt/somedir /usr/bin/bash

— phoops
fonte

2

C'è un file / bin / bash nella cartella rootfs

— USER3254789

2

Potrebbe essere causato da un comando / riga non riuscito nel /root/.bashrco /root/.bash_profilenel tuo chroot. Puoi rinominare temporaneamente questi file? Puoi anche assicurarti che bashsia eseguibile ( chmod +x /chroot/bin/bash)?

— phoops,

aspade @ home-ba: ~ / DebianArm $ sudo chmod + x rootfs / bin / bash. aspade @ home-ba: ~ / DebianArm $ sudo chroot rootfs. chroot: impossibile eseguire il comando '/ bin / bash': nessun file o directory del genere

— USER3254789

38

L'avevo capito. bin / bash è lì, ma non avevo / lib e / lib64 al suo interno. / bin / bash dipende (ofc) da libc, ld-linux, libdl ecc ... Era abbastanza semplice cp -a / usr rootfs /, cp -a / lib rootfs /, cp -a / lib64 rootfs /. (Puoi legare quelli spesso, ma li ho copiati, perché voglio eseguire qualcosa di pericoloso, che potrebbe corrompere quei file in rootfs.) Il messaggio da chroot potrebbe essere più descrittivo. "nessun file o directory del genere" significa in realtà "non posso eseguire questo sh ...".

— Dalibor Filus,

1

@EmilVatai ha aggiunto :-)

— Dalibor Filus,

13

Avevo /bin/bashall'interno della directory chroot, ma non avevo / lib e / lib64 al suo interno. Il messaggio da chroot potrebbe essere più descrittivo. "nessun file o directory di questo tipo" significa in realtà "non posso eseguirlo ...".

/bin/bashdipende ovviamente da libc, ld-linux, libdl ecc., puoi usare ldd /bin/bashper vedere quali librerie richiede.

1) Puoi mount -o bindusare queste directory sotto chroot 2) Oppure puoi copiare queste librerie in chroot, se non ti fidi dell'env chroot per non corromperle, in questo modo:

cp -a /usr rootfs/
cp -a /lib rootfs/
cp -a /lib64 rootfs/

— Dalibor Filus
fonte

questo creerà duplicati .. che non è ottimizzato quando abbiamo un sacco di configurazioni

— yellowandred

1

Questo non crea duplicati se si utilizza il primo metodo (contrassegnato come 1)). Il secondo è utile se si esegue il chroot in un ambiente non attendibile. Ad esempio, hai una partizione con un trojan o qualcosa del genere.

— Dalibor Filus,

4

chroottenta di avviare la shell impostata nella $SHELLvariabile di ambiente per impostazione predefinita, ma la cerca nella nuova directory root, che sembra non contenere /bin/bash, quindi non può avviarsi.

Puoi dire a chroot di avviare un altro programma all'interno della nuova radice semplicemente aggiungendolo come parametro:

chroot /your/new/root /bin/foo --options...

Nota che il percorso del comando è interpretato nella tua nuova radice, quindi in questo esempio il programma chiamato è in realtà in/your/new/root/bin/foo

— crater2150
fonte

2

C'è un file / bin / bash nel file rootfs, quindi qual è il problema

— USER3254789

1

a chiunque abbia effettuato il downvoting: sebbene questo non fosse il problema nel caso del poster, questa è una spiegazione valida e non problematica dell'errore nella domanda. Se riscontri altri problemi, ti preghiamo di lasciare un commento quando effettui il downgrade del voto.

— crater2150,

2

Stavo ottenendo lo stesso errore durante il tentativo di inviare a un account chroot su un server remoto. Nel mio caso, mi mancava il seguente file nella directory lib64 remota. Il server è Centos6.9

ld-linux-x86-64.so.2

È stato risolto eseguendo quanto segue:

cp /lib64/ld-linux-x86-64.so.2 /secure/jail/lib64/

— shawn
fonte

non l'ho risolto per me, ma cp -r /lib /lib64 /secure/jailrisolvendolo, avevo bisogno di qualcosa sia da lib che da lib64, e non mi sono preoccupato di capire esattamente cosa. (probabilmente perché avevo abilitato il multiarch)

— hanshenrik il

0

devi eseguire ldd contro bash ldd $(which bash), quindi potresti trovare una dipendenza mancante, ad esempio se non hai montato / copiato lib64, per 64 sistemi, lo farà attraverso questo errore.

— Errore
fonte

0

Nel caso in cui si stia eseguendo una compilazione incrociata, è necessario utilizzare il simulatore qemu che può eseguire / mnt / somedir / bin / bash dopo aver copiato qemu-arm-static (lo sto facendo per armhf) in / mnt / somedir / usr / bin sarai in grado di fare chroot.

Dai un'occhiata a questo per maggiori dettagli: https://blog.lazy-evaluation.net/posts/linux/debian-armhf-bootstrap.html

— Jainam MJ
fonte

1

Non vi è alcuna indicazione che questo è ciò che l'utente sta cercando di fare.

— Kusalananda

Gli errori sono gli stessi per entrambi i casi. Se qualcuno che sta eseguendo la compilazione incrociata deve affrontare questo problema, può trovare la risposta qui.

— Jainam MJ,