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): 9.1.3 How reproducible: Always Steps to Reproduce: 1.create dd with diskdump-enabled driver 2.install with "linux dd" 3.insert floppy and hit "ok" when asked Actual results: loading the driver fails with unresolved symbols from diskdumplib Expected results: diskdumplib dependency is resolved, module is loaded. Additional info: 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.