Bug 112857

Summary: mkinitrd doesn't support upcoming libata module
Product: [Retired] Red Hat Linux Reporter: Peter Bieringer <pb>
Component: mkinitrdAssignee: Jeremy Katz <katzj>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-04 18:34:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter Bieringer 2004-01-04 10:07:39 UTC
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

Comment 1 Jeremy Katz 2004-01-04 18:14:23 UTC
mkinitrd shouldn't need any special code here...  Does the
sata_promise module not have a module dependency on libata?  

Comment 2 Peter Bieringer 2004-01-04 18:24:35 UTC
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?

Comment 3 Jeremy Katz 2004-01-04 18:34:12 UTC
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.

Comment 4 Peter Bieringer 2004-01-06 19:51:43 UTC
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.