CentOS 6开机启动流程实验篇

Posted 2020-08-09

CentOS 6开机启动流程实验篇

---

• centos 系统的启动流程

• grub

• 破坏Linux的核心文件再修复体验系统启动流程

---

CentOS 6开机启动的具体详情请参见理论篇！

了解了系统启动的基本流程，以下我们通过“破坏式实验”，即破坏系统启动过程中的一些关键环节，使系统无法启动，然后我们再通过修复这些文件使得系统正常重启，进而体验Linux系统的启动流程，这些关键环节包括破坏grub三个stage(stage1、stage1-5、stage2) 中的任何一个阶段，甚至是整个grub; 还有挂载文件/etc/fstab，内核文件vmlinuz, 系统引导时需要加载的驱动程序文件initramfs以及MBR中的相关信息等。

接下来开始实验，建议提前备份相关文件或给系统先做快照！

1. 破坏MBR中的前446bytes，即stage1

2. 破坏MBR之后的扇区，即stage1-5

3. 删除整个grub文件(stage2随即也被删除)

4. 删除用户空间的第一个进程: /sbin/init

5. 删除/boot目录

6. 删除initramfs文件

7. 删除/boot及/etc/fstab

8. 在逻辑卷的系统上删除/boot及/etc/fstab

见CentOS 6开机启动流程实验篇

1.破坏MBR中的前446bytes，即stage1

[[email protected] ~]#dd if=/dev/zero of=/dev/sda bs=446 count=1   #破坏MBR中的bootloader,即stage1
1+0 records in
1+0 records out
446 bytes (446 B) copied, 0.00123036 s, 362 kB/s
[[email protected] ~]#

此时重启系统，发现系统直接进入了光盘引导模式

分析：开机直接进入了光盘引导模式，说明系统的开机时经过了POST-->Bios, 却在系统引导时出现的问题，这属于grub的事，我们只需重新安装grub即可。

进入救援模式，重新安装grub:

可在上面那个界面直接选择Rescue救援模式，也可重装启动系统，按ESC键，选择CD-ROM再进入。

查看下磁盘的挂载与分区是否正常，如果正常则直接重装grub,注意重装grub解决不了分区表被破坏的情况，这是两码事，所以给系统提前备份分区表很重要！

修复：重建grub

重启：

正常的开机启动画面，而不是直接进入了光盘引导界面！

小结：如果stage1被破坏，系统认为硬盘无法启动，故而系统会直接进入光盘引导模式，也不会进入grub错误的界面，因此此时系统根本就无法启动，只能进入救援模式！进入之前如果提示chroot /mnt/sysimage,则表示/etc/fstab文件是正常的.

2.破坏MBR之后的扇区，即stage1-5

[[email protected] ~]#dd if=/dev/zero of=/dev/sda bs=512 count=2 seek=1
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 0.00508186 s, 202 kB/s
[[email protected] ~]#

重启：发现屏幕一直卡在了黑色界面

好吧，手动进入救援模式然后重建grub!

重建grub后可查看/dev/sda上的前1024字节

此时重启系统就正常启动了！

小结：如果stage1.5被破坏，则系统启动过程中会黑屏，一直卡着，也不会进入光盘引导模式，因为stage1未被破坏，则系统认为可以从硬盘启动，成功地进行了stage1,当进行stage1.5时发现stage1.5被破坏，系统就无法正常启动下去，无法找到相应的驱动，就一直黑屏卡着不去。此时若想恢复系统，就手动进入救援模式，然后重建grub.

其实，安装grub有两种方法，此处选择是的简单高效的一种：

