写在开篇
血案：本地开发机是CentOS 7，本想删除在/usr/lib/下的一个软链，如：/usr/lib/xxx。当正想删除时，突然被别的事情打扰了一下，回过神之后莫名奇妙的执行了命令：“rm -rf /usr/lib/”，忘记指定文件名了，你说尴尬不尴尬？就在千钧一发之际，马上进行了ctrl+c终止了。但，血案还是发生了，现象就是重启后无法正常进入操作系统了。因日常使用的开发机各种环境都已经搭建好，就不想折腾了。虽然它是虚拟机，但我没有每时每刻对它做快照，就算恢复以前做过的快照，那也不是我想要的样子了。所以，决定对它进行抢救。抢救过程
- 找一台同一个ISO安装的、且正常运行的系统进行对比/usr/lib/路径下的文件数量
文章图片
上面的截图中，就是正常运行的OS，/usr/lib下的文件数量是49个。
- 已经损坏的操作系统，在救援模式查看/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/下，且是覆盖其所有。然后关机，并将其的启动顺序设置为从硬盘启动，然后开机
文章图片
文章图片
- 开机后，发现已经正常进入操作系统，完美！成功从棺材边抢救回来了。
文章图片
写在最后
从这种小事就可以说明，我是一个大头虾！如果是线上的生产环境这么个搞法，估计要进监狱了。虽然这次的血案是发生在自己本地的开发机中，同时也给我敲响了一个警钟：敬畏生产环境！【翻车！误删/usr/lib/引发的血案，从棺材边成功抢救的过程分享。】本文转载于（喜欢的盆友关注我们）：https://mp.weixin.qq.com/s/TF...
推荐阅读
- 容器技术（docker|容器 & k8s——Kubernetes详解 & 集群部署 & Metrics-Server）
- Linux|容器 & k8s——kubernetes kubectl工具使用
- Linux|Linux tcp客户端断开重连,【干货】TCP连接的状态详解以及故障排查
- linux|linux tcp自动重连,TCP连接的状态详解以及故障排查
- Linux|TCP可靠传输-拥塞控制
- Python闲谈|python 玩玩乐 - moviepy 剪辑视频变成 gif 图
- linux|wsl如何修改默认分配内存（）
- linux|Vim中如何全选并复制（）
- vim|vim如何删除全文