前言

上周帮用户处理了一个 linux 虚拟机在重启后无法正常进入操作系统的故障，觉得比较有意思，在这里分享给大家。

1. 故障描述

事情的起因是一台系统版本为 CentOS 7.2 的 VMware 虚拟机出现了 ssh 登录报错，然后客户就想着通过重启操作系统的方式看看能否解决问题，结果发现重启后操作系统直接就起不来了，卡在如下所示界面：

在这里插入图片描述

故障表现即：不管怎么重启虚拟机，最后都会卡在 Starting Switch Root... 这里，在等待较长时间后会提示 Failed to execute /bin/sh, giving up: No such file or directory。

2. 故障诊断

Step1：在接到客户的消息时，我脑海里第一时间想到了如下几种可能性：

系统 Crash 了？
系统 /etc/fstab 文件中某些设置了开机自动挂载的项挂载失败了？
磁盘或者分区出现了坏块？

Step2：联系客户发起远程，由于客户也不清楚系统在发生故障前都做了哪些操作，所以想着还是先进单用户模式做个初步排查，结果在执行 chroot /sysroot 时出现了如下报错：

在这里插入图片描述

到这一步时我开始觉得这个故障的原因和我一开始想象的不一样了，因为之前处理过的一些故障，还从来没有遇到过进单用户模式在切换根环境变量时出现报错。

Step3：既然单用户模式在切换根环境变量时报错，我想着那进救援模式是不是也会报错呢？接下来就让用户挂载了一个 CentOS 7 版本的镜像进救援模式，果然不出所料，在执行 chroot /mnt/sysimage 切换根环境变量时也出现了如下报错：

在这里插入图片描述

Step4：接下来就是要检查 /bin/sh 和 /bin/bash 两个文件是否存在，查询完发现系统提示没有该文件：

在这里插入图片描述

特别说明：这里有个点需要注意下，因为不管是单用户模式还是救援模式，我们其实都没有成功切换到系统的根环境变量下来，所以在查询时一定要注意你查看的是 iso 救援模式系统的信息还是故障主机的系统信息。如上图所示，编号为1的地方我们查看的信息就是 iso 救援模式系统的，而编号为2的地方查看的才是故障主机系统的信息，由此可以判断，原系统里面就是缺少了 /bin/sh 和 /bin/bash 两个文件。

Step5：带着关键报错信息和疑问去网上查了一些资料，类似的故障案例里面有说是因为 /lib64 的软链接异常导致的，后面看到了红帽官网的《Kernel panicked on boot and ‘chroot /mnt/sysimage’ command in rescue mode fails with ‘chroot failed to run command /bin/sh no such file or directory’ error》这篇 KB 文章。

1）首先我查看了下 /lib64 的软链接信息，发现软链接是正常的（此时我以为是正常的，其实被误导了，后面会说）：

sh-4.2# ls -l /mnt/sysimage

在这里插入图片描述

2）紧接着我又查看了下 /bin 目录的信息（此时我还以为是正常的，呵呵）：

在这里插入图片描述

3）接着我按照红帽官方 KB 所提供的步骤去做检查：

在这里插入图片描述

敲重点：终于在这一步我发现了问题，因为前面的检查让我认为不管是 /lib64 的软链接还是 /bin 的软链接都是正常的，但是当我在执行 /mnt/sysimage/lib64/ld-linux-x86-64.so.2 命令时发现 ld-linux-x86-64.so.2 居然不能自动补全，此时我开始怀疑：虽然软链接看似存在，但是源文件 /usr/lib64 可能缺少了；再联想到 /bin 目录也从 /usr/bin 软链接过来的，但前面查询时明明提示 /bin/sh 和 /bin/bash 两个文件也是不存在的；基于此，我愈发觉得可能是 /usr 目录有异常。

Step6：检查发现原系统的 /usr 目录下除了一个 local 目录，其余啥也没有，此时终于找到“罪魁祸首”了，就是因为 /usr 目录下的其它文件被删除了，所以即使 /lib64 的软链接和 /bin 的软链接看着都正常，但其实已经失效了。

在这里插入图片描述

故障原因已经定位到，接下来就是该如何解决问题了。

3. 故障原因

系统 /usr 目录下的文件被删除，导致很多从 /usr 目录下的文件创建的软链接失效，如 /usr/lib64 和 /usr/bin 等，从而出现 ssh 登录报错，甚至重启后无法进入操作系统。

系统 ssh 服务依赖的关键文件主要位于 /usr/sbin/sshd 和 /usr/lib64，因此系统 /usr 目录下的文件被删除，ssh 肯定会受到影响；其次，登录系统所需的 bashshell 通常位于 /usr/bin/bash，这也是为什么系统在重启后会卡在 Starting Switch Root... 这里进不去，而在单用户以及救援模式下我们也无法切换到根环境变量下。

除此之外，用户环境配置所需的很多工具如 ls、grep 等命令都在 /usr/bin 下，所以当 /usr 目录下的文件被删除，在使用这些命令时肯定也会报错的（后面我自己复现了故障并进行了验证）。