https://bugzilla.kernel.org/show_bug.cgi?id=60758 Lin Feng <linf@xxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linf@xxxxxxxxxxxxxxxxxx --- Comment #50 from Lin Feng <linf@xxxxxxxxxxxxxxxxxx> --- Hi all, I got exactly the same problem on a CentOS 6.4 64bit kvm guest. That's while trying to update my kenrel to mainline 3.13-rc5 console repeat writing "FATAL: Module scsi_wait_scan not found." and finally panic. The whole output graph is maily same as pasted by Vincent Li. After tracking this bugzilla I get the thought that the dracut mismatch with the kernel. Since kerne 3.6 and following have dropped scsi_wait_scan module but CentOS6.4's dracut is hardcoded to add the instruction "modeprobe scsi_wait_scan" into /init script in initramfs image. So I tried following approaches for confirmation: 1. Update kernel to 3.5(it still holds the scsi_wait_scan module): it boots find. 2. Update the dracut to the latest version in git tree, since it has removed the redundant "modeprobe scsi_wait_scan" for building 3.6 and later kernels but it doesn't work, telling me that could not find root device like pasted in step3. 3. Decompress the initramfs and modify the /init script by removing the line "modeprobe scsi_wait_scan" but it doesn't work neither: (snips) dracut Warning: No root device "block:/dev/disk/by-uuid/cedcbd9c-32eb-4a3f-9dad-ae5fc560642a" found dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line. dracut Warning: Signal caught! dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line. Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 CPU: 1 PID: 1 Comm: init Tainted: GF 3.13.0-rc5 #6 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff88005dbf9d98 ffffffff8156c92b 000000000000fffe ffffffff817dd350 ffff88005dbf9e18 ffffffff8156c6b8 ffffffff00000010 ffff88005dbf9e28 ffff88005dbf9dc8 ffff88005dbdf7b8 ffff88005dbf9dd8 Call Trace: [<ffffffff8156c92b>] dump_stack+0x49/0x5e [<ffffffff8156c6b8>] panic+0xbb/0x1d5 [<ffffffff8104e75b>] find_new_reaper+0x17b/0x180 [<ffffffff8104f8e5>] forget_original_parent+0x45/0x1c0 [<ffffffff8111e1f0>] ? perf_cgroup_switch+0x180/0x180 [<ffffffff8104fa77>] exit_notify+0x17/0x130 [<ffffffff8104fd7e>] do_exit+0x1ee/0x480 [<ffffffff81050061>] do_group_exit+0x51/0xc0 [<ffffffff810500e7>] SyS_exit_group+0x17/0x20 [<ffffffff81579212>] system_call_fastpath+0x16/0x1b ------------------------------------------------------------------------------- >From 2 and 3 it seems that scsi_wait_scan is necessary in some cases, like H87 board and my KVM case. Any idea, Can anyone tell me how to move on? Thanks in advance. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
