CentOS 8 GLIBC升级失败系统崩溃抢修实战
- 1. 恐怖的问题
- 2. 参考解决方案
- 3. 抢修实战
- 3.1 准备工作
- 3.2 抢修流程
- 3.3 解决启动后Permission Denied
- 3.3.1 参考方案
- 3.3.2 解决
- 4. 总结
服务器为CentOS 8，支持glibc版本为2.28，但编译一个工具的glibc需求版本为2.34，于是非常脑残地参考这篇Tutorial开始升级之旅：下载glibc-2.34，并
configure到了系统目录，然后将源码make && make install，然后……
1. 恐怖的问题
几乎所有命令都执行不了了，报类似下面的错误：
symbol lookup error: /usr/lib64/libdl.so.2: undefined symbol: dl_vsym, version GLIBC_PRIVATE
结论是：CentOS 8与高版本glibc不兼容，glibc-2.28有的符号（例如：dl_vsym），但glibc-2.34可能没有。但CentOS 8的大多数程序都依赖这些符号，于是炸裂。
这篇文章指明还有机会在ssh连接时恢复系统环境。可惜的是，博主脑子一热退出了ssh，此后再也无法访问服务器。
2. 参考解决方案
- centos6.9中glibc升级失败救援+救援模式挂载硬盘
- Centos7手动升级glibc导致系统异常（无法开机）
总的来说基本思路如下：
- 拿一个U盘制作原系统（比如我的系统是CentOS 8，就下载CentOS 8 iso）启动盘
- U盘内进入
Rescue模式 - 在
Rescue模式下重装兼容的glibc包
这里最大的问题在于CentOS镜像太大，下载太费时间。而Debian提供的Live OS小巧易用，并且可以安装rpm包管理器。于是我们采用如下思路抢修：
- 制作Debian Live OS
- 将原系统挂载到Live OS中
- 在Live OS中下载并安装glibc RPM包
- chroot检查是否成功恢复
接下来具体介绍抢修过程
3. 抢修实战
3.1 准备工作
- 制作启动盘（以下为个人制作方法）
- 准备一个空U盘
- 下载ventoy
- 运行
ventoy.exe安装至U盘 - 下载Debian Live OS镜像，下载debian-live-12.0.0-amd64-standard.iso即可，这个镜像最小
- 将下载的iso复制到U盘中即可
- 手机数据线（用于为Live OS联网）
- 前往机房
3.2 抢修流程
-
服务器强制关机
-
将U盘插入USB口
-
开机，选择从U盘启动。不同机器处理方式不同。例如，Dell R740服务器需要开机时按F11，手动选择从U盘启动。但博主抢修的这台机器是惠普的，似乎自己就识别到了U盘
-
选择Debian Live OS进入
-
进入Live OS后，没有网络。此时手机打开热点，将数据线连接到服务器的USB口上，并从高级选项中选择通过USB共享网络。
-
此时，服务器上通过ip addr应该能够看到一个多出来的网卡，例如，博主的是enx12c483f98c5a。可以看到该网卡还没有被分配ip地址。
-
输入
sudo dhclient为网卡动态获取ip，ping www.baidu.com测试网络是否连接成功。 -
下载
rpm包。直接上清华源找对应的rpm包。这里博主升级前就是glibc-2.28。cd ~ wget https://mirrors.tuna.tsinghua.edu.cn/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-2.28-228.el8.x86_64.rpm wget https://mirrors.tuna.tsinghua.edu.cn/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-common-2.28-228.el8.x86_64.rpm wget https://mirrors.tuna.tsinghua.edu.cn/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-langpack-en-2.28-228.el8.x86_64.rpm -
挂载原系统并安装rpm包：
-
输入sudo lsblk查看原系统在哪个设备上，CentOS一般来说root为
/dev/mapper/cl-root，挂载这个分区即可sudo mount /dev/mapper/cl-root /mnt -
安装rpm包
sudo apt install rpm sudo rpm -ivh --nodeps --force --root=/mnt glibc-*.rpm
-
-
sudo chroot /mnt成功即说明glibc抢修成功 -
接下来
sudo umount /mnt && sudo shutdown，等待关机后，拔出U盘。 -
静待重启……………………难过的事情再次发生了，系统卡在了无休止的
Permission Denied中（在加载界面按下esc可查看）
3.3 解决启动后Permission Denied
3.3.1 参考方案
- Centos 8 stuck in boot loop, multiple permission denieds. Any solution to this?
3.3.2 解决
根据上述参考，猜测与selinux有关，于是尝试禁用selinux。具体做法是在grub菜单处，按下e修改command line：将enforcing=0加入到command line最后，然后ctrl + x启动系统。终于成功了！猜测是因为安装rpm的时候破坏了selinux的某些配置，例如发现/.autorelabel文件消失了。至于如何恢复selinux就不在本文的讨论范围之内了。博主非常极端地把selinux关掉了😄。
4. 总结
这次抢修经历是非常惊心动魄的，前前后后加起来差不多5、6个小时。多亏了seekstar的帮忙。回过头来，这次抢修最大的教训就是再也不会在服务器环境乱动glibc了。OK，现在可以起飞了🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫
