1 前言

有时候我们会遇到glibc的库被破坏而收入如下错误提示，

ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

注：
– 然后发现“ls”、“cp”等命令都无法使用并报相同的错误
– 由于glibc是GNU/Linux系统的核心库，该库提供关键的API
– 关键的API包括，
— open
— read
— write
— malloc
— printf
— getaddrinfo
— dlopen
— pthread_create
— crypt
— login
— exit等基础接口

2 解决方案

2.1 非停机方案

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

注：
– 修复的前提是“libc.so.6”软链接指向的“libc-2.5.so”没有被破坏，否则需要停机操作
– 定义环境变量“LD_PRELOAD”声明动态链接库的位置为“/lib64/libc-2.5.so”
– 以空格分隔后紧跟需要执行命令（包括修复命令）

2.2 停机RPM命令修复方案

2.2.1 以拯救模式引导系统

从其他媒体（光盘、光盘镜像、U盘等）方式引导系统，
https://www.cmdschool.org/archives/9315
以上会发现无法正常执行“chroot /mnt/sysimage”命令去变更根目录，会收到如下提示，

/bin/sh: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32

2.3.2 传输软件包到拯救模式系统环境

wget http://srpms.cmdschool.org/Server/glibc-2.5-18.x86_64.rpm

注：
– 例子演示使用http协议下载需要修复的软件包（需要配置拯救模式的网络）
– 另外亦可通过U盘等方式将该包复制到系统中

2.2.3 重装软件包

rpm -Uvh --replacefiles --replacepkgs --root=/mnt/sysimage glibc-*.rpm

2.3 停机备份还原方案

2.3.1 备份正常状态下的glibc库相关文件

tar cjvf glibc-2.5.tar.bz2 `rpm -ql glibc-2.5`

注：以上使用tar命令在正常的系统环境备份glibc软件包相关的文件以备还原使用

2.3.2 以拯救模式引导系统

从其他媒体（光盘、光盘镜像、U盘等）方式引导系统，
https://www.cmdschool.org/archives/9315
以上会发现无法正常执行“chroot /mnt/sysimage”命令去变更根目录，会收到如下提示，

/bin/sh: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32

2.3.3 传输软件包到拯救模式系统环境

wget http://srpms.cmdschool.org/glibc-2.5.tar.bz2

注：
– 例子演示使用http协议下载需要修复的软件包（需要配置拯救模式的网络）
– 另外亦可通过U盘等方式将该包复制到系统中

2.3.4 将备份包还原到异常的系统目录

tar -xf glibc-2.5.tar.bz2 -C /mnt/sysimage

注：以上使用tar命令将正常系统备份的glibc文件还原的异常系统的挂载目录

参阅的文档
===================

libc的介绍
——————
https://www.gnu.org/software/libc/

修复libc.so.6的处理方法
———————
https://www.cnblogs.com/gtarcoder/p/6015486.html