CENTOS 7.9升级glibc起死回生术

原始需求：研发希望版本归一，所以统一把glibc 升级到2.19和把anaconda3升级到Anaconda3-2023.03-Linux-x86_64.sh版本

升级过程：

升级glibc过程不赘述，常规操作过程，成熟工艺：

1. cd /opt
2. tar zxvf glibc-2.19.tar.gz
3. cd /opt/glibc-2.19/
4. mkdir build
5. cd build
6. ../glibc-2.19/configure  --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
7. make
8. make install

升级anaconda3 过程：

1. chmod 777 Anaconda3-2023.03-Linux-x86_64.sh
2. ./Anaconda3-2023.03-Linux-x86_64.sh (yes / /usr/anaconda3,yes)
3. 再连一个terminal，执行：

conda config --show

conda config --set auto_activate_base False

============上诉都是常规操作，在centos6.10版本没有任何问题========

CENTOS 7.9版本问题现象：

升级完成后，包括centos7.9，所有业务使用正常，terminal连接正常，任务执行正常。已有VNC远程连接桌面正常，但是再新增的VNC控制台服务就出现了黑色背景，无上下工具栏的问题。在服务器启动vncserver 到5902端口:

桌面内可正常执行terminal，现象如下：

开始怀疑是VNC与anaconda3冲突的问题（网上大量文章是这个）。

卸载删除anaconda3无效，删除用户目录下的  .local / .conda / .config / .vnc目录无效

后来发现即使不用vnc连，直接IPMI连和接显示器，也一样是黑色背景。

查看centos 7.9 2009 自带的 gnome版本是 3.28.3

在gnome3之后引入了Mutter窗口管理组件，所以手工尝试启动（mutter -r &）,背景可以出来，但是仍然工具栏无法出来。

救助大神，诊断到是/usr/lib64/mutter/libmutter-cogl-2.so这个库在加载过程中出现问题被中断了，进行如下几个尝试：

• 尝试升级gnome-shell和mutter不能解决该问题。
• 尝试修改xstartup内容无效。
• 尝试继续继续升级glibc到2.20、2.21版本，现象依旧 升级到2.22及以后版本centos7.9自带的gcc和其他组件已不能完成编译。

查/usr/lib64/mutter/libmutter-cogl-2.so对glibc的支持关系可以看到gnome3的mutter只能支持如下四个版本的glibc，其他版本的都不兼容【注意：centos8的gnome只能兼容2.17和2.28两个版本】，centos6.10兼容性好是因为未使用Mutter窗口管理组件

基本没有选择，考虑降级glibc：

尝试的路线1：

找到原有镜像，通过rpm -qa|grep glibc 找出所安装的相关组件，然后在OS的镜像里找出对应的rpm文件名。强制重装到2.17版本

rpm -ivh glibc-2.17-317.el7.x86_64.rpm --nodeps  --force

rpm -ivh glibc-common-2.17-317.el7.x86_64.rpm --nodeps  --force

rpm -ivh glibc-devel-2.17-317.el7.x86_64.rpm --nodeps  --force

rpm -ivh glibc-headers-2.17-317.el7.x86_64.rpm --nodeps  --force

rpm -ivh libc-utils-2.17-317.el7.x86_64.rpm --nodeps  --force

可以安装，但是无法生成link文件，系统生效还是2.19版本

尝试的路线2：

手工新编译一个2.17版本的glibc，替换2.19

1. cd /opt
2. tar zxvf glibc-2.17.tar.gz
3. cd /opt/glibc-2.17/
4. mkdir build
5. cd build
6. ../glibc-2.17/configure  --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
7. make
8. make install

编译成功，但是发现文件的连接仍然是2.19,（注意，后续编译大于2.19版本的如2.20版本时会替换连接文件）

尝试的路线3：

因我这个服务器不能上外网，配置本地repo，然后强制downgrade

[root@CENTOS79 yum.repos.d]# more glibc.repo

[glibc]

name=glibc

baseurl=file:///data/misc/centos709

gpgcheck=1

enabled=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

[7u]

name=7u

baseurl=file:///data/misc/centos709

enabled=1

gpgcheck=0

然后执行

yum downgrade glibc  glibc-devel glibc-headers  glibc-common  --skip-broken

