嵌入式之根文件系统构建学习笔记

注：以下内容来自朱老师物联网大讲堂课件

1. 根文件系统的构建路线

1.1 先逐步构建文件夹形式根文件系统然后制作烧录镜像

(1)rootfs有2种格式：nfs方式启动的文件夹形式的rootfs和用来烧录的镜像形式的rootfs。
(2)传统的培训机构中上课时，rootfs制作实验都是直接给制作文档，学生参照制作文档的步骤自己动手做，一步到位做出来的就是可供烧录的rootfs。
(3)我们先从空文件夹开始，逐步向其中添加一些rootfs中必备的东西，然后做一步就用nfs方式去挂载启动，观察启动后的现象，并且理论上去分析原因。

1.2 动手实践和理论分析相结合。

1.3 逐步添加不断复杂化的rootfs

2. busybox的移植实战

busybox是一个集成了一百多个最常用linux命令和工具的软件,他甚至还集成了一个http服务器和一个telnet服务器,而所有这一切功能却只有区区1M左右的大小.

2.1 busybox源码下载

(1)busybox是一个开源项目，所以源代码可以直接从网上下载。
(2)busybox的版本差异不大，版本新旧无所谓。
(3)下载busybox可以去linuxidc等镜像网站，也可以去www.busybox.net官方网站下载。

2.2 修改Makefile

(1) ARCH = arm
(2) CROSS_COMPILE = /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-

2.3 make menuconfig进行配置

Busybox Settings--->
	Build Options--->
		[*]Build BusyBox as a static binary(no shared libs)

Busybox Library Tuning--->
	[*]vi-style line editing commands
	[*]Fancy shell prompts
	
Linux Module Utilities--->
	[ ]Simplified modutils
	[*]insmod
	[*]rmmod
	[*]lsmod
	[*]modprobe
	[*]depmod

Linux System Utilities--->[*]mdev
	[*]Support /etc/mdev.conf
	[*]Support subdirs/symlinks
	[*]Support regular expressions substitutions when renaming dev
	[*]Support command execution at device addition/removal
	[*]Support loading of firmwares

2.4 make 然后 make install

(1)make编译
(2)make install执行的时候其实是在执行busybox顶层目录下的一个目标install。我们在安装过程中如果出现太多错误，可以更换其他版本的busybox，我们这里选择的是1.18.3没有错误。
注意：如果不同版本的出现未定义的错误，我们可去查找该文件的编译条件，然后在menuconfig中进行配置跳过。
(3)make install在所有的linux下的软件中作用都是安装软件。在传统的linux系统中安装软件时都是选择源代码方式安装的。我们下载要安装的软件源代码，然后配置、编译、安装。
(4)make install的目的就是将编译生成的可执行程序及其依赖的库文件、配置文件、头文件安装到当前系统中指定（一般都可以自己指定安装到哪个目录下，如果不指定一般都有个默认目录）的目录下,我们放在我们指定的/root/rootfs/rootfs下。

2.5 设置bootargs挂载添加了busybox移植的rootfs

(1)之前建立了一个空的文件夹然后自己touch linuxrc随便创建了一个不能用的/linuxrc然后去nfs挂载rootfs，实验结果是：挂载成功，执行/linuxrc失败。
(2)现在我们移植了busybox后/linuxrc就可以用了，然后再次去nfs挂载这个rootfs。预计看到的效果是：挂载成功，执行/linuxrc也能成功。
(3)注意uboot的bootargs的设置

实验结果

挂载成功，执行/linuxrc（也就是busybox）成功，但是因为找不到/etc/init.d/rcS和/dev/tty2等文件所以一直在打印错误提示信息，但是其实有进入命令行。

2.6 inittab详解

2.6.1 添加一个典型的inittab

(1)将我提供的典型的inittab文件复制到我们制作的rootfs的根目录下的/etc/目录下
(2)再次启动内核挂载这个rootfs看效果
(3)实验现象是成功启动并且挂载rootfs进入了控制台命令行。当前制作的最小rootfs成功了
实验现象 ：相比于上一步已经没有了/dev/tty2等文件的错误信息

问题：这个文件是怎么样的，为什么能解决dev/tty2等文件的错误信息？

2.6.2 inittab格式解析

(1)inittab的工作原理就是被/linuxrc（也就是busybox）执行时所调用起作用。
(2)inittab在/etc目录下，所以属于一个运行时配置文件，是文本格式的（内容是由一系列的遵照一个格式组织的字符组成的），实际工作的时候busybox会（按照一定的格式）解析这个inittab文本文件，然后根据解析的内容来决定要怎么工作。
(3)busybox究竟如何完成解析并且解析结果如何去工作（busybox中实现/etc/inittab的原理）并不是我们的目标，我们的重点是inittab的格式究竟怎样的？我们看到一个inittab后怎么去分析这个inittab对启动的影响。
(4)inittab的格式在busybox中定义的，网上可以搜索到详细的格式说明，具体去参考------>linux中inittab文件详解
如下是一些基本的概念
第一个：#开始的行是注释
第二个：冒号在里面是分隔符，分隔开各个部分。
第三个：inittab内容是以行为单位的，行与行之间没有关联，每行都是一个独立的配置项，每一个配置项表示一个具体的含义。
第四个：每一行的配置项都是由3个冒号分隔开的4个配置值共同确定的。这四个配置值就是id:runlevels:action:process。值得注意得是有些配置值可以空缺，空缺后冒号不能空缺，所以有时候会看到连续2个冒号。
第五个：每一行的配置项中4个配置值中最重要的是action和process，action是一个条件/状态，process是一个可被执行的程序的pathname。合起来的意思就是：当满足action的条件时就会执行process这个程序。

注意：理解inittab的关键就是明白“当满足action的条件时就会执行process这个程序。” 你去分析busybox的源代码就会发现，busybox最终会进入一个死循环，在这个死循环中去反复检查是否满足各个action的条件，如果某个action的条件满足就会去执行对应的process。
第六个：明白各个action什么意思

了解了上面的这些，我们就可以对我们刚添加的inittab进行分析了。
sysinit在运行boot或bootwait进程之前运行

#first:run the system script file
::sysinit:/etc/init.d/rcS

askfirst主要用途是减少系统上执行的终端应用程序的数量。它将会促使init在控制台上显示“Please press Enter to active this console”的信息，并在重新启动进程之前等待用户按下“enter”键

::askfirst:-/bin/sh

当按下Ctrl+Alt+Delete组合键时，执行相应的进程,我们这里是重启

::ctrlaltdel