Bug 89794
| Summary: | mkinitrd makes totally unwarranted assumptions about a format of modules.conf | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Michal Jaegermann <michal> |
| Component: | mkinitrd | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | martin.wilck |
| 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: | 2003-06-11 04:26:53 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: | |||
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. 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. Can't remember why modprobe -c was bad, so going to try it and see what happens :) Does this mean there won't be a bug fix package for mkinitrd for RH9? 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? |
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.