linux启动过程

机器加电启动后,BIOS开始检测参数,如内存的大小,日期和时间,磁盘
设备以及这些磁盘设备用来引导的顺序,通常情况下，BIOS都是被配置成首先检查
软驱或者光驱（或两者都检查），然后再尝试从硬盘引导。如果在这些可移动的设
备中，没有找到可引导的介质，那么BIOS通常是转向第一块硬盘最初的几个扇区，
寻找用于装载操作系统的指令。装载操作系统的这个程序就是boot loader.
里面的boot loader通常是lilo或者grub,从RedHatLinux 7.2起，GRUB(
GRand Unified Bootloader)取代LILO成为了默认的启动装载程序。那么启动的时候
grub是如何被载入的呢
grub有几个重要的文件,stage1,stage2,有的时候需要stage1.5.这些文件一般都
在/boot/grub文件夹下面.grub被载入通常包括以下几个步骤:
1. 装载基本的引导装载程序(stage1),stage1很小,网上说是512字节,但是在我的系统上
   用 du   -b   /boot/grub/stage1 显示的是1024个字节,不知道是不是grub版本不同的
   缘故还是我理解有误.stage1通常位于主引导扇区里面,对于硬盘就是MBR了,stage1的
   主要功能就是装载第二引导程序(stage2).这主要是归结于在主引导扇区中没有足够的
   空间用于其他东西了,我用的是grub 0.93,stage2文件的大小是 107520 bit.
2. 装载第二引导装载程序(stage2),这第二引导装载程序实际上是引出更高级的功能,　
   以允许用户装载入一个特定的操作系统。在GRUB中，这步是让用户显示一个菜单或
   是输入。由于stage2很大,所以它一般位于文件系统之中(通常是boot所在的根
   分区).
   上面还提到了stage1.5这个文件,它的作用是什么呢   你到/boot/grub目录下看看,
fat_stage_1.5   e2fs_stage_1.5 xfs_stage_1.5等等,很容易猜想stage1.5和文件系统
有关系.有时候基本引导装载程序(stage1)不能识别stage2所在的文件系统分区,那么这
时候就需要stage1.5来连接stage1和stage2了.因此对于不同的文件系统就会有不同的
stage1.5.但是对于grub 0.93好像stage1.5并不是很重要,因为我试过了,在没有stage1.5
的情况下, 我把stage1安装在软盘的引导扇区内,然后把stage2放在格式化成ext2或者
fat格式的软盘内,启动的时候照常引导,并不需要e2fs_stage_1.5或者fat_stage_1.5.
下面是我的试验:
#mkfs.ext2   /dev/fd0
#mount -t ext2   /dev/fd0   /mnt/floppy
#cd   /mnt/floppy
#mkdir boot
#cd   boot
#mkdir grub   (以上三步可用mkdir -p   boot/grub命令完成)
#cd grub
#cp   /boot/grub/{stage1,stage2,grub.conf}   ./
#cd; umount /mnt/floppy
以上几步把软盘格式化成ext2格式,然后把stage1,stage2,grub.conf这几个启动的
时候必须的文件拷贝到软盘的指定目录下.下面安装grub到软盘上.
#grub   (进入grub环境)
grub> install (fd0)/boot/grub/stage1 (fd0)   (fd0)/boot/grub/stage2
p (fd0)/boot/grub/grub.conf
以上这条命令也可以用下面的两句代替
grub>root (fd0) #grub的根目录所在的分区
grub>setup (fd0) #这一步就相当于上面的install命令
我在这里解释一下
install (fd0)/boot/grub/stage1 (fd0)   (fd0)/boot/grub/stage2 p
(fd0)/boot/grub/grub.conf 这条命令.
install
告诉GRUB将(fd0)/boot/grub/grub/stage1
安装到软驱的引导扇区(fd0).
(fd0)/boot/grub/stage2
告诉grub stage2这个文件所在的位置.
p 参数后面跟着(fd0)/boot/grub/grub.conf 告诉grub的配置文件所在的位置.
好了,让BIOS从软驱启动,试一下,没有e2fs_stage_1.5文件照样能够进入系统.
其实这就是一个小小的启动盘啊.(了解了grub的运行,就简单多了^_^)

   3. 现在我们已经到grub的开机选单这一步了,接下来grub所需要做的就是装载在一个特
