升级后重启造成fsck.ext3: Unable to resolve UUID

这篇文章帮了我的大忙了：转载自：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=45460133-027b-40b6-8b4d-e52aaf4c417f /boot    ext3    defaults                  1 2 
None                    /dev/pts                   devpts  defaults                  0 0 
/dev/cdrom              /mnt/cdrom                 udf,iso9660 noauto,owner,kudzu,ro 0 0 
/dev/fd0                /mnt/floppy                auto    noauto,owner,kudzu        0 0 
None                    /proc                      proc    defaults                  0 0 
None                    /sys                       sysfs   defaults                  0 0 
UUID=34d192db-17eb-442e-9613-c5c24c6fa9fa /var/log ext3    defaults,errors=panic     1 2 
UUID=e32ec5f4-d795-414a-8d73-a2bb3ea86342 swap     swap    defaults                  0 0 

根据你的每个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：
  1. # tune2fs -l 磁盘名称 | grep UUID 

  磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"

   

  运行如下命令，生成新的UUID

  1. tune2fs -U random 磁盘名称 

  磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"

   

  运行如下命令，验证是否已生成新UUID：

  1. # tune2fs -l 磁盘名称 | grep UUID 

  磁盘名称 - 即你要修复的磁盘名称，例如上面表述中的"/dev/sdr2"

   

  对每个有问题的挂载点运行如上命令，并记录新的UUID。 
  

• 更新文件系统表。 
  运行如下命令，将根挂在为可读写：

1. mount / -o remount,rw 

• 运行如下命令，打开fstab进行编辑，我们要把这个表里旧的有问题UUID换成新的UUID。 
  具体修改方法，找到旧的的UUID，直接删除写入新的UUID即可。最后别忘了保存！

  1. vi /etc/fstab 

  运行如下命令，将根挂载为只读：

  1. mount / -o remount,ro 

• 重启服务器。 
  运行如下命令，重启服务器：

1. shutdown -r now  

另外一种简单的解决方法，重做系统.... 
以上解决方法我已经在生产环境下的ESX4.1使用过。 
注意：如果出错的文件系统与重要数据有关，最好小心一点儿，先备份数据，把共享的存储关闭掉。