chroot: nie można uruchomić polecenia „/ bin / bash”: nie ma takiego pliku ani katalogu

54

Po uruchomieniu chrootpolecenia pojawia się błąd:

failed to run command ‘/bin/bash’: No such file or directory
executable chroot USER3254789
źródło
1
Czy to pytanie można uznać za czysty duplikat unix.stackexchange.com/questions/76490/... ? Odpowiedzi na pytania stanowią możliwe rozwiązanie problemu zdecydowanie warte linku, ale to nie czyni z niego duplikatu.
Karl Richter,
1
Problemem było to, że korzystałem z 32-bitowego Live CD, aby zamontować 64-bitowy dysk systemu operacyjnego i chroot na nim. 32-bitowe jądro nie może uruchomić 64-bitowej wersji bash. Rozwiązaniem było uzyskanie 64-bitowej płyty CD na żywo. (Połączony duplikat jest całkowicie niezwiązany.)
Leons
Nie jest to duplikat, mimo że wyjaśnienie źródła problemu dotyczy obu pytań. Pytanie oznaczone jako duplikat dotyczy brakujących bibliotek w instalacji ogólnej, podczas gdy pytanie dotyczy konkretnie błędu występującego w środowisku chroot.
bschlueter

Odpowiedzi:

33

Ten błąd oznacza, że w chroot nie ma /bin/bashkatalogu . Upewnij się, że wskazałeś, gdzie znajduje się plik wykonywalny (lub innej powłoki) w katalogu.bashchroot

Jeśli masz /mnt/somedir/usr/bin/bashto wykonaćchroot /mnt/somedir /usr/bin/bash

phoops
źródło
2
W folderze
rootfs
2
Może to być spowodowane błędem polecenia / wiersza w twoim /root/.bashrclub . Czy możesz tymczasowo zmienić nazwę tych plików? Czy możesz także upewnić się, że jest wykonywalny ( )? /root/.bash_profilechrootbashchmod +x /chroot/bin/bash
phoops
aspade @ home-ba: ~ / DebianArm $ sudo chmod + x rootfs / bin / bash. aspade @ home-ba: ~ / DebianArm $ sudo chroot rootfs. chroot: nie można uruchomić polecenia '/ bin / bash': Brak takiego pliku lub katalogu
USER3254789
37
Rozgryzłem to. bin / bash już tam jest, ale nie miałem w nim / lib i / lib64. / bin / bash zależy (ofc) od libc, ld-linux, libdl itp. Tak prosty wystarczy cp -a / usr rootfs /, cp -a / lib rootfs /, cp -a / lib64 rootfs /. (Możesz montować-bindować te ofc, ale skopiowałem je, ponieważ chcę uruchomić coś niebezpiecznego, co może uszkodzić te pliki w rootfach.) Wiadomość od chroot może być bardziej opisowa. „brak takiego pliku lub katalogu” naprawdę oznacza „Nie mogę uruchomić tego sh ...”.
Dalibor Filus
1
@EmilVatai dodał :-)
Dalibor Filus
13

Miałem /bin/bashwewnątrz katalogu chrootowanego, ale nie miałem w nim / lib i / lib64. Wiadomość z chroot może być bardziej opisowa. „brak takiego pliku lub katalogu” naprawdę oznacza „Nie mogę uruchomić tego ...”.

/bin/bashzależy oczywiście od libc, ld-linux, libdl itp. Możesz użyć, ldd /bin/bashaby zobaczyć, jakich bibliotek potrzebuje.

1) Możesz mount -o bindte katalogi w chroot 2) Lub możesz skopiować te biblioteki do chroot, jeśli nie ufasz chrootowanej env, aby ich nie uszkodzić, tak jak:

cp -a /usr rootfs/
cp -a /lib rootfs/
cp -a /lib64 rootfs/
Dalibor Filus
źródło
spowoduje to utworzenie duplikatów .. co nie jest zoptymalizowane, gdy mamy wiele ustawień
yellowandred
1
Nie tworzy to duplikatów, jeśli używasz pierwszej metody (oznaczonej jako 1). Drugi jest przydatny, jeśli chrootujesz do niezaufanego środowiska. Na przykład masz partycję z trojanem lub coś takiego.
Dalibor Filus
4

chrootpróbuje uruchomić powłokę ustawioną $SHELLdomyślnie w zmiennej środowiskowej, ale szuka jej w nowym katalogu głównym, który wydaje się nie zawierać /bin/bash, więc nie może się uruchomić.

Możesz powiedzieć chrootowi, aby uruchomił inny program w nowym katalogu głównym, po prostu dodając go jako parametr:

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

Zauważ, że ścieżka polecenia jest interpretowana w twoim nowym katalogu głównym, więc w tym przykładzie wywoływany program jest w rzeczywistości/your/new/root/bin/foo

krater2150
źródło
2
W pliku rootfs znajduje się plik / bin / bash, więc w czym problem
USER3254789
1
każdemu, kto zlekceważył opinię: chociaż nie był to problem w przypadku plakatu, jest to prawidłowe i nieproblemowe wyjaśnienie błędu w pytaniu. Jeśli zauważysz inny problem, zostaw komentarz, gdy coś głosujesz.
crater2150,
2

Otrzymałem ten sam błąd podczas próby ssh do konta chrootowanego na zdalnym serwerze. W moim przypadku brakowało następującego pliku w zdalnym katalogu lib64. Serwer to Centos6.9

ld-linux-x86-64.so.2

Zostało to naprawione poprzez wykonanie następujących czynności:

cp /lib64/ld-linux-x86-64.so.2 /secure/jail/lib64/
Shawn
źródło
nie naprawiłem tego, ale robiąc cp -r /lib /lib64 /secure/jailto, potrzebowałem czegoś zarówno z lib, jak i lib64, i nie zadałem sobie trudu, aby dowiedzieć się dokładnie, co. (prawdopodobnie dlatego, że mam włączoną funkcję multiarch)
hanshenrik
0

musisz uruchomić ldd przeciwko bashowi ldd $(which bash), wtedy możesz znaleźć brakującą zależność, na przykład jeśli nie zainstalowałeś / nie skopiowałeś lib64, dla 64 systemów, przejdzie przez ten błąd.

Błąd
źródło
0

Jeśli wykonujesz kompilację krzyżową, musisz użyć symulatora qemu, który może uruchomić / mnt / somedir / bin / bash po skopiowaniu qemu-arm-static (robię to dla armhf) do / mnt / somedir / usr / bin będziesz mógł zrobić chroot.

Sprawdź to, aby uzyskać więcej informacji: https://blog.lazy-evaluation.net/posts/linux/debian-armhf-bootstrap.html

Jainam MJ
źródło
1
Nic nie wskazuje na to, że użytkownik chce to zrobić.
Kusalananda
Błędy są takie same dla obu przypadków. Jeśli ktoś, kto wykonuje kompilację krzyżową, napotyka ten problem, może znaleźć odpowiedź tutaj.
Jainam MJ