Bug 833629 - Bootup halts at "starting wait for storage scan" on iMac 27 inch with 3.4 kernel
Summary: Bootup halts at "starting wait for storage scan" on iMac 27 inch with 3.4 kernel
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-19 22:43 UTC by Basil Mohamed Gohar
Modified: 2013-03-14 19:18 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-03-14 19:18:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
boot.log (10.01 KB, text/plain)
2012-06-19 22:45 UTC, Basil Mohamed Gohar
no flags Details
smolt information (3.09 KB, text/plain)
2012-06-19 22:47 UTC, Basil Mohamed Gohar
no flags Details

Description Basil Mohamed Gohar 2012-06-19 22:43:56 UTC
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.

Comment 1 Basil Mohamed Gohar 2012-06-19 22:45:16 UTC
Created attachment 593094 [details]
boot.log

This is my latest boot.log.

Comment 2 Basil Mohamed Gohar 2012-06-19 22:47:43 UTC
Created attachment 593095 [details]
smolt information

Comment 3 Basil Mohamed Gohar 2012-06-19 22:48:34 UTC
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.

Comment 4 Basil Mohamed Gohar 2012-06-27 14:27:04 UTC
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.

Comment 5 Basil Mohamed Gohar 2012-07-05 16:46:46 UTC
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.

Comment 6 Basil Mohamed Gohar 2012-07-20 14:45:37 UTC
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.

Comment 7 Eric Gerney 2012-08-06 16:30:31 UTC
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?

Comment 8 Eric Gerney 2012-08-14 20:35:38 UTC
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.

Comment 9 Basil Mohamed Gohar 2012-08-14 20:55:35 UTC
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.

Comment 10 Eric Gerney 2012-08-20 17:43:42 UTC
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?

Comment 11 Nathan Kohagen 2012-08-23 06:21:44 UTC
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)

Comment 12 Josh Boyer 2013-03-14 18:27:59 UTC
Is this still happening with 3.8.2 from updates-testing and the latest F17 updates?

Comment 13 Basil Mohamed Gohar 2013-03-14 19:09:30 UTC
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. :(

Comment 14 Josh Boyer 2013-03-14 19:18:06 UTC
Thank you for letting us know.


Note You need to log in before you can comment on or make changes to this bug.