的故事意外的是新开发的jar包部署在旧的服务器上，版本是RedHatEnterpriseLinuxASrelease4(NahantUpdate5)，并且提示需要更高版本的jdk，高版本的jdk提示glibc版本太低无法升级，没错，就是套娃。使用编译源码的方式将glibc从2.3升级到2.9。升级后ls命令不好用了。在使用LD_PRELOAD方法解决了ls命令不好用的问题后，很有成就感！轻度强迫症当然得重启，然后#reboot就没了。.操作系统起不来。各种尝试，最好的结果卡在Startingcups-config-daemon:StartingHALdaemon:nevergoanyfurther。007的服务器被996的程序员黑进了ICU。看，关闭服务器看起来是无辜的。删库似乎太刻意了，会被人指责人格有问题。挽救的思路是像《信条》那样进行逆向处理，用原来的低版本覆盖glibc相关的静态库和动态库。cpcoverage与rpmcoverage一起安装。必要条件是能够进入机房直接操作服务器，因为此时ssh已经连接不上了。有同版本的Linux系统光盘，Linux救援模式需要从光盘启动。有同版本Linux系统的iso镜像文件获取rpm[或替代方法]使用同版本Linux系统的服务器或虚拟机下载.a文件[或替代方法]准备rpm安装包将文件解压，所有需要的rpm包都包含在RHEL4.6-i386-AS-DVD\RedHat\RPMS目录下。需要准备的安装包如下：.a同版本的静态库文件到服务器对应目录下，方便使用下载下面的库文件目录/lib目录/usr/lib把这些安装包和静态库放入U盘，U盘插入服务器。救援进程进入光驱系统，将光盘放入光驱。开机快速按F2，通过+-号进入调整启动顺序，将光驱调到最上面回车，系统重启，进入光驱启动界面按F5，进入linuxrescue然后回车，稍等，回车回车，回车回车，回车回车，回车移动光标到否，回车，回车回车，回车提示原系统已经挂载到/mnt/sysimage，回车进入，你当前所在的是光盘救援模式（rescuemode），环境是光盘系统，原系统的所有文件都在光盘的子目录/mnt/sysimage中系统。可以看到在/mnt/sysimage下可以看到原系统的所有目录结构。挂载U盘，首先将U盘挂载到光盘系统，mount-tvfat/dev/sdb1/mnt/usb/不同环境下U盘的标识不一定是sdb1，有可能是sda1物理机，可以使用fdisk-l命令查看各个目录的容量，确定哪个是U盘。如果U盘格式挂载错误，U盘可能是fat16格式。执行mount-tmsdos/dev/sdb1/mnt/usb/试试。此时U盘中的文件都在/mnt/usb/目录下。原系统的所有文件都在/mnt/sysimage下。将usb目录下的文件复制到/mnt/sysimage下你能记住的任意目录下，把这篇文章复制到/mnt/sysimage/home。cp/mnt/usb/*/mnt/sysimage/home切换到原来的系统执行#chroot/mnt/sysimage这个命令让你从当前光驱系统切换到原来的系统（也就是我们要抢救的系统),执行pwd和ls可以看到你所在的目录是原系统的根目录，账号是原系统的root账号。总之，原系统是不能直接进入的，但是可以从光驱系统跳进去。安装rpm进入/home,rpm-ivh--forcerpm包名将U盘的rpm包一一安装。如果你装失败了，等你把所有成功的都装完了以后再试。不会和答题卡的子题打同一个套路，都是依赖导致失败。最好自己给rpm重命名，改成一个简称（比如glibccomm.rpm），“-”一定要去掉。当时我看到显示器上显示的名字有乱码和问号。猜到了是哪个包，后悔之前没有重命名。替换静态库文件，然后手动cp命令替换/lib和/usr/lib的静态库（*.a文件）。cp/home/libpthread.a/libcp/home/*.a/usr/lib修改动态库软链接手动修改动态库软链接无论安装rpm包时是否自动修改软链接，最好手动修改。进入/lib目录，先rm*2.9*#删除高版本库再ln-sflibutil-2.3.4.solibutil.so.1ln-sflibresolv-2.3.4.solibresolv.so.2ln-sflibnss_nis-2.3.4.solibnss_nis.so.2ln-sflibnss_nisplus-2.3.4.solibnss_nisplus.so.2ln-sflibnss_hesiod-2.3.4.solibnss_hesiod.so.2ln-sflibnss_files-2.3.4.solibnss_files。so.2ln-sflibnss_dns-2.3.4.solibnss_dns.so.2ln-sflibnss_compat-2.3.4.solibnss_compat.so.2ln-sflibnsl-2.3.4.solibnsl.so.1ln-sflibdl-2.3.4.solibdl.so.2ln-sflibcrypt-2.3.4.solibcrypt.so.1ln-sflibBrokenLocale-2.3.4.solibBrokenLocale.so.1ln-sflibanl-2.3.4.solibanl.so.1ln-sflibc-2.3.4.solibc.so.6ln-sflibrt-2.3.4.solibrt.so.1ln-sflibpthread-0.10.solibpthread.so.0ln-sflibm-2.3。4、solibm.so.6跳回光驱系统执行exit跳回光驱系统，在上图中光标处再次输入exit，回车，系统重启。马上修改BIOS，设置系统从硬盘启动，原来的系统可以正常启动。成功营救萨华，很有成就感！也可以试试其他的操作把服务器弄下来，只要能把那个操作再反过来，问题不大。为什么不重新加载？上面部署的东西都是很多年前的东西了，物是人非，没办法从头再来。为什么敢升级？亲眼看到别人升级RHEL6.6的glibc，没有任何反应。我真的不知道会有这么严重的问题。如果您没有相同版本的光盘，一张相近的光盘就可以了。我实际使用的光盘是RHEL4.6，比原来的系统体积小。如果你能拿到rpm和.a文件，就不用按照本文的方法了。网友提供的替换so的解决方案不靠谱，必须用rpm安装。2.3不能升级到2.9，但不代表不能升级到2.4。如果版本接近，可能会成功。这个服务器还在运行，那些jar包已经部署到其他服务器上了。
