注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Wei Ding blog

 
 
 

日志

 
 

升级后重启造成fsck.ext3: Unable to resolve UUID(转载)  

2014-10-22 19:13:20|  分类: linux |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
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.

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使用过。 
注意:如果出错的文件系统与重要数据有关,最好小心一点儿,先备份数据,把共享的存储关闭掉。

本文出自 “Wilber82” 博客,请务必保留此出处http://wilber82.blog.51cto.com/1124820/724472

  评论这张
 
阅读(514)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017