Comment 14 for bug 1057054

Then the only possible actors left are the actual initramdisk contents e.g.
zcat <initrd> | cpio -id and examine all the scripts (init, conf/modules) to determine
how it could be loaded. The absence of the module reference in all of /etc and
/usr/share/initramfs-tools/ tell me that whatever is loading that module is doing
so as a side effect or an administration artifact e.g. someone wrote a udev rule and forgot.

Another possible source and this is also way out in left field is if modules.dep
was compromised and scsi_sh_rdac was added as dependency of another module
and thus loaded indirectly.

root@nashira:/lib/modules/2.6.32-41-generic# grep scsi_dh modules*
modules.builtin:kernel/drivers/scsi/device_handler/scsi_dh.ko
modules.dep:kernel/drivers/scsi/device_handler/scsi_dh_rdac.ko:
modules.dep:kernel/drivers/scsi/device_handler/scsi_dh_hp_sw.ko:
modules.dep:kernel/drivers/scsi/device_handler/scsi_dh_emc.ko:
modules.dep:kernel/drivers/scsi/device_handler/scsi_dh_alua.ko:
Binary file modules.dep.bin matches
modules.order:kernel/drivers/scsi/device_handler/scsi_dh_rdac.ko
modules.order:kernel/drivers/scsi/device_handler/scsi_dh_hp_sw.ko
modules.order:kernel/drivers/scsi/device_handler/scsi_dh_emc.ko
modules.order:kernel/drivers/scsi/device_handler/scsi_dh_alua.ko
root@nashira:/lib/modules/2.6.32-41-generic# vim modules.dep
root@nashira:/lib/modules/2.6.32-41-generic# vim modules.builtin

Fine here.

concerning boot probe, scsi discovery is asymmetric, there's no expectation
of order. Performance tuning is where I get off, I also don't know much about
iSCSI transport, though yeah, jumbo frames it probably wise.

If you're seeing those messages before the file system is mounted then
the actors are definitely *in the ramdisk*, you just need to find them.