全面解决/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.22‘下没有GLIBCXX_3.4.22和ImportError: /lib64/libc.so

重点: 修改前一定要备份，修改过程如果出现错误不要关闭ssh
修改需要修改两个so，也就是说需要准备好以下两步操作中符合要求的so，请先看完重点在进行操作，贸然修改会对服务器有严重损害,请备份，如果操作出错需急救直接进入出错以及修复教程

如果你准备好了两个符合依赖关系版本的so，那么第二步和第一步基本一致，但一定要记得备份，因为新的so可能不支持某些你原来安装的软件，比如python，php等，除非是为了某个特殊需求必须用到，而且服务器不打算做其它太多的项目，那么可以折腾，否则建议尝试使用docker创建需要的环境。

全面解决/usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.22'下没有GLIBCXX_3.4.22和ImportError: /lib64/libc.so.6: version GLIBC_2.33’ not found

/lib64/libstdc++.so.6: version `GLIBCXX_3.4.22报错是c++环境依赖缺失
修正方案：
1.使用以下命令查看是否缺少

strings /usr/lib64//libstdc++.so.6 | grep GLIBC

查看到列表中缺少版本 `GLIBCXX_3.4.22’

将原来的/usr/lib64/libstdc++.so.6 也就是提示信息的/usr/lib64/libstdc++.so.6重命名为/usr/lib64/libstdc++.so.6-bak(自己根据实际报错信息修改)

mv /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6-bak

然后查找本机的拥有的libstdc++.so依赖

locate libstdc++.so

正常情况会出现很多，使用第一个命令一一验证哪个libstdc++.so版本拥有 `GLIBCXX_3.4.22’，比如搜索到一个/usr/lib/libstdc++.so.30

strings /usr/lib/libstdc++.so.30| grep GLIBC

查看后发现符合要求（不符合就继续查其它），就将/usr/lib/libstdc++.so.30复制到/usr/lib64/文件夹下

cp /usr/lib/libstdc++.so.30 /usr/lib64/

然后用新的符合要求的libstdc++.so.30建立软连接

ln -s  /usr/lib64/libstdc++.so.6.0.30 /usr/lib64/libstdc++.so.6

然后再用原来的命令检测，发现已经有包含 `GLIBCXX_3.4.22’

strings /usr/lib64//libstdc++.so.6 | grep GLIBC

至此完成

出错以及修复（云服务器直接找客服）

至于第二个ImportError: /lib64/libc.so.6: version `GLIBC_2.33’ not found，不要轻易修改，**如果没有这个文件会导致连接不上shell，不要问我为什么知道。**建议尝试直接使用建立软链接或者覆盖原来文件的方式，找到符合条件的文件覆盖掉（记住这个只是软链，你要找到真正的文件进行覆盖!）。
重要的事 重要的事如果不小心修改了 /lib64/libc.so.6，此时大部分shell命令都会失效，不要慌张，更不要关闭ssh连接（不要问我为什么知道），此时要保持ssh连接不要关闭，因为关闭了就无法再连接了，只能跑系统急救了
未关闭解决方法执行以下命令（linux公社找到的解决答案）

LD_PRELOAD=/lib64/libc-2.26.so ln -s /lib64/libc-2.26.so  /lib64/libc.so.6

记住/lib64/libc-2.26.so必须是你主机存在的文件，所以根据实际情况操作。比如你将/lib64/libc.so.6改名为/lib64/libc.so.6-bak了，那么可以重新建立软链

LD_PRELOAD=/lib64/libc.so.6-bak ln -s /lib64/libc.so.6-bak  /lib64/libc.so.6

或者

sln /lib64/libc.so.6-bak /lib64/libc.so.6

当然你还可以恢复重命名再建立软链接:

LD_PRELOAD=/lib64/libc.so.6-bak mv /lib64/libc.so.6-bak /lib64/libc.so.6

建立软链如上

所以最好的办法就是直接建立软连接覆盖，或者将原来的libc.so.6复制一份作为备份，然后将新的libc.so.xx版本复制到lib64下并重命名为libc.so.6覆盖原文件，也算一种方法（理论可行）

重点 第二个libc.so.6即使找到了符合条件的文件，也可能本机内核不支持（此时还可以升级内核，看了下，放弃），坑点来了，如果你修改了第一个libstdc++.so.6，那么大概率要修改libc.so.6，因为不同版本对应不同依赖。所以此时可以找一个符合依赖关系且符合系统版本的libc.so.6，重新建立软链接，以维持建立好的新libstdc++.so.6动态依赖。否则打道回府，将第一步的libstdc++.so.6修改还原。

正常修改libc.so.6方式：
https://blog.csdn.net/u014634615/article/details/120333287
还有一种人吓傻了关闭了ssh连接的急救
CentOS无法登录root的原因及解决方法？针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
情况一：
如果还连着的ssh终端，没有断开，直接执行如下命令即可恢复：

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

情况二：
ssh已经断开，无法新建新的ssh连接，重启系统，报错无法进入系统。
出现报错：Kernel panic - not syncing: Attempted to kill init!
处理办法
进入rescue救援模式，将链接文件复制到被删除的文件系统。
操作步骤如下：
1、开机进入BIOS设置，修改BOOT启动顺序为光盘优先启动 CD-ROM Drive；
2、重启系统后由光盘引导，进入安装启动菜单，选择“Rescue install system”救援模式；
3、进入到Rescue界面，选择Continue
4、系统挂载在/mnt/sysimage下 ，选择OK（如果要到root环境下，运行 chroot /mnt/sysimage 命令，此处不需要）
5、选择进入模式：shell 进入命令行模式，fakd是诊断模式，reboot重启电脑，这里选择shell
6、进入shell命令行，提示符为bash-4.1#
7、不要执行chroot /mnt/sysimage，因为硬盘文件系统就在该目录下，从/lib64下复制软连接即可，操作如下：
bash-4.1# cd /lib64
bash-4.1# cp -d libc.so.6 /mnt/sysimage/lib64/libc.so.6
bash-4.1# reboot
之后即可恢复正常
以上就是CentOS无法登录root的原因及解决方法 作者：云V小编 https://www.bilibili.com/read/cv14139558 出处：bilibili