busybox制作initrd.img和根文件系统
参考书籍：《深度探索Linux操作系统 系统构建和原理解析》
参考博客：https://blog.****.net/mao0514/article/details/51248738
（一）开发环境介绍
1．使用win7_64的笔记本安装Virtualbox虚拟机，笔记本cpu为i5-2450m。虚拟机上安装Ubuntu16.04系统作为编译环境，同时虚拟机也作为最小系统运行环境。
2．最小系统使用Linux内核版本选择4.15.0，内核配置使用x86_64默认配置（即使用命令make x86_64_defconfig）。busybox选择版本1.30.0，使用busybox制作initrd.img，并且同使用busybox制作根文件系统，busybox编译配置相同，只需要在默认配置上修改为静态链接（setting–Build static binary ）。
3．在根目录新建文件夹/vita作为新系统启动分区，使用gparted分配10G（大小随便）给新分区，新分区设备文件为/dev/sda3。将新分区挂载在/vita目录，在此目录下新建/boot用于存放bzImage和initrd.img。同时/vita也存放根文件系统。制作好的目录如下：
（二）制作initrd.img
1．下载busybox包，解压，配置，编译，安装等步骤之后，会在当前目录下生产_install目录，里面有一些不依赖其他库的静态进程，可以直接运行。
我们首先将_install拷贝到initramfs目录用于生成initrd.img
mkdir initramfs
cp -R busybox-1.30.0/_install/* initramfs/
cd initramfs
2．测试initrd。由于内核将initrd.img镜像解压到根文件系统后就将运行权交于initrd.img中的/init程序,所以我们可以自行选择是否要加载根文件系统，可以不加载根文件系统直接使用initrd.img里的内容做根文件系统，下面进行两种测试，单独运行initrd.img。
（1）测试一：使用linuxrc的内容作为启动脚本
① 由于我们使用initramfs，所以内核运行时是找init文件而不是linuxrc，所以直接将linuxrc改名为init
mv linuxrc init
这里可以稍微解释下linuxrc的运行原理，在busybox的源码下/init/init.c有如下内容：
表明linuxrc的作用和init一样，也就是执行linuxrc就是执行/sbin/init。我们知道busybox使用软链接将一个进程链接成多个进程，然后通过main函数args的第一个参数（也就是进程名）来区分具体执行哪一个,我们直接把文件名该为init其实就相当于执行了/sbin/init程序。
② 新建文件夹，添加配置文件
mkdir dev etc lib mnt proc sys
配置文件可以选择busybox里面的例子，在busybox-1.30.0\examples\bootfloppy\etc目录下，可以找到相关文件
将这些文件拷贝到initramfs/etc下，于是etc结构如下。
cp -R ../busybox-1.30.0/examples/bootfloppy/etc/* etc/
之所以要添加配置文件是因为/init程序等同于/sbin/init，了解linux system V启动方式的同学肯定知道，/sbin/bin会根据/etc/inittab的配置内容进行相关配置，如果这里不进行配置运行内核时会首先提示找不到rcS文件，也即“can’t run ‘/etc/init.d/rcS’: No such file or directory”。
这里稍微解释下各个文件内容
etc/inittab
::sysinit:/etc/init.d/rcS
::respawn:-/bin/sh
tty2::askfirst:-/bin/sh
::ctrlaltdel:/bin/umount -a -r
简单说就是每一行表示一种执行策略，例如第一行表示在系统启动时执行RCS，第二行表示如果sh挂了会自动重启sh，第三行表示使用tty2启动的sh启动时会首先询问，第四行表示使用ctrl+alt+del快捷键时执行的程序。这里我们改下配置内容
::sysinit:/etc/init.d/rcS
console::respawn:-/bin/sh
将sh启动的控制程序交给console，并且删除其他操作。
etc/fstab
proc /proc proc defaults 0 0
fstab表示系统启动时默认挂载的文件系统，通常可以把一些特殊文件系统挂载下，例如/proc,/sysfs
etc/profile
# /etc/profile: system-wide .profile file for the Bourne shells
echo
echo -n "Processing /etc/profile... "
# no-op
echo "Done"
echo
profile通常是使用tty并进行登录时才会用到，profile是通常会调用~/.bashrc的配置修改用户环境变量。
etc/init.d/rcS
#! /bin/sh
/bin/mount -a
rcS在这里是作为inittab的启动脚本
③ 添加控制台设备文件
内核在准备好initramfs后会判断/dev/console是否存在，不存在就报错，存在就会继续执行/init并将以后的输出输出到控制台中。
mknod dev/console c 5 1
mknod dev/null c 1 3
④ 配置grub，在/boot/grub.cfg中先新建菜单项，可以参考我的上一篇博客“Linux内核学习（3）最小系统制作”，再配置initrd的参数，表示initrd.img的位置，例如：
⑤ 生成initrd.img文件，并将此文件拷贝到/boot下，最后再重启
find . |cpio -o -H newc|gzip ../initrd3.img
cp ../initrd3.img /vita/boot
⑥ 在grub菜单中选择自己新建的菜单
启动后结果如下，执行下ls，发现只有initrd.img里面的内容，而不是根文件系统/vita下的内容
（2）测试二：自定义/init脚本
① 可以直接在上述基础上进行，也就是修改/init的内容。
rm init
vim init
init：
#!/bin/sh
#
echo "exec initramfs init"
echo "mounting proc and sys"
mount -t proc proc /proc
mount -t sysfs sysfs /sys
echo "detect and export hardware info"
mdev -s
echo "start /bin/sh"
exec /bin/sh
这里注意不能直接执行/bin/sh,需要先先挂载proc和sysfs，然后创建设备结点，否则会造成如下错误，表示init执行错误。mdev的作用是将sysfs文件系统下扫描的设备在/dev下创建设备结点。
② 修改init后的步骤和上述“测试一”一样，重启后显示如下
结果虽然执行了sh，但是仍有提示“can’t access tty”,而且部分busybox功能失效，例如执行reboot无任何反映，应该是未执行相关初始化的原因。但是我们这里只是测试，所以无需纠结。
3．使用initrd启动根文件系统
（1）当initrd中充当挂载根文件系统的桥梁时，这时initramfs/etc下可以不需要配置(这里我们依旧保留，其实没有使用)，而应当把配置文件移动到根文件系统中。
（2）修改initramfs/init启动脚本
vim init
init：
#!/bin/sh
#
echo "exec initramfs init"
echo "mounting proc and sys"
mount -t proc proc /proc
mount -t sysfs sysfs /sys
echo "detect and export hardware info"
mdev -s
echo "Mount real rootfs to /mnt/sysroot..."
mount -t ext4 /dev/sda3 /mnt/sysroot
echo "Switch to read rootfs..."
exec switch_root /mnt/sysroot /sbin/init
这里我们多执行了两步操作，挂载根文件系统/dev/sda3到/mnt/sysroot目录，执行switch_root切换根文件系统目录到/mnt/sysroot下，并且执行/sbin/init。
（三）制作根文件系统
1．制作根文件系统和initrd.img步骤相差无几，首先是一样的拷贝基本文件。
cp -R ../busybox-1.30.0/_install/* /vita
2．配置文件
cp -R etc/* /vita/etc/
3．创建相关文件,删除无用文件
cd /vita
mkdir -p dev etc lib mnt/sysroot proc sys
rm linuxrc
4．修改下fstab和rcS
vim etc/fstab
fstab:
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
添加sysfs的挂载
vim etc/init.d/rcS
rcS:
#!/bin/sh
/bin/mount -a
mdev -s
自动创建设备结点
5．重启
可以看到log都正确的打印，输入ls后看到的目录的确是/vita目录，也就是正确切换到根文件系统了。
（四）常见错误
1．“Failed to create /dev/root:”，这种错误有时候会被误解为驱动问题，其实查看kernel源码会发现有如下调用顺序：
可以看到，如果init文件不存在（没指定参数时默认启动init），内核会主动挂载根文件系统，但是如果没有进行任何先前动作就去挂载一般都会失败，例如需要先进行挂载/proc和/sysfs。所以如果我们忘记在initrd.img中写/init会出现这种错误。
2．“can’t run ‘/etc/init.d/rcS’: No such file or directory”，这种错误比较常见，但是经常不那么容易弄懂。
我这里说一种我出现的问题，花了比较长的时间才解决。
首先我的根文件系统明明已经写了rcS而且也没有任何乱码，仔细检查根文件系统明明没有任何问题。这时我突然想到，如果无意间执行了initrd.img中的/sin/init程序，那么此程序会检查有没有/etc/inittab配置，如果没有此会默认执行/etc/init.d/rcS脚本，而如果/etc下什么文件都没有，那么首先报的问题就是缺少/etc/init.d/rcS。后来我仔细检查initrd.img/init内容发现并没有执行到initrd.img/sbin/init。虽然没有解决问题，但是我却发现了另外一个问题，initrd.img/init文件没有执行权限，也就是如下：
可以看到init文件的权限没有可执行权限，但是这个问题会影响到rcS吗，我又研究了一下kernel的源码，发现有如下片段：
if (ramdisk_execute_command) {
ret = run_init_process(ramdisk_execute_command);
if (!ret)
return 0;
pr_err("Failed to execute %s (error %d)\n",
ramdisk_execute_command, ret);
}
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
ret = run_init_process(execute_command);
if (!ret)
return 0;
panic("Requested init %s failed (error %d).",
execute_command, ret);
}
if (!try_to_run_init_process("/sbin/init") ||
!try_to_run_init_process("/etc/init") ||
!try_to_run_init_process("/bin/init") ||
!try_to_run_init_process("/bin/sh"))
return 0;
ramdisk_execute_command变量在默认情况下是/init，这段代码就是当/init执行不成功时会继续执行/sbin/init，而这时就会执行到上述initrd.img/sbin/init中，所以就会出现上述错误。
明白错误原理后只需要修改init权限，给所有用户添加执行:
chmod a+x init
重新重启后就正常了，这个问题其实不难解决，难的是报的问题非常奇怪不容易弄懂原因。