CentOS 6开机启动流程实验篇

前端之家收集整理的这篇文章主要介绍了CentOS 6开机启动流程实验篇前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

[root@centos6~]#ddif=/dev/zeroof=/dev/sdabs=446count=1#破坏MBR中的bootloader,即stage1
1+0recordsin
1+0recordsout
446bytes(446B)copied,0.00123036s,362kB/s
[root@centos6~]#

wKiom1ffg5HwIsYfAACUwG-yhjc648.png

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

wKiom1ffg6vCE6kiAAVuFPagJpQ368.png

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

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

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

wKioL1ffg8SCVjvhAAANnE19Wvg511.png

wKioL1ffg_DClq0tAAAm_2dgFjA457.png

wKioL1ffhAijomdlAAAgkyfd-w8319.png

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

wKioL1ffhCGhvzhxAAAclS0M4IA707.png

wKioL1ffhFChVmHUAAA1oUZthGI263.png

修复:重建grub

wKiom1ffhGrDbS0dAAA7CBsboMc280.png

重启:

wKioL1ffhH_gYc6WAAAEtAd1N5c602.png

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

wKioL1ffhJbzxK-bAAAIKmFzvIs858.png

wKioL1ffhLaSYoJjAACL0FegsQ4070.png

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

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

@H_403_132@[root@centos6~]#ddif=/dev/zeroof=/dev/sdabs=512count=2seek=1 2+0recordsin 2+0recordsout 1024bytes(1.0kB)copied,0.00508186s,202kB/s [root@centos6~]#

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

wKiom1ffhPyjH0lVAAAGjl6_IVk350.png

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

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

wKioL1ffhRmS-LkkAABNZDQG6K0589.png

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

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

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

@H_403_132@安装grub: (1)grub-install安装grubstage1和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就是指要安装在哪个设备上,如:

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

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

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

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

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

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

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

@H_403_132@[root@centos6~]#cp-r/boot/grub. [root@centos6~]#rm-rf/boot/grub [root@centos6~]#

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

重启时我们发现Error 15字样

wKiom1ffhUKSF1scAAAEJ7PWhXI026.png

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

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

wKioL1ffhV2QPz3cAAAdNrHYmNk069.png

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

wKioL1ffhX2g30p1AAAMOsIuIWw327.png

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

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

wKioL1ffhZiQKKtMAAAWpr66_38821.png

如果是在grub> 模式,可以这么写:

wKiom1ffha7gX5RBAABhyAqweWE033.png

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

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

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

@H_403_132@[root@centos6~]#cp/sbin/init. [root@centos6~]#rm-f/sbin/init [root@centos6~]#

wKiom1ffhduRROoBAAAkZBRCeuA361.png

重启后我们直接进入了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掉即可。因为单用户模式并不依赖很多服务就可进入!

wKiom1ffhibjQ8qhAAAX4rUMmFQ142.png

然后我们重启就可以了!

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

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

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

删除之前要备份!

wKiom1ffhj_Bh9qpAAGOhpgfx2o513.png

尝试进单用户模式修复:

wKioL1ffhlainN0rAACt1Y95uEE842.png

5.删除/boot目录

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

wKioL1ffhmzAaYczAABHDbky2sA237.png

@H_403_132@[root@centos6~]#umount/boot [root@centos6~]#rm-rf/boot [root@centos6~]#

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

wKioL1ffhreBiNNWAAADl53tx6k294.png

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

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

第一:先恢复vmlinuz,rpm安装kernel包

wKiom1ffhtTCLVP8AAAdkqg-jn0647.png

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

6.删除initramfs文件

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

@H_403_132@mkinitrd/boot/initramfs-`uname-r`.img`uname-r` @H_403_132@[root@centos6~]#rm-f/boot/initramfs-2.6.32-642.el6.x86_64.img [root@centos6~]#

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

wKioL1ffhvqSbiWuAAADokU5weI555.png

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

wKiom1ffhxHwnR48AAAgSgU63uc427.png

如此,系统也可正常启动!

7.删除/boot及/etc/fstab