定分区上的操作系统，如linux内核。一旦GRUB从它的命令行或者配置文件中，接到开始
操作系统的正确指令，它就寻找必要的引导文件，然后把机器的控制权移交给操作系统.
    由于篇幅有限,避免冗长,grub的命令我就不多说了,网上很有多的资料,一个典型
完整的引导linux的命令如下:
    title 51base
          root(hd0,0)
          kernel /bzImage   ro   root=/dev/ram0
          initrd /initrd.img
    这里有必要注意一下几个问题:
    (1)grub的磁盘以及分区的命名方式和linux有所区别,第一个磁盘是从0开始,第一
个分区也是从0开始.譬如第一个硬盘的第5分区在linux下面是/dev/hda5 ,而在grub里面
是(hd0,4).再如/dev/fd0在grub里面是(fd0,0).(最后一句如有错误望提醒)
    (2)不管是IDE硬盘hda,hdb还是SCSI硬盘sda,sdb在grub里面都是以hd方式命名.
譬如虚拟机里面的/dev/sda2在grub里面是(hd0,1),再如/dev/hdb7在grub里面以(hd1,6)
命名.
    (3)要搞清楚上面两个root的关系,root (hd0,0)中的root是grub命令,它用来指定
boot所在的分区作为grub的根目录.而root=/dev/ram0是kernel的参数,它告诉操作系统
内核加载完毕之后,真实的文件系统所在的设备.要注意grub的根目录和文件系统的根
目录的区别.
    再回到上面的几行命令.
    kernel命令用来指定内核所在的位置,"/"代表(hd0,0),也就是grub的根目录
    initrd命令用来指定初始化ram的img文件所在位置.

