chroot: не вдалося запустити команду '/ bin / bash': Немає такого файлу чи каталогу

54

Коли я запускаю chrootкоманду, видається помилка:

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

executable chroot

— USER3254789
джерело

1

Чи можна вважати питання чистим дублікатом unix.stackexchange.com/questions/76490/… ? Відповіді на питання представляють можливий варіант вирішення проблеми, який, безумовно, варто посилати, але це не робить питання його дублікатом.

— Карл Ріхтер

1

Проблема для мене полягала в тому, що я використовував 32-розрядний компакт-диск Live для монтажу 64-розрядного диска ОС та chroot до нього. 32-розрядне ядро не може запустити 64-розрядну баш. Рішенням було отримати 64-розрядний Live CD. (Зв'язаний дублікат повністю не пов’язаний.)

— Леон

Це не дублікат, незважаючи на пояснення джерела проблеми, що стосується обох питань. Питання, яким це позначено як дублікат, стосується відсутніх бібліотек на загальній установці, тоді як це питання стосується помилки, що виникає в хроноване середовищі.

— bschlueter

33

Ця помилка означає, що в chroot немає /bin/bashкаталогу . Переконайтесь, що ви вказали його на те, де (або інша оболонка) виконується в каталозі.bashchroot

Якщо ви /mnt/somedir/usr/bin/bashтоді виконаєтеchroot /mnt/somedir /usr/bin/bash

— фопс
джерело

2

У папці rootfs є файл / bin / bash

— USER3254789

2

Це може бути викликано деякою невдалою командою / рядком у /root/.bashrcабо /root/.bash_profileу вашому chroot. Чи можете ви тимчасово перейменувати ці файли? Ви також можете переконатися, що bashвиконується ( chmod +x /chroot/bin/bash)?

— foops

aspade @ home-ba: ~ / DebianArm $ sudo chmod + x rootfs / bin / bash. aspade @ home-ba: ~ / DebianArm $ sudo chroot rootfs. chroot: не вдалося виконати команду '/ bin / bash': Немає такого файлу чи каталогу

— USER3254789

37

Я зрозумів це. bin / bash є, але в мене не було / lib та / lib64. / bin / bash залежить (ofc) від libc, ld-linux, libdl тощо ... Отже, простого cp -a / usr rootfs /, cp -a / lib rootfs /, cp -a / lib64 rootfs / було достатньо. (Ви можете монтувати-прив'язувати ці файли ofc, але я скопіював їх, тому що я хочу запустити щось небезпечне, що могло б пошкодити ці файли у rootfs.) Повідомлення від chroot може бути більш описовим. "немає такого файлу чи каталогу" насправді означає "я не можу запустити цю ш ...".

— Далібор Філус

1

@EmilVatai додав :-)

— Далібор Філз

13

Я мав /bin/bashвсередині хронізованого каталогу, але у мене не було / lib та / lib64. Повідомлення від chroot може бути більш описовим. "немає такого файлу чи каталогу" насправді означає "я не можу це запустити ...".

/bin/bashзвичайно залежить від libc, ld-linux, libdl тощо. Ви можете використовувати, ldd /bin/bashщоб побачити, які бібліотеки йому потрібні.

1) Ви можете використовувати mount -o bindці каталоги під chroot 2) Або ви можете скопіювати ці бібліотеки в chroot, якщо ви не довіряєте chrooted env, щоб не пошкодити їх, наприклад:

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

— Далібор Філус
джерело

це створить дублікати .. що не оптимізоване, коли у нас багато налаштувань

— yellowandred

1

Це не створює дублікатів, якщо ви використовуєте перший метод (позначений як 1). Другий з них корисний, якщо ви хотієте не довіреного середовища. Наприклад, у вас є перегородка з трояном або щось подібне.

— Далібор Філус

4

chrootнамагається запустити оболонку, встановлену у вашій $SHELLзмінній оточення за замовчуванням, але вона шукає її у вашому новому кореневому режимі, який, здається, не містить /bin/bash, тому не може запуститися.

Ви можете сказати chroot запустити іншу програму всередині нового кореня, просто додавши його як параметр:

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

Зауважте, що шлях команди інтерпретується всередині вашого нового кореня, тому в цьому прикладі фактично називається програма/your/new/root/bin/foo

— кратер2150
джерело

2

У файлі rootfs є файл / bin / bash, тож у чому проблема

— USER3254789

1

тому, хто виступав проти: хоча це не було проблемою у справі афіші, це дійсне і не спростовне пояснення помилки у питанні. Якщо ви бачите будь-яку іншу проблему, будь ласка, залиште коментар, коли ви щось зволікаєте.

— кратер2150

2

Я отримував таку ж помилку, коли намагався передати ssh до облікового запису на віддаленому сервері. У моєму випадку мені було відсутнє наступний файл у віддаленій директорії lib64. Сервер - Centos6.9

ld-linux-x86-64.so.2

Це було виправлено шляхом виконання наступного:

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

— шон
джерело

не виправляв це для мене, але робив cp -r /lib /lib64 /secure/jailвиправлення, мені було потрібно щось і від lib, і від lib64, і я не намагався зрозуміти, що саме. (напевно, тому, що у мене був включений

— мультиарх

0

вам потрібно запустити ldd проти bash ldd $(which bash), тоді ви можете виявити відсутність залежності, наприклад, якщо ви не змонтували / скопіювали lib64 для 64 систем, це призведе до цієї помилки.

— Помилка
джерело

0

Якщо ви робите перехресну компіляцію, вам потрібно використовувати симулятор qemu, який може запускати / mnt / somedir / bin / bash, коли ви копіюєте qemu-arm-static (я це роблю для armhf) в / mnt / somedir / usr / бін ви зможете зробити chroot.

Перевірте це, щоб отримати докладнішу інформацію: https://blog.lazy-evaluation.net/posts/linux/debian-armhf-bootstrap.html

— Jainam MJ
джерело

1

Немає вказівки на те, що саме це намагається зробити користувач.

— Kusalananda

Помилки однакові для обох випадків. Якщо хтось, хто робить перехресну компіляцію, стикається з цим питанням, він може знайти відповідь тут.

— Jainam MJ