libc.so.6被误删除后的急救 libc.so.6: ELF file OS ABI invalid

公布一下我的处理方法：
系统：CentOS release 5.4 x86_64
1、 LD_PRELOAD=/lib64/libc-2.5.so ls /lib64/libc.so.6  #如果存在
2、 LD_PRELOAD=/lib64/libc-2.5.so mv /lib64/libc.so.6 /lib64/libc.so.6.bak  #其实也可以删除
3、 LD_PRELOAD=/lib64/libc-2.5.so ln -s /lib64/libc-2.5.so /lib64/libc.so.6    #增加软连

大家可以根据自己的版本修改成自己的libc-2.5.so版本文件  

转：http://devzc.com/post/440

最近遇到机房的一台虚拟机（测试机器）的libc库的软链libc.so.6被删除了，实际文件libc.2.4.so还在。

机器现状：

还有shell远程连入，但是各种命令都不能再使用：

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

网上搜索了一番，找到这个解决方案：

# LD_PRELOAD=<real libc> ln ......
相当于直接调用 ln命令，
所以，
先删除连接 ：
# cd /lib
# LD_PRELOAD=/lib/libc-2.3.6.so.bak rm libc.so.6
再建立新连接 ：
# LD_PRELOAD=/lib/libc-2.3.6.so.bak ln -s /lib/libc-2.3.6.so.bak libc.so.6

==》

分析： 由于shell仍然连入，因此此种方案可行。

原理就是： 
linux调用so的库文件时，搜素路径为当前路径，再是系统lib目录。
但是提供了一个LD_PRELOAD系统变量来改变这个顺序。设置LD_PRELOAD了后，库加载的顺序就改为：
搜素路径为： LD_PRELOAD ，当前路径，再是系统lib目录。 
（LD_PRELOAD还有其他妙用，可以参见之前的博文：linux下实现inject&hook）
因此，本次问题解决就很简单了：   LD_PRELOAD=/lib64/libc.2.4.so ln -s  libc.2.4.so   libc.so.6 
搞定。。。
针对这个问题，网上还有种方法是说使用busybox，但是至少在腾讯tlinux机器上，出现此种问题，busybox不能使用的。
原因是这个机器版本的busybox依赖libc。

============

现在抛出另一个问题：没有shell连接了怎么办？或者是libc.so彻底被删除了咋办？

=》解决也比较简单了（对于机器在机房的童鞋来说，你就认了吧，好好请运维吃饭，让他跑跑腿。。。）： 

1.实体机：

   直接拆下硬盘，在相同版本的linux机器上挂载，人工copy过去。

2.虚拟机：

   关闭出问题的虚拟机，当前虚拟机同一个母机的其他虚拟机，增加虚拟硬盘，选择出问题的虚拟机硬盘文件，搞定后，和实体机处理的方式就一样了。

比如virtualbox的：