Bug 132918 - Add ability to specify where the modules dir is located
Summary: Add ability to specify where the modules dir is located
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Keywords: FutureFeature, Patch
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-19 16:42 UTC by Felipe Alfaro Solana
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-23 01:37:51 UTC
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 16:44 UTC, Felipe Alfaro Solana
no flags Details | Diff

Description Felipe Alfaro Solana 2004-09-19 16:42:56 UTC
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 16:44:56 UTC
Created attachment 103996 [details]
Add ability to specify alternate kernel directory modules directory

Comment 2 Jeremy Katz 2004-09-20 17:55:01 UTC
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 18:44:34 UTC
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 13:56:07 UTC
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 23:20:34 UTC
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-23 01:37:51 UTC
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.