Description of problem:
When using a driver disk with RHEL3 U3 containing a driver that
supports diskdump, loading the driver disk will fail because loader is
unable to locate the "diskdumplib" module.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.create dd with diskdump-enabled driver
2.install with "linux dd"
3.insert floppy and hit "ok" when asked
loading the driver fails with unresolved symbols from diskdumplib
diskdumplib dependency is resolved, module is loaded.
I made a "modules.dep" file on the dd that looks as follows:
a320raid: scsi_mod diskdumplib
I found the following workaround:
After dd loading fails, select "choose manually" and select a driver
thatsupports diskdump natively such as mptbase. even if loading that
driver fails, diskdumplib will now be loaded and a 2nd attempt to load
the dd will succeed.
This is of course less than optimal.
Another workaround would be to disable diskdump in the drivers for the
BOOT kernel. Also sub-optimal.
You need to include the diskdumplib module on your driver disk. All
dependent modules that aren't in the "loaded by default list" (which
is basically just scsi_mod, sd_mod) need to be on your driver disk.
I can do that.
It doesn't make sense to me though. Why should a native RedHat driver
have to be on the disk? All that would be needed is to have the loader
look for modules first on the driver disk and then in the default
location. I'd expect this behavior, actually.
So, I accept this as a temporary workaround, but I'd consider it more
than desirable that this be fixed in future releases.