Bug#596015: initramfs-tools: provide support for scsi_wait_scan

[maximilian attems <max@stro.at>]

On Wed, 08 Sep 2010, Michael Prokop wrote:

> 
> scsi_wait_scan is a kernel module that waits until all the async
> scans are complete.
> 
> Debian kernel as well as the ones from other Debian based distros
> usually have this stuff compiled as a kernel module and not
> statically into the kernel (which is good, because under certain
> conditions scsi_wait_scan *could* fail maybe, and disabling the
> compiled in driver doesn't seem to be possible).

known.

~/src/initramfs-tools$ egrep scsi_wait_scan /usr/share/initramfs-tools/scripts/init-top/udev 
        modprobe -q scsi_wait_scan && modprobe -r scsi_wait_scan || true

 
> I just got a bugreport against Grml, stating that Grml as well as
> Debian and Ubuntu Server fail to boot on recent IBM BladeCenter HS22
> hardware. Having scsi_wait_scan statically compiled into the kernel
> is known to fix this problem. Instead of going this approach I'd
> recommend to implement proper support for that in our i-t (which is
> also the way to go according to the module's source).

telling the admin to use rootdelay is the more sane approach.
as they'd be still using the updated and supported linux-2.6.
>From such big boxes one can and should expect an educated admin.
 
> My recommendation is to run "modprobe scsi_wait_scan" by default and
> provide a bootoption like "noscsiwait" to skip this part if wanted.
> (Optionally we could also try to rmmod the module after a long period
> of time hanging in the init process, in case we notice that there
> *might* be problems with autoloading the module; though I'm not yet sure
> whether this would really work, haven't looked into the details yet).

we do.
 
> I would volunteer to implement that and provide an according Grml
> ISO with that feature to the bugreporter for proper testing.
> 
> What do you think of that? maks?

the trouble is that scsi_wait_scan is not implemented across all
relevant scsi drivers, nor inside of any usb driver nor inside of libata.
There were old patches floating for the later on. They'd need
to be resurrected massaged and reposted. I'd assume that the
correct fix for aboves bug lies on linux-2.6 side.