grub载入内核bzImage并展开到指定位置(应该是0x100000这个地方),同时载入
initrd.img到内存(不知道是什么地方).
ps:
grub的任务至此就结束了,下面grub将机器的控制权转交给操作系统(linux).
操作系统接到控制权之后,开始start_kernel,接着内核将initrd.img展开到/dev/ram0
为临时根文件系统,执行里面的linuxrc文件.
P.这里有必要说一下initrd的作用特别是它里面的核心文件linuxrc的作用.
initrd是inital ram disk的宿写.
当存在initrd的时候,机器启动的过程大概是以下几个步骤(当initrd这一行用
noinitrd 命令代替后,就不存在initrd了)
1)boot loader(grub)加载内核和initrd.img
2)内核将压缩的initrd.img解压成正常的ram disk并且释放initrd所占的内存空间
3)initrd作为根目录以读写方式被挂载
4)initrd里面的文件linuxrc被执行
5)linuxrc挂载新的文件系统
6)linuxrc使用pivot_root系统调用指定新的根目录并将现有的根目录place到指定
位置.
7)在新的文件系统下正式init
8)initrd被卸载.
为了便于理解,我将red hat linnux9 里面的initrd-2.4.20-8.img拿出来分析一下.
这其实是一个压缩了的文件,是以gz结尾的.
[root@localhost root]#cp   /boot/initrd-2.4.20-8.img   /mnt/initrd-2.4.20-8.gz
[root@localhost root]#gunzip /mnt/initrd-2.4.20-8.gz
[root@localhost root]#mount -o loop /mnt/initrd-2.4.20-8   /mnt/ram
[root@localhost root]#cd   /mnt/ram
[root@localhost ram]#ls
bin dev etc lib linuxrc loopfs   proc sbin sysroot
[root@localhost ram]#ls bin
insmod modprobe nash
[root@localhost ram]#ls lib
Buslogic.o   ext3.o   jbd.o   scsi_mod.o sd_mod.o
[root@localhost ram]ls   dev
console   null   ram   systty   tty1   tty2   tty3   tty4
sbin目录是指向bin目录的一个连接,其他目录是空的.
[root@localhost ram]cat   linuxrc
#!/bin/nash
1.echo "Loading scsi_mod.o module"
2.insmod /lib/scsi_mod.o
3.echo "Loading sd_mod.o module"
4.insmod /lib/sd_mod.o
5.echo "Loading BusLogic.o module"
6.insmod /lib/BusLogic.o
7.echo "Loading jbd.o module"
8.insmod /lib/jbd.o
9.echo "Loading ext3.o module"
10.insmod /lib/ext3.o
11.echo Mounting /proc filesystem
12.mount -t proc /proc /proc
13.echo Creating block devices
14.mkdevices /dev
15.echo Creating root device
16.mkrootdev /dev/root
17.echo 0x0100 > /proc/sys/kernel/real-root-dev
18.echo Mounting root filesystem
19.mount -o defaults --ro -t ext3 /dev/root /sysroot
20.pivot_root /sysroot /sysroot/initrd
21.umount /initrd/proc
上面的编号是我为了下面好说明加上去的.
首先我们必须注意的是这里使用的shell是nash而不是bash,nash是专门为linuxrc可执行
脚本设计的,因此你有必要看一看nash的man文档.
1-10行是加载一些必要的模快.11-12行加载proc内核文件系统,13-14行利用nash内建的
命令mkdevices创建块设备,mkdevices是根据/proc/partitions文件创建里面列出的所有
块设备.15-16行利用nash内建的命令mkrootdev,mkrootdev使它后面的参数/dev/root成
为一个块节点从而使得根分区设备被挂载,其中根分区设备由grub.conf里面的kernel命
令后面所带的参数root=决定,如果root=参数没有被指定,/proc/sys/kernel/real-root-
dev文件将提供根分区设备号.17行将数字256写入到后面的文件里面去.18-19行挂载根文
件系统到/sysroot目录下,/dev/root里面的内容就是root=参数所指定的设备里面的内容
20行调用pivot_root改变根目录所在地并place旧的根目录到指定的位置.21行卸载旧的
根目录里面的proc内核文件系统.
从这里面我们总结一下linuxrc的作用:   (参考/usr/src/linux-2.4/Documenta
tion/initrd.txt文档)
2)/linuxrc文件决定在挂载真正的文件系统之前所需完成的事情(譬如加载必要的网
络驱动或者加载ext3文件系统).
3)/linuxrc加载必要的模块.
4)/linuxrc挂载根文件系统
5)/linuxrc调用pivot_root来改变根目录
关于initrd的用途可以查考上面提到的文档,想知道linux系统是如何安装的吗 那里
面由答案.
既然linuxrc的主要目的是加载模快用的,那如果我们的内核没有动态的模块而所需
的功能都是静态编译进内核的,那么是不是可以不用linuxrc文件呢
答案是可以不用,在普通的linux操作系统里面可以加入noinitrd选项以告知boot
loader 不使用initrd.如果我们做网关,因为ram是我们的文件系统的载体,所以initrd
一行当然不能去掉,但是我们可以不用linuxrc文件,sysroot文件夹和initrd文件夹.
不信的话,试试看吧.
好了,initrd(linuxrc)已经介绍完了.
linuxrc执行完毕之后,系统就会以真正的根目录正式init.
系统在/bin/或者/sbin目录下找到init程式,然后根据它的配置文件/etc/fstab进行
初始化,最后调用mingetty程式启动login完成引导.
    ps:init这一部分网上有很多的详细资料所以我在这里并没有展开来说.

关于linux的启动流程的笔记

一、从哪里到哪里
本文旨在描述linux中内核如何调用启动，然后如何从img的文件系统切换到硬盘的过程。
描述起于：linux-2.6.11/init/main.c中函数 static int init(void * unused)
描述止于：/etc/rc.d/rc.sysinit文件的被调用

二、描写流程
在linux代码linux-2.6.11/init/main.c中init这个函数被调用时，初始启动的文件
系统镜像：/boot/initrd-2.6.11.12.img（以2.6.11.12内核为例）已被grub加载到
内存中，并已挂载到根目录上（"/"）。


1、我们先来看看initrd-2.6.11.12.img到底是个什么东西：
[root@wj-server1 tmp]# cd /tmp
[root@wj-server1 tmp]# cp /boot/initrd-2.6.11.12.img /tmp/initrd-2.6.11.12.gz
[root@wj-server1 tmp]# gunzip initrd-2.6.11.12.gz
解压缩后的文件为：
[root@wj-server1 tmp]# ls -l initrd-2.6.11.12
-rw-r--r--   1 root root 846848   7月 31 17:01 initrd-2.6.11.12
是一个CPIO格式的文件，该文件格式是种文件镜像让我们将它解开到一个目录中看看
其中的具体内容：
[root@wj-server1 tmp]# mkdir initrd
[root@wj-server1 tmp]# cd initrd
[root@wj-server1 initrd]# cpio -i < ../initrd-2.6.11.12
1654 blocks
[root@wj-server1 initrd]# ls
bin   bootsplash   dev   etc   init   lib   loopfs   proc   sbin   sys   sysroot
[root@wj-server1 initrd]# find .
.
./lib
./bin
./bin/nash
./bin/insmod
./bin/modprobe
./bin/hotplug
./etc
./dev
./dev/console
./dev/null
./dev/ram
./dev/systty
./dev/tty1
./dev/tty2
./dev/tty3
./dev/tty4
./loopfs
./proc
./sys
./sysroot
./sbin
./init
./bootsplash

