翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

写在开篇

血案:本地开发机是CentOS 7,本想删除在/usr/lib/下的一个软链,如:/usr/lib/xxx。当正想删除时,突然被别的事情打扰了一下,回过神之后莫名奇妙的执行了命令:“rm -rf /usr/lib/”,忘记指定文件名了,你说尴尬不尴尬?就在千钧一发之际,马上进行了ctrl+c终止了。但,血案还是发生了,现象就是重启后无法正常进入操作系统了。因日常使用的开发机各种环境都已经搭建好,就不想折腾了。虽然它是虚拟机,但我没有每时每刻对它做快照,就算恢复以前做过的快照,那也不是我想要的样子了。所以,决定对它进行抢救。
抢救过程
  1. 找一台同一个ISO安装的、且正常运行的系统进行对比/usr/lib/路径下的文件数量
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

上面的截图中,就是正常运行的OS,/usr/lib下的文件数量是49个。
  1. 已经损坏的操作系统,在救援模式查看/usr/lib/路径下的文件数量
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

发现只有44个了,和正常的OS对比少了5个,虽然当时马上ctrl+c终止了,手速再快也无力回天了,还是丢了文件。关于如何进入救援模式,继续往下看哈。
  1. 接着,从正常的os中,进入/usr目录,直接在相对路径中打包lib目录,最终得到lib.tar.gz文件,并把它sz到本地。
  2. 通过软碟通(UltraISO)打开CentOS7的ISO镜像文件,并添加文件lib.tar.gz文件到其根目录下,最后另存为一个新的ISO镜像文件。
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

  1. 通过这个添加了lib.tar.gz文件的CentOS7镜像启动,并进入救援模式,进入救援模式的整个过程如下:
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

到此为止就进入到救援模式下了,且进入的是虚拟系统的根目录,真实的目录存储在/mnt/sysimage下面
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

  1. 使用chroot命令切换到真实的根目录
    chroot /mnt/sysimage/

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

  1. 挂载光驱到/home/isodata目录下
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

挂载光驱成功后,注意到了lib.tar.gz文件了吗?没错了,就是之前把它弄进去的。
  1. 将lib.tar.gz复制出来,并将其解压后,拷贝到/usr/lib/下,且是覆盖其所有。然后关机,并将其的启动顺序设置为从硬盘启动,然后开机
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

  1. 开机后,发现已经正常进入操作系统,完美!成功从棺材边抢救回来了。
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
文章图片

写在最后
从这种小事就可以说明,我是一个大头虾!如果是线上的生产环境这么个搞法,估计要进监狱了。虽然这次的血案是发生在自己本地的开发机中,同时也给我敲响了一个警钟:敬畏生产环境!
【翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。】本文转载于(喜欢的盆友关注我们):https://mp.weixin.qq.com/s/TF...

    推荐阅读