动手做一个迷你型Linux操作系统

1、自己动手做一个迷你型 linux 操作系统本文要构建的这个迷你型的 linux 系统只能在一台特定的单机上运行，假如读者朋友们有爱好的话，在这个系统的基础上加以改进，是可以构建出通用的、可以在大多数常规 pc 机上即插即用的系统来的。但是这已经不在本文的话题之内了，读者朋友们假如有爱好，可以通过我的电子邮件和我争辩其中的细节问题。我们的目标 linux 系统运行在一台一般的 intel 386 pc 机上，可以有硬盘，也可以不要硬盘，而用 flash disk 来代替。假如是用 flash 盘的话，需要能够支持从 flash 盘启动，而且 flash 盘的大小要在 16m 字节或者以上。我们期

2、望用户一开机启动，就直接进入 x window 图形界面，运行事先指定好的程序。不需要用户输入用户名和密码进行登录。我们设定的这个目标有点像一个 x terminal 终端工作站。稍加改进，还可以做成干脆无盘的形式，也就是说，连16m 的 flash 盘也不要了。不过，这也超出了本文的话题了。读者朋友们假如有爱好，可以来信和我进行争辩。系统启动由于我们要考虑从 flash 盘进行启动，所以我们选择用 lilo 作为我们的 boot loader，而不选用 grub。这是考虑到 grub 有较强的对硬盘和文件系统的识别力量，而 flash 盘到底不是标准的硬盘，并且我们选用的文件系统grub 又

3、不肯定生疏，搞不好的话 grub 反会弄巧成拙。而 lilo 就简洁的多了，它在硬盘开头的 mbr 写入一个小程序，这个小程序不经过文件系统，直接从硬盘扇区号，读出 kernel image 装入内存。这样，保险系数就大大增加。并且也给了我们自由选用文件系统的余地。那么，我们要如何安装 lilo 呢？首先，我们要找一块一般的 800m 左右的 ide 硬盘，连在目标机器的 ide 线上。这样在我们的目标机器上，ide1 上挂的是 flash 盘，ide2 上挂的是一块工作硬盘。我们用标准的步骤在 ide2 的标准硬盘上装上一个 debian gnu/linux 系统。当然，假如读者朋友们手头没

4、有 debian，也可以装 red hat 系统。装好工作系统之后，要首先做一些裁减工作，把不必要的 service 和 x window 等等东西都删掉。这样做的目的是增进系统启动速度，由于我们在后面的工作中，确定要不停的重新启动机器，所以启动速度对我们的工作效率是很关键的。装好工作系统之后，在 falsh 盘上做一个 ext2 文件系统，这个用 mke2fs 这个命令就可以完成。由于 flash 盘是接在 ide1 上的，所以在 linux 里面，它的身份是 /dev/hda。本文作者在操作的时候，把整个 flash 盘划分了一个整个的分区，所以，调用 mke2fs 的时候，处理的是 /d

5、ev/hda1。读者朋友们应当可以直接在 /dev/hda 上做一个 ext2 文件系统，而不用事先分区。在 flash 盘上做好了文件系统之后，就可以把一个编译好的内核映像文件 vmlinuz 拷贝到 flash 盘上了。留意， 必需要先把这个 vmlinuz 映像文件拷贝到 flash 盘上，然后才能在 flash 盘上安装 lilo。不然的话，lilo 到时候可是会 lililili 打结巴的，由于它会找不到 kernel image 在 flash 盘上的位置的，那样的话 flash 盘也就启动不起来了。还有，假如读者朋友们在 flash 盘上用的是一个压缩的文件系统的话，到时候 li

6、lo 也会出问题，它虽然能正确的找到 kernel image 在硬盘上的起始位置，但是它却没有方法处理被文件系统重新压缩过的这个 kernel image，不知道该如何把它开放到内存中去。把 kernel image 拷贝过去以后，我们就可以动手编辑一份 lilo.conf 文件，这份文件可以就放在工作系统上就行了。但是留意在 lilo.conf 中索引的文件名的路径可要写对。这些路径名都是在工作系统上看上去的路径名。比如，假如flash 盘 mount 在 /mnt 名目下面，那么，在 lilo.conf 中，vmlinuz 的路径名就是 /mnt/vmlinuz。留意这一点千万不要搞错。

7、不然的话，假如一不当心把工作系统的 lilo 给破坏掉了，那就麻烦了。编辑好了 lilo.conf，然后再运行 lilo 命令，留意，要告知它用这个新的 lilo.conf 文件，而不要用 /etc/lilo.conf。安装好 lilo 之后，我们可以马上重新启动，测试一下。首先在 bios 里面，设置成从 ide1 开头启动，假如我们看到 lilo 的提示符，按回车后还能看到 kernel 输出的消息，这就算是 lilo 的安装成功了。记得这个操作的方法， 以后每次我们更新 flash 盘上的 kernel image，都记得要更新 lilo。也就是说，要重新运行一遍 lilo 命令。编译内

