rhel系统启动过程_linux系统启动流程及常见问题解决

运行环境：centos6 Vmware

一、系统启动流程介绍

linux系统启动时我们可以看到很多启动信息，整体来说系统启动分为以下几个过程：加电自荐：power on system test

选择启动程序，加载MBR

加载系统内核Kernel，执行系统初始化信息

启动用户空间第一个执行程序init

用户登陆系统

(1)加电自检

自检主要是检测一下硬件设备是否存在并能正常工作，简单来说加电过程就是给CMOS通电，然后启动其上的BIOS程序，BIOS程序会根据CMOS上面的一些配置信息去读取其他的硬件设备信息并检测是否存在并能正常运行，之后进行硬件设备的初始化。

(2)选择启动程序，加载MBR

在硬件设备初始化后，BIOS会列出一些可以启动的装置顺序，启动管理程序来处理核心文件的加载问题，启动管理程序就是Boot Loader，它是一个程序，所以也依赖于一个硬件之上，所以这个硬件就为硬盘，准确的说为第一个可以启动的硬盘的第一个扇区内，就是我们之前谈到的MBR(Master Boot Record，主引导纪录)当中。Boot Loader有两个主要功能，第一是去识别、加载操作系统的核心文件，并提交到内存中运行，进而来启动对应的操作系统，另一个主要的功能就是提供菜单信息，并将启动管理功能转交给其它的加载程序。(Windows操作系统不具备将启动管理功能转交给其他的加载程序的功能，所以要同时装linux系统和windos操作系统时一定要先装windows操作系统，最后安装Linux系统，通过Linux系统提供的Boot Loader菜单列表可以选择启动Windows操作系统的Boot Loader信息，也就是将启动管理功能的控制权转交给Windows系统分区的第一个扇区当中的Loader程序，然后完成   Windows的启动。)

(3)加载系统内核Kernel，执行系统初始化信息

在Boot Loader开始读取操作系统内核文件后，内核文件解压缩后装在到内存当中，然后根据内核提供的功能开始测试与加载各个设备，内核文件通常放在/boot目录当中，并且是一个以VMlinuz开头的文件，所以这里我们遇到了一个问题，鸡与蛋的问题(内核程序没有加载到磁盘，就没有办法读取系统上的内核文件，如果先去加载磁盘，就必须有磁盘的驱动程序)，所以为了解决这个维妮塔，我们采用一种叫做虚拟文件系统来解决这个问题，虚拟文件系统也放在/boot目录下，是一个以initrd开头的文件，这个文件可以通过Boot Loader程序将其加载到内存当中，这个文件会被解压缩并且在内存中模拟一个根文件系统，Boot Loader可以加载kernel与initrd，然后再内存中让initrd解压缩解压缩成根目录，然后内核可以再这个虚拟的根文件系统之上加载合适的驱动程序，来加载硬盘等设备，之后释放虚拟的根文件系统，并且以制度方式挂载磁盘上真实的根文件系统，之后开始正常的启动过程。

(4)启动用户空间第一个执行程序init

init的配置文件中centos6中采用Upstart的方式，其特点时守护进程间的通信依赖于D-Bus进行，在该文件中有一个非常重要的配置项目，就是默认的系统启动级别，分为以下几种：0 ：关闭所有服务：关机

1：单用户模式，sigle模式，该级别可以允许root用户直接登陆而无需认证

2：多用户模式，需要用户认证，会启动网络功能

3：完全多用户模式，文本界面

4：预留级别

5：完全多用户模式，图形界面

6：关闭所有服务，重启

通常使用较多的默认级别为3或者5，切换方式为命令init[0-6],通常可以使用命令runlevel来查看运行的级别

二、常见问题解决

(1)系统启动时默认直接进入光盘引导系统

MBR分区前446字节被破坏，也就是对应着stage1 阶段，/boot/grub目录下的一阶段文件丢失，所以导致无法引导。可通过救援模式进入光盘自带shell，通过命令chroot 切换至真根模式。通过df命令模式查看到当前真根被挂载到/mnt/sysconfig目录下，如图所示：df

