一、故障现象
现网一台suse11 sp3主机发生异常宕机后，在IBM IMM管理口中查看发现有硬件报错，经IBM维护人员确认为主板问题。冷重启后主机可以正常进入系统，后来在更换主板后，发现主机无法正常启动，提示“ waiting for device to appear ” ，回退使用老的主板后，报错依旧。本篇将该问题的处理修复过程记录下。报错界面如下：
通过光盘引盘进入修复模式，查看到系统上的fstab配置为：
# cat /etc/fstab.bak
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part2 swap swap defaults 0 0
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part1 / ext3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part3 /boot ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part8 /home ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part11 /onip/teastore ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part5 /opt ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part10 /teasredo ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part7 /tmp ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part9 /usr ext3 acl,user_xattr 1 2
/dev/disk/by-id/scsi-3600507605b40d5e91d00a6a210f2b49e-part6 /var ext3 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
UUID=ab3be7bb-498e-442f-99d6-2d1389082e57 /teasdata ext3 defaults 0 0
二、故障处理与分析
1、从故障提示上来看有"could not find xxx分区" ，这里想通过修复模式查看下分区信息。发现选择failsafe模式并设置init=/bin/bash引导后，依旧出现该报错；
2、使用SuSE linux光盘挂载进入rescue修复模式时，发现无法正常发现分区；
3、改用redhat6.3 光盘引导进入修改模式后，发现可以正常发现分区。ls /dev/disk/by-id下发现磁盘的scsi id号发生了变化
# ls /dev/disk/by-id/scsi*
scsi-3600507605b40d5e9ff00007907615ef2 scsi-3600507605b40d5e9ff00007907615ef2-part1
scsi-3600507605b40d5e9ff00007907615ef2-part10 scsi-3600507605b40d5e9ff00007907615ef2-part11
scsi-3600507605b40d5e9ff00007907615ef2-part2 scsi-3600507605b40d5e9ff00007907615ef2-part3
scsi-3600507605b40d5e9ff00007907615ef2-part4 scsi-3600507605b40d5e9ff00007907615ef2-part5
scsi-3600507605b40d5e9ff00007907615ef2-part6 scsi-3600507605b40d5e9ff00007907615ef2-part7
scsi-3600507605b40d5e9ff00007907615ef2-part8 scsi-3600507605b40d5e9ff00007907615ef2-part9
scsi-3600e0eca0468bfa8ff0008317d2914e9
备份/etc/fstab后，更改/etc/fstab内的挂载点信息为当前查看到的信息，并将最后的挂载点最后1 2修改为0 0 (1 2 表示开机自检，如果检测到错误可能会无法启动，之前现网中遇到这样的问题，所以初始也怀疑是该问题引起的)，重新引导发现还是出现刚刚的报错。
4、引导修复的过程中，从SuSE站点是看到类以的报错信息 －－－ Booting SLES11SP1 aborts with waiting for device to appear 。
5、按照SuSE页面提示，再启使用redhat6.3镜像引导进入修复模式，挂载原系统分区后，使用mkinitrd 重新生成ram img文件/boot/vmlinuz-3.0.76-0.11-default后，再引重启引导，主机停留下fall back appear 信息界面时，让选择 Y/N ，此处选择yes后，主机正常引导并进入系统，业务人员检查发现业务启动正常。
三、故障原因及后续分析
1、让SuSE确认是否为系统bug
后续联系SuSE二线建单确认后 ，SuSE给予的答复是在SuSE 11 SP3下不是系统bug，在SuSE官方资料库中有相关案例记载，在更换硬件或升级内核等操作时，在重启时可能会出现该问题。
2、是否可以通过在/etc/fstab中使用UUID规避该问题
SuSE给予的答复是：更改fstab没有用，主要是需要更新initrd文件内的信息。这也是为什么要执行mkinitrd的原因。