这篇文章帮了我的大忙了：转载自：http://wilber82.blog.51cto.com/1124820/724472
今天在做服务器补丁部署，有一台ESX4.1的服务器在升级后重启过程中挂了，通过iLO口登陆看到如下信息：
|
fsck.ext3: Unable to resolve 'UUID=34d192db-17eb-442e-9613-c5c24c6fa9fa' And *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. |
意识到这肯定和磁盘文件系统有关系，对于我等Linux菜鸟，当时及瘫倒在地，不知所措。
其实这个问题是由于升级过程中发生了某些问题导致的，VMware暂时没有给出Cause Root，但是有临时解决办法。
先收集必要的信息：
遇到这种情况后，输入root密码进入修复模式（此时即便重启，也无法正常使用，也无法进入排错模式）。
输入命令fsck，列出文件系统信息：
记录每个“Unable to resolve”后边的字符串，这是对应挂载点的UUID。
输入命令cat /etc/fstab，列出文件系统表信息：
|
UUID=79815890-f11c-4907-80fe-d1cd6bf061f8 / ext3 defaults 1 1 |
根据你的每个UUID找到对应的挂载点，例如上表中列出的。
输入命令ls -l /dev/disk/by-uuid，列出磁盘跟UUID关系：
|
total 0 lrwxrwxrwx 1 root root 10 Nov 9 14:36 45460133-027b-40b6-8b4d-e52aaf4c417f -> ../../sdm1 lrwxrwxrwx 1 root root 10 Nov 9 14:36 e32ec5f4-d795-414a-8d73-a2bb3ea86342 -> ../../sdr1 lrwxrwxrwx 1 root root 10 Nov 9 14:36 34d192db-17eb-442e-9613-c5c24c6fa9fa -> ../../sdr2 lrwxrwxrwx 1 root root 10 Nov 9 14:36 79815890-f11c-4907-80fe-d1cd6bf061f8 -> ../../sdr5 |
找到对应的磁盘名称，例如上表"../../sdr2"就代表"/dev/sdr2"。
依次记录每个有问题的UUID和其对应的磁盘名称、挂载点名称。
下面是修复阶段：
- 给有问题的挂载点重新生成新的UUID。
运行如下命令，再次确认UUID：- # tune2fs -l 磁盘名称 | grep UUID
磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"
运行如下命令，生成新的UUID
- tune2fs -U random 磁盘名称
磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"
运行如下命令，验证是否已生成新UUID：
- # tune2fs -l 磁盘名称 | grep UUID
磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"
对每个有问题的挂载点运行如上命令，并记录新的UUID。
- 更新文件系统表。
运行如下命令，将根挂在为可读写：
- mount / -o remount,rw
-
运行如下命令，打开fstab进行编辑，我们要把这个表里旧的有问题UUID换成新的UUID。
具体修改方法，找到旧的的UUID，直接删除写入新的UUID即可。最后别忘了保存！- vi /etc/fstab
运行如下命令，将根挂载为只读：
- mount / -o remount,ro
- 重启服务器。
运行如下命令，重启服务器：
- shutdown -r now
另外一种简单的解决方法，重做系统....
以上解决方法我已经在生产环境下的ESX4.1使用过。
注意：如果出错的文件系统与重要数据有关，最好小心一点儿，先备份数据，把共享的存储关闭掉。