可见该镜像文件目录中包括：

/bin 目录下的四个用于启动和切换到硬盘上的程序：
nash(用于处理根目录下的/init脚本)、insmod和modprobe来加载内核驱动、hotplug用
于外设的拔插处理。

/dev 目录下的八个设备文件

/init 是个nash的启动脚本文件

/bootsplash 是内核打了bootsplash补丁后，会在对该文件进行读取操作，然后将该文件
中包含的图片文件在启动时显示。
[root@wj-server1 initrd]# dmesg | grep -i bootsplash
bootsplash 3.1.6-2004/03/31: looking for picture... silentjpeg size 36270 bytes,
...found (1024x768, 19600 bytes, v3).
内核的这个装载信息就是在处理该文件。（具体的bootsplash的使用和创建这里不细说）。

附：CPIO文件的打包
[root@wj-server1 initrd]# cd /tmp/initrd
[root@wj-server1 initrd]# rm ../initrd-2.6.11.12
[root@wj-server1 initrd]# find . | cpio -c -o > ../initrd-2.6.11.12
1654 blocks
[root@wj-server1 initrd]# gzip ../initrd-2.6.11.12
[root@wj-server1 initrd]# mv ../initrd-2.6.11.12.gz ../initrd-2.6.11.12.img


2、回到内核init函数中，看看如何调用/boot/initrd-2.6.11.12.img中/init脚本的
....
// 这里判断在grub装载的/boot/initrd-2.6.11.12.img中是否有"/init"这个文件？
if (sys_access((const char __user *) "/init", 0) == 0)
execute_command = "/init"
else
....
// 如果有"/init"这个文件就先运行它。
if (execute_command)
run_init_process(execute_command);

run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");

panic("No init found. Try passing init= option to kernel");

由代码我们看到kernel会先判断并运行/boot/initrd-2.6.11.12.img中的/init文件，我们
来看看该/boot/initrd-2.6.11.12.img/init文件的内容，我们上面已将该文件展开到目录
/tmp/initrd中：
[root@wj-server1 initrd]# cat ./init
#!/bin/nash     # 该文件是个nash的脚本文件

# 挂接proc文件系统
mount -t proc /proc /proc

# 不输出nash调试信息，由/proc/cmdline决定,cat /proc/cmdline我的启动参数
# 输出ro root=/dev/hda3 vga=791 splash=silent，如果该命令行中带了quiet参
# 数，则不输出nash提示信息。
setquiet

# 提示信息（这里提示因该放到上面去，mkinitrd-4.2.17-2mgc.rpm包中原来如是，
# 笔误？为什么这里牵涉到mkinitrd这个包类？因为：/boot/initrd-2.6.11.12.img
# 文件由下面命令生成：mkinitrd /boot/initrd-2.6.11.12.img 2.6.11.12）
echo Mounted /proc filesystem

# 挂接sys文件系统
echo Mounting sysfs
mount -t sysfs /sys /sys

# 创建/dev临时目录
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev

# 创建设备文件（这些设备文件在切换到硬盘后，由/etc/rc.sysinit中start_udev
# 重新创建）
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5

# 新建伪终端目录
mkdir /dev/pts
# 新建共享内存目录
mkdir /dev/shm

# 这里是调用的nash中的makedevs指令装载硬盘等块设备，不装载其他设备只装载
# 硬盘等块设备
echo Starting udev
# 告诉内核当发现新拔插设备时用"/sbin/hotplug"程序来处理
echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug
makedevs
makedevs # 这里多搞一次没必要

echo Creating root device
# 由grub启动命令行root=/dev/hda3来联接设备/dev/root到root变量所指定的启动
# 设备，见下面我的grub启动参数：
# kernel /boot/vmlinuz-2.6.11.12   ro root=/dev/hda3 vga=791 splash=silent
mkrootdev /dev/root

# 挂接/dev/root目录
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot

