GLIBC 升级失败导致系统崩溃解决方法

在较为老旧版本的 Centos 中搭建 TensorFlow 深度学习开发环境时（例如：Centos6.9），由于 GNU GLIBC 库（内核运行库）版本比较低，我们需要对其进行更新以满足 TensorFlow 的安装需求。

更新时，执行误操作只要不断开远程连接还有挽回的余地，但远程异常断开连接之后很多人就没有辙了，准备抢救数据&文件，重装系统。事实上，我们先不要急着重装系统，来试一试是否可以 Rescue ！

场景

GNU GLIBC 库（内核运行库）升级失败导致系统崩溃，导致终端下使用命令会显示错误信息。

主要是因为当前系统中使用到 Glibc 库的应用程序是用旧版 Glibc 编译的，而在安装新版 Glibc 库时却在安装时出了错（或者库是安装成功了，但不兼容），导致安装没成功，却把旧版的库给替换了（也可能是没有替换只是链接给覆盖掉了），这就进入了死循环了，导致系统所有命令几乎都执行不了。

👇👇👇核心解决办法：👇👇👇

只能是进入到不依赖于当前系统中 Glibc 库的终端中去把 Glibc 库的链接（或文件）还原成原来的备份版，这只能使用光盘镜像的方式实现了。

如果当前没有光盘，可以尝试在开机时直接切换到恢复模式进入 Shell（关于如何进入到恢复模式下的 Shell 可见后文），看下面的关键命令是否可用，如果可用就直接解决了：

$ rm -rf /lib64/libc.so.6
$ LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6

---

如果不行的话，只能用光盘镜像进行恢复了。下面我们来看如何基于光盘镜像进行 rescue：

Rescue

具体步骤如下：

[1] >>>> Rescue installed system

首先准备好系统安装盘，进入 BIOS，使用系统镜像安装盘进行启动，选择 Rescue installed system。如下：

注意，选择恢复模式之后，可能还需要选择 语言和键盘。保持默认的就好。

[2] >>>> Setup Networking

上述操作完成后会询问 是否设置网络，一般来说网络没问题就不用设置了，这里我们选择 No。如下：

[3] >>>> Rescue

设置网络后，我们需要设置 Rescue 选项。界面如下所示：

↓↓↓↓↓↓ 选项参数说明 ↓↓↓↓↓↓

• Continue 选项：此选项下，救援模式程序会自动查找系统中已有的文件系统，并把他们挂载到 /mnt/sysimage 目录下；
• Read-Only 选项：此选项下，表示以只读的方式挂载已有的文件系统；
• Skip 选项：表示想要手动挂载 ；
• Advanced 选项：高级选项就不作说明了。

这里，我们选择 Continue 选项。

[4] >>>> Root for rescue

我们知道，原系统会被挂载到 /mnt/sysimage 路径下。

设置好 Rescue 选项之后，会提醒我们如果想获得原系统的 root 环境，通过执行 chroot /mnt/sysimage 即可。如下：

[5] >>>> Start shell

这里，可以执行 fakd 诊断。当然我们选择直接进入恢复模式下的 shell：

[6] >>>> Solution

由于 /usr/lib64/libc-2.12.so & libc.so.6 -> libc-2.12.so 的问题，我们发现执行 chroot /mnt/sysimage 会产生报错：

Starting shell...
bash-4.1# chroot /mnt/sysimage
/bin/sh: error while loading shared libraries: libc.so.6 cannot open ... file: no such file or directory

此时不要害怕，执行：

$ cp /lib64/libc-2.12.so /mnt/sysimage/lib64/libc-2.12.so
$ cp /lib64/libc.so.6 /mnt/sysimage/lib64/libc.so.6

这是因为在升级 Glibc 添加软连接指向 libc.so.6 时出错所以将软连接删除，更换为以前系统的glibc-2.12 指向的软连接，再次执行:

bash-4.1# chroot /mnt/sysimage

发现可以正常切换，没有再出现错误的提示。现在可以重启系统，设置后开机就没问题。

---