Red Hat Bugzilla – Bug 443119
FEAT RHEL 5.3: kernel posttrans and preun hooks for other packages
Last modified: 2016-04-18 05:46:55 EDT
+++ This bug was initially created as a clone of Bug #440584 +++
+++ This bug was initially created as a clone of Bug #433121 +++
Above bug assigned to mkinitrd.... this cloned bug to track kernel piece.
Description of problem:
DKMS would like to have the opportunity to run it's auto-rebuilder/installer
after a new kernel RPM has been installed, without having to wait for a system
restart to run it. Likewise, when a kernel RPM is removed, it would like to be
able to run to remove modules managed by it.
Debian kernels intentionally run scripts located in /etc/kernel/postinst.d/
following new kernel package installation, /etc/kernel/prerm.d/ before kernel
package removal. DKMS drops a script into these directories, to perform the
I want Fedora and RHEL kernels to do likewise. Patch attached.
Version-Release number of selected component (if applicable):
-- Additional comment from email@example.com on 2008-02-16 10:35 EST --
Created an attachment (id=295073)
-- Additional comment from firstname.lastname@example.org on 2008-02-16 10:36 EST --
Note this patch implements the same interface as that used for Debian and Ubuntu
kernels. The scripts are invoked with $1 = kernel version, and $2 = path to
vmlinuz file. (DKMS doesn't need $2, but I'm keeping the interface the same to
match so people can reuse their scriptlets.)
-- Additional comment from email@example.com on 2008-03-18 21:17 EST --
now has the actual scripts being invoked by kernel rpm %posttrans and %preun.
Now it's time for the kernel .spec patch, as discussed on fedora-kernel-list, to
be applied, which adds %posttrans and %preun invocation of /sbin/new-kernel-pkg
-- Additional comment from firstname.lastname@example.org on 2008-03-18 21:35 EST --
has the patch, and the kernel.spec dependency on mkinitrd needs to bump to >=
-- Additional comment from email@example.com on 2008-03-19 16:40 EST --
-- Additional comment from firstname.lastname@example.org on 2008-04-04 11:22 EST --
Thanks for filing the request. Last time we evaluated this it was decided that
these patches would potentially adversely affect the kernel install process
(third party scripts might introduce problems) however we can bing this issue up
early in the 5.3 development cycle and review the comments of our kernel
-- Additional comment from email@example.com on 2008-04-06 13:19 EST --
Warren, you were saying that you were interested in this functionality for RHEL?
-- Additional comment from firstname.lastname@example.org on 2008-04-06 21:09 EST --
Hi Jon, was this rejected because of the DKMS purpose of building out-of-tree
The other major case where rpm posttrans is extremely useful is where you need
to build alternative network bootable images. Several architectures as well as
many modern LinuxBIOS-based thin clients require a kernel + initrd to be wrapped
with a certain tool in order to be network bootable because they cannot boot the
kernel and initrd directly.
-- Additional comment from email@example.com on 2008-04-06 21:19 EST --
BTW, why is this in kernel.spec instead of within mkinitrd like Fedora 9?
-- Additional comment from firstname.lastname@example.org on 2008-04-06 21:27 EST --
If implemented for RHEL, it should be done as it was done in Fedora. My
original proposal (which this bug is based on) had it all in kernel.spec. As
implemented in Fedora, the good bits are in mkinitrd, so that's what should be
done for RHEL.
-- Additional comment from email@example.com on 2008-04-07 10:18 EST --
no reason to fork mkinitrd over this. Go ahead and include this feature in
mkinitrd, while we debate the wisdom of including the kernel %posttrans/%prerm
-- Additional comment from firstname.lastname@example.org on 2008-04-18 14:00 EST --
Changing component to mkinitrd per comment comment #6
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Unfortunately the previous automated notification about the
non-inclusion of this request in Red Hat Enterprise Linux 5.3 used
the wrong text template. It should have read: this request has been
reviewed by Product Management and is not planned for inclusion
in the current minor release of Red Hat Enterprise Linux.
If you would like this request to be reviewed for the next minor
release, ask your support representative to set the next rhel-x.y
flag to "?" or raise an exception.
I don't think there is any kernel piece needed here. It seems like it will be done in mkinitrd.
Marking this closed.