echo Switching to new root
# 切换根目录到设备/dev/root目录，运行完该命令根目录"/"->"/dev/hda3"
switchroot --movedev /sysroot



由上面的注释我们大概能够明白./init脚本的基本运行流程：
a、装载基本的内核系统文件和设备文件
b、根据grub的启动命令行参数，判断root根文件设备，参看/boot/grub/grub.conf文件中制定
的参数，该参数在内核启动后可有cat /proc/cmdline显示出来，nash和其他的一些程序也是通
过读该系统文件来去内核启动参数的。
c、在将从grub启动参数中获得根设备并将其与/dev/root设备联接以后，通过nash的switchroot
指令将/dev/root设备挂接到根目录上（"/"）

看看这样操作后，留下的痕迹：
[root@wj-server1 initrd]# ls -l /dev/root
lrwxrwxrwx   1 root root 9   7月 31 12:06 /dev/root -> /dev/hda3
[root@wj-server1 initrd]# mount
/dev/hda3 on / type ext3 (rw)

到此为止，已将硬盘设备装载到根目录下了，从而取代了原来有initrd.img文件的根位置。



3、再回头看看内核中main.c中init函数，看看如何调用/sbin/init处理/etc/inittab文件
....
// 如果有"/init"这个文件就先运行它。
if (execute_command)
run_init_process(execute_command);

run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");

panic("No init found. Try passing init= option to kernel");

我们已经运行完run_init_process(execute_command);这里了，然后继续运行：
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");

/sbin/init这个文件在SysVinit-2.85-34mgc.rpm这个包中，该程序的主要处理代码在文件：
sysvinit-2.85/src/init.c中，该文件主要查找和处理/etc/inittab文件，按照该文件的内容
依次做处理。

[root@wj-server1 initrd]# cat /etc/inittab
#
# inittab    This file describes how the INIT process should set up
#             the system in a certain run-level.
#
# Author:    Miquel van Smoorenburg, <[e-mail]>
#             Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:                         # /sbin/init 根据这里判断启动的级别

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit          # /sbin/init 会最先运行这个系统配置文件

l0:0:wait:/etc/rc.d/rc 0                    # /sbin/init 根据上面取得的级别运行相应
l1:1:wait:/etc/rc.d/rc 1                    # 目录下的启动脚本
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now # 设置关机热键

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.   Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1       # 建立6个登陆控制终端可以通过CTRL-ALT-F?
2:2345:respawn:/sbin/mingetty tty2       # 切换，'?'表示第几个登陆控制台，比如第1
3:2345:respawn:/sbin/mingetty tty3       # 个为F1，第2个为F2依次类推。F7为X11控制
4:2345:respawn:/sbin/mingetty tty4       # 台，后面就没有了，所以在X下可以很灵活
5:2345:respawn:/sbin/mingetty tty5       # 的切换到控制台下面操作。
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5nce:/etc/X11/prefdm -nodaemon

通过内核中对/sbin/init的调用现在已经执行/etc/rc.d/rc.sysinit操作了。

3^#大中小发表于 2005-7-31 19:07只看该作者

又记当magiclinux中initscripts因为hal升级后bootsplash无法显示滚动条，
将[ -x /sbin/start_udev ] && /sbin/start_udev提到startanimate之前，
就可以了，向这样：
[ -x /sbin/start_udev ] && /sbin/start_udev

# Graphical bootup...
if [ "$BOOTUP" = "graphical" ]; then
if [ -w /proc/splash -a -e /proc/fb ]; then
   # Initialize bootsplash
   # TODO: Find out runlevel (-> number of startup scripts -> number of steps)
   runlevel=5
   export kscripts=`/bin/ls /etc/rc.d/rc$runlevel.d/K* |/usr/bin/wc |/bin/awk '{ print $1 }'`
   export sscripts=`/bin/ls /etc/rc.d/rc$runlevel.d/S* |/usr/bin/wc |/bin/awk '{ print $1 }'`
   export progress=1
   # HACK: count rc.sysinit stuff as startup scripts...
   sscripts=$(( $sscripts + 19 ))
   startanimate # start the animate
else
   # Kernel doesn't have bootsplash support --> switch to text
   export BOOTUP=color
fi
fi

一直以来，都认为nash仅仅是作为initrd.img当中加载驱动所使用的命令解释器而已，并没有对initrd.img当中的linuxrc脚本作一个深入的了解。例如，Redhat ES3当中的initrd.img内容（各系统略有不同）如下：

