A fix could look like this: 
 
    # Now copy the upper level driver modules 
    lastmod='' 
    for module in $uld_modules; do 
        # If name starts with lib we have a module name, otherwise param 
        if [ ${module#lib} = ${module} ]; then 
            echo "options ${lastmod} ${module}" >> $tmp_mnt/etc/modprobe.conf 
        else 
            lastmod=${module##*/} 
            lastmod=${lastmod%.ko} 
            if [ ! -f $tmp_mnt/$module ]; then 
                if ! ( cd ${root_dir:-/} ; cp -p --parents $module 
$tmp_mnt ) ; then 
                    oops 6 "Failed to add module $module." 
                    return 
                fi 
            fi 
        fi 
    done 
 

Kurt, your fix is not correct. We already have code to separate out modules and
options:

    while read module params ; do
        ...
    done < <(echo "$drv_modules")

So it looks more as if the module list is not written correctly.

Created attachment 48751 [details]
mkinitrd

Updated /sbin/mkinitrd. Please retest with it.

1. Your mkinitrd seems to work (it does not error out)  
2. ... but you discard the module parameters that are likely to be needed   
3. ... ... and you fail to explain why my variant is wrong. 
           Yours is more elegant, yes ... 
 

The code in comment 1 doesn't help because insmod does not look at 
modprobe.conf. There is no need to separate modules from parameters; they only 
got mixed by acciddent. 
 
The parameter problem is a bit messy: parameters for some modules loaded with 
insmod (dasd_mod, ide_core, scsi_mod) are lost. Parameters for modules loaded 
with modprobe are lost because the modprobe.conf* files are missing. 
 
Since we now have modprobe in the initrd, I suggest that we add its config 
files, use it for all module loading. 

Created attachment 48854 [details]
Proposed fix

Switch to using modprobe instead of insmod; add modprobe.conf* to the initrd.
Please review and test this patch before committing...

Hmm; I don't think that'll work. We have to be able to pass module options via
the kernel cmdline; not sure whether we handle that now correctly.

However, using modprobe instead of insmod is probably not a bad approach.
So we should always copy in modprobe.conf et al.

Well, the patch handles the cmdline arguments properly. So ignore that bit.
Otherwise the patch looks quite ok to me ...

Created attachment 48882 [details]
With module.* parameter handling

We should add parameters of the form "module.something" to the modprobe calls.
Actually this would allow to get rid of some of the other special cases.

The code that this now generates in the init script is ugly, but we can
probably live with it for one release.

Hannes, could you please test this fix?

Install entries in modprobe.conf are an additional problem: we only       
have a limited set of binaries in the initrd, so some of the actions       
specified may fail in exceptional cases. We will only have with storage-type     
modules in the initrd though, which are not as weird as some other types.     
Almost all install actions either null out a module (with /bin/true as the     
action) or load a dependent module (by calling /sbin/modprobe recorsively).    
Removing install actions from modprobe.conf are likely to break more things    
than they will fix.    
    
I have added attachment 11 [details] and a version of /bin/true to the cvs now.  
  
An open issue is that we should probably pass the original INITRD_MODULES list 
of modules to modprobe instead of the resolved modules. This requires some 
changes to the fs_modules / drv_modules split code though. 

Tested mkinitrd on SATA and IDE machine. Closing bug.