Red Hat Bugzilla – Bug 833629
Bootup halts at "starting wait for storage scan" on iMac 27 inch with 3.4 kernel
Last modified: 2013-03-14 15:18:06 EDT
Description of problem: When attempting to boot up the system with the 3.4 kernels, progress halts with the message "starting wait for storage scan". This is not a problem with 3.3.4, but it is with 3.40.0 and 3.4.2. Version-Release number of selected component (if applicable): 3.4 & 3.4.2 How reproducible: Happens every time Steps to Reproduce: 1. Set grub to choose a kernel boot image of 3.4 or 3.4.2 2. Restart the computer 3. Get tired of waiting (overnight) for system to finish booting up. Actual results: System pauses during bootup Expected results: System proceeds smoothly and quickly through bootup Additional info: I will attach some info in follow-up comments, I'm posting this from another computer.
Created attachment 593094 [details] boot.log This is my latest boot.log.
Created attachment 593095 [details] smolt information
I'd be happy to provide any other information that would be useful in finding the source of this error. For what it's worth, I get a feeling that it's related the HFSplus filesystem on the EFI boot partition.
I just wanted to follow-up and say that this is still an issue with kernel-3.4.3-1.fc17.x86_64. I'm not sure if it's directly related to the kernel or if it's something to do with the EFI boot partition not being properly updated during the kernel's install routines, which is also a possibility.
This remains an issue for kernel-3.4.4-3.fc17.x86_64. Please let me know what else I can provide that would be useful for fixing this issue.
I can confirm this with the 3.4.5 kernel update as well. And it is still booting up on the 3.3 kernel as long as that is an option, but too many kernel updates pushes 3.3 off the boot list, even though the kernel is still installed, so the system effectively becomes unbootable at all.
I don't believe this is iMac or kernel 3.4.5 specific. I'm unable to successfully boot kernel-PAE-3.5.0-2.fc17.i686, whereas kernel-PAE-3.4.6-2.fc17.i686 boots without issue. When I attempt to boot int 3.5.0, systemd hangs at fedora-wait-storage.service and drops you into emergency mode. Poking around in there shows the lv_home LV to be 'NOT available'. The device file dm-2 is not there. lv_swap and lv_root are fine. Running lvm vgchange -ay appears to make it available, however, I don't know how to get to a workable system state from there. My next step is to debug systemd to see if I can glean something about what's failing. Is there any other information that I should be looking for to track this down?
This issue was also repeated with kernel 3.5.1-1.fc17.i686.PAE... system wouldn't boot, hung at fedora-wait-storage.service. I was able to correct it with the following two changes: 1) Specifically adding the unavailable LV to the kernel cmd line: rd.lvm.lv=vg_ejg/lv_home lv_swap and lv_root are also there, so this was a sucessful guess. 2) Add rd.blacklist=scsi_wait_scan to the kernel cmd line. It's inserted, removed and inserted again by fedora-wait-storage.service. This module appears to be causing two issues. First, an external USB drive identified via this fstab entry: # Maxtor 150 GB - USB UUID=12476f3f-9cd4-41da-b225-37ce8a2a1672 /media/maxtor ext3 noatime 0 0 ...would fail. Second, the associated LV block device above was removed. Again, I don't know the specifics, but these two changes permits me to boot 3.5.1-1.fc17.i686.PAE without issue.
I don't know if we're having the same issue or not, because I am not using LVM at all, and I unplugged my only external storage on this computer, and it still has the problem booting (but on kernel 3.5.0-2, I haven't successfully booted to get the 3.5.1 kernel). I also tried blacklisting the scsi_wait_scan module as mentioned above, and I still get the "Starting Wait for storage scan..." at the end.
Agreed. My issue has been reported by another user as bug # 848149. Is your dracut udevd issuing a stack trace prior to systemd starting up?
After installing kernel-3.5.x, I encountered the same problem - my boot stalled on fedora-wait-storage.service. I did the magic sysrq (Alt-Sysrq REISUO), rebooted with my 3.4 kernel, and the following command fixed the problem: systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service I can now boot the 3.5.x kernel. That only works if you didn't install your system on top of LVM or RAID. (source: http://freedesktop.org/wiki/Software/systemd/Optimizations)
Is this still happening with 3.8.2 from updates-testing and the latest F17 updates?
I long since stopped using that hardware and it is no longer in my possession. Someone else in my company is using it, and MacOS is back on it. :(
Thank you for letting us know.