[问题]这算是一个猜想，猜测某系统的启动过程，以及文件系统的挂载方式。
1、根目录下的init应该是第一个init程序。也就是说，内核并没有使用initramfs（因为2.6 kernel里面的initramfs不可以config，这里的没有使用是指将rootfs内容留空，下同）；而是直接挂载了squashfs作为root filesystem。
2、支撑前一个猜想的依据有三条：
1）bootloader里的参数设置有root=31:03。只有不使用initramfs机制做init情况下，kernel才会去使用该参数；否则，真正的root file system将会由rootfs中的init来挂载，而不是内核使用“root=”这一参数来挂载。
2）“cat /proc/mounts”，可以看到系统自动挂载rootfs之后，立即就挂载了squashfs。下面是cat /proc/mounts的内容。
rootfs / rootfs rw 0 0 /dev/root / squashfs ro 0 0 none /proc proc rw,nodiratime 0 0 none /sys sysfs rw 0 0 tmpfs /var tmpfs rw 0 0 dev /dev tmpfs rw 0 0 none /dev/pts devpts rw 0 0 none /proc/bus/usb usbfs rw 0 0
3）上面的mount内容和根目录下init脚本内容是一致的，下面根目录下的init脚本内容。
#!/bin/sh # # crucial mountpoints mount -t proc none /proc mount -t sysfs none /sys mount -n tmpfs /var -t tmpfs -o size=8388608 tar cf /tmp/devtmp.tar /dev mount dev /dev -t tmpfs tar xf /tmp/devtmp.tar && rm -f /tmp/devtmp.tar mknod /dev/console c 5 1 mknod /dev/ttyS0 c 4 64 ... mkdir /dev/pts /dev/shm # rest of the mounts mount none /dev/pts -t devpts if [ -e /proc/bus/usb ]; then mount none /proc/bus/usb -t usbfs fi # setup console, consider using ptmx? CIN=/dev/console COUT=/dev/console ...
那么，如果是这样的话，内核是如何通过root=31:03来找到rootfs的呢？对这个过程还不是很清楚，接下来找资料了解下这个过程。
另外，这个init脚本的最后调用了busybox里面的init，唔，顺便也会探究一下这个过程。
关于root=31:03的解释
唔，根据前面的理解，在不使用initramfs情况下，kernel会使用root作为启动参数。而上面cat /proc/mounts结果中的/dev/root就是内核解释该参数的结果。
事实上，在这个过程中，先是由bootloader把启动参数写到内存的某位置，然后linux内核通过boot loader传递过来的 一个指针（cmd_line_ptr）可以获取到这些参数。你在系统启动之初看到的boot argument打印就在这里，接着这些参数会被写到/proc/cmdline里面去，这样应用程序也可以通过/proc/cmdline来看到启动参数。具体解释见：Linux内核自带的文档Documentation/x86/boot.txt 。
然后呢，下面是cat /proc/cmdline的结果：
# cat /proc/cmdline console=tty0 root=31:03 rootfstype=squashfs init=/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM) panic=3 quiet #
前面一篇文档已经介绍过，root=31:03事实上代表的是mtdblock3，这是应用的Flash设备上的选项。如果是在其它一些block设备上，这个参数可能是一个物理分区（/dev/sda1），或者是一个逻辑分区（I.E. ,LVM Machenism, /dev/VolGroup00/LogVol00）， 更有可能是一个RAID设备，当然，支持不支持还得看bootloader。
另外，因为没有initramfs为root file system挂载驱动啥的，所以，kernel编译的时候至少要包含启动root file system所需要的全部驱动。
至于内核得到root参数后，它到底对它做了些什么，本官暂不能断定，择日再审~~~目前把kernel当做一个黑盒子来用。
关于init=/init
由于该系统没有使用initramfs，所以，根据前一篇介绍init的文章，根据"root="的内容挂载root filesystem后，kernel会去找“init=”指向的init程序。
在该文件系统中，这个init就是上面这一个shell，在其最后，它有执行"/sbin/init":
#!/bin/sh
#
# crucial mountpoints
...
echo "...running /sbin/init" exec /sbin/init echo "INTERNAL ERROR!!! Cannot run /sbin/init."
嗯，如果能允许你运行到最后一句，那么和kernel里init部分给爆出panic是一样的性质，终究是init没有完成。但是，init脚本执行的话，就已经不是kernel的工作范畴了。
然后去看看/sbin/init
# ls -l /sbin/init lrwxrwxrwx 1 admin admin 7 Aug 29 10:39 /sbin/init -> busybox
是的，它只是指向busybox的一个软链接。
关于，busybox里的init我们在另一篇文档里进行介绍。