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

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

1. 恐怖的问题2. 参考解决方案3. 抢修实战3.1 准备工作3.2 抢修流程3.3 解决启动后Permission Denied3.3.1 参考方案3.3.2 解决

3.4 解决undefined reference to `__libc_csu_fini'

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关掉了。

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，现在可以起飞了

好文链接