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

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

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

你可能感兴趣的:(vmware,排错,esxi,vsphere,esx)