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):
Steps to Reproduce:
You can now invoke "mkinitrd" as follows
to create the initial ramdisk for a kernel from the resulting kernel
that is produced when compiling with "make rpm".
This patch shouldn't break any scripts that depend on mkinitrd.
Tested on i386 Fedora Core -devel.
Created attachment 103996 [details]
Add ability to specify alternate kernel directory modules directory
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
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
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/
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...
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
This is why the %preun of the kernel package also runs new-kernel-pkg.