Bug 476472 - mkinitrd produces initrd unusable with disks serviced by aic7xxx module
mkinitrd produces initrd unusable with disks serviced by aic7xxx module
Status: CLOSED DUPLICATE of bug 466607
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-14 22:47 EST by Michal Jaegermann
Modified: 2008-12-15 04:17 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-15 04:17:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-12-14 22:47:03 EST
Description of problem:

Mystery!! There are no problems with a disk access during an installation and/or upgrade and resulting system does not boot because disks cannot be found. Again, there is not a whiff of a problem when booting the same system "rescue".

After a prolonged head scratching and hacking initrd images the situation turns out to be as follows.  Disks are serviced by Adaptec AIC7XXX controller and dmesg shows the following picture:

<6>aic7xxx 0000:01:03.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input3
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec aic7892 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi 0:0:0:0: Direct-Access     FUJITSU  MAP3367NC        0108 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 4
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: wide asynchronous
scsi: waiting for bus probes to complete ...
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
scsi target0:0:0: Ending Domain Validation

That "Domain Validation" happens regardless if it is turned off in BIOS, or not, and it takes a rather long time.  A controller is also not in a hurry at all to get to "Beginning Domain Validation" point.  In the meantime initrd attempts to create disk block devices and mount /.  Disks are really not available yet, and it will be not for quite a while, so this miserably fails.

Anaconda does a number of other things after 'aic7xxx' was inserted so when it attempts to find disks they are already there and everything is fine.

When looking how to hack /sbin/mkinitrd script to produce something usable I found that there is 'scsi_wait_scan' module, and it can be configured in with a help of a, non-existent, file /etc/sysconfig/mkinitrd and, as it turned out,
it solves the problem.  Now initrd waits for disks to show up before attempting
to use these (for a possible resume device and for a root file system).  I would not mind seeing that documented instead of having to figure that out from /sbin/mkinitrd shell code.

Would not be better to default to scsi_wait_scan="yes" if there are any disk scsi modules involved?  An extra boot delay in some cases surely beats a non-booting machine.  I strongly suspect that this is not the only controller and a situation which would need that.  A configuration option could turn that scsi_wait_scan off it really not required.

Version-Release number of selected component (if applicable):
mkinitrd-6.0.71-2.fc10

How reproducible:
always
Comment 1 Michal Jaegermann 2008-12-14 22:48:40 EST
BTW - Fedora 8, from which this system was upgraded, was booting "straight" - without any extra mkinitrd tricks.
Comment 2 Warren Togami 2008-12-14 23:36:32 EST
Please try the new mkinitrd build in Bug #470628.
Comment 3 Michal Jaegermann 2008-12-15 01:34:37 EST
With updates to mkinitrd-6.0.71-3.fc10.i386 and nash-6.0.71-3.fc10.i386 I see the  following sequence in 'init' from initrd image produced with a help of those:

 .....
 modprobe -q scsi_transport_spi
 echo "Loading aic7xxx module"
 modprobe -q aic7xxx
 modprobe scsi_wait_scan
 rmmod scsi_wait_scan
 mkblkdevs
 .....

regardless if /etc/sysconfig/mkinitrd with 'MODULES=scsi_wait_scan' line exists or not.  This is really equivalent to what I eventually forced with mkinitrd-6.0.71-2.fc10 so, yes, I am convinced that this works.  I am afraid that I will not risk rebooting that in this moment as a stricken machine is for me remote.

Actually with /etc/sysconfig/mkinitrd present I got two extra lines after 'modprobe -q aic7xxx'.  These:

 echo "Loading scsi_wait_scan module"
 modprobe -q scsi_wait_scan

but that amounts to the same as above so this will be fixed in the future update.

It appears that I was running an upgrade too early.
Comment 4 Hans de Goede 2008-12-15 04:17:53 EST
This bug has already been reported, so I'm closing this as a dup of the earlier report.

*** This bug has been marked as a duplicate of bug 466607 ***

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