安装glibc错误链接导致系统崩溃，u盘启动紧急救援模式下修复系统。
Posted 篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了安装glibc错误链接导致系统崩溃，u盘启动紧急救援模式下修复系统。相关的知识，希望对你有一定的参考价值。 Sln 命令 创建动态符号链接 用法 sln source dest 故障案例：一个误操作 导致了一个不小的故障，输入所有命令都无效，直接系统无法启动。 执行完此命令后各种命令都不在管用。 重启后，这个圈圈无休止的转啊转的，直接无法启动系统。 最好镜像选择跟故障系统版本一致的镜像，此时需要制作一个 centos系统的启动u盘，这个参考百度知道。 使用+号 调节选项顺序 我们将+Hard Drive 调到第一个 设备标识符 我们选择0:1的这个，因为我的u盘挂载的标识也是这个。 按F10 回车后进入这个界面 选择第三个的 Troubleshooting 进入下面界面 进入第二个 救援centos系统 rescure a centos system 输入 1 回车----然后有个return字样的 再按一次回车。 说明：此时的根目录是挂载的u盘启动的镜像的根目录，而原来的故障系统的根目录已经变成/mnt/sysimage/ 其实 原本系统的 /lib64/ 目录其实是 /usr/lib64 的一个软连接 访问/lib64 其实就是指向/usr/lib64/ 这个目录 这个是u盘启动的镜像 lib64目录下的 ld库文件 而原本的故障系统内的 ld库文件发现 ld-2.17.so这个已经没有了。 那就直接将u盘镜像内的所有ld库文件复制到 故障系统的相应 lib64目录下 然后 exit 重启 调节启动顺序，恢复成调节前的样子。 重启后， 重启后命令什么的恢复正常使用 总结：血的教训啊，lib库下面的库文件千万别随便更改设置链接等等操作，后果很严重、这一个命令操作 虽然不如 rm –fr /* 这样毁天灭地，不过破坏性也是够强的。 以上是关于安装glibc错误链接导致系统崩溃，u盘启动紧急救援模式下修复系统。的主要内容，如果未能解决你的问题，请参考以下文章 CentOS误删除glibc导致系统系统一系列错误的解决办法故障描述
sln /usr/lib64/ld-linux-x86-64.so.2 /usr/lib64/ld-2.17.so
[root@localhost ~]# sln /usr/lib64/ld-linux-x86-64.so.2 /usr/lib64/ld-2.17.so
Invalid link from "/usr/lib64/ld-linux-x86-64.so.2" to "/usr/lib64/ld-2.17.so": Too many levels of symbolic links
[root@localhost ~]# ls
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
[root@localhost ~]# ifconfig
-bash: /usr/sbin/ifconfig: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
[root@localhost ~]# ll
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
安装linux的启动u盘
设置 bios 默认u盘启动
救援模式
拷贝修复ld库文件
