CentOS 8 GLIBC升级失败系统崩溃抢修实战

服务器为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导致系统异常（无法开机）

总的来说基本思路如下：

1. 拿一个U盘制作原系统（比如我的系统是CentOS 8，就下载CentOS 8 iso）启动盘
2. U盘内进入Rescue模式
3. 在Rescue模式下重装兼容的glibc包

这里最大的问题在于CentOS镜像太大，下载太费时间。而Debian提供的Live OS小巧易用，并且可以安装rpm包管理器。于是我们采用如下思路抢修：

1. 制作Debian Live OS
2. 将原系统挂载到Live OS中
3. 在Live OS中下载并安装glibc RPM包
4. 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 抢修流程

1. 服务器强制关机

2. 将U盘插入USB口

3. 开机，选择从U盘启动。不同机器处理方式不同。例如，Dell R740服务器需要开机时按F11，手动选择从U盘启动。但博主抢修的这台机器是惠普的，似乎自己就识别到了U盘

4. 选择Debian Live OS进入

5. 进入Live OS后，没有网络。此时手机打开热点，将数据线连接到服务器的USB口上，并从高级选项中选择通过USB共享网络。
   

6. 此时，服务器上通过ip addr应该能够看到一个多出来的网卡，例如，博主的是enx12c483f98c5a。可以看到该网卡还没有被分配ip地址。
   

7. 输入sudo dhclient为网卡动态获取ip，ping www.baidu.com测试网络是否连接成功。

8. 下载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
   

9. 挂载原系统并安装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
     

10. sudo chroot /mnt成功即说明glibc抢修成功

11. 接下来sudo umount /mnt && sudo shutdown，等待关机后，拔出U盘。

12. 静待重启……………………难过的事情再次发生了，系统卡在了无休止的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关掉了😄。

3.4 解决undefined reference to `__libc_csu_fini’

更新于2023/8/11。恢复后的服务器无法编译，报类似下述错误：
/usr/lib/gcc/x86_64-redhat-linux/8/…/…/…/…/lib64/crt1.o：在函数‘_start’中：
(.text+0x16)：对‘__libc_csu_fini’未定义的引用

恢复过程中可能由于--nodeps --force 原因有些依赖包没装好，因此系统起来后需要重装一下：

sudo yum reinstall glibc
sudo yum reinstall glibc-devel

4. 总结

这次抢修经历是非常惊心动魄的，前前后后加起来差不多5、6个小时。多亏了seekstar的帮忙。回过头来，这次抢修最大的教训就是再也不会在服务器环境乱动glibc了。OK，现在可以起飞了🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫🛫