Назад | Перейти на главную страницу

Chroot при запуске

У меня есть сценарий, который запускается при запуске, но он не запускает приложение в chroot.

#!/bin/sh 
/usr/sbin/chroot /root/chrootdir/ /bin/sh -c "lighttpd -f /etc/lighttpd.conf -m /lib" 
echo "script activated" >> /log/www.log

файл журнала записывается / добавляется при запуске, но сервер lighttpd не запускается. Запуск сценария при работающем ящике работает нормально и запускает lighttpd. Это встроенная система с ядром linux и busybox. inittab запускает /etc/init.d/rcS, который, в свою очередь, запускает мой скрипт start_www. сценарий start_www - это последнее, что запускает rcS.

Обновить:

/ bin / sh: ошибка при загрузке разделяемых библиотек: libm.so.6: невозможно открыть файл общих объектов: нет такого файла или каталога

но libm.so.6 находится в /root/chrootdir/lib/libm.so.6, что теперь делать? как указать путь к libm.so? безуспешно попробовал команду «export LD_LIBRARY_PATH = / lib; lighttpd -f /etc/lighttpd.conf -m / lib».

Обновление 2: . когда я запускаю команду:

chroot / root / chrootdir / / sbin / lighttpd -f /etc/lighttpd.conf -m / lib

он запускает веб-сервер без каких-либо предупреждений или ошибок. Но когда я запускаю тот же сценарий во время запуска, он внезапно не может найти библиотеки. Внутри моего chrootdir я получил файл .profile, содержащий:

экспорт LD_LIBRARY_PATH = / lib

я предполагаю, что файл настроек .profile не используется во время запуска, как мне установить путь к библиотеке?

Вы можете создать сценарий инициализации для lighttpd, а затем передать во время выполнения LD_LIBRARY_PATH в командной строке, так что вам будет наплевать на .profile и так далее. Синтаксис, например

# LD_LIBRARY_PATH=/lib/:/usr/local/lib/ myCommand

Вы также можете использовать команду ldd для проверки связанных библиотек.

Вместо того chroot-выпуск /bin/sh -c "lighttpd -f /etc/lighttpd.conf -m /lib" попробуйте запустить ту же команду внутри сценария оболочки, помещенного в chroot, вроде:

/sbin/chroot /root/chrootdir/ /start_it_up.sh

UPD.: Итак, накопив все, что я предложил в своих комментариях к этому ответу:

  1. mount --bind ваши родительские системные библиотеки помещаются в каталоги chroot lib - по крайней мере, чтобы проверить, будет ли он вообще работать
  2. Использовать флаг ld LD_DEBUG=files чтобы узнать, какие зависимости могут быть у некоторых библиотек, поскольку они также влияют на общий отказ предварительной загрузки целевой

Сможете ли вы восстановить glibc с его помощью?

./configure --prefix=/usr --enable-add-ons --libexecdir=/lib