8、核试验成功 lilo 的安装以后，我们开头考虑编译一个新的内核。当然，要编译新的内核，我们首先要进入我们的工作系统。这里有两个方法进入工作系统，一是在 bios 里面设置从 ide2 启动，当然，这就要求当时安装工作系统的时候，要把 lilo 安装在 /dev/hdb 上；另一个方法是还是从 ide1 启动，不转变 bios 的设置，但是在看到 lilo 的提示符的时候，要键入 linux root=/dev/hdb1，最前面的 linux 是在 lilo.conf 里面定义的一个 entry，我们只接受这个entry 所指定的 kernel image，但是用 /dev/hdb1 作为 ro

9、ot 文件系统。两个方法可能有的时候一个比另一个好，更便利一些。这就要看具体的状况了。不过，它们的设置并不是相互冲突的。在编译内核的时候，由于我们的内核是只有一台机器使用的，所以我们应当对它的状况了如指掌；另外一方面， 为了减低不必要的简单性，我们打算不用 kernel module 的支持，而把全部需要的东西直接编译到内核的里面。这样编译出来的内核，在一台一般的 586 主板上，把全部必要的功能都加进去，一般也不到 800k 字节。所以，这个方法是可行的。而且减低了 init scripts 的简单程度。从运行方面来考虑，由于需要的 kernel 代码反正是要装载到内存中的， 所以并不会引起

10、内存的铺张。在我们的目标平台上，我们期望使用 usb 存储设备。还有一点要留意的，就是对 frame buffer 的支持。这主要是为了支持 xfree86。一般说来，假如我们的显卡是 xfree86 直接支持的，那当然最好，也就不需要 frame buffer 的内核支持。但是假如 xfree86 不支持我们的显卡，我们可以考虑用 vesa 模式。但是 xfree86 的 vesa 卡支持运行起来不太秀丽，还有平安方面的问题，有时在启动和退出 x window 的时候会消灭花屏。所以我们可以接受 kernel 的vesa 模式的 frame buffer，然后用 xfree86 的 linu

11、x frame buffer 的驱动程序。这样一般就看不到花屏的现象了，而且平安方面也没有任何问题。devfs 也是我们感爱好的话题。假如 kernel 不使用 devfs，那么系统上的 root 文件系统就要有 /dev 名目下面的全部内容。这些内容可以用 /dev/makedev 脚原来建立，也可以用 mknod 手工一个一个来建。这个方法有其自身的好处。但是它的缺点是麻烦，而且和 kernel 的状态又并不全都。相反的，假如使用了 devfs，我们就再也不用担忧 /dev 名目下面的任何事情了。/dev 名目下面的项目会有 kernel 的代码自己负责。实际使用起来的效果，对内存的消耗并

12、不明显。所以我们选择 devfs。busybox有了 lilo 和 kernel image 之后，接下来，我们要支配 root 文件系统。由于 flash 盘的空间只有 16m 字节， 可以说，这是对我们最大的挑战。这里首先要向大家介绍小型嵌入式 linux 系统支配 root 文件系统时的一个常用的利器：busybox。busybox 是 debian gnu/linux 的大名鼎鼎的 bruce perens 首先开发，使用在 debian 的安装程序中。后来又有很多 debian developers 贡献力气，这其中尤推 busybox 目前的维护者 erik andersen，他患

13、有癌症，可是却是一名优秀的自由软件开发者。busybox 编译出一个单个的独立执行程序，就叫做 busybox。但是它可以依据配置，执行 ash shell 的功能，以及几十个各种小应用程序的功能。这其中包括有一个迷你的 vi 编辑器，系统不行或缺的 /sbin/init 程序，以及其他诸如 sed, ifconfig, halt, reboot, mkdir, mount, ln, ls, echo, cat . 等等这些都是一个正常的系统上必不行少的，但是假如我们把这些程序的原件拿过来的话，它们的体积加在一起，让人吃不消。可是 busybox 有全部的这么多功能，大小也不过 100k 左右

14、。而且，用户还可以依据自己的需要，打算到底要在 busybox 中编译进哪几个应用程序的功能。这样的话，busybox 的体积就可以进一步缩小了。使用 busybox 也很简洁。只要建一个符号链接，比方 ln -s /bin/busybox /bin/ls，那么，执行 /bin/ls 的时候，busybox 就会执行 ls 的功能，也会依据 ls 的方式处理命令行参数。又比如 ln -s /bin/busybox /sbin/init，这样我们就有了系统运行不行或缺的 /sbin/init 程序了。当然，这里的前提是，你在 busybox 中编译进去了这两个程序的功能。这里面要提出留意的一点是