@H_403_132@[root@centos6~]#umount/boot [root@centos6~]#rm-rf/boot [root@centos6~]#rm-f/etc/fstab [root@centos6~]#

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

wKioL1ffhzHTbmTeAAADHkahq_I331.png

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

进入救援模式:

wKioL1ffh1zxrWyBAABWIIpcZxk490.png

wKiom1ffh43AOqRTAAANJQGhqi0979.png

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

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

wKioL1ffh6WQ-tN9AAAUncWqUzA363.png

wKiom1ffh7jDMJNNAAA2M3mzgeU136.png

wKiom1ffh8uTCv2aAAAxpIqub4s537.png

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

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

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

wKioL1ffh96yvAD8AAAECp5qK-8015.png

wKioL1ffh_PAJNCHAAADlkx7oiA883.png

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

wKiom1ffiAajS6CmAAAHAb-uBUE169.png

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

wKioL1ffiBihCFkSAAAkeVg9aD4925.png

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

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

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

wKiom1ffiDPDwDJQAACIbjRXwBk884.png

wKioL1ffiEnBeoPjAACEyj7leIo084.png

wKiom1ffiFqSilQFAABn7KsvGF8032.png

wKiom1ffiGywYtKRAACC9_XEOKg525.png

wKioL1ffiH3QqNKbAADCcQNLHxA242.png

wKiom1ffiJKTT4noAADb28XJXig757.png

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

@H_403_132@[root@localhost~]#cd/boot [root@localhostboot]#rm-rf* [root@localhostboot]#cd [root@localhost~]#umount/boot [root@localhost~]#rm-rf/boot [root@localhost~]#rm-f/etc/fstab [root@localhost~]#

重启:系统进入了grub

wKiom1ffiT_gl4peAAAQbksGmTA857.png

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

wKioL1ffiVXisTXiAAAM0LFYmck342.png

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

wKiom1ffiWmhSjQCAAA6EBCqcuY404.png

wKioL1ffiXvyRy3dAAARdtyek4E413.png

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

wKioL1ffiYyBwjn-AAAPxs0Q4SY385.png

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

wKiom1ffiaTSMI0LAAATzObZjIw424.png

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

wKioL1ffibewaz8WAAAiJ9rv7YM932.png

wKioL1ffic2gju2wAAAgAUI0b6Q045.png

重启系统使其自动挂载:

wKiom1ffieLQl2ZJAAAUPcakyXM011.png

wKiom1ffifjh0uOGAAAhifWlVQo989.png

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

安装kernel:

wKioL1ffig2yLs0kAAAj0SeQBZQ737.png

重装grub:

wKiom1ffiibwcODAAAAVmloXN8k946.png

grub.conf

wKiom1ffij6jEafPAAAMvjCGAjk040.png

至此,就可以重启系统了!

wKioL1ffjrDyP56qAAAeZkNWElA648.png

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

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

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

wKioL1ffjsLyo9lTAACrMMO0lkE506.png

wKiom1ffjtXAHv-5AAArqE8UQ5M516.png

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

@H_403_132@1、在第一个title之上添加password--md5PASSWORD:主要用于保护编辑功能 2、在某个title内添加password--mdtPASSWORD:主要用于保护内核 生成密码的命令:grub-md5-crypt;opensslpasswd-1

如:

@H_403_132@[root@centos6~]#opensslpasswd-1Password: Verifying-Password: $1$AawgjWjr$eEQJyxtCwJOk54Gnq2zK/. [root@centos6~]#

wKiom1ffju2Rdx_jAADht9awLtc396.png

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

wKiom1ffjv-jTDb0AAAUOWcEDzc164.png

wKioL1ffjw_zpwKiAAAVSRQ-3tU061.png

正常的grub界面:

wKioL1ffjyGToK-bAAAWODcwoio859.png

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

wKioL1ffjzHSptIiAAADNpiLrV4375.png

然后系统就可以启动了!

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

@H_403_132@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系统中起的作用。

原文链接:https://www.f2er.com/centos/380676.html

猜你在找的CentOS相关文章