问题发生
试图通过编译安装升级Linux服务器的glibc库版本,install失败以后,shell中的大部分命令(ls,cat,rm,cp,ln,scp,vi,yum等)都执行报错,尝试新的ssh连接时提示拒绝连接。
命令报错类似:
# ls
ls: relocation error: /usr/lib64/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
或者
bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
可补救·操作空间
开始尝试修复
步骤1
glibc是Linux系统底层库,许多shell命令乃至bash本身都依赖这套动态链接库。
以上问题出在/lib64(/usr/lib64)
目录下的软连接损坏,或连接的so库文件版本不统一,或所连接的so库文件本身存在问题。
解决思路就是把以下软连接全部恢复为指向原始版本(低版本)。
前提是先到/lib64
目录下,用ls+两次TAB键的方法确认好自己系统下的libc-<x.xx>.so
最低版本号(也就是好用的版本)是哪个。
lrwxrwxrwx. 1 root root 10 Jul 4 16:55 ld-linux-x86-64.so.2 -> ld-2.17.so
lrwxrwxrwx. 1 root root 14 Jul 4 16:55 libanl.so.1 -> libanl-2.17.so
lrwxrwxrwx. 1 root root 23 Jul 4 16:55 libBrokenLocale.so.1 -> libBrokenLocale-2.17.so
lrwxrwxrwx. 1 root root 15 Jul 4 16:55 libcidn.so.1 -> libcidn-2.17.so
lrwxrwxrwx. 1 root root 16 Jul 4 16:55 libcrypt.so.1 -> libcrypt-2.17.so
lrwxrwxrwx. 1 root root 12 Jul 4 16:55 libc.so.6 -> libc-2.17.so
lrwxrwxrwx. 1 root root 13 Jul 4 16:55 libdl.so.2 -> libdl-2.17.so
lrwxrwxrwx. 1 root root 12 Jul 4 16:55 libm.so.6 -> libm-2.17.so
lrwxrwxrwx. 1 root root 14 Jul 4 16:55 libnsl.so.1 -> libnsl-2.17.so
lrwxrwxrwx. 1 root root 21 Jul 4 16:55 libnss_compat.so.2 -> libnss_compat-2.17.so
lrwxrwxrwx. 1 root root 17 Jul 4 16:55 libnss_db.so.2 -> libnss_db-2.17.so
lrwxrwxrwx. 1 root root 18 Jul 4 16:55 libnss_dns.so.2 -> libnss_dns-2.17.so
lrwxrwxrwx. 1 root root 20 Jul 4 16:55 libnss_files.so.2 -> libnss_files-2.17.so
lrwxrwxrwx. 1 root root 21 Jul 4 16:55 libnss_hesiod.so.2 -> libnss_hesiod-2.17.so
lrwxrwxrwx. 1 root root 22 Jul 4 16:55 libnss_nisplus.so.2 -> libnss_nisplus-2.17.so
lrwxrwxrwx. 1 root root 18 Jul 4 16:55 libnss_nis.so.2 -> libnss_nis-2.17.so
lrwxrwxrwx. 1 root root 18 Jul 4 16:55 libpthread.so.0 -> libpthread-2.17.so
lrwxrwxrwx. 1 root root 17 Jul 4 16:55 libresolv.so.2 -> libresolv-2.17.so
lrwxrwxrwx. 1 root root 13 Jul 4 16:55 librt.so.1 -> librt-2.17.so
lrwxrwxrwx. 1 root root 15 Jul 4 16:55 libutil.so.1 -> libutil-2.17.so
步骤2
由于ln命令已经不能使用,可使用sln命令,创建/修复软连接。命令格式:sln <被指向的文件> <软连接名>
。假设需要回退到版本号XXX,那么只需以下命令就可以修复。
cd /lib64
sln ld-XXX.so ld-linux-x86-64.so.2
sln libanl-XXX.so libanl.so.1
sln libBrokenLocale-XXX.so libBrokenLocale.so.1
sln libcidn-XXX.so libcidn.so.1
sln libcrypt-XXX.so libcrypt.so.1
sln libc-XXX.so libc.so.6
sln libdl-XXX.so libdl.so.2
sln libm-XXX.so libm.so.6
sln libnsl-XXX.so libnsl.so.1
sln libnss_compat-XXX.so libnss_compat.so.2
sln libnss_db-XXX.so libnss_db.so.2
sln libnss_dns-XXX.so libnss_dns.so.2
sln libnss_files-XXX.so libnss_files.so.2
sln libnss_hesiod-XXX.so libnss_hesiod.so.2
sln libnss_nisplus-XXX.so libnss_nisplus.so.2
sln libnss_nis-XXX.so libnss_nis.so.2
sln libpthread-XXX.so libpthread.so.0
sln libresolv-XXX.so libresolv.so.2
sln librt-XXX.so librt.so.1
sln libutil-XXX.so libutil.so.1
至此,如果没有操作错误,ls等关键命令、包括ssh连接都应该已经可以正常使用,修复完成。
但是,由于笔者操作过程中的失误(“sln xxx yyy”写成了”sln yyy xxx”),导致ld-2.17.so原始库文件被覆盖成软连接文件,所以需要进一步的补救。
误操作后的二次补救
解决思路就是恢复不小心损坏的ld-2.17.so文件,那么就需要一份可用的ld-2.17.so文件数据。由于笔者使用的是服务器集群,原始文件从其他节点就可以获取。如果是单机服务器,可能需要借助互联网获取ld-2.17.so原始文件。
目前最大的阻碍是:scp,mount,wget等命令都不能使用,需要考虑如何将获取到的原始文件放到问题服务器的磁盘上——解决方法是echo命令+重定向输出文件,具体展开如下:
7F 45 4C 46 02 01 01 00 00 00 00 00 00 00 00 00 03 00 3E 00 01 00 00 00 20 11 00 00 00 00 00 00
40 00 00 00 00 00 00 00 48 77 02 00 00 00 00 00 00 00 00 00 40 00 38 00 07 00 40 00 1C 00 1B 00
01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 18 02 00 00 00 00 00 A0 18 02 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 00 06 00 00 00
40 1B 02 00 00 00 00 00 40 1B 22 00 00 00 00 00 40 1B 22 00 00 00 00 00 38 14 00 00 00 00 00 00
10 16 00 00 00 00 00 00 00 00 20 00 00 00 00 00 02 00 00 00 06 00 00 00 00 1E 02 00 00 00 00 00
......(共5107行,略)......
x7Fx45x4Cx46x02x01x01x00x00x00x00x00x00x00x00x00x03x00x3Ex00x01x00x00x00x20x11x00x00x00x00x00x00
x40x00x00x00x00x00x00x00x48x77x02x00x00x00x00x00x00x00x00x00x40x00x38x00x07x00x40x00x1Cx00x1Bx00
x01x00x00x00x05x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00
xA0x18x02x00x00x00x00x00xA0x18x02x00x00x00x00x00x00x00x20x00x00x00x00x00x01x00x00x00x06x00x00x00
x40x1Bx02x00x00x00x00x00x40x1Bx22x00x00x00x00x00x40x1Bx22x00x00x00x00x00x38x14x00x00x00x00x00x00
x10x16x00x00x00x00x00x00x00x00x20x00x00x00x00x00x02x00x00x00x06x00x00x00x00x1Ex02x00x00x00x00x00
......(共5107行,略)......
x7Fx45x4Cx46x02x01x01x00x00x00x00x00x00x00x00x00x03x00x3Ex00x01x00x00x00x20x11x00x00x00x00x00x00x40x00x00x00x00x00x00x00x48x77x02......(略)......
- 将编辑后的十六进制数据与echo命令参数一起,组成
echo -e "编辑后的16进制数据" > ~/savetheworld.bin
的形式,粘贴到连接着问题服务器的ssh终端,执行。 - 经过漫长的等待之后(以小时记,因为回显很慢。可灵活利用shell客户端中类似CommandWindow的功能,在输入框中输入命令来节省时间),生成的
~/savetheworld.bin
文件就作为损坏的ld-2.17.so文件的替代,重新用上文sln修复软连接的方法,最终修复成功。
END
原文地址:https://blog.csdn.net/u010549608/article/details/126281354
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_23050.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!