Red Hat Bugzilla – Bug 112857
mkinitrd doesn't support upcoming libata module
Last modified: 2007-04-18 13:00:56 EDT
Description of problem: I play around with libata enabled kernels, see e.g. here for more: (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103980) and found, that "libata" is not really supported by "mkinitrd" "mkinitrd" has 2 options for additional module loading: --preload=... --with=... for the "libata" module, "--preload" is too early (libata requires scsi_mod to be loaded), post loading after the scsi modules with "--with" it's too late, because the "sata_promise" module was already tried to load (but failed because of the missing "scsi_mod") Version-Release number of selected component (if applicable): mkinitrd-3.3.10-1 (from RHL 7.3), FC1's 3.5.14-1 also How reproducible: Always Steps to Reproduce: 1. Rebuild a kernel with "libata" and "sata_promise" as module 2. Extend /etc/modules.conf with alias scsi_hostadapter sata_promise 3. Create initial RAMdisk with mkinitrd 4. Boot Actual Results: SATA module not loaded, drives cannot be used Expected Results: SATA module loaded after proper load of "libata", usage of drives. Additional info: Workarounds (before creating the initial RAMdisk): Administrators way: Adjust /etc/modules.conf like the following: alias scsi_hostadapter libata alias scsi_hostadapter1 sata_promise mkinitrd maintainers or packagers way: Fix /sbin/mkinitrd like shown here: --- mkinitrd.rhl73 Sun Jan 4 10:59:06 2004 +++ mkinitrd Sun Jan 4 10:59:52 2004 @@ -39,7 +39,7 @@ else IMAGESIZE=3000 fi -PRESCSIMODS="scsi_mod sd_mod unknown" +PRESCSIMODS="scsi_mod sd_mod libata unknown" fstab="/etc/fstab" usage () { Both workarounds are working here on RHL 7.3
mkinitrd shouldn't need any special code here... Does the sata_promise module not have a module dependency on libata?
Perhaps, but does module dependency help on using "insmod" like the boot loader does? Why was "scsi_mod" hardwired added by "mkinitrd" if not because of similar reason?
Yes, mkinitrd parses the modules.dep file and makes sure that all of the dependent modules are there. sd_mod is "special" because while there really isn't a dependency of the host adapter module on sd_mod (you could just have a cdrom attached for example), to be useful for the initrd case, you need to have sd_mod. Looking at the modules.dep for the 2.6 kernel I'm currently running, it looks like the module dependency is there, so everything will work fine assuming depmod -a is properly run after the modules are installed.
Ok, you're right about the use of modules.dep, but this is only implemented in the FC1 release. At least RHL 9.0 do not show any modules.dep support.