linux窗口叉号不显示,linux因勿删或误操作导致登录界面异常，命令无法使用，显示/bin/bash:No such file or directory...

一、故障现象

1、用secure CRT连接服务器时显示：

/bin/bash:No such file or directory

翻译成中文是：没有此类文件或目录

2、直接登录服务器执行命令时显示：

/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

翻译成中文大概的意思是：找不到/lib/ld-linux-x86-64.so.2文件

只有cd命令可以正常使用

二、故障原因

1、背景介绍

此服务器需要源码安装zabbix，而源码安装需要安装很多包，所以必须通过yum安装，在服务器上配置了yum之后是可以使用的，但只能装一些简单的包，只要依赖到glibc和gcc这种系统包时就会报错，比如安装net-snmp-devel这个包的时候就会报错，错误如下：

百度了下这个错误

上面这两条意思是说glibc-devel和glibc-headers缺少需要的glibc包

duplicate的意思是重复，意思是说上面这两个包有重复

关于重复包这个问题，在网上找了解决办法，但是没有成功，下图是解决办法：

上述两条命令是为了移除重复的rpm包，在服务器上照着执行，无果，错误依旧

因为yum报错的原因大概都是由于glibc包的问题，查看本机安装的glibc相关包：

看到这些包的小版本号各种对不上，于是想在官网下一个对应的glibc包安装试试是否可行，于是到centOS的官网找到对应的glibc包：

于是下载安装此包

安装的时候发现这个包也是有依赖包，yum又不能使用，就加了一个参数--nodeps(不检查依赖关系) –force(强制安装)执行安装，也就有了后面的系统奔溃了

2、原因推测

强制安装并且不检查依赖关系这两个参数的添加可能导致系统本身的glibc软件包损坏或者是覆盖掉本身的glibc包，总之是本身的glibc包不能正常使用了，除了cd，所有的命令都不能使用了，但是系统上的程序并不影响，nmsweb依旧可以访问

三、故障处理

1、前提条件

奔溃的服务器必须有挂载的镜像或者系统光盘，目的是要复制镜像里的或者系统光盘里的glibc包到奔溃的服务器里

2、 处理过程

2.1 重启系统后进入安装启动菜单，上下键移动到Rescue install system 救援安装系统:

2.2  等待系统加载完内核：

2.3 选择操作语言(一般是english):

2.4 选择键盘模式(US)：

2.5 是否启动网络(建议不启动)：

2.6 系统询问是否将系统以读写或只读模式挂载到/mnt/sysimage(别无选择)：

2.7 系统再次询问是否将原操作系统挂载到/mnt/sysimage

2.8 成功进入linux救援模式

2.9 查看原操作系统的文件

2.10  RHEL5.5默认/dev/hda是光驱镜像(CentOS默认的光驱镜像是/dev/cdrom)

挂载光驱到/mnt/source下，并查看光驱内容

下图是RHEL5.5的操作方法，如果是CentOS系统的话应该是

mount /dev/cdrom /mnt/

2.11挂载好之后进入/mnt/packages目录下，就可以看到所有系统包了。将glibc相关rpm包复制到/root家目录

2.12  使用rpm2cpio命令将glibc-2.5-49.x86_64.rpm包制作成repo格式的文件

2.13 在/mnt/sysimage/root下创建util文件夹，然后cd util，再执行cpio -idcuv< ../util.repo进行util.repo的解压，在/mnt/sysimage/root/util/可以看到libx64，将其中所有文件复制到/mnt/sysimage/libX64下

2.14  注意：执行下图中的cp命令会报一个错：cp : omitting directory `rtkaio`，这个错误是因为复制的目录下面还有子目录，但是并不影响，可以跳过这个错误

2.15  执行chroot /mnt/sysimage (较难理解)

为什么要执行这个命令？原因是因为救援模式下启动的是一个基本的文件系统，就是ramdisk里的文件系统，并没有切换到本机硬盘上的“真正”文件系统，而是把磁盘上的根文件系统以只读的方式挂载在sysimage上,而chroot 则是手动切换到磁盘上的文件系统，只不过正常情况下，这个过程是自动的，而救援模式下就相当于把这一步给你省略了，所以得手动切换。

2.16 重新安装原操作系统镜像中的glibc包

2.17 然后重启系统完成glibc重装后的恢复操作

四、 故障总结

1、处理心得

在平时的工作中，面对生产环境要小心再小心，虽然这次奔溃事件没有耽误工作完成时间，却也是让人后怕的，因为如果不能顺利解决这个事情，有可能会重装系统，如果系统有诸多的程序，那可能也要付之东流了，这件事情也告诉我们有一个干净的系统是多么重要，如果系统之前没有安装那些低版本高版本的系统包，yum也就能正常安装，所以以后涉及到系统包的，一定要慎之又慎，切不可重蹈覆辙！

2、glibc、gcc、binutils的作用

gcc(gnu collect compiler)是一组编译工具的总称。它主要完成的工作任务是“预处理”和“编译”，以及提供了与编译器紧密相关的运行库的支持，如libgcc_s.so、libstdc++.so等。

binutils提供了一系列用来创建、管理和维护二进制目标文件的工具程序，如汇编(as)、连接(ld)、静态库归档(ar)、反汇编 (objdump)、elf结构分析工具(readelf)、无效调试信息和符号的工具(strip)等。通常，binutils与gcc是紧密相集成 的，没有binutils的话，gcc是不能正常工作的。

glibc是gnu发布的libc库，也即c运行库。glibc是linux系统中最底层的api(应用程序开发接口)，几乎其它任何的运行库 都会倚赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现