安装grub：
(1) grub-install安装grub stage1和stage1_5到/dev/DISK磁盘上，并复制GRUB相关文件到DIR/boot目录下
grub-install --root-directory=DIR /dev/DISK
(2) grub
grub> root (hd#,#)grub> setup (hd#)

其中，grub-install 命令的选项--root-directory是指要安装到哪个目录下，/dev/DISK就是指要安装在哪个设备上，如：

grub-install --root-directory=/mnt/boot /dev/sda

在上面的两个例子中，我们省略了--root-direcoty=,因为我们上在本机上重装grub，当可省略，这里注意，最后挂载点的目录名称，一定是boot, 因为grub在安装的时候，它会去找boot目录，如果找不到则报错，当我们把盘挂载到boot之后，可以认为，该盘的名字就叫boot，所以，它会在该盘内写入bootloader,以引导系统。

而用grub命令安装grub时，root (hd#,#) 表示第#-1个设备的第#-1个分区，因为磁盘分区的编号是从0开始的。

root (hd0,0) 表示第一个磁盘的第一个分区

且grub命令的重装grub时，会依赖/boog/grub目录下的相关文件，而grub-install命令不会依赖，故而建议用grub-install的方式重装grub。

3.删除整个grub文件(stage2随即也被删除)

删除整个grub文件时，建议先备份一下再删除！

[[email protected] ~]#cp -r /boot/grub .
[[email protected] ~]#rm -rf /boot/grub
[[email protected] ~]#

/boot/grub目录里面都有哪些文件，以及grub.conf里面的内容解释请看上文的关键词解释部分，此处不再赘述。

重启时我们发现 Error 15 字样

照样手动进入救援模式先重装grub，因为删除了grub文件，grub肯定是被破坏了！

此时我们在重装grub时发现“分区表签名”的问题，可忽略！

我们进入grub目录可查看grub下的文件是否全部恢复：

发现少了grub.conf文件，没有grub.conf文件，系统在启动时也就无法加载内核，当然启动不成功，故而我们此时可以选择手写一份grub.conf文件，永久有效，也可选择重启，此时系统会进入grub> 模式，在grub> 模式里面我们也可以以命令的形式给出系统内核文件存放的位置、内核的名称及核心参数，以及虚拟文件系统initrd, 但仅对本次启动有效，下次启动时还得书写一次！

此时我们选择直接在grub目录里面书写：

如果是在grub> 模式，可以这么写：

小结：grub-install只能重装grub的stage1与stage1-5,无法恢复grub.conf文件，即无法完全重装stage2,故需要我们牢记grub.conf文件的六项基本条例，以便正常恢复系统，当然备份最好。

4.删除用户空间的第一个进程: /sbin/init

/sbin/init是用户空间的第一个进程，是一个二进制文件，我们无法书写，删除之前备份,恢复思路是将备份init恢复到/sin目录下。

[[email protected] ~]#cp /sbin/init .
[[email protected] ~]#rm -f /sbin/init
[[email protected] ~]#

重启：

重启后我们直接进入了switching root模式，发现命令都无法执行，其实很容易理解，/sbin/init都被删除了还怎么执行命令！

此时的系统其实已经经历了POST-->BIOS-->MBR-->GRUB--加载内核阶段，但当启动init进程时却无法启动了，系统进入了switching root模式，却什么也干不了！那么我们的思路可以这么来：既然init启动不了，我们就想办法让其启动，一般地，init 默认执行的是/sbin/init,既然/sbin/init被删除了，那么我们就把/sbin/init替换为/bin/bash,也就是说，将用户空间第一个进程init使其启动为/bin/bash,然后利用bash命令将备份的init文件恢复到/sbin目录下即可。

启动过程中修改内核参数可以进入grub修改，也可以在启动菜单的选项下修改(进入单用户模式或直接按a键修改内核参数), 我们选择直接在启动菜单下按a键添加内核参数:init=/bin/bash

在进入bash模式时，需要重新以读写方式挂载根/.

而且这一过程也用不着进入救援模式，但是这一方法有时在添加完内核参数并重启时系统卡在某个地方，往往是由于某个服务起不来而导致的，此时只需进入单用户模式将上此服务用chkconfig命令off掉即可。因为单用户模式并不依赖很多服务就可进入！

[[email protected] ~]#cp /sbin/init .
[[email protected] ~]#rm -f /sbin/init
[[email protected] ~]#

然后我们重启就可以了！

别外，进入救援模式自然屡试不爽，直接将备份的init文件恢复到/sbin目录下就完事，且不用担心由于某服务没起来而卡住的现象！

自然，如果系统初始化脚本/etc/rc.d/rc.sysinit被删除了，亦可通过同样的方法找回，有人说没备份咋办，呵呵，那就找相同配置的另一机器吧！

删除系统初始化脚本:/etc/rc.d/sysinit

删除之前要备份！

重启：

尝试进单用户模式修复：

5.删除/boot目录

/boot目录里面的文件最重要的文件有两个：vmlinuz,grub

[[email protected] ~]#umount /boot
[[email protected] ~]#rm -rf /boot
[[email protected] ~]#

重启：这个错误类型是不是有点熟悉的味道。。。跟破坏了stage2的错误一样！

分析：既然整个/boot目录都被删除了，而/boot目录下最重要的文件是vmlinuz与grub，于是我们先恢复这两个文件看看。/boot下的其它文件在安装kernel时会自动生成！

另外，既然这个错误跟stage2一样，那么说明即便删除整个/boot目录，也能成功地进行stage1与stage1-5,这是因为stage1在MBR中，而stare1-5在MBR后面的扇区上，stage2是在磁盘上！

第一：先恢复vmlinuz，rpm安装kernel包

第二： 恢复grub, 直接grub-install /dev/sda,然后再书写grub.conf文件即可

6.删除initramfs文件

删除了initramfs文件，这个文件是在加载内核的时候要用到的，而且上一个实验也证明了在安装kernel时此文件会自动生成，要想恢复此文件则重新安装kernel即可，反正也不费事；当然，initramfs这种重要的文件还有有命令可以生成的！

mkinitrd /boot/initramfs-`uname -r`.img   `uname -r`

[[email protected] ~]#rm -f /boot/initramfs-2.6.32-642.el6.x86_64.img 
[[email protected] ~]#

重启：又是熟悉的味道。。。跟破坏了stage1-5的错误一样

由启动错误可知，initramfs是与stage1-5相关的！

如此，系统也可正常启动！

7.删除/boot及/etc/fstab

[[email protected] ~]#umount /boot
[[email protected] ~]#rm -rf /boot
[[email protected] ~]#rm -f /etc/fstab
[[email protected] ~]#

相信有了以上实验，这个已经没多大难度了，恢复/boot就是恢复vmlinuz与grub,然后再书写一个挂载文件即可/etc/fstab即可。

重启：

这个错误太熟悉不过了吧，stage2被破坏了，stage1在MBR中，stage1-5在MBR后面的扇区中，跟删除/boot目录没关系。

进入救援模式：

由此可见，系统的挂载关系已经被破坏，我们根据上面的提示，写好挂载配置文件/etc/fstab后重启系统，让系统自动挂载，然后再重新进入救援模式，恢复/boot目录！

在写挂载配置文件之前，我们必须要知道/boot在哪个位置上，此时df命令已经不行了，此时我们可用fdisk -l来查看, 而根在哪个分区上，fdisk -l 命令是不容易看出来的，我们只能通过“试”的方法：多创建个几个目录，如/mnt/sda#,然后分别挂载除/boot即引导分区以外的其它几个分区！直至找到为止；另外，我们还得知道文件系统类型，我们可用bldid命令来获取!

此时，我们已经知道根在/dev/sda2上，而/boot在/dev/sda1上，且文件系统类型为ext4,OK，我们来书写/etc/fstab吧，然后重启让系统自动挂载之！

注意：此时的/etc/fstab在/mnt/sda2上，即路径为：/mnt/sda2/etc/fstab

但当我们书写系统挂载配置文件时发现：

错误很明显，路径错了！注意设备的挂载。

挂载关系好了之后再重启系统让其自动挂载：

挂载关系无误后就可以安装kernel并重装grub了：

8.在逻辑卷的系统上删除/boot及/etc/fstab

两样地，如何系统是逻辑卷分区的，当删除/etc/fstab后在救援模式下也是无法查看具体的分区情况的，在做实验之前，我们先对该系统的逻辑卷情况做一大致了解：

OK,我们来删除/boot及/etc/fstab:

[[email protected] ~]# cd /boot
[[email protected] boot]# rm -rf *
[[email protected] boot]# cd
[[email protected] ~]# umount /boot
[[email protected] ~]# rm -rf /boot
[[email protected] ~]# rm -f /etc/fstab
[[email protected] ~]#

重启：系统进入了grub

因为此时vmlinuz也被删除了，故grub也无能为力，我们进入救援模式：

查看分区情况：我们能了解到/boot分区在/dev/sda1上，另外，只能了解到/dev/sda2为逻辑卷，但具体如何分的还不得知

此时我们用lvscan命令来扫描一下逻辑卷：此时即可发现逻辑卷的具体分区情况以及状态。

再将inactive的逻辑卷激活：vgchage -ay

此时，根据上一个的经验，我们应该先写好系统挂载的配置文件，然后重启系统让其自动挂载，再rpm安装kernel，重装grub,即可大功告成！与上个实验唯一不同的是，这个逻辑卷实验我们用lvscan时就能够知道根/ 分区在哪(本实验在vg0上，而vg0在/dev/sda2上)，于是，我们即可把根先挂载上，然后切根，再书写/etc/fstab文件。

重启系统使其自动挂载：

看到挂载关系已经正常，此刻我们就可以rpm安装kernel，然后重装grub了。

安装kernel:

重装grub:

grub.conf

至此，就可以重启系统了！

最后，我们做一个grub的自我保护机制小实验：

GRUB的界面也支持命令行接口，在GRUB界面可以按照提示输入e、b、c等命令进行相应的编辑，在对应的title中输入c可以进入命令行模式，在命令行中可以输入一个信息如：

help: 获取帮助find: 文件查找，通常用于定位文件，方法find（hd#,#)/root
kernel
initrd
boot

GRUB也有自己的保护机制，只有通过论证才能修改grub.conf信息。可以通过以下方式来对grub.conf进行保护：

1、在第一个title之上添加password --md5 PASSWORD :主要用于保护编辑功能
2、在某个title内添加password --mdt PASSWORD : 主要用于保护内核

生成密码的命令：grub-md5-crypt; openssl passwd -1

如：

[[email protected] ~]#openssl passwd -1Password: 
Verifying - Password: 
$1$AawgjWjr$eEQJyxtCwJOk54Gnq2zK/.
[[email protected] ~]#

提示按"p" 键输入密码：用于保护grub.conf的编辑功能

正常的grub界面：

选中相应的菜单直接回车试图启动系统时，提示输入密码：

然后系统就可以启动了！

如果是grub出现了问题导致系统无法启动，上面已经有大量的实验了，通过救援模式进行修复，主要步骤如下：

chroot /mnt/sysimage: 改变到磁盘根目录 
fdisk -l /dev/sda: 使用fdisk 检查磁盘分区
grub-install /dev/sda: 安装grub引导程序到磁盘/dev/sda的MBR扇区
exit

当然，grub-install命令也可用grub代替：#grubgrub>root (hd0,0)
grub>setup (hd0)
grub>quit 

但时，grub命令在修复grub的会依赖到/boot/grub/目录下的一些文件，
而grub-install命令是不依赖的！

至此本文就结束了，前半部分(理论篇)我们主要讲述了centos 6的启动流程，解析了相关的关键词，后半 部分(实验篇)将通过大量破坏式实验体验了相关的关键文件在Linux系统中起的作用。

本文出自 “止战-连Sir” 博客，请务必保留此出处http://liansir.blog.51cto.com/9372908/1854077