Bug 89794 - mkinitrd makes totally unwarranted assumptions about a format of modules.conf
Summary: mkinitrd makes totally unwarranted assumptions about a format of modules.conf
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-28 15:46 UTC by Michal Jaegermann
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-11 04:26:53 UTC
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2003-04-28 15:46:20 UTC
Description of problem:

A code in /sbin/mkinitrd scripts assumes some particular layout of
/etc/modules.conf which by no means can be ensured that it there.
In particular it picks module options by doing
  
    options=`sed -n -e "s/^options[     ][      ]*$module[      ][      ]*//p"
$modulefile 2>/dev/null`

while a real form can be something of that kind

      options mymodule \
      a,long,list,of,options,continues,on,subsequent,lines

What is more "options" string does not need to start on the leftmost column;
in particular if some conditionals are involved.

This is not an invented example.  I have entries of that sort in
my /etc/modules.conf although these modules are not used at this moment
by initrd.

How about a code in this style instead:

   options=$(/sbin/modprobe -c | grep "options $module")
   options="${options#options $module }"

as 'modprobe' does much better job at parsing modules.conf then ad hoc
methods.  This does depend on an output format from 'modprobe -c' but
this should be more reliable then a form of edited modules.conf.

Version-Release number of selected component (if applicable):
This really applies to all versions of mkinitrd I know including
3.4.43-1 from the current rawhide.

Comment 1 Martin Wilck 2003-05-15 14:27:07 UTC
Confirmed.

The main problem is that even simple lines like

options scsi_mod max_scsi_luns=32

are not recognized by "mkinitrd" in RH 9 because the 'sed' line quoted by Michal
above doesn't find options entries like this one (because "$module" at that
point will be "scsi_mod.o" rather than "scsi_mod"). This means that with RH9 it
has become impossible to specify module options like with earlier RH versions.

Michal's other suggestions are valid but they'd represent improvements over
earlier behavior. This one must be fixed because it's a regression.


Comment 2 Jeremy Katz 2003-05-16 21:57:17 UTC
The simple case is already fixed in rawhide.  Using modprobe -c has problems
(I've looked at doing it before), but don't remember what they were off the top
of my head.  I'll look at it again.

Comment 3 Jeremy Katz 2003-06-11 04:26:53 UTC
Can't remember why modprobe -c was bad, so going to try it and see what happens :)

Comment 4 Martin Wilck 2003-06-11 06:52:12 UTC
Does this mean there won't be a bug fix package for mkinitrd for RH9?

Comment 5 Karsten Weiss 2003-08-19 09:52:36 UTC
I second this wish: A fix in rawhide is *no* solution for RH9. There really should be 
an errata rpm for mkinitrd because module options parsing doesn't work at all with 
mkinitrd of RH9. (See comment #1 above) 
 
Why did I have to waste one hours time yesterday when we ran into this bug, 
too,  when there is a bug fix available since weeks? 
 


Note You need to log in before you can comment on or make changes to this bug.