Bug 132918 - Add ability to specify where the modules dir is located
Add ability to specify where the modules dir is located
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: FutureFeature, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-19 12:42 EDT by Felipe Alfaro Solana
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-22 21:37:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Add ability to specify alternate kernel directory modules directory (3.48 KB, patch)
2004-09-19 12:44 EDT, Felipe Alfaro Solana
no flags Details | Diff

  None (edit)
Description Felipe Alfaro Solana 2004-09-19 12:42:56 EDT
Description of problem:
-----------------------
"mkinitrd" always assumes the kernel modules directory is located at
"/lib/modules". I've patched "mkinitrd" to add the optional
"--with-modules-dir=<path-to-lib-modules>" switch. This switch allows
the user to specify an alternate location for the kernel modules
directory. If the "--with-modules-dir" switch is not specified, the
default kernel modules directory "/lib/modules" is used. Thus, this
patch doesn't change the expected behavior of mkinitrd and shouldn't
break any scripts that depend on it.

Please, see the attached "mkinitrd-modules-dir.patch" file.

Version-Release number of selected component (if applicable):
mkinitrd-4.1.11-1

How reproducible:
N/A

Steps to Reproduce:
N/A
  
Actual results:
You can now invoke "mkinitrd" as follows

mkinitrd --with-modules-dir=/var/tmp/kernel-2.6.9rc2mm1/lib/modules
/var/tmp/kernel-2.6.9rc2mm1/boot/initrd-2.6.9-rc2-mm1 2.6.9-rc2-mm1

to create the initial ramdisk for a kernel from the resulting kernel
that is produced when compiling with "make rpm".

Expected results:
This patch shouldn't break any scripts that depend on mkinitrd.

Additional info:
Tested on i386 Fedora Core -devel.
Comment 1 Felipe Alfaro Solana 2004-09-19 12:44:56 EDT
Created attachment 103996 [details]
Add ability to specify alternate kernel directory modules directory
Comment 2 Jeremy Katz 2004-09-20 13:55:01 EDT
What's the use case of this?  You really want the initrd to be
generated on the machine that you're installing the kernel on as,
otherwise, you won't necessarily get all of the modules you need
Comment 3 Felipe Alfaro Solana 2004-09-20 14:44:34 EDT
The kernel.org vanilla kernel, when told to do a "make rpm", doesn't invoke "mkinitrd" to 
create the initial ram disk (or at least, I have been unable to find how to force it do), so I 
had to patch the "mkspec" script under "scripts/packages" in the kernel source tree.

However, patching this script to generate a SPEC file (kernel.spec) that calls "mkinitrd", 
causes "mkinitd" to look for modules in "/lib/modules" but the modules are located at 
"$RPM_BUILD_ROOT/lib/modules" instead.

Thus, I had to patch "mkinitd" first, then invoke it from the kernel.spec SPEC file using:

mkinitrd --with-modules=$RPM_BUILD_ROOT/lib/modules $RPM_BUILD_ROOT/boot/
initrd-$KERNELRELEASE $KERNELRELEASE
Comment 4 Jeremy Katz 2004-09-21 09:56:07 EDT
But if you're going to have to patch the script anyway, why not patch
the script to dtrt and add the proper %post to the kernel package?

This seems like you're taking the wrong approach...
Comment 5 Felipe Alfaro Solana 2004-09-22 19:20:34 EDT
I can create the initial ramdisk during the "%post" stage, as you suggest, but this will leave 
the initrd image file orphaned (not belonging to the package). Thus, if the kernel RPM gets 
removed/upgraded, the initrd file will be left lying around, which is something I don't like 
pretty much.
Comment 6 Jeremy Katz 2004-09-22 21:37:51 EDT
This is why the %preun of the kernel package also runs new-kernel-pkg.

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