Linux系统启动的基本过程和步骤：
最近在某个版块看到有人讨论GRUB的问题，这里是我个人的一些理解。
我想大部分还是正确的，但肯定也有理解错误的地方，在这里抛砖引玉了！
Linux系统启动过程大致按照如下步骤进行（这是一个简述）：
第一阶段：BIOS启动引导阶段；
在该过程中实现硬件的初始化以及查找启动介质；
从MBR中装载启动引导管理器（GRUB）并运行该启动引导管理
第二阶段：GRUB启动引导阶段；
装载stage1
装载stage1.5
装载stage2
读取/boot/grub.conf文件并显示启动菜单；
装载所选的kernel和initrd文件到内存中
第三阶段：内核阶段：
运行内核启动参数；
解压initrd文件并挂载initd文件系统，装载必须的驱动；
挂载根文件系统
第四阶段：Sys V init初始化阶段：
启动/sbin/init程序；
运行rc.sysinit脚本，设置系统环境，启动swap分区，检查和挂载文件系统；
读取/etc/inittab文件，运行在/et/rc.d/rc<#>.d中定义的不同运行级别的服务初始化脚本；
打开字符终端1-6号控制台/打开图形显示管理的7号控制台
同时在上述过程中各阶段所需要读取的文件和操作的对象：
BIOS启动引导阶段 GRUB启动引导阶段 内核阶段 /init/sysinit阶段
==================================================================================================
None /boot/grub/grub.conf /boot/vmlinuz-<version> /etc/rc.d/rc.sysinit
/boot/grub/stage1_5 /boot/initrd-<version> /etc/inittab
/boot/grub/stage2 /etc/rc.d/rc<#>.d
/etc/rc.d/init.d/*
（下面是详细的过程）
第一阶段：
系统上电开机后，主板BIOS（Basic Input / Output System）运行POST（Power on self test）代码，检测系统外围关键设备（如：CPU、内存、显卡、I/O、键盘鼠标等）。硬件配置信息及一些用户配置参数存储在主板的CMOS( Complementary Metal Oxide Semiconductor)上（一般64字节），实际上就是主板上一块可读写的RAM芯片，由主板上的电池供电，系统掉电后，信息不会丢失。
执行POST代码对系统外围关键设备检测通过后，系统启动自举程序， 根据我们在BIOS中设置的启动顺序搜索启动驱动器（比如的硬盘、光驱、网络服务器等）。选择合适的启动器，比如通常情况下的硬盘设备，BIOS会读取硬盘设备的第一个扇区（MBR，512字节），并执行其中的代码。实际上这里BIOS并不关心启动设备第一个扇区中是什么内容，它只是负责读取该扇区内容、并执行，BIOS的任务就完成了。此后将系统启动的控制权移交到MBR部分的代码。
注： 在我们的现行系统中，大多关键设备都是连在主板上的。因此主板BIOS提供了一个操作系统（软件）和系统外围关键设备（硬件）最底级别的接口，在这个阶段，检测系统外围关键设备是否“准备好”，以供操作系统使用。
第二阶段：
BIOS通过下面两种方法之一来传递引导记录：
第一， 将控制权传递给initial program loader（IPL），该程序安装在磁盘主引导记录（MBR）中
第二， 将控制权传递给initial program loader（IPL），该程序安装在磁盘分区的启动引导扇区中
无论上面的哪种情况中，IPL都是MBR的一部分并应该存储于一个不大于446字节的磁盘空间中，因为MBR是一个不大于512字节的空间。
因此IPL仅仅是GRUB的第一个部分（stage1），他的作用就是定位和装载GRUB的第二个部分（stage2）；stage2对启动系统起关键作用，该部分提供了GRUB启动菜单和交互式的GRUB的shell。启动菜单在启动时候通过/boot/grub/grub.conf文件所定义的内容生成。在启动菜单中选择了kernel之后，GRUB会负责解压和装载kernel image并且将initrd装载到内存中。最后GRUB初始化kernel启动代码。
完成之后后续的引导权被移交给kernel。
假设Boot Loader为grub (grub-0.97)，其引导系统的过程如下：
grub分为stage1 (stage1_5) 和stage2两个阶段。stage1可以看成是initial program loaderI（IPL），而stage2则实现了grub的主要功能，包括对特定文件系统的支持（如ext2，ext3，reiserfs等），grub自己的shell，以及内部程序（如：kernrl，initrd，root）等。
stage 1：MBR（512 字节，0头0道1扇区），前446字节存放的是 stage1，后面存放硬盘分区表信息，BIOS将stag1载入内存中0x7c00处并跳转执行。stage1（/stage1/start.S）的任务非常单纯，仅仅是将硬盘0头0道2扇区读入内存。0头0道2扇区内容是源代码中的/stage2/start.S，编译后512字节，它是stage2或者stage1_5的入口。
注：此时stage1是没有能力识别文件系统的，其定位硬盘0头0道2扇区过程如下：
BIOS将stage1载入内存0x7c00处并执行，然后调用BIOS INIT13中断，将硬盘0头0道2扇区内容载入内存0x7000处，然后调用copy_buffer将其转移到内存0x8000处。定位0头0道2扇区有两种寻址方式：LBA、CHS。
start.S的主要功能是将stage2或stage1_5从硬盘载入内存，如果是stage2，则载入0x820处；如果是 stage1_5，则载入0x2200处。
注：这里的stage2或者stage1_5不是/boot分区/boot/grub目录下的文件，这个时候grub还没有能力识别任何文件系统。分以下两种情况：
（1）假如start.S读取的是stage1_5，它存放在硬盘0头0道3扇区向后的位置，stage1_5作为stage1和stage2中间的桥梁，stage1_5有识别文件系统的能力，此后grub才有能力去访问/boot分区/boot/grub目录下的 stage2文件，将stage2载入内存并执行。
（2）假如start.S读取的是stage2，同样，这个stage2也不是/boot分区/boot/grub目录下的stage2，这个时候start.S读取的是存放在/boot分区Boot Sector的stage2。这种情况下就有一个限制：因为start.S通过BIOS中断方式直接对硬盘寻址（而非通过访问具体的文件系统），其寻址范围有限，限制在8GB以内。因此这种情况需要将/boot分区分在硬盘8GB寻址空间之前。
假如是情形（2），我们将/boot/grub目录下的内容清空，依然能成功启动grub；假如是情形（1），将/boot/grub目录下stage2删除后，则系统启动过程中grub会启动失败。
这个地方经常要进行的操作：
是关于grub常用的几个指令对应的函数：
grub>root (hd0,0) --root指令为grub指定了一个根分区
grub>kernel /xen.gz-2.6.18-37.el5 --kernel指令将操作系统内核载入内存
grub>module /vmlinuz-2.6.18-37.el5xen ro root=/dev/sda2 --module指令加载指定的模块
grub>module /initrd-2.6.18-37.el5xen.img --指定initrd文件
grub>boot --boot 指令调用相应的启动函数启动OS内核
第三阶段：
如阶段2所述，grub>boot指令后，系统启动的控制权移交给kernel。Kernel会立即初始化系统中各设备并做相关配置工作，其中包括CPU、I/O、存储设备等。
关于设备驱动加载，有两部分：一部分设备驱动编入Linux Kernel中，Kernel会调用这部分驱动初始化相关设备，同时将日志输出到kernel message buffer，系统启动后dmesg可以查看到这部分输出信息。另外有一部分设备驱动并没有编入Kernel，而是作为模块形式放在initrd（ramdisk）中。
在2.6内核中，支持两种格式的initrd，一种是2.4内核的文件系统镜像image-initrd，一种是cpio格式。以 cpio 格式为例，内核判断initrd为cpio的文件格式后，会将initrd中的内容释放到rootfs中。
initrd是一种基于内存的文件系统，启动过程中，系统在访问真正的根文件系统/时，会先访问initrd文件系统。将initrd中的内容打开来看，会发现有bin、devetc、lib、procsys、sysroot、init等文件（包含目录）。其中包含了一些设备的驱动模块，比如scsi ata等设备驱动模块，同时还有几个基本的可执行程序 insmod, modprobe, lvm，nash。主要目的是加载一些存储介质的驱动模块，如上面所说的scsi ideusb等设备驱动模块，初始化LVM，把/根文件系统以只读方式挂载。
initrd中的内容释放到rootfs中后，Kernel会执行其中的init文件，这里的init是一个脚本，由nash解释器执行。这个时候内核的控制权移交给init文件处理，我们查看init文件的内容，主要也是加载各种存储介质相关的设备驱动。
驱动加载后，会创建一个根设备，然后将根文件系统/以只读的方式挂载。这步结束后释放未使用内存并执行switchroot，转换到真正的根/上面去，同时运行/sbin/init程序，开启系统的1号进程，此后系统启动的控制权移交给 init 进程。关于switchroot是在nash中定义的程序。
Linux Kernel需要适应多种不同的硬件架构，但是将所有的硬件驱动编入Kernel又是不实际的，而且Kernel也不可能每新出一种硬件结构，就将该硬件的设备驱动写入内核。实际上Linux Kernel仅是包含了基本的硬件驱动，在系统安装过程中会检测系统硬件信息，根据安装信息和系统硬件信息将一部分设备驱动写入 initrd 。这样在以后启动系统时，一部分设备驱动就放在initrd中来加载。
第四阶段：
init进程起来后，系统启动的控制权移交给init进程。
/sbin/init进程是所有进程的父进程，当init起来之后，它首先会读取配置文件/etc/inittab，进行以下工作：
1）执行系统初始化脚本(/etc/rc.d/rc.sysinit)，对系统进行基本的配置，以读写方式挂载根文件系统及其它文件系统，到此系统基本算运行起来了，后面需要进行运行级别的确定及相应服务的启动；
2）确定启动后进入的运行级别；
3) 执行/etc/rc.d/rc，该文件定义了服务启动的顺序是先K后S，而具体的每个运行级别的服务状态是放在/etc/rc.d/rcn.d（n=0~6）目录下，所有的文件均链接至/etc/init.d下的相应文件。
4）有关key sequence的设置
5) 有关UPS的脚本定义
6）启动虚拟终端/sbin/mingetty
7）在运行级别5上运行X
这时呈现给用户的就是最终的登录界面。
至此，系统启动过程完毕：）
说明：
1）/etc/rc.d/rc.sysint -- System Initialization Tasks
它的主要工作有：
配置selinux，
系统时钟，
内核参数（/etc/sysctl.conf），
hostname，
启用swap分区，
根文件系统的检查和二次挂载（读写），
激活RAID和LVM设备，
启用磁盘quota
检查并挂载其它文件系统
等等。
GRUB的基本原理以及对GRUB的操作控制方法：
GRUB全称为Grand Unified Boot Loader，是Linux操作系统主流的启动引导管理器。主要作用是启动和装载Linux操作系统。系统启动过程中一旦完成了BIOS自检，GRUB会被立刻装载。在GRUB里面包含了可以载入操作系统的代码以及将操作系统引导权传递给其他启动引导管理器的代码。GRUB可以允许用户选择使用不同的kernel启动系统，或者在启动系统的过程中设置不同的启动参数。
而通常BIOS会以下面两种方法之一来调用启动引导管理器：
将控制权移交给于驱动器主引导记录的initial program loader（IPL）；
将控制权移交给其他启动引导管理器，再由他们将控制权移交给安装在分区引导扇区的IPL
通常情况下启动引导管理器GRUB由两部分组成（stage1和stage2）：
stage1比较小，通常可以驻留在MBR或者各个磁盘分区的启动扇区中，主要作用是装载stage2。
stage2比较大，从磁盘的启动引导分区读取
至于在stage1和stage2之间存在一个stage1.5，是因为starge1.5具有识别文件系统的能力。
在Linux系统中对GRUB的配置有两种方法：
主要引导管理器：
会将启动引导管理器的stage1安装在MBR上，这时启动引导管理器必须被配置为可以传递控制权到其他操作系统；
次要引导管理器：
会将启动引导管理器的stage1安装在一些分区的引导扇区上，而其他的启动引导管理器会被安装在MBR上，由他们来向Linux启动引导管理器传递控制权。
GRUB在启动过程中可以提供命令行交互界面，可以从ext系列，reiserfs，fat等多种文件系统引导系统，并且可以提供密码加密功能，其内容在/boot分区下，系统启动过程中由配置文件/boot/grub/grub.conf来定义启动方式，对该配置文件的更改会立即生效。
在配置文件/boot/grub/grub.conf文件中定义的内容包括：
grub所在的分区，引导系统所使用的kernel文件位置，硬件初始化使用的initrd文件位置，以及启动参数。
例如：
grub>root (hd0,0) --root指令为grub指定了一个根分区
grub>kernel /xen.gz-2.6.18-37.el5 --kernel指令将操作系统内核载入内存
grub>module /vmlinuz-2.6.18-37.el5xen ro root=/dev/sda2 --module指令加载指定的模块
grub>module /initrd-2.6.18-37.el5xen.img --指定initrd文件
grub>boot --boot 指令调用相应的启动函数启动OS内核
可见其指定的内容大多数在/boot分区，如果切换到/boot分区之后会看到这些内容：
/boot/vmlinuz-* linux kernel的一个copy；
/boot/initrd*.img 初始化的ram disk文件
/boot/grub/device.map linux设备名和grub设备名的映射文件
/boot/grub/grub.conf 主配置文件
通常GRUB出错几率不是很大，但一旦出现问题恐怕采用最多的方式是重装grub到MBR中。
在这种时候需要注意的问题有：
首先，设备映射关系：
GRUB里面对设备名称的定义和系统中对设备名称的定义方法不一样：
（fd0） /dev/fd0
（hd0） /dev/sda /dev/hda
（hd1） /dev/sdb /dev/hdb
如够进入系统或者救援模式，可执行命令/sbin/grub-install /dev/sda（或者hda）进行GRUB重装：
# /sbin/grub-install device
处于某种原因MBR中信息出错可以使用上面的命令将其重装到磁盘主引导记录中；但是如果在不能进入系统的情况下就需要通过grub的命令行界面进行手动设置，这个时候就要注意上面所提到的映射关系。
同时，在grub命令行中对grub进行手动设置的时候需要注意所使用的命令：
# root （hd0,0） --指定启动分区
# setup（hd0） --表示将grub安装在主引导记录上
# quit --退出grub shell
下面是一个完整的grub.conf文件内容：
[root@dhcp-0-195 ~]# cat /etc/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup001/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=30
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
password --md5 $1$apEcJWbA$DTJ8a6mKn/3yrTTSXBtdH0
title Red Hat Enterprise Linux Client (2.6.18-8.1.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-8.1.1.el5 ro root=/dev/VolGroup001/LogVol00 crashkernel=128M@16M
initrd /initrd-2.6.18-8.1.1.el5.img
系统启动运行级别的概念以及服务的定制方法；
当initrd可以正常检测和装载之后，最后的工作就基本上由操作系统来进行了。当系统的init进程起来之后系统启动的控制权移交给init进程。
/sbin/init进程是所有进程的父进程，当init起来之后，它首先会读取配置文件/etc/inittab，进行以下工作：
1）执行系统初始化脚本(/etc/rc.d/rc.sysinit)，对系统进行基本的配置，以读写方式挂载根文件系统及其它文件系统，后面需要进行运行级别的确定及相应服务的启动，（从这个角度可以看出如果要定义系统的init动作，需要修改/etc/rc.d/rc.sysinit脚本）
2）通过对/etc/inittab文件的读取确定启动后进入的运行级别；
3) 在相应的运行级别中执行/etc/rc.d/rcx.d目录下的脚本名称，该文件定义了服务启动的顺序是先K后S，而具体的每个运行级别的服务状态是放在/etc/rc.d/rcn.d（n=0~6）目录下，但这些文件均是到/etc/init.d下的相应文件的链接。
系统会按照在该目录下的文件名称和优先级执行对应运行级别目录下的脚本：
在某个运行级别的对应目录下，K开头的服务被关闭，S开头的服务被开启，K在S开始之前执行，在执行过程中按照数字来定义优先级，数字越低优先级越高。
4）按照/etc/rc.d/rcX.d目录中的定义，系统会于后台启动相应的服务，如果要对某个运行级别中的服务进行更具体的定制，通过chkconfig命令来操作，或者通过setup/ntsys/system-config-services来进行定制。
5）在/etc/inittab文件中存在有关key sequence，UPS的脚本定义，启动虚拟终端/sbin/mingetty的设置，这时呈现给用户的就是最终的登录界面。
也就是说后台启动的服务完毕之后，如果系统默认进入字符界面，则运行mgetty进入1-6号终端控制台，如果系统默认进入图形界面，则开启gdm服务进入7号虚拟图形控制台。
至此，系统启动过程完毕。
对于/etc/rc.d/rc.sysinit文件的说明：
/etc/rc.d/rc.sysint -- System Initialization Tasks 执行系统初始化任务的脚本。
它的主要工作有：
配置selinux，
系统时钟，
内核参数（/etc/sysctl.conf），
hostname，
启用swap分区，
根文件系统的检查和二次挂载（读写），
激活RAID和LVM设备，
启用磁盘quota
检查并挂载其它文件系统
这是其基本要实现的工作内容：
#!/bin/bash
#
# /etc/rc.d/rc.sysinit - run once at boot time
#
# Taken in part from Miquel van Smoorenburg's bcheckrc.
# Check SELinux status
# Because of a chicken/egg problem, init_crypto must be run twice. /var may be
# encrypted but /var/lib/random-seed is needed to initialize swap.
# Only read this once.
# Initialize hardware
# Set default affinity
# Load other user-defined modules
# Load modules (for backward compatibility with VARs)
# Start the graphical boot, if necessary; /usr may not be mounted yet, so we
# may have to do this again after mounting
# Configure kernel parameters
# Set the hostname.
# Initialize ACPI bits
# RAID setup
# Device mapper & related initialization
# Update quotas if necessary
# Remount the root filesystem read-write.
# Clean up SELinux labels
# Clear mtab
# Remove stale backups
# Enter mounted filesystems into /etc/mtab
# Mount all other filesystems (except for NFS and /proc, which is already
# mounted). Contrary to standard usage,
# filesystems are NOT unmounted in single user mode.
# Check to see if a full relabel is needed
# Start the graphical boot, if necessary and not done yet.
# Initialize pseudo-random number generator
# Use the hardware RNG to seed the entropy pool, if available
# Configure machine if necessary.
# Clean out /.
# Do we need (w|u)tmpx files? We don't set them up, but the sysadmin might...
# Clean up /var. I'd use find, but /usr may not be mounted.
# Reset pam_console permissions
# Clean up utmp/wtmp
# Clean up various /tmp bits
# Make ICE directory
# Start up swapping.
以下是我在生产环境中所碰到的一些和GRUB修复有关的案例：
案例一：
GRUB无法找到kernel image的问题：
产生这类型问题的原因包括：
配置文件中指定了错误的kernel image名称或者路径，在/boot分区下kernel文件被删除或者更名，kernel image文件被破坏，Raid-1磁盘阵列更换故障盘后信息不同步等。
对于这类型问题的解决方法：
可以设法通过救援模式或者在开机的时候进入grub的shell，然后利用grub shell尝试手动指定和装载正确的kernel image信息或者在救援模式下检查和重写grub.conf文件。
需要注意的是，如果要通过救援模式进入grub命令行界面需要先chroot，即执行chroot /mnt/sysimage。在
grub>提示符之后执行：
# root （hd0,0）
# setup（hd0）
# quit
不管通过什么样的方法和配置，只要使GRUB能够正确找到kernel image是解决问题的关键。
在对grub修复的时候尤其要注意MBR信息在软件Raid上的恢复。
Linux的boot分区不能建立在软件Raid-0上，但是可以建立在Raid-1阵列上。也就意味着系统的GRUB也是同时写入到Raid-1磁盘阵列两块盘的MBR中。但是如果这个信息一旦这个信息没有正确写入或者正常完成写入，问题就会出现。
这种情况多发于对Raid-1阵列中的坏盘进行更换的时候。
一个典型的例子是，用户只有两块磁盘做Raid-1，他在两块盘上分别规划了同样的磁盘分区/boot swap以及/，对应的设备是md0，md1和md2。在其中的某一个磁盘出现问题的时候，用户更换一块新的磁盘，并且按照原来的盘规划了/boot，swap以及/，同时使用了命令mdadm -A对三个md都进行了重组，重组能够顺利完成，但是一旦重启系统在出现一个GRUB的提示对话框之后引导停止。
从这个情况看来，很显然，md0，md1和md2内的数据都由原来的磁盘向新的磁盘进行了同步，但是MBR的内容和信息没有同步过来。这就造成了系统启动的失败。
解决该问题的方法：
可以使用救援模式引导系统，或者使得GRUB能够检测到文件系统——即出现GRUB>提示符，执行下面的命令，将GRUB重装到第一块盘：
# root （hd0,0）
# setup（hd0）
# quit
然后执行，将GRUB重装到第二块盘：
# root （hd1,0）
# setup（hd0）
# quit
完成之后重启系统。这种方法还可以对付在BIOS中对启动引导管理器进行的修改。
案例二：
None System or Disk Error和GRUB的关系：
某个用户曾经报告一台HP的DL380服务器上原有40G和140G两块硬盘，并且按照第一块硬盘所能够提供的磁盘空间建立了一个软件Raid-0磁盘阵列。该用户在没有拔除这两块硬盘的情况下直接加入了两块新的硬盘并计划对原有的Raid-0阵列进行扩容。但在插入硬盘重启之后显示“None System or Disk Error”，在用户拔除这两块硬盘之后重启还出现同样的信息。
根据描述的系统启动过程来看，这个none system or disk error的报错，表明系统启动引导过程中并没有装在任何启动引导管理器（GRUB）信息，而之所以没有找到这些信息是因为这些磁盘的MBR里面没有用于引导的IPL或者说白了系统所用于引导的磁盘根本就不是启动盘。看来系统并没有使用用户设想的磁盘作为启动引导磁盘。那么也就时说这和在磁盘的GRUB没有任何关系，我们所要做的第一能够确保系统使用正确的磁盘引导，第二就是没有对原有的GRUB进行任何错误的修改就行。
按照我们对问题的分析，用户更换了硬盘所在的槽位，问题得到解决。
产生该问题的原因是因为HP DL380服务器在安装系统必须在阵列上进行，但是新加入的磁盘或者阵列会更改原来默认的启动引导顺序。尽管这和GRUB的修复没有任何关系，但是能够准确定位该问题的所在至少能够减少排错的时间以及一些不必要的麻烦。
案例三：
在RHEL3中HP服务器上的cciss和system-map的问题：
众所周知在GRUB中对设备进行命名的方法和系统命名的方法是不同的。不管系统中的启动引导磁盘是sd接口还是hd接口在GRUB中都会被统一识别为hd，并且hda/sdahd0，hdb/sdbhd1……依次类推。这和系统对设备的命名方式显然存在一些差异，但是这种差异通过在/boot/grub/device-map文件中进行解释和映射来实现系统对两种设备命名方法的映射。
这是一个device-map文件的内容：
遗憾的是，redhat老版本的操作系统如RHEL3的某个版本，在一些特殊的硬件上，如HP的cciss中对系统设备名和GRUB设备名的映射关系不正确而导致系统在这些硬件上无法启动。这可以认为是操作系统的一个bug，所幸该bug在RHEL3靠后的几个发行版后都得到了修复。
尽管碰到这种问题的几率极低，但需要明确一点，检查设备映射是否正确也是GRUB排错的一项内容。
这里顺别说一下：
cciss是惠普的smart array控制器的设备名，c0指channl 0，第一个SCSI通道，d0指逻辑盘1，d1指逻辑盘2……，p1指第一个分区，p2是第二个分区……。在这种情况下，我们可以看到很多HP的服务器在通过该设备连接硬盘的时候，经常看到的设备是/dev/cciss/c0d0p1，/dev/cciss/c0d0p2，/dev/cciss/c0d0p3等。
案例四：
在GRUB中向kernel传递了错误的根分区信息导致系统kernel panic：
在GRUB的配置中，根分区信息的指定是必须的，但是一旦错误指定了根分区或者根分区文件文件系统或卷标被破坏都回导致在启动引导过程中出现kernel panic情况。
这是在GRUB中对/分区指定的信息：
kernel /vmlinuz-2.6.18-8.1.1.el5 ro root=LABEL=/
那么一旦/卷标被删除，可以通过e2label的方式重新创建，或者将其直接更改为：
kernel /vmlinuz-2.6.18-8.1.1.el5 ro root=/dev/sda2
即以直接指定/分区名的方式来指定根分区。
这个操作可以在开机发现错误之后于GRUB命令行中直接修改，或者进入救援模式进行操作。当前所定义的内容如果成功，切记将其记录到/etc/grub.conf或者/boot/grub/grub.conf文件中。
其实这是一个非常典型的错误，出错的时候，屏幕上显示的大概情况如下：
Creating block devices
Creating root devices
mkrootdev：label / not found
Mounting root filesystem
Mount：error 2 mounting ext3
Pivotroot：pivot_root（/sysroot， /sysroot/initrd） failed：2
umount /initrd/proc failed：2
Freeing unused kernel memory：164k freed
Kernel panic：no init found. Try passing init = option to kernel.
很显然，这个时候如果是因为/文件系统无法找到或者挂载成功，必须的内核模块没有加载成功或者initrd文件被破坏都有可能出现同样的信息（这里所指的模块是包括了驱动器，硬件控制器以及作用于文件系统的驱动程序，当然如果是模块造成系统启动不成功的话，可以使用mkinitrd命令对initrd文件进行重建）。
具体的命令是：
# mkinitrd –f /boot/initrd-<kernel version>.img <kernel-version>
例如：
# mkinitrd –f /boot/initrd-2.6.9-42.ELsmp.img 2.6.9-24.ELsmp
在完成了initrd镜像的重建之后可以重新启动系统。
如果问题确认是因为initrd镜像被破坏而导致无法识别文件系统，则通过上面的操作已经能够正确找到root文件系统并开启init进程。
案例五：
该案例实际上和上面的案例有紧密关系。上面的案例中由于GRUB无法正确加载根文件系统而导致kernel panic。造成这个问题的原因也是多种多样。但是即便通过上面的修复可以使得kernel加载根文件系统并且开启init进程，那么在下一步rc.sysinit脚本执行过程中任何区域出现错误也会导致系统无法启动。
因为在存储方面，sc.sysinit脚本会初始化软件raid以及lvm设备然后读取/etc/fstab，所以这个时候如果/etc/fstab文件配置不正确，也会造成系统启动不成功。
从出现的问题现象上基本可以断定是/etc/fstab的问题，但是好在这个时候可以进入修复模式，对问题的修复方法也容易很多。这是出现问题的时候的截屏：
Coundn’t find matching filesystem: LABEL=/
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to countinus):
在这个界面中输入root密码可以在出现的修复模式中运行命令修复。
另外一个会造成该现象的原因是在读/etc/fstab文件并挂载文件系统的时候文件系统检测失败。在这种情况下需要确保文件系统处于umount状态下运行e2fsck。
案例六：
对initrd文件的修复：
initrd是一种基于内存的文件系统，启动过程中，系统在访问真正的根文件系统/时，会先访问initrd文件系统。将initrd中的内容打开来看，会发现有bin、devetc、lib、procsys、sysroot、init等文件（包含目录）。其中包含了一些设备的驱动模块，比如scsi ata等设备驱动模块，同时还有几个基本的可执行程序 insmod, modprobe, lvm，nash。主要目的是加载一些存储介质的驱动模块，如上面所说的scsi ideusb等设备驱动模块，初始化LVM，把/根文件系统以只读方式挂载。
Linux Kernel需要适应多种不同的硬件架构，但是将所有的硬件驱动编入Kernel又是不实际的，而且Kernel也不可能每新出一种硬件结构，就将该硬件的设备驱动写入内核。实际上Linux Kernel仅是包含了基本的硬件驱动，在系统安装过程中会检测系统硬件信息，根据安装信息和系统硬件信息将一部分设备驱动写入 initrd 。这样在以后启动系统时，一部分设备驱动就放在initrd中来加载。
所以在启动过程中initrd文件会在1号进程被开启之前执行，如果一旦initrd文件被破坏或者非正常的更改就会导致系统无法启动。根据以前对initrd原理的解释，initrd中的init是使用nash解释器去执行，所以系统启动没有到nash的时候停住，可以基本上判断是initrd这里hang住。比较可行的办法是通过mkinitrd命令重建initrd，生成一个新的用于初始化和装载模块的ramdisk镜像。
具体的命令是：
# mkinitrd –f /boot/initrd-<kernel version>.img <kernel-version>
例如：
# mkinitrd –f /boot/initrd-2.6.9-42.ELsmp.img 2.6.9-24.ELsmp
或者通过强制的方式重装一个kernel，因为kernel基本上以不变的方式覆盖原来kernel所安装的内容，同时会在rpm安装kernel命令中有重建initrd的脚本：
[root@dhcp-0-195 ~]# rpm -q --scripts kernel
postinstall scriptlet (using /bin/sh):
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ]; then
if [ -f /etc/sysconfig/kernel ]; then
/bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi
fi
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.18-8.1.1.el5 || exit $?
if [ -x /sbin/weak-modules ]
then
/sbin/weak-modules --add-kernel 2.6.18-8.1.1.el5 || exit $?
fi
preuninstall scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 2.6.18-8.1.1.el5 || exit $?
if [ -x /sbin/weak-modules ]
then
/sbin/weak-modules --remove-kernel 2.6.18-8.1.1.el5 || exit $?
fi
案例七：
在系统启动过程中对rc.sysinit脚本进行定位的方法：
在最近对一些客户问题进行处理的时候有时会发现一些因为对/etc/rc.d/rc.sysinit脚本的更改而导致系统无法启动成功的问题。由于rc.sysinit脚本所负责系统环境变量、存储，设备初始化、配额等多个部分的设置和初始化，所以在启动过程中出现如果是因为rc.sysinit的更改而出现dead lock不容易定位是哪个地方的设置出现问题。
由于rc.sysinit脚本是由多个部分组成，一个比较简单的办法就是在每个部分之间加上一个标记。例如：
sleep 10
echo “sleep 10”
这样系统在执行rc.sysinit脚本过程中的每个部分都会停10秒并显示一个提示信息“sleep 10”，这样可以通过显示的信息定位大概问题出在哪里。
案例八：
在系统启动过程中出现的初始化和启动swap的时候系统出现的dead lock的解决方法：
在某些情况下系统启动到enable swap的时候会长时间的dead lock现象，在某些时候系统悬挂于此而始终不能打开mgetty终端提供控制台。
swap交换分区是一个特殊的文件系统，该文件系统的基本作用就是可以使操作系统将一部分驻留于内存而暂时不操作的进程转移到swap分区中而腾出物理内存给新的需要执行的进程。
红帽官方推荐的使用交换分区的比例是2G物理内存以下，交换分区为物理内存的1.5-2倍；4G以上物理内存推荐交换分区与物理内存为1：1。
但一般情况下可能会有多种原因造成swap文件系统的初始化失败而且由于swap分区内容在用户空间无法操作，所以很难准确获得原因。但很多时候系统在启动到swap的时候并没有真正的dead lock，而是由于之后的一些其他服务的启动影响了系统打开终端并给用户造成系统启动swap失败的假象。
基本上一些启动顺序在swap之后的服务都有可能产生这种影响，但由于系统在安装之后默认加载在kernel parameter “rhgb quite”会掩盖整个的启动过程，所以在系统启动到GRUB的时候通过进入GRUB菜单，手动删除“rhgb quite”会防止在启动的时候屏蔽启动过程并显示完整的启动信息。
另外这个rhgb（redhat graphical boot）本身就有可能干扰后续的服务启动。在很多时候实际上后面的服务已经起来，但是系统会显示enable swap并停在该处。在这个时候可以使用ping的方法或者ssh去探测该主机是否已经可以登录并提供服务。
来源：http://linux.chinaunix.net/bbs/thread-1013345-2-1.html
*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。
发布文章
