Linux系统启动流程之(3)系统故障修复之二

Linux系统启动流程之(3)系统故障修复之二

经过上一篇能够了解如何来从新安装grub从而修复grub引导，那么若是损坏的不只仅为grub引导，若是还出现了其它更为严重的问题呢。下面几个案例来讲明：

 

案例一：

一般系统服务运行以前会运行init程序来开启第一个进程，那么若是init被删除呢？

#删除或者移动init程序到别处

[root@mzf ~]# which init
/sbin/init
[root@mzf ~]# mv /sbin/init /testdir/
[root@mzf ~]# which init
/usr/bin/which: no init in (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/apache2:/root/bin)

#而后重启系统，进入grub菜单选择一个进入系统的引导项，直接按c进行交互式grub设置在kernel内核参数后面设置init=/bin/bash表示以bash进程来看成第一个进程：

 

解析：grub交互界面虽然只能修复bootloader及第一阶段，可是里面却提供了不少命令来帮助修复，好比使用find能够对猜想有boot引导文件的分区进行查找，这里查找此目录下有vmlinuz虚拟根文件系统和initramfs内核加载及切换器，能够判断(hd0,0)极有可能就是须要恢复的boot分区，固然若是有多个也就逐一排查。

#进入指定的启动进程/bin/bash，而后将刚才移动到其余分区的init程序移回来

一、挂载刚才移动到init程序的目标分区

mount -n -o rw /dev/sda5 /testdir/

二、从新以指定方式挂载根

mount -o remount,rw /

三、拷贝此文件到原来的路径

cp /testdir/init /sbin/

四、查看init命令是否在/sbin/init下

which init

注意：这里是经过grub命令行模式下指定的内核参数进入到的/bin/bash，所以也只挂载了内核参数中root根分区，全部要进行从新挂载对应的其它分区，而后将文件还原就好了。

 

 

案例二：

假设/boot分区下的全部文件丢失，也就没有grub引导加载的全部阶段了。

#查看当前/boot已是否被挂载