chroot /mnt/sysconfig

进入救援模式后查看MBR前512字节中前446字节都为0，且/boot/grub目录下stage1阶段文件全部丢失hexdump -C -n 512 -v /dev/sda

我们可以通过命令来生成丢失的stage1阶段的文件以及向mbr添加数据grub-install /dev/sda(注意：这里要直接跟硬盘名称，不能跟分区名，如sda1,该操作是对整个硬盘)

添加完之后可以通过hexdump命令查看MBR数据，以及/boot/grub下的文件

(2)系统正常引导，但提示1.5错误

系统提示1.5错误，意味着/boot/grub目录下的1.5阶段文件丢失以及MBR从512字节之后大量字节丢失。解放方法和上文(1)相同，使用相同命令，该命令会自动补齐grub目录下除grub.conf文件的所以文件。(也可能是/boot目录下的文件全部丢失，解决方法请看实验)

grub-install /dev/sda

(3)系统登陆时停留如下图界面

系统stage2阶段文件丢失，可以进入救援模式进入真根模式编辑，该方法会在下文中演示)也可以通过输入命令暂时进入系统，进入后还需要编辑/boot/grub目录下的grub.conf文件

root (hd0，0)

找到根目录文件，需要一个一个进入测试，table键显示文件

找到后按下Enter键，输入kernel /以及Table键补齐

这样就可以正常进入系统，不过只是本次生效，如果不进入/boot/grub目录配置grub.conf文件，下次开机还需要手动配置。

(3)当遇到(2)的情况时，手动配置kernel 按Table键时什么都不显示，无法手动配置

当无法手动Table不出自己需要的信息时说明/Boot文件下的文件丢失，所以在我们需要的时候无法手动Table出文件名，所以此时只能进入救援模式，通过chroot命令进入真根模式，安装丢失文件。

进入救援模式，切换真根环境，发现/boot目录里面只有一个gurb目录，grub目录中还丢失了grub.conf文件，所以我们需要编辑grub.conf文件，以及安装/boot下的文件

mount  /dev/cdrom1 /media(因为这个系统的虚拟机有两个光盘，所以是cdrom1)

rpm -ivh /media/Packages/kernel-2.6.32-696.e16.x86_64.rpm --force(这里需要强制覆盖以下，因为内核本来就没有删除，这里只是要恢复需要的内核文件)

这里可以看到/boot目录下文件已经从新生成

进入grub目录下编辑grub.conf文件vim /boot/grub/grub.conf

三 、实验

误删除系统中的fstab文件以及/boot目录下的所有文件

1、进入救援模式

2、当我们用命令chroot进入真根环境时提示错误，因为/etc/fstab文件丢失，系统无法开机自动挂载，这里我们需要手动挂载根目录到光盘提供的目录，如图所示，这样以便我们能进入真根环境mount /dev/sda2  /mnt/sysimage

3、首先要恢复丢失的/etc/fstab文件，然后我们才能真正进入/boot目录中就行配置，从假根环境中通过blkid命令将结果输出重定向到真根环境中/etc/fstab中blkid >> /mnt/sysimage/etc/fstabchroot /mnt/sysimage/

4、编辑真根环境/etc/fstab文件vim /etc/fstab

将刚才导入的结果及进行编辑，写入正确的格式

这里建议重新启动，让系统重新自动挂载，也可以使用命令mount -a，但是会有些错误发现不了，比如该命令支持UUID等号后面有双引号，如果你的fstab文件中UUID等号后面都带了双引号，mount -a当时可以生效，但是当你再次进入救援系统时还是无法挂载，这里重启启动后就可以看到系统已经正常挂载。

5、通过df命令查看已经正常挂载，恢复/boot目录下的文件rpm -ivh /media/Packages/kernel-2.6.32-696.e16.x86_64.rpm --force(修复除/boot目录下除了grub目录的所有文件)grub-install /dev/sda(自动再/boot目录下创建grub目录，并创建除grub.conf文件外的所有文件)vim /boot/grub/grub.conf(上文中已经提到如何编辑)