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

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