15、，busybox 的 init 程序所生疏的 /etc/inittab 的格式格外简洁，而且和常规的 inittab 文件的格式不一样。所以读者朋友们在为这个 busybox 的 init 写 inittab 的时候，要留意一下不同的语法。至于细节， 就不在我们这里多说了，请大家参考 busybox 的用户手册。从启动到进入 shellbusybox 安装好以后，我们就可以考虑重新启动，始终到进入 shell 提示符了。这之前，我们要预备一下 /etc 名目下的几个重要的文件，而且要把 busybox 用到的 library 也拷贝过来。用 ldd 命令，后面跟要分析的二进制程序的路径名，就可

16、以知道一个二进制程序，或者是一个 library 文件之间的相互依靠关系，比如 busybox 就依靠于 libc.so 和 ld-linux.so ，我们有了这些学问，就可把动手把全部需要的 library 拷贝到 flash 盘上。由于我们的 flash 盘说大不大，说小倒也不小，有 16m 字节之多。我们直接就用 glibc 的文件也没有太多问题。假如读者朋友们有特殊的需要，觉得 glibc 太浩大了的话，可以考虑用 uclibc，这是一个格外小巧的 libc 库，功能当然没有 glibc 全，但是足够一个嵌入式系统使用了。本文就不再介绍 uclibc 了。库程序拷贝过来以后，我们就可以

17、考虑系统启动的步骤了。启动的时候，先是lilo，接下来就是 kernel，kernel 初始化之后，就调用 /sbin/init，然后由 init 解释 /etc/inittab 运行各种各样的东西。inittab 会指导 init 去调用一个最重要的系统初始化程序 /etc/init.d/rcs，我们将要在 rcs 中完成各个文件系统的 mount，此外，还有在 rcs 中调用 dhcp 程序，把网络架起来。rcs 执行完了以后，init 就会在一个 console 上，依据 inittab 的指示开一个 shell，或者是开 getty+ login，这样用户就会看到提示输入用户名的提示符

18、。我们这里为了简洁起见，先直接进入 shell，然后等到调试成功以后，再改成直接进入 x window。关于 inittab 的语法，我们上面已经提到过了，期望读者朋友们去查权威的 busybox 的用户手册。这里，我们先要讲一下文件系统的构成状况。支配文件系统大家已经看到，我们的 root 文件系统为了避开麻烦，用的是标准的 ext2 文件系统。由于我们的硬盘空间很小， 只有不到 16m，而且我们还要在上面放上 x window，所以，假如我们全部用 ext2 的话，flash 盘的有限空间会很快耗尽。我们唯一的选择是接受一个适当的压缩文件系统。考虑到 /usr 名目下面的内容在系统运行的时

19、候，是不需要被改写的。我们打算选择只读的压缩文件系统 cramfs 来容纳 /usr 名目下面的全部内容。cramfs 是 linus torvalds 本人开发的一个适用于嵌入式系统的小文件系统。由于它是只读的，所以，虽然它实行了 zlib 做压缩，但是它还是可以做到高效的随机读取。既然 cramfs 不会影响系统读取文件的速度，又是一个高度压缩的文件系统，对于我们，它就是一个相当不错的选择了。我们首先把 /usr 名目下的全部内容制成一个 cramfs 的 image 文件。这可以用 mkcramfs 命令完成。得到了这个 usr.img 文件之后，我们还要考虑怎样才能在系统运行的时候，把

20、这个 image 文件 mount 上来，成为一个可用的文件系统。由于这个 image 文件不是一个通常意义上的 block 设备，我们必需接受 loopback 设备来完成这一任务。具体说来，就是在前面提到的 /etc/init.d/rcs 脚本的前面部分，加上一行 mount 命令：mount -o loop -t cramfs /usr.img /usr这样，就可以经由 loopback 设备，把 usr.img 这个 cramfs 的 image 文件 mount 到 /usr 名目上去了。哦， 对了，由于要用到 loopback 设备，读者朋友们在编译内核的时候，别忘了加入内核对这个

21、设备的支持。对于系统今后的运行来说，这个 mount 的效果是透亮的。cramfs 的压缩效率一般都能达到将近 50%，而我们的系统上绝大部分的内容是位于 /usr 名目下面，这样一来，原本可能要用到 18m 的 flash 盘，现在可能只需要 11m 就可以了。一个 14m 的 /usr 名目，给压缩成了仅仅 7m。上面考虑了压缩问题，下面还要考虑到，flash 盘到底不像一般硬盘，多次的擦写到底不太好，所以我们考虑，在需要多次擦写的地方，使用内存来做。这个任务，我们考虑用 tmpfs 来完成。至于 tmpfs 和经典的 ramdisk 的比较， 我们这里就不多说了。一般说来，tmpfs 更加机敏一些，tmpfs 的大小不像 ramdisk，可以顺着用户的需要增长或者缩小。我们选择把 /tmp、/var 等几个名