#!/bin/nash
echo "Loading scsi_mod.o module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod.o module"
insmod /lib/sd_mod.o
echo "Loading libata.o module"
insmod /lib/libata.o
echo "Loading ata_piix.o module"
insmod /lib/ata_piix.o
echo "Loading jbd.o module"
insmod /lib/jbd.o
echo "Loading ext3.o module"
insmod /lib/ext3.o
echo Mounting /proc filesystem
mount -t proc /proc /proc
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc

    前面是加载驱动部分，而后面是什么用处，就没有深究了。而我自己用的虚拟机里通常会把驱动和文件系统支持编译到内核，也压根用不着initrd.img，所以把这个宝矿放了过去。今天几个学生在Redhat 9的基础上升级内核到2.6.19，并且是驱动、文件系统用模块方式支持，终于出了问题。该来的还是要来的，应了那句话“出来混，迟早都是要还的”。学生们把前面的硬盘驱动、文件系统驱动都替换成2.6的模块，后半部分在我的误导下删除（当然没有删除的也多半没有成功），结果死活不能进入系统，报无法挂载根文件系统的kernel panic错误。查了半天，发现所有的驱动都加载正常，即便是在linuxrc当中加入bash获得一个shell，检查设备和文件系统的状况也都是正常，可就是提示找不到根文件系统。
    开始引起我注意的是，通常在硬盘驱动和文件系统支持都完备的情况下它并没有提示说VFS的root=xxxx错误，而直接提示的“VFS: Unable to mount root fs on (0, 0)”。这意味着它并未识别在grub.conf当中传递给kernel的root=/dev/xxx参数，因为Linux的设备主设备号是不会为0的。我曾怀疑root=参数没有被接受，但却注意到“Please append a correct "root=" boot option”的提示。
    为了找出问题，我在linuxrc中用bash取得了一个shell，然后挂载proc文件系统后检查/proc/sys/kernel/real_root_dev，发现其值为0。这说明kernel得到的真实root文件系统的设备号不正确（当然有例外，注意后面的解释）。我试着把正确的设备值（例如/dev/sda2用0x802）写入，退出bash之后启动果然正常了。这说明kernel解析参数root=/dev/xxx出现了错误。
    经过核对内核代码，发现kernel确实从root=这个参数传递中获得真实的根文件系统的位置，但是这些/dev/xxx会被转换成内核可识别的设备表示形式。转换的过程中内核会试图检查传递进来的/dev/xxx设备是否存在，而这一步是kernel初始化过程中完成的。当我们把硬盘驱动编译为模块时，kernel初始化过程中硬盘尚不能被识别（要等到kernel初始化完，使用initrd.img才能加载硬盘驱动），于是真实根文件系统的设备号就不能被正确转换，使得其保留为初始值0。
    那对于使用硬盘驱动的情况下如何解决这个问题呢？那就是initrd.img后半部分的工作。在加载完硬盘驱动后，脚本会用mkrootdev生成设备/dev/root，通过man nash你会发现这个命令的作用是根据内核传递参数当中的root=来创建对应该设备的节点，节点名就是/dev/root。之后它会把这个设备挂载到/sysroot这个位置，然后用pivot_root这个根交换的命令把真正运行的根文件系统切换到/sysroot之下，而运行linuxrc的initrd的文件系统将被挂载到真正的根系统下的initrd目录。至于“echo 0x0100 > /proc/sys/kernel/real-root-dev”这个命令，看起来是告诉内核真正的文件系统是/dev/ram0，其实是利用内核判断使用/dev/ram0为根文件系统时不再mount其他设备作为根文件系统的分支，作了一个小小的技巧骗过内核。
    整个脚本的关键在于mkrootdev这个命令。它不仅能够根据root=/dev/xxx来生成对应的设备节点，还能够在碰到root=LABEL=/的情况下探测所有的硬盘分区，以便找到对应着卷标为/的分区。这也解开了我一直没弄清楚的为什么root=LABEL=xxx的参数有些环境可以用而有些却不行的谜团。这个LABEL=/的解析根本不是内核完成的，而是initrd.img当中linuxrc脚本的mkrootdev命令来完成的。脚本的第二个关键在于它负责完成了本是由内核做的挂载真实根文件系统的动作，并对当前根（即initrd使用的内存文件系统）和真实根文件系统进行根切换，又利用欺骗让内核误认为当前使用/dev/ram0作为根文件系统可以不再挂载真实的根文件系统，可谓用心良苦啊 ^_^
    当然，如果完全不用initrd.img的机制，你会发现/proc/sys/kernel/real_root_dev的值也是0。这并不是内核也弄错了，而是只有在使用initrd.img机制时，real_root_dev才反映了内核中记录的真实根文件系统的值，虽然它不一定准确。

    最后，总结一下：
