Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1962 - Difficult to use non-obvious /lib/modules/<foo> module directories
Summary: Difficult to use non-obvious /lib/modules/<foo> module directories
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: modutils
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-03 09:33 UTC by Chris Siebenmann
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-04-07 17:02:08 UTC

Attachments (Terms of Use)

Description Chris Siebenmann 1999-04-03 09:33:31 UTC
The Rawhide modutils-2.1.121 appears to be compiled to
use only
	/lib/modules/`uname -r`
and	/lib/modules
as the search path for modules, unlike the RedHat 5.2
modutils, which seem to have been compiled to check
/lib/modules/preferred as well (and first, from the
looks of things).

 The net effect of this change seems to be to make it
practically impossible to use the old scheme where
/lib/modules/preferred was symlinked to the right
place. I believe this is undesirable; I don't want
to be frobbing EXTRAVERSION in kernel Makefiles for
every variant I test-compile (among other things,
this will make patches from kernel version to kernel
version fail to apply cleanly!).

 I suggest that RedHat revert/enhance/whatever modutils
to check /lib/modules/preferred again.

Comment 1 Cristian Gafton 1999-04-05 23:47:59 UTC
You can modprobe modules only against the running kernel, and now we
have a very sure way of identifying the running kernel, so the
preferred hack is no longer needed.

Comment 2 Chris Siebenmann 1999-04-06 20:09:59 UTC
If the preferred hack is no longer supposed to be there at all,
you might want to delete the stanza in /etc/rc.d/rc.sysinit that
falls back to it.

 Personally, I think that relying on uname -r/EXTRAVERSION is a
bit fragile in an environment where people may build their own
kernels, but clearly RedHat disagrees.

Comment 3 Bill Nottingham 1999-04-06 22:30:59 UTC
it has been removed in the latest initscripts (removed about 3/29
or so).

Comment 4 Cristian Gafton 1999-04-07 17:02:59 UTC
Relying on EXTRAVERSIOn is a whole lot more stable than the previous
preffered hack. This is what EXTRAVERSION is for and it is not
terribly difficult to change that value when compiling a customized

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