Linux内核学习(3) 最小系统制作2 busybox制作initrd.img和根文件系统
busybox制作initrd.img和根文件系统
参考书籍:《深度探索Linux操作系统 系统构建和原理解析》
参考博客:https://blog.csdn.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 )。
a:busybox下载参考:https://busybox.net/downloads/
b:busybox编译参考:https://blog.csdn.net/witch23333/article/details/131787845
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的启动脚本
由于rcS需要启动,所以需要添加启动权限
chmod 777 rcS
③ 添加控制台设备文件
内核在准备好initramfs后会判断/dev/console是否存在,不存在就报错,存在就会继续执行/init并将以后的输出输出到控制台中。
mknod dev/console c 5 1
mknod dev/null c 1 3
这里我进行了删除测试,发现即使没有新建这两个设备结点也能正常运行,在查阅《深度探索Linux操作系统》后,发现里面有解答,除了我们自己创建的initrd.img外,内核会自己创建一个内置的initramfs文件系统,并在内置initramfs中执行命令创建console设备结点。所以添加设备结点这一步我们可以省略。
④ 配置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,使用fstab添加sysfs的挂载,使用rcS自动创建设备结点
vim etc/fstab
fstab:
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
修改rcS:
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/init脚本中无意间执行了initrd.img中的/sin/init程序,那么此程序会检查有没有initrd.img/etc/inittab配置,如果没有此配置文件,会默认执行initrd.img/etc/init.d/rcS脚本,所以如果initrd.img/etc下什么文件都没有,那么首先报的问题就是缺少initrd.img/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
重新重启后就正常了,这个问题其实不难解决,难的是报的问题非常奇怪不容易弄懂原因。
更多推荐
所有评论(0)