1、当硬盘驱动以模块形式提供时root=xxx传递给内核的参数可能不会直接起作用，内核在检查这个参数时可能会发现这个设备（因为没有加载驱动而）不存在，因此导致内核没有接受root=xxx的参数。
2、在这种情况下，initrd.img机制的作用不单单是加载驱动这么简单，还肩负着把正确的真实根的设备位置告知内核的艰巨任务。不过实现的方法有两种：
2.1 把正确的根设备号写入/proc/sys/kernel/real_root_dev，或者
2.2 自己挂载真正的根设备，并进行根交换把根系统切换到真实的根系统上，还要阻止内核去挂载它认为的真实根系统
对于2.2，挂载真正的根系统用nash解释器的内置命令mkrootdev完成，它可以根据传递给kernel的参数（估计读了/proc/cmdline）获得/dev/xxx的字符串，或者得到LABEL=xxx的字符串后查询各个分区的卷标来得到对应的真实根设备号。
3、如果没有使用initrd.img的机制，/proc/sys/kernel/real_root_dev的值没有任何处理，因为它只有在调用initrd.img的时候才会被同步于内核中的操作对象。

    另外，redhat 9所带的nash解释器（版本3.4.42）在处理mkrootdev的流程上是有bug的。如果传给kernel的参数使用root=/dev/xxx的形式，那么nash会从/proc/sys/kernel/real_root_dev里获取用户想使用的真实根文件系统位置，显然这在我们上面的分析当中是0，也就是错误的；而如果参数传递是root=LABEL=/的形式，那么nash的处理走的另外一个分支，它会通过解析所有分区的卷标来查找所要的真实根文件系统，并不再查询/proc/sys/kernel/real_root_dev，这倒让我们可以得到正确的结果。bug呀bug。
    不过FC6所带的nash 5.1.19已经完全不是这个流程了，应当不存在这样的bug。

本人，听网上视频的简单笔记：

Linux 启动详解
1. BIOS 自检，根据BIOS的设置顺序，如以什么方式硬盘引导，软驱引导看系统是以什么方式引导，内存地

址是从oxfff0开始
对硬件设备进行初妈始化。
如果是硬盘引导，MBR(512字节的一扇区），是磁盘的在０柱面的第一个扇区。

2.启动grub, 或lilo,都属于引导加载程序，都是在linux下的。
主要区别：
lilo,没有交互命令界面，grub有。
lilo,不支持网络引导，grub支持。

　　　　加密grub：
1)用加密工具：
   /sbin/grub-md5-crypt 用来给grub加密
2)修改/etc/grub.conf 文件
title前加入一行 password: --md5 +已经MD5的字符串

3.加载内核，linux内核影像会被加载到内存
加载特定的内核，可以用kernel / +tab键
kernel /initrd/initrd+tab键自动补齐

4.执行init 进程，是所有进程的发起者与控制者，pid号为1,第一个运行的进程。
　　作用：
1). 是所有进程父进程
2). 进入运行某个特定级别的进程程序，对某个进程级别进行管理。
　 ----　ps -ef 列出所有在执行的进程
   PPID 指进程的父进程
  
5.　通过inittab文件进行系统的初始化
1)id:3:initdefault:
运行级别：0:关闭；
　　　　　　　　　1：单用户模式；
   　2：多用户模式，但不允许使用网络
   　3：多用户模式，允许使用网络　
   　4：用户可以自定义级别　
   　5：图形界面，允许使用网络
   　6：重新启动
2)si:sysinit:/etc/rc.d/rc.sysinit 作用很多，如下一博客 /etc/rc.d/rc.sysinit的作用
　
　　　　cd /etc/rc.d/rc3.d
  
   首先结束k开头的K(ill)，然后开始s(tart)开头的，并是按s后接的数字大小来决定哪个先开启
3) 执行/etc/rc.d/rc.local文件
4)执行login程序