Bug 89794 - mkinitrd makes totally unwarranted assumptions about a format of modules.conf
mkinitrd makes totally unwarranted assumptions about a format of modules.conf
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-04-28 11:46 EDT by Michal Jaegermann
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-11 00:26:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2003-04-28 11:46:20 EDT
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 \

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 10:27:07 EDT

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 17:57:17 EDT
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 00:26:53 EDT
Can't remember why modprobe -c was bad, so going to try it and see what happens :)
Comment 4 Martin Wilck 2003-06-11 02:52:12 EDT
Does this mean there won't be a bug fix package for mkinitrd for RH9?
Comment 5 Karsten Weiss 2003-08-19 05:52:36 EDT
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.