| 在某些linux系统里面本身自带的glibc版本过低，导致rpm无法安装。如果你直接更新系统的glibc版本会导致系统崩溃，就算你编译安装好glibc库到非系统目录，但是你不能去设置环境变量 和ld.so.conf 这个2个文件，你一但设置指向新版本的glibc库，系统分分钟崩溃。更不能把这个新库直接安装到系统目录下。笔者最近不幸遇到了这个问题。
glibc介绍glibc是什么？为什么升级风险这么高？glibc的作用是什么？ glibc是GNU发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。内核实现一个功能，glibc要花很久才会用上，由于glibc和内核不是一块开发的，所以glibc需要去兼容不同版本的内核，而内核也要去兼容不同版本的 glibc，双方都背负了太多的历史包袱。 简单理解其实和http api接口类似，区别在于glibc是调用内核对底层磁盘，内存，网卡等的操作，http api则是对应用层app的操作，比如听一首歌，下载一部电影实则都是在调用http api接口。
问题发生试图通过编译安装升级Linux服务器的glibc库版本，install失败以后，shell中的大部分命令（ls，cat，rm，cp，ln，scp，vi，yum等）都执行报错，尝试新的ssh连接时提示拒绝连接。 命令报错类似： # lsls: 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
可补救·操作空间有ssh客户端连接着这台服务器没有断开原始的低版本glibc库文件还在cd，pwd，export，echo，sln，chmod命令可用，输入ls+两次TAB键可以提示目录下所有文件
开始尝试修复
步骤1glibc是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.solrwxrwxrwx. 1 root root 14 Jul 4 16:55 libanl.so.1 -> libanl-2.17.solrwxrwxrwx. 1 root root 23 Jul 4 16:55 libBrokenLocale.so.1 -> libBrokenLocale-2.17.solrwxrwxrwx. 1 root root 15 Jul 4 16:55 libcidn.so.1 -> libcidn-2.17.solrwxrwxrwx. 1 root root 16 Jul 4 16:55 libcrypt.so.1 -> libcrypt-2.17.solrwxrwxrwx. 1 root root 12 Jul 4 16:55 libc.so.6 -> libc-2.17.solrwxrwxrwx. 1 root root 13 Jul 4 16:55 libdl.so.2 -> libdl-2.17.solrwxrwxrwx. 1 root root 12 Jul 4 16:55 libm.so.6 -> libm-2.17.solrwxrwxrwx. 1 root root 14 Jul 4 16:55 libnsl.so.1 -> libnsl-2.17.solrwxrwxrwx. 1 root root 21 Jul 4 16:55 libnss_compat.so.2 -> libnss_compat-2.17.solrwxrwxrwx. 1 root root 17 Jul 4 16:55 libnss_db.so.2 -> libnss_db-2.17.solrwxrwxrwx. 1 root root 18 Jul 4 16:55 libnss_dns.so.2 -> libnss_dns-2.17.solrwxrwxrwx. 1 root root 20 Jul 4 16:55 libnss_files.so.2 -> libnss_files-2.17.solrwxrwxrwx. 1 root root 21 Jul 4 16:55 libnss_hesiod.so.2 -> libnss_hesiod-2.17.solrwxrwxrwx. 1 root root 22 Jul 4 16:55 libnss_nisplus.so.2 -> libnss_nisplus-2.17.solrwxrwxrwx. 1 root root 18 Jul 4 16:55 libnss_nis.so.2 -> libnss_nis-2.17.solrwxrwxrwx. 1 root root 18 Jul 4 16:55 libpthread.so.0 -> libpthread-2.17.solrwxrwxrwx. 1 root root 17 Jul 4 16:55 libresolv.so.2 -> libresolv-2.17.solrwxrwxrwx. 1 root root 13 Jul 4 16:55 librt.so.1 -> librt-2.17.solrwxrwxrwx. 1 root root 15 Jul 4 16:55 libutil.so.1 -> libutil-2.17.so
步骤2由于ln命令已经不能使用，可使用sln命令，创建/修复软连接。命令格式：sln <被指向的文件> <软连接名>。假设需要回退到版本号XXX，那么只需以下命令就可以修复。 cd /lib64sln ld-XXX.so ld-linux-x86-64.so.2sln libanl-XXX.so libanl.so.1sln libBrokenLocale-XXX.so libBrokenLocale.so.1sln libcidn-XXX.so libcidn.so.1sln libcrypt-XXX.so libcrypt.so.1sln libc-XXX.so libc.so.6sln libdl-XXX.so libdl.so.2sln libm-XXX.so libm.so.6sln libnsl-XXX.so libnsl.so.1sln libnss_compat-XXX.so libnss_compat.so.2sln libnss_db-XXX.so libnss_db.so.2sln libnss_dns-XXX.so libnss_dns.so.2sln libnss_files-XXX.so libnss_files.so.2sln libnss_hesiod-XXX.so libnss_hesiod.so.2sln libnss_nisplus-XXX.so libnss_nisplus.so.2sln libnss_nis-XXX.so libnss_nis.so.2sln libpthread-XXX.so libpthread.so.0sln libresolv-XXX.so libresolv.so.2sln librt-XXX.so librt.so.1sln 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命令+重定向输出文件，具体展开如下： 以文本编辑器（例如使用Windows上的EmEditor）的二进制模式打开原始文件，全选复制出文件的原始字节内容，如下： 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行，略)...... 继续编辑文本，替换复制内容中的" “(1个空格)和” “(2个空格)替换为”/x"，并且在每行首也插入"/x"，如下： /x7F/x45/x4C/x46/x02/x01/x01/x00/x00/x00/x00/x00/x00/x00/x00/x00/x03/x00/x3E/x00/x01/x00/x00/x00/x20/x11/x00/x00/x00/x00/x00/x00/x40/x00/x00/x00/x00/x00/x00/x00/x48/x77/x02/x00/x00/x00/x00/x00/x00/x00/x00/x00/x40/x00/x38/x00/x07/x00/x40/x00/x1C/x00/x1B/x00/x01/x00/x00/x00/x05/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/x00/xA0/x18/x02/x00/x00/x00/x00/x00/xA0/x18/x02/x00/x00/x00/x00/x00/x00/x00/x20/x00/x00/x00/x00/x00/x01/x00/x00/x00/x06/x00/x00/x00/x40/x1B/x02/x00/x00/x00/x00/x00/x40/x1B/x22/x00/x00/x00/x00/x00/x40/x1B/x22/x00/x00/x00/x00/x00/x38/x14/x00/x00/x00/x00/x00/x00/x10/x16/x00/x00/x00/x00/x00/x00/x00/x00/x20/x00/x00/x00/x00/x00/x02/x00/x00/x00/x06/x00/x00/x00/x00/x1E/x02/x00/x00/x00/x00/x00......(共5107行，略)...... 合并所有行为一行，并去掉所有空格，如下： /x7F/x45/x4C/x46/x02/x01/x01/x00/x00/x00/x00/x00/x00/x00/x00/x00/x03/x00/x3E/x00/x01/x00/x00/x00/x20/x11/x00/x00/x00/x00/x00/x00/x40/x00/x00/x00/x00/x00/x00/x00/x48/x77/x02......(略)...... 将编辑后的十六进制数据与echo命令参数一起，组成echo -e "编辑后的16进制数据" > ~/savetheworld.bin的形式，粘贴到连接着问题服务器的ssh终端，执行。经过漫长的等待之后（以小时记，因为回显很慢。可灵活利用shell客户端中类似CommandWindow的功能，在输入框中输入命令来节省时间），生成的~/savetheworld.bin文件就作为损坏的ld-2.17.so文件的替代，重新用上文sln修复软连接的方法，最终修复成功。
总结你只能用第三方工具把glibc引入你的项目，第一是让rpm安装包自带这个库 ，第二种是 使用yum或者其他第三方工具库进行安装 ，第三种就是换更新的系统 ，新出的系统里面自带高版本glibc。我建议直接换系统 如果对系统版本没有强制要求的情况。
下载地址:
Docker如何查看镜像里的文件
解决Docker删除镜像报错:Error response from daemon:conflict:unable to& |