[root@mzf ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2       10190136 2803944   6861904  30% /
tmpfs             502068       0    502068   0% /dev/shm
/dev/sda1         194241   34109    149892  19% /boot
/dev/sda5        7922096   18280   7494728   1% /testdir

#直接删除/boot里的全部文件

[root@mzf ~]# rm -rf /boot/
rm: cannot remove `/boot': Device or resource busy#由于此文件夹仍是挂载点，全部提示

#查看/boot目录下，发现已经没有任何文件了

[root@mzf ~]# ls /boot/

#卸载此目录

[root@mzf ~]# umount /boot/

#而后重启

[root@mzf ~]# reboot

 

具体修复过程：

一、使用光盘引导启动救援模式

进入救援模式提供的shell后入后先安装grub-install

 

解析：

一、df查看当前分区是否已经挂载成功

二、挂载光盘的镜像，使用其中工具

三、切换到要安装grub的分区，也就是/dev/sda所挂载的/mnt/sysp_w_picpath目录

四、直接指定磁盘使用grub-install对/dev/sda彻底安装grub

五、查看/boot/grub是否生成各个阶段文件

 

二、而后恢复vmlinuz

#输入exit退会到救援模式shell进程，而后查看刚刚挂载的光盘镜像文件目录

 

解析：这时发现，在光盘的isolinux文件中已经提供了vmlinuz和initrd.img文件，甚至还有splash.jpg就是grub菜单文件已经grub.conf模板文件等，固然只须要绿框中指定的就行。

#拷贝vmlinuz到指定的目录下，就boot分区对应的目录

 

解析：由于刚才已经挂载了光盘，全部会获得不少命令工具，所以使用findmnt查看第一个分区及boot分区所在挂载点，固然也能够经过df查看；而后将光盘里保存的vmlinuz拷贝到指定挂载点/mnt/sysp_w_picpath/boot下便可。

 

三、而后恢复initramfs.img文件

#从新切换到boot挂载点，并使用mkinitrd根据当前kernnel信息来生成对应版本号的initrd文件

 

解析：这里不去光盘里自身isolinux目录下去拷贝initrd.img。由于系统kernel里保存了内部版本信息，全部能够直接切回到boot分区挂载点来安装对应的版本，若是kernel升级过，使用此命令生成的也是对于版本的initramfs.img。

 

四、从新创建grub.conf配置文件

#虽然所选的各类文件都会恢复文件，可是grub.conf文件并未自动根据当前环境而自动生成，所以还须要根据当前环境进行手动编辑。

 

说明：由于vmlinuz从光盘镜像挂载点下的isolinux目录里命令就是vmlinuz而不带版本号，全部这里保持一致，直接路径便可。

#固然initramfs-`uname -r`.img这个文件名很长很差记忆，那么使用末行模式读入便可

 

#将指定须要的文件基名放到指定位置，并在kernel添加指定root分区的参数

 

注意：这里必需要指定root所在分区，kernel和initrd指定的参数必须和/boot目录下的文件名及路径所对应。

#下面重启系统。

reboot

#进入系统修复过程

 

而后等待系统修复完毕自动重启便可

 

 

案例三：

删除/boot下全部文件和/etc/fstab文件，并强制卸载当前kernel。而后经过救援模式来进行逐个恢复使系统正常使用。

 

逐一破坏过程：

#删除/boot下的全部文件

[root@mzf ~]# rm -rf /boot/*

#查看文件/boot下文件已经被清空

[root@mzf ~]# ls /boot/

#卸载boot分区

[root@mzf ~]# umount /boot/

#删除/etc/fstab文件

[root@mzf ~]# rm -f /etc/fstab

#忽律依赖关系直接卸载内核文件

[root@mzf ~]# rpm -e kernel --nodeps

#重启坏掉的系统

[root@mzf ~]# reboot

解析：以上的操做以及让主板没法找到boot分区，没有内核也就没法知道其内核版本，没有了/etc/fstab文件，即便是救援模式也没法检查其硬盘下挂载关系。

 

修复过程：

一、重启从光盘引导进入救援模式，修复分区表及文件系统探测

#安装以往的操做一种到救援模式自动检测分区的界面

 

解析：由于没有了/etc/fstab文件，救援模式下也没法知道对应的挂载关系。

#而后回车选择shell界面，df查看当前挂载状况

 

说明：此时已经肯定救援模式也须要靠/etc/fstab文件来操做对应的分区以及其挂载关系。固然此文件被删除。

#为了检查分区的信息，这里挂载光盘镜像，来获取更多的命令工具

mkdir /mnt/cdrom  &&  mount /dev/cdrom /mnt/cdrom

 

#使用blkid命令来查看当前磁盘的命令及对应UUID已经文件系统类型

blkid

 

解析：这里就发现了1个磁盘/dev/sda，已经4个分区，/dev/sda5能够猜想为逻辑分区，而通常系统会在主分区下，那么如今排除掉为交换分区的/dev/sda3，考虑的有/dev/sda{1,2,5}。

#下面进一步查看，使用parted工具来查看更详细的分区信息

 

解析：经过parted命令打印出/dev/sda的详细文件系统类型以及其对应的特殊标记，从上面能够看出，只有2个主分区； 再次这能够发现Number列为1，及第一个分区的大小只有210MB，而Number列为2及第二个分区大小为11G左右，由此能够猜想boot所在第一个分区，且其对应的文件系统都为ext4，而/分区为第二个分区，为了肯定，下面也可使用fsdisk命令查看详细大小。

#进一步查看分区信息来推断，使用fdisk 命令

 

解析：由于检查到了boot为一个独立的分区，全部说要要救援模式下的系统来识别当前系统下的分区及挂载关系，那么至少须要填写两个挂载关系，及boot分区和根分区。

#根据以上信息来挂载boot分区和/根分区

 

解析：只有对刚才猜想的分区提供了挂载点进行访问，那么下面才能经过查看其对应挂载点

下的文件列表来进一步推段。

#查看两个分区下的挂载点目录下文件列表

 

解析：这里root分区能够判定是/dev/sda2了，可是/mnt/boot挂载点下并无任何东西，

多是由于此分区下文件已经被清除。因而编写/etc/fstab文件。

#在编写/etc/fstab文件，提供根分区和boot分区的对应挂载关系

 

#而后再次重启

reboot

 

二、检查分区及分区系统可否被救援模式识别且自动挂载

最后再次进入救援模式，一种根据以往的设置显示出此界面

 

解析：显示出此简明表示已经检查到了有一个存放系统的根分区，并且将会被挂载到/mnt/sysp_w_picpath下面。因而肯定进入下一个界面。

 

说明：最终出现此界面说明根系统分区真的被挂载上了，因而下面回车并选择进入shell。

#在救援模式shell下面使用df查看当前文件系统对于的挂载点

 

 

三、根据上面的挂载点对应关系，下面进行具体系统恢复

(1)根据上面的挂载点对应关系，下面开始安装内核

解析：这里必须先挂载光盘，由于须要的命令工具和软件包都在其中，而后切换到此目录后，使用rpm工具进行安装，由于的当前是在救援模式下引导的系统，全部，在安装时必须使用--root=选项来指定系统根分区的路径，及在哪一个系统分区上安装此kernel包。固然，由于kernel是直接忽略依赖关系进行卸载，不免会清除一下残留记录，因此使用--replacepkgs表示直接从新安装。

 

(2)重建/boot分区所需的全部文件

#经过挂载的光盘将vmlinuz拷贝到boot分区挂载点下

 

#切换到真正的根文件系统分区

 

#从新安装initramfs.img文件

 

解析：由于已经从新安装了kernel，那么使用uname -r命令查看的也会是与其相对于的版本。

#从新彻底安装gurb

 

说明：此时boot分区里的全部grub引导所选要的阶段文件以及备份文件都已经生成完毕，可是任然缺乏最后的一个grub.conf配置文件。

#从新编写grub.conf配置文件

在编写以前，为了让其更加回到原状，这里把vmlinuz文件后面添加内核版本号

 

使用vim新建/boot/grub/grub.conf文件

 

提示：这里再次提示，必需要指定根分区所在的分区，不然grub第2阶段没法进行根切换。

 

一块儿完成后检查一下，而后exit退回到救援模式shell，而后reboot重启

等待selinux修复