为什么在initrd和initramfs中使用nash而不是busybox？

Busybox似乎更通用 。 我以前用过initrd。 您可以select仅在几个应用程序或一吨的应用程序进行编译，具体取决于在初始引导阶段需要多lessfunction。 这使您可以在启动阶段自定义很多事情。

事实certificate，'纳什'在封面上做了很多“东西”，而与“忙碌”的一对一你必须自己努力工作。 在我的情况下，我们有一个CUSTOM Centos-5内核，必须引导到无盘（root-on-nfs）环境，以及基于磁盘的系统上，包括Sata，SAS，MPT RAID控制器，Megaraid *，…附件磁盘。 内核configuration是SO自定义的，当试图处理它并构build内核RPM时，标准的RH / CentOS .spec构build过程barf。 我已经大规模地破解了分布式的.spec文件来解决这些问题，而这本身就是一个主要问题。 在尝试恢复一个尽可能标准的内核时，我已经做了以下的事情，并且绊倒了许多我将要描述的问题 –

a）使用busybox和initramfs进行networking引导

这很好。 我的initramfs.cpio存档文件包含一个静态链接的bb，lvm和一个自定义的lite-weight dhcp客户端，以及该系统使用系统的BIOS PXE启动代码启动的所有以太网驱动程序。 NFS客户端模块（sunrpc，nfs，lockd，…）也位于cpio归档文件中，并由bb加载。 NB。 在我使用的Dell系统上，通过PXE / TFTP启动的vmlinuz映像的大小限制为8MB。 该过程是加载列表中的驱动程序，直到eth0出现，运行dhcp客户端以获取IP地址，networking掩码，主机名和网关。 然后启动networking，并且通过“nfsroot = server：remote-root-fs”命令行参数指定的根f / s被NFS挂载到rootfs（/ newroot）的一个目录中，然后'switch_root -c / dev / console / newroot / sbin / init'从initramfs传输到基于NFS的root f / s。

这里唯一的区别是我提供了一个cpio压缩文件内置到内核中。 在所有其他方面，内核映像和模块由RH / Centos提供。 所有可以作为模块构build的东西（几乎所有东西）都是！

b）通过initramfs和nash启动磁盘

启动到本地（无iSCSI / FC / etc）连接的磁盘或RAID / LVM设置时，为何从busybox切换到“nash”。 简单的答案是，我无法弄清楚使用bb单独完成工作的配方，所以我的cpio归档文件还包含了nash二进制文件以及一个简化的init.nash启动脚本。 一旦我确定我们没有通过networking引导（在内核命令行中没有“nfsroot = …”），我简单地加载适当的模块，然后“运行”纳什脚本，让它做最后阶段提出。 纳什做的，我无法弄清楚如何使用busybox复制的位是：

• 项目清单

  • mkrootdev -t ext3 -o defaults，ro / dev / VolGroup00 / NAS_ROOTFS
  • 回声安装根文件系统。
  • mount / sysroot
  • echo设置其他文件系统。
  • setuproot
  • 回显切换到新的根目录并运行init。
  • switchroot

特别是，最后两个nash内build命令“setuproot”和“switchroot”做了一些我不能复制的东西，尽pipe尝试过了。 特别是，如果我忽略了'setuproot'做了什么，并做了我认为应该做的事情（为/ sysroot挂载创build一个fstab条目，从/ dev – > / sysroot / dev传输任何逻辑卷/设备映射器信息，等等），然后'switch_root / sysroot / sbin / init'它似乎可以工作，但是一旦rc.sysinit得到处理启动命令的简短方法，就会崩溃。 在紧急shell中，我看到除了控制文件之外，“/ dev / mapper /”是空的，并且通常与/ dev / mapper /中的LVM设备节点具有软链接的“/ dev / VolGroup00 /消失了。 为什么在busybox中发生这种情况，而不是nash我不知道，而现在我只能用一个最小的nash脚本来做最后一个setuproot和switchroot到真正的磁盘根f / s。