Por que usar o nash em vez do busybox no initrd e no initramfs?
Estou apenas procurando por prós e contras de ambos (e quaisquer outros aplicativos com funcionalidade semelhante). Atualmente estou inclinado para o busybox sendo a melhor opção, mas não posso deixar de me perguntar por que o redhat e o fedora usam o nash em seu initrd.
É estritamente por motivos comerciais ou é técnico?
Obrigado Chenz
O Busybox parece ser mais versátil . Eu usei isso antes para o initrd. Você pode optar por compilar em apenas alguns aplicativos ou uma tonelada deles, dependendo de quanto funcionalidade você precisava durante o estágio inicial de inicialização. Isso permite que você personalize muitas coisas durante o estágio de inicialização.
Acontece que 'nash' faz um monte de 'coisas' embaixo das capas, enquanto com o 'busybox' all-in-1 você tem que fazer mais o trabalho duro sozinho. No meu caso, temos um kernel Centoso-CUSTOM-5 que deve ser inicializado em um ambiente sem disco (root-on-nfs), bem como em sistemas baseados em disco com controladores raid Sata, SAS, MPT, Megaraid *, ... discos. A configuração do kernel é tão personalizada que o padrão RH / Centos .spec constrói barf de procedimentos ao tentar processá-lo e construir o RPM do kernel. Eu hackei massivamente o arquivo .spec distribuído para contornar esses problemas, e isso por si só é um grande problema. Na tentativa de reverter para um kernel que é tão padrão quanto possível eu fiz o seguinte, e tropecei em muitos problemas, alguns dos quais eu vou descrever -
a) Inicialização da rede com o busybox e o initramfs
Isso funciona muito bem. Meu arquivo initramfs.cpio contém um bb dhvp vinculado estaticamente, e um cliente dhcp de peso leve personalizado, junto com todos os drivers Ethernet que esse sistema irá inicializar usando o código de inicialização do BIOS PXE do sistema. Os módulos do cliente NFS (sunrpc, nfs, lockd, ...) também estão no arquivo cpio e são carregados pelo bb. NB O tamanho da imagem vmlinuz que é inicializada via PXE / TFTP é limitado a 8 MB nos sistemas da Dell que eu tenho. O procedimento é carregar os drivers em uma lista até que apareça uma eth0, execute o cliente dhcp para obter um endereço IP, uma máscara de rede, um nome de host e um gateway. Então a rede é ativada, e a raiz f / s especificada através do argumento de linha de comando "nfsroot = server: remote-root-fs" é montada pelo NFS em um diretório no rootfs (/ newroot), então 'switch_root -c / dev / console / newroot / sbin / init 'para transferir do initramfs para a raiz f / s baseada em NFS.
A única diferença aqui é que eu forneço um arquivo cpio para ser embutido no kernel. Em todos os outros aspectos, a imagem e os módulos do kernel são fornecidos pela RH / Centos. Tudo o que pode ser construído como um módulo (e que quase tudo) é!
b) Inicialização de disco via initramfs e nash
Por que mudar de busybox para 'nash' ao inicializar para um disco anexado local (sem iSCSI / FC / etc) ou instalação de raid / LVM. A resposta simples é que eu não consigo descobrir a receita para fazer o trabalho usando apenas bb, então meu arquivo cpio também inclui o binário nash junto com um script de inicialização init.nash reduzido. Uma vez que eu determinei que não estamos inicializando pela rede (sem "nfsroot = ..." na linha de comando do kernel), eu simplesmente carrego os módulos apropriados, então 'exec' o script nash e deixo que ele faça os estágios finais de o surgimento. Os bits que o nash faz que eu não consegui descobrir como replicar usando o busybox são:
Item da lista
Em particular, os dois últimos comandos embutidos nash, 'setuproot' e 'switchroot', fazem algo que não posso replicar, apesar de ter tentado. Em particular, se eu ignorar o que 'setuproot' faz e faz o que eu acho que deveria ser feito (crie uma entrada fstab para a montagem / sysroot, transfira qualquer informação de volume lógico / mapeador de dispositivo de / dev - > / sysroot / dev , etc) e, em seguida, 'switch_root / sysroot / sbin / init' parece funcionar, mas depois deixa de funcionar uma vez rc.sysinit fica um curto caminho para o processamento dos comandos de inicialização. No shell de emergência, vejo que "/ dev / mapper /" está vazio, além do arquivo de controle, e que o diretório "/ dev / VolGroup00 /" que normalmente possui softlinks para os nós do dispositivo LVM em / dev / mapper / foi completamente desaparecido. Por que isso ocorre com busybox e não nash eu não sei, e no momento eu vou viver com exec'ing um script mínimo de nash para fazer o último bit de setuproot e switchroot para a raiz do disco real f / s.