CentOS 6下 boot分区和fstab文件丢失修复方案

某些场景下,可能会出现/boot分区损坏或分区挂载文件丢失或者误删而无法取消删除的情况(至少生产环境是这样的 毕竟没有多少人会在服务器上安图形界面),这就需要我们能够手动恢复这些文件

接下来,笔者模拟一个丢失了/boot分区 同时/etc/fstab文件丢失的情况 这里特别说明的是 该修复流程是在CentOS 6上测试通过,7+亦可参考,如是其他例如debian系列的 具体详情请参考项目官网

1. 首先,我们通过手动删除/boot分区和/etc/fstab来构造一个模拟的修复场景,请注意,不要在任何生产环境中执行此操作,否则就只能后果自负了。 执行指令如下:

[root@Centos6 ~]# rm -rf /boot/
rm: cannot remove `/boot': Device or resource busy
[root@Centos6 ~]# rm -rf /etc/fstab
[root@Centos6 ~]# ls /etc/fstab
ls: cannot access /etc/fstab: No such file or directory
[root@Centos6 ~]# ls -al /boot
total 6
dr-xr-xr-x.  2 root root 1024 Sep  2 21:25 .
dr-xr-xr-x. 22 root root 4096 Sep  2 21:14 ..

然后,我们执行重启操作:

[root@Centos6 ~]# reboot

2. 此时,我们看到,系统启动到grub后卡住了,这是因为grub文件被我们删除了,而无法加载1.5阶段了。因此,这时就必须要通过挂载光盘来解决了。

3. 如图,进入计算机的BIOS设置中,切换为CD-ROM引导。然后挂载光盘并进入rescure mode(救援模式);然后一路选择下一步即可(网络配置可根据自身需求配置)

4. 如果前面操作正确的话,应该能看见和笔者一样的界面

5. 我们先用fdisk -l和blkid查看一下当前环境下的分区信息

通过命令回显,我们可以很容易的判定/dev/sda2为swap分区,而对于boot和root分区则无法100%确定,因此还需进一步确认,即通过临时挂载/dev/sda1和/dev/sda3来确定boot分区和root

6. 创建用于临时挂载的目录,并依次挂载/dev/sda1和/dev/sda3到挂载目录

7. 现在我们可以通过ls命令查看下两个目录的内容。

从命令执行结果,我们可以很容易的确定/dev/sda1为boot分区,/dev/sda3为root根分区

8. 手动编写系统分区挂载文件etc/fstab

9. 为了保障修改写入硬盘,我们手动同步;然后执行exit退出,并重启系统。

bash-4.1# sync
bash-4.1# exit

10. 重启系统后,依旧是进不了系统的,因为还没有修复完成。这里请参照第③步和第④步,进入救援模式。如果没有操作失误,你应该能够看到如下图所示的交换式界面。请注意,这和我们第1次进入救援模式有一个明显的区别是救援系统为我们找到了根分区/mnt/sysimage。还记得我们前面手动写入的etc/fstab吗?对,就是它。

11. 如图所示,我们重启后,救援系统为我们找到了根分区。但是这里需要注意的是,当前分区并非真正的分区,我们还需要手动切根。

bash-4.1# chroot /mnt/sysimage/

chroot后,你应该已经发现了,bash提示符发生了一些变化,变成了sh-4.1#

虽然系统根分区和boot分区我们已经成功挂载回去了,但是没有内核文件和grub我们依旧无法启动。我们需要挂载光盘来获得相应文件,然后RPM安装Kernel

sh-4.1# mount /dev/sr0 /mnt/
sh-4.1# rpm -ivh /mnt/Package/kernel-2.6.32-696.e16.x86_64.rpm --force

12. OK,通过上一步我们已经(重新强制)安装好了内核。现在我们来修复(重新安装)grub启动引导器。

sh-4.1# grub-install /dev/sda    #后面的参数为磁盘名

如果你运行的结果如上图所示,那么恭喜你,grub修复成功了!如果不是,不要急,重新运行一遍grub-install /dev/sda 即可。

13. 现在,我们通过ls命令查看系统中内核和启动引导组件的状态。

如图所示,boot分区下我们看到了内核文件和initramfs文件以及包括grub在内的其他系统组件。但是,似乎还没有grub.conf文件,也就是系统启动时候的那个菜单配置文件。 嗯!我们再手写一个。

sh-4.1# vi /boot/grub/grub.conf

详细代码如下:

14. 至此,我们完成了所有的修复步骤。同第⑨步出于保障数据写入的原因,我们依旧执行如下指令,然后重启系统。

sh-4.1# sync
sh-4.1# exit
bash-4.1# exit

15. 系统重新启动后,如希望的那样,看见了之前笔者手动写入的grub菜单;然后系统继续启动,进入正常的启动流程。是不是有点小激动?

16. 嗯!当你到达如笔者这样的界面,就说明成功了。

17. 感谢阅读。( ̄▽ ̄)/


本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券