Зачем использовать nash вместо busybox в initrd и initramfs?
Я просто ищу плюсы и минусы обоих действительно (и любых других приложений с аналогичной функциональностью). В настоящее время я склоняюсь к тому, чтобы busybox был лучшим вариантом, но я не могу не задаться вопросом, почему redhat и fedora используют nash в своих initrd.
Это чисто по деловым причинам или по техническим причинам?
Спасибо, Ченз
Оказывается, nash делает много "вещей" под прикрытием, в то время как с "busybox" all-in-1 вы должны делать большую часть тяжелой работы самостоятельно. В моем случае у нас есть ПОЛЬЗОВАТЕЛЬСКОЕ ядро Centos-5, которое должно загружаться в бездисковую среду (root-on-nfs), а также в дисковых системах с подключенными контроллерами Sata, SAS, MPT, Megaraid *, ... диски. Конфигурация ядра настолько индивидуальна, что стандартные процедуры сборки RH / Centos .spec не работают при попытке обработать ее и построить RPM ядра. Я массово взломал распространяемый файл .spec, чтобы обойти эти проблемы, и это само по себе является серьезной проблемой. Пытаясь вернуться к ядру, которое является максимально стандартным, я сделал следующее и наткнулся на многие проблемы, некоторые из которых я опишу:
а) Загрузка по сети с помощью busybox и initramfs
Это прекрасно работает. Мой архив initramfs.cpio содержит статически связанный bb, lvm и пользовательский облегченный dhcp-клиент, а также все драйверы Ethernet, которые эта система когда-либо будет загружать, используя системный загрузочный код PXE BIOS. Клиентские модули NFS (sunrpc, nfs, lockd, ...) также находятся в архиве cpio и загружаются с помощью bb. NB. Размер образа vmlinuz, загружаемого через PXE / TFTP, ограничен 8 МБ в имеющихся у меня системах Dell. Процедура состоит в том, чтобы загружать драйверы в список, пока не появится eth0, запустить клиент DHCP, чтобы получить IP-адрес, сетевую маску, имя хоста и шлюз. Затем сеть запускается, и корневой файловый сервер, указанный с помощью аргумента командной строки "nfsroot = server: remote-root-fs", монтируется по NFS в каталог в rootfs (/ newroot), затем 'switch_root -c / dev / console / newroot / sbin / init 'для передачи из initramfs в корень f / s на основе NFS.
Единственная разница здесь в том, что я поставляю архив cpio для встраивания в ядро. Во всем остальном образ ядра и модули поставляются RH / Centos. Все, что можно построить как модуль (и почти все), есть!
б) Загрузка с диска через initramfs и nash
Зачем переключаться с busybox на nash при загрузке с локального (без iSCSI / FC и т. Д.) Подключенного диска или при установке raid / LVM. Простой ответ заключается в том, что я не могу понять рецепт выполнения работы, используя только bb, поэтому мой архив cpio также включает двоичный файл nash вместе с сокращенным сценарием запуска init.nash. Как только я определил, что мы не загружаемся по сети (нет «nfsroot = ...» в командной строке ядра), я просто загружаю соответствующие модули, затем выполняю сценарий nash и позволяю ему выполнять заключительные этапы воспитание. Биты, которые делает nash, которые я НЕ мог понять, как реплицировать с помощью busybox:
Элемент списка
В частности, последние две встроенные команды nash «setuproot» и «switchroot» делают то, что я не могу воспроизвести, несмотря на попытки. В частности, если я проигнорирую то, что делает setuproot, и сделаю то, что, по моему мнению, должно быть сделано (создайте запись fstab для монтирования / sysroot, перенесу любую информацию о логическом томе / устройстве-сопоставлении из / dev -> / sysroot / dev, etc), а затем 'switch_root / sysroot / sbin / init', похоже, он работает, но затем вылетает, как только rc.sysinit получает короткий путь к обработке команд запуска. В аварийной оболочке я вижу, что «/ dev / mapper /» пуст, кроме управляющего файла, и что каталог «/ dev / VolGroup00 /», который обычно имеет программные ссылки на узлы устройства LVM в / dev / mapper /, полностью исчезнувший. Почему это происходит с busybox, а не с nash, я не знаю, и на данный момент я просто буду жить с exec'ing минимальным сценарием nash, чтобы выполнить последний бит setuproot и переключить root на настоящий корень диска f / s.
Busybox вроде бы больше универсальный. Я использовал его раньше для initrd. Вы можете компилировать только несколько приложений или тонну из них, в зависимости от того, какая функциональность вам нужна на начальном этапе загрузки. Это позволяет вам настраивать множество вещей на этапе загрузки.