今天在做服务器补丁部署，有一台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.

Original UUID

意识到这肯定和磁盘文件系统有关系，对于我等Linux菜鸟，当时及瘫倒在地，不知所措。
其实这个问题是由于升级过程中发生了某些问题导致的，VMware暂时没有给出Cause Root，但是有临时解决办法。

先收集必要的信息：
遇到这种情况后，输入root密码进入修复模式（此时即便重启，也无法正常使用，也无法进入排错模式）。
输入命令fsck，列出文件系统信息：

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。 
    Repaire p_w_picpaths
     
  • 更新文件系统表。 
     运行如下命令，将根挂在为可读写：
 
  
 
  
  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使用过。 
注意：如果出错的文件系统与重要数据有关，最好小心一点儿，先备份数据，把共享的存储关闭掉。