在开篇写到：本地开发机是CentOS7，想删除/usr/lib/下的一个软链接，如：/usr/lib/xxx。正要删除的时候，突然被别的事情打扰了。恢复后莫名其妙的执行了命令：“rm-rf/usr/lib/”，忘记指定文件名了，是不是觉得很尴尬？就在关键时刻，ctrl+c被立马终止了。然而凶案还是发生了，现象是重启后无法正常进入操作系统。由于日常使用的开发机各种环境都已经搭好了，我也懒得理了。虽然是虚拟机，但我并不是每时每刻都给它拍快照，即使我把之前拍的快照恢复过来，也不是我想要的。于是，决定挽救它。在救援过程中，找一个安装在同一个ISO上并且运行正常的系统进行对比。/usr/lib/路径下的文件个数上面截图中，是正常运行的OS，/usr/lib/下的文件个数为49个。在损坏的操作系统中，在rescue模式下查看/usr/lib/路径下的文件数，发现只有44个文件，比正常OS少了5个。虽然ctrl+c马上终止了，手再快也无能为力，还是丢文件。关于如何进入救援模式，继续往下看。然后从普通OS进入/usr目录，直接打包相对路径下的lib目录，最后得到lib.tar.gz文件，sz到本地。通过UltraISO打开CentOS7的ISO镜像文件，在其根目录下添加lib.tar.gz文件，最后另存为一个新的ISO镜像文件。启动添加了lib.tar.gz文件的CentOS7镜像，进入救援模式。进入救援模式的整个过程如下：至此，你进入了救援模式，进入了虚拟系统的根目录。/mnt/sysimage下存放的目录使用chroot命令切换到真正的根目录chroot/mnt/sysimage/把光驱挂载到/home/isodata目录成功挂载光驱后，有没有注意到lib.tar.gz文件？？没错，之前就放在那里了。复制lib.tar.gz，解压，复制到/usr/lib/，全部覆盖。然后关机，并设置它的启动顺序为从硬盘启动，然后开机，发现已经正常进入操作系统了，完美！他被成功地从棺材旁边救了出来。写在最后，从这么点小事，就可以说明我是大头虾了！如果是线上生产环境，估计要坐牢了。虽然这血腥的事件发生在我本地的开发机上，但也给我敲响了警钟：尊重生产环境！本文转载于（喜欢就关注我们）：https://mp.weixin.qq.com/s/TF...
