转自：http://bbs.chinaunix.net/viewthread.php?tid=2046548&page=1&authorid=11195425
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去探测该主机是否已经可以登录并提供服务。
=================================================================================================================================================================================
附上Linux启动过程详解（转自：http://roclinux.cn/?p=1301），讲得比较精简
启动第一步－－加载BIOS
当你打开计算机电源，计算机会首先加载BIOS信息，BIOS信息是如此的重要，以至于计算机必须在最开始就找到它。这是因为BIOS中包含了CPU的相关信息、设备启动顺序信息、硬盘信息、内存信息、时钟信息、PnP特性等等。在此之后，计算机心里就有谱了，知道应该去读取哪个硬件设备了。
启动第二步－－读取MBR
众所周知，硬盘上第0磁道第一个扇区被称为MBR，也就是Master Boot Record，即主引导记录，它的大小是512字节，别看地方不大，可里面却存放了预启动信息、分区表信息。
系统找到BIOS所指定的硬盘的MBR后，就会将其复制到0×7c00地址所在的物理内存中。其实被复制到物理内存的内容就是Boot Loader，而具体到你的电脑，那就是lilo或者grub了。
启动第三步－－Boot Loader
Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核做好一切准备。
Boot Loader有若干种，其中Grub、Lilo和spfdisk是常见的Loader。
我们以Grub为例来讲解吧，毕竟用lilo和spfdisk的人并不多。
系统读取内存中的grub配置信息（一般为menu.lst或grub.lst），并依照此配置信息来启动不同的操作系统。
启动第四步－－加载内核
根据grub设定的内核映像所在路径，系统读取内存映像，并进行解压缩操作。此时，屏幕一般会输出“Uncompressing Linux”的提示。当解压缩内核完成后，屏幕输出“OK, booting the kernel”。
系统将解压后的内核放置在内存之中，并调用start_kernel()函数来启动一系列的初始化函数并初始化各种设备，完成Linux核心环境的建立。至此，Linux内核已经建立起来了，基于Linux的程序应该可以正常运行了。
启动第五步－－用户层init依据inittab文件来设定运行等级
内核被加载后，第一个运行的程序便是/sbin/init，该文件会读取/etc/inittab文件，并依据此文件来进行初始化工作。
其实/etc/inittab文件最主要的作用就是设定Linux的运行等级，其设定形式是“：id:5:initdefault:”，这就表明Linux需要运行在等级5上。Linux的运行等级设定如下：
0：关机
1：单用户模式
2：无网络支持的多用户模式
3：有网络支持的多用户模式
4：保留，未使用
5：有网络支持有X-Window支持的多用户模式
6：重新引导系统，即重启
关于/etc/inittab文件的学问，其实还有很多，在后序文章中设计到的，卖个关子，敬请期待，呵呵
启动第六步－－init进程执行rc.sysinit
在设定了运行等级后，Linux系统执行的第一个用户层文件就是/etc/rc.d/rc.sysinit脚本程序，它做的工作非常多，包括设定PATH、设定网络配置（/etc/sysconfig/network）、启动swap分区、设定/proc等等。如果你有兴趣，可以到/etc/rc.d中查看一下rc.sysinit文件，里面的脚本够你看几天的:P
启动第七步－－启动内核模块
具体是依据/etc/modules.conf文件或/etc/modules.d目录下的文件来装载内核模块。
启动第八步－－执行不同运行级别的脚本程序
根据运行级别的不同，系统会运行rc0.d到rc6.d中的相应的脚本程序，来完成相应的初始化工作和启动相应的服务。
启动第九步－－执行/etc/rc.d/rc.local
你如果打开了此文件，里面有一句话，读过之后，你就会对此命令的作用一目了然：
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don’t
# want to do the full Sys V style init stuff.
rc.local就是在一切初始化工作后，Linux留给用户进行个性化的地方。你可以把你想设置和启动的东西放到这里。
启动第十步－－执行/bin/login程序，进入登录状态
此时，系统已经进入到了等待用户输入username和password的时候了，你已经可以用自己的帐号登入系统了。:)
=======================================================================================
还有一篇文章也不错（http://bbs.chinaunix.net/thread-1947041-1-1.html）
本文以RedHat9.0和i386平台为例，剖析了从用户打开电源直到屏幕出现命令行提示符的整个Linux启动过程。并且介绍了启动中涉及到的各种文件。
阅读Linux源代码，无疑是深入学习Linux的最好方法。在本文对Linux启动过程的介绍中，我们也尝试从源代码的视角来更深入的剖析Linux
的启动过程，所以其中也简单涉及到部分相关的Linux源代码，Linux启动这部分的源码主要使用的是C语言，也涉及到了少量的汇编。而启动过程中也执
行了大量的shell(主要是bash
shell)所写脚本。为了方便读者阅读，笔者将整个Linux启动过程分成以下几个部分逐一介绍，大家可以参考下图：
当用户打开PC
的电源，BIOS开机自检，按BIOS中设置的启动设备(通常是硬盘)启动，接着启动设备上安装的引导程序lilo或grub开始引导
Linux，Linux首先进行内核的引导，接下来执行init程序，init程序调用了rc.sysinit和rc等程序，rc.sysinit和rc
当完成系统初始化和运行服务的任务后，返回init；init启动了mingetty后，打开了终端供用户登录系统，用户登录成功后进入了Shell，这
样就完成了从开机到登录的整个启动过程。
下面就将逐一介绍其中几个关键的部分：
第一部分：内核的引导(核内引导)
Red
Hat9.0可以使用lilo或grub等引导程序开始引导Linux系统，当引导程序成功完成引导任务后，Linux从它们手中接管了CPU的控制权，
然后CPU就开始执行Linux的核心映象代码，开始了Linux启动过程。这里使用了几个汇编程序来引导Linux，这一步泛及到Linux源代码树中
的“arch/i386/boot”下的这几个文件：bootsect.S、setup.S、video.S等。
其中
bootsect.S是生成引导扇区的汇编源码，它完成加载动作后直接跳转到setup.S的程序入口。setup.S的主要功能就是将系统参数（包括内
存、磁盘等，由BIOS返回）拷贝到特别内存中，以便以后这些参数被保护模式下的代码来读取。此外，setup.S还将video.S中的代码包含进来，
检测和设置显示器和显示模式。最后，setup.S将系统转换到保护模式，并跳转到 0x100000。
那么0x100000这个内存地址中存放的是什么代码？而这些代码又是从何而来的呢？
0x100000这个内存地址存放的是解压后的内核，因为Red
Hat提供的内核包含了众多驱动和功能而显得比较大，所以在内核编译中使用了“makebzImage”方式，从而生成压缩过的内核，在RedHat中内
核常常被命名为vmlinuz，在Linux的最初引导过程中，是通过"arch/i386/boot/compressed/"中的head.S利用
misc.c中定义的decompress_kernel()函数，将内核vmlinuz解压到0x100000的。
当CPU跳到
0x100000时，将执行"arch/i386/kernel/head.S"中的startup_32，它也是vmlinux的入口，然后就跳转到
start_kernel()中去了。start_kernel()是"init/main.c"中的定义的函数，start_kernel()中调用了
一系列初始化函数，以完成kernel本身的设置。start_kernel()函数中，做了大量的工作来建立基本的Linux核心环境。如果顺利执行完
start_kernel()，则基本的Linux核心环境已经建立起来了。
在start_kernel()的最后，通过调用
init()函数，系统创建第一个核心线程，启动了init过程。而核心线程init()主要是来进行一些外设初始化的工作的，包括调用
do_basic_setup()完成外设及其驱动程序的加载和初始化。并完成文件系统初始化和root文件系统的安装。
当
do_basic_setup()函数返回init()，init()又打开了/dev/console设备，重定向三个标准的输入输出文件stdin、
stdout和stderr到控制台，最后，搜索文件系统中的init程序（或者由init=命令行参数指定的程序），并使用
execve()系统调用加载执行init程序。到此init()函数结束，内核的引导部分也到此结束了，
第二部分：运行init
init的进程号是1，从这一点就能看出，init进程是系统所有进程的起点，Linux在完成核内引导以后，就开始运行init程序，。init程序
需要读取配置文件/etc/inittab。inittab是一个不可执行的文本文件，它有若干行指令所组成。在Redhat系统中，inittab的内
容如下所示(以“###"开始的中注释为笔者增加的)：
#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#
# Author: Miquel van Smoorenburg,
# 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 havenetworking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
###表示当前缺省运行级别为5(initdefault)；
id:5:initdefault:
###启动时自动执行/etc/rc.d/rc.sysinit脚本(sysinit)
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
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
###当运行级别为5时，以5为参数运行/etc/rc.d/rc脚本，init将等待其返回(wait)
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
###在启动过程中允许按CTRL-ALT-DELETE重启系统
# 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"
###在2、3、4、5级别上以ttyX为参数执行/sbin/mingetty程序，打开ttyX终端用于用户登录，
###如果进程退出则再次运行mingetty程序(respawn)
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
###在5级别上运行xdm程序，提供xdm图形方式登录界面，并在退出时重新执行(respawn)
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon
以上面的inittab文件为例，来说明一下inittab的格式。其中以#开始的行是注释行，除了注释行之外，每一行都有以下格式：
id:runlevel:action:process
对上面各项的详细解释如下：
1. id
id是指入口标识符，它是一个字符串，对于getty或mingetty等其他login程序项，要求id与tty的编号相同，否则getty程序将不能正常工作。
2. runlevel
runlevel是init所处于的运行级别的标识，一般使用0－6以及S或s。0、1、6运行级别被系统保留：其中0作为shutdown动作，1作
为重启至单用户模式，6为重启；S和s意义相同，表示单用户模式，且无需inittab文件，因此也不在inittab中出现，实际上，进入单用户模式
时，init直接在控制台（/dev/console）上运行/sbin/sulogin。在一般的系统实现中，都使用了2、3、4、5几个级别，在
Redhat系统中，2表示无NFS支持的多用户模式，3表示完全多用户模式（也是最常用的级别），4保留给用户自定义，5表示XDM图形登录方式。
7－9级别也是可以使用的，传统的Unix系统没有定义这几个级别。runlevel可以是并列的多个值，以匹配多个运行级别，对大多数action来
说，仅当runlevel与当前运行级别匹配成功才会执行。
3. action
action是描述其后的process的运行方式的。action可取的值包括：initdefault、sysinit、boot、bootwait等：
initdefault是一个特殊的action值，用于标识缺省的启动级别；当init由核心激活以后，它将读取inittab中的
initdefault项，取得其中的runlevel，并作为当前的运行级别。如果没有inittab文件，或者其中没有initdefault
项，init将在控制台上请求输入runlevel。
sysinit、boot、bootwait等action将在系统启动时无条件运行，而忽略其中的runlevel。
其余的action（不含initdefault）都与某个runlevel相关。各个action的定义在inittab的man手册中有详细的描述。
4. process
process为具体的执行程序。程序后面可以带参数。
第三部分：系统初始化
在init的配置文件中有这么一行：
si::sysinit:/etc/rc.d/rc.sysinit
它调用执行了/etc/rc.d/rc.sysinit，而rc.sysinit是一个bash
shell的脚本，它主要是完成一些系统初始化的工作，rc.sysinit是每一个运行级别都要首先运行的重要脚本。它主要完成的工作有：激活交换分
区，检查磁盘，加载硬件模块以及其它一些需要优先执行任务。
rc.sysinit约有850多行，但是每个单一的功能还是比较简单，而且带有注释，建议有兴趣的用户可以自行阅读自己机器上的该文件，以了解系统初始化所详细情况。由于此文件较长，所以不在本文中列出来，也不做具体的介绍。
当rc.sysinit程序执行完毕后，将返回init继续下一步。
第四部分：启动对应运行级别的守护进程
在rc.sysinit执行后，将返回init继续其它的动作，通常接下来会执行到/etc/rc.d/rc程序。以运行级别3为例，init将执行配置文件inittab中的以下这行：
l5:5:wait:/etc/rc.d/rc 5
这一行表示以5为参数运行/etc/rc.d/rc，/etc/rc.d/rc是一个Shell脚本，它接受5作为参数，去执行/etc/rc.d
/rc5.d/目录下的所有的rc启动脚本，/etc/rc.d/rc5.d/目录中的这些启动脚本实际上都是一些链接文件，而不是真正的rc启动脚本，
真正的rc启动脚本实际上都是放在/etc/rc.d/init.d/目录下。而这些rc启动脚本有着类似的用法，它们一般能接受start、stop、
restart、status等参数。
/etc/rc.d/rc5.d/中的rc启动脚本通常是K或S开头的链接文件，对于以以S开头
的启动脚本，将以start参数来运行。而如果发现存在相应的脚本也存在K打头的链接，而且已经处于运行态了(以/var/lock/subsys/下的
文件作为标志)，则将首先以stop为参数停止这些已经启动了的守护进程，然后再重新运行。这样做是为了保证是当init改变运行级别时，所有相关的守护
进程都将重启。
至于在每个运行级中将运行哪些守护进程，用户可以通过chkconfig或setup中的"System Services"来自行设定。常见的守护进程有：
amd：自动安装NFS守护进程
apmd:高级电源管理守护进程
arpwatch：记录日志并构建一个在LAN接口上看到的以太网地址和IP地址对数据库
autofs：自动安装管理进程automount，与NFS相关，依赖于NIS
crond：Linux下的计划任务的守护进程
named：DNS服务器
netfs：安装NFS、Samba和NetWare网络文件系统
network：激活已配置网络接口的脚本程序
nfs：打开NFS服务
portmap：RPC portmap管理器，它管理基于RPC服务的连接
sendmail：邮件服务器sendmail
smb：Samba文件共享/打印服务
syslog：一个让系统引导时起动syslog和klogd系统日志守候进程的脚本
xfs：X Window字型服务器，为本地和远程X服务器提供字型集
Xinetd：支持多种网络服务的核心守护进程，可以管理wuftp、sshd、telnet等服务
这些守护进程也启动完成了，rc程序也就执行完了，然后又将返回init继续下一步。
第五部分：建立终端
rc执行完毕后，返回init。这时基本系统环境已经设置好了，各种守护进程也已经启动了。init接下来会打开6个终端，以便用户登录系统。通过按Alt+Fn(n对应1-6)可以在这6个终端中切换。在inittab中的以下6行就是定义了6个终端：
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
从上面可以看出在2、3、4、5的运行级别中都将以respawn方式运行mingetty程序，mingetty程序能打开终端、设置模式。同时它会
显示一个文本登录界面，这个界面就是我们经常看到的登录界面，在这个登录界面中会提示用户输入用户名，而用户输入的用户将作为参数传给login程序来验
证用户的身份。
第六部分：登录系统，启动完成
对于运行级别为5的图形方式用户来说，他们的登录是通过一个图形化的登录界面。登录成功后可以直接进入KDE、Gnome等窗口管理器。而本文主要讲的还是文本方式登录的情况：
当我们看到mingetty的登录界面时，我们就可以输入用户名和密码来登录系统了。
Linux的账号验证程序是login，login会接收mingetty传来的用户名作为用户名参数。然后login会对用户名进行分析：如果用户名
不是root，且存在/etc/nologin文件，login将输出nologin文件的内容，然后退出。这通常用来系统维护时防止非root用户登
录。只有/etc/securetty中登记了的终端才允许root用户登录，如果不存在这个文件，则root可以在任何终端上登录。/etc
/usertty文件用于对用户作出附加访问限制，如果不存在这个文件，则没有其他限制。
在分析完用户名后，login将搜索/etc/passwd以及/etc/shadow来验证密码以及设置账户的其它信息，比如：主目录是什么、使用何种shell。如果没有指定主目录，将默认为根目录；如果没有指定shell，将默认为/bin/bash。
login程序成功后，会向对应的终端在输出最近一次登录的信息(在/var/log/lastlog中有记录)，并检查用户是否有新邮件(在/usr
/spool/mail/的对应用户名目录下)。然后开始设置各种环境变量：对于bash来说，系统首先寻找/etc/profile脚本文件，并执行
它；然后如果用户的主目录中存在.bash_profile文件，就执行它，在这些文件中又可能调用了其它配置文件，所有的配置文件执行后后，各种环境变
量也设好了，这时会出现大家熟悉的命令行提示符，到此整个启动过程就结束了。
希望通过上面对Linux启动过程的剖析能帮助那些想深入学习Linux用户建立一个相关Linux启动过程的清晰概念，进而可以进一步研究Linux接下来是如何工作的。