可成功但是仍无效。

路线4：既然降版本不行，尝试强行relink到2.17版本

但是这个地方犯了一个大错误，不能直接unlink，否则所有系统的命令，除了cd外都会失效。

好在该服务器加载有nfs目录，紧急上传一个busybox，恢复link，顺便调整到2.17版本的so：

/nas/soft/busybox ln -s libutil-2.17.so libutil.so.1

/nas/soft/busybox ln -s ld-2.17.so ld-linux-x86-64.so.2

/nas/soft/busybox ln -s libanl-2.17.so libanl.so.1

/nas/soft/busybox ln -s libBrokenLocale-2.17.so libBrokenLocale.so.1

/nas/soft/busybox ln -s libcidn-2.17.so libcidn.so.1

/nas/soft/busybox ln -s libcrypt-2.17.so libcrypt.so.1

/nas/soft/busybox ln -s libc-2.17.so libc.so.6

/nas/soft/busybox ln -s libdl-2.17.so libdl.so.2

/nas/soft/busybox ln -s libm-2.17.so libm.so.6

/nas/soft/busybox ln -s libnsl-2.17.so libnsl.so.1

/nas/soft/busybox ln -s libnss_compat-2.17.so libnss_compat.so.2

/nas/soft/busybox ln -s libnss_db-2.17.so libnss_db.so.2

/nas/soft/busybox ln -s libnss_dns-2.17.so libnss_dns.so.2

/nas/soft/busybox ln -s libnss_files-2.17.so libnss_files.so.2

/nas/soft/busybox ln -s libnss_hesiod-2.17.so libnss_hesiod.so.2

/nas/soft/busybox ln -s libnss_nisplus-2.17.so libnss_nisplus.so.2

/nas/soft/busybox ln -s libnss_nis-2.17.so libnss_nis.so.2

/nas/soft/busybox ln -s libpthread-2.17.so libpthread.so.0

/nas/soft/busybox ln -s libresolv-2.17.so libresolv.so.2

/nas/soft/busybox ln -s librt-2.17.so librt.so.1

系统恢复正常，看起来完美了，但是。。。。仍然不可用（因为这个是自己编译产生的2.17的so文件）

继续努力。

跟踪mutter 的so使用依存关系，补齐差异的so

在出问题的服务器，新建/usr/lib64/glibc/目录，从干净的centos7.9系统拷贝如下几个文件到该目录，并做文件链接：

sln /usr/lib64/glibc/libc-2.17.so /lib64/libc.so.6

sln /usr/lib64/glibc/ld-2.17.so /usr/lib64/ld-linux-x86-64.so.2

sln /usr/lib64/glibc/libdl-2.17.so /usr/lib64/libdl.so.2

sln /usr/lib64/glibc/libm-2.17.so /lib64/libm.so.6

sln /usr/lib64/glibc/libpthread-2.17.so /lib64/libpthread.so.0

大功告成！！！！恢复正常使用

============如果是仅仅只glibc升级到2.19,马上就往回改===========

如果是仅仅只glibc升级到2.19,马上就往回改，简单很多，只需要如下命令执行：

sln /usr/lib64/libc-2.17.so /lib64/libc.so.6

sln /usr/lib64/ld-2.17.so /usr/lib64/ld-linux-x86-64.so.2

sln /usr/lib64/libdl-2.17.so /usr/lib64/libdl.so.2

sln /lib64/libm-2.17.so /lib64/libm.so.6

sln /lib64/libpthread-2.17.so /lib64/libpthread.so.0

使用系统原来自带的小版本号的so，就可以恢复正常了。

=======================体会心得==============

1. 没事别动glibc，管他研发说什么。动glibc高危，我等老鸟都扒层皮，菜鸟直接熟了。
2. 沉着冷静，控制故障范围。本次涉及5台服务器，业务正常使用，研发基本没感知。
3. 出现重大异常后，别动现场，去外部重新搭测试环境尝试和复现。最多只拿一台做测试。
4. 广交朋友，越专业的技术，越需要专业的人去长眼。别人一句话，够我跑三天。

本文已获得转载授权，如需再次转载请联系作者获取授权

本文地址：https://www.fasteda.cn/post/332.html