+++ 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 appropriate actions. I want Fedora and RHEL kernels to do likewise. Patch attached. Version-Release number of selected component (if applicable): kernel-2.6.25-0.50.rc2.fc9.x86_64.rpm -- Additional comment from matt_domsch on 2008-02-16 10:35 EST -- Created an attachment (id=295073) kernel-posttrans-preun.patch -- Additional comment from matt_domsch 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 matt_domsch on 2008-03-18 21:17 EST -- mkinitrd-6.0.39-1.fc9.x86_64 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 --rpmposttrans. Thanks, Matt -- Additional comment from matt_domsch on 2008-03-18 21:35 EST -- https://www.redhat.com/archives/fedora-kernel-list/2008-February/msg00083.html has the patch, and the kernel.spec dependency on mkinitrd needs to bump to >= 6.0.39-1 -- Additional comment from davej on 2008-03-19 16:40 EST -- applied. -- Additional comment from jcm 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 engineers again. -- Additional comment from matt_domsch on 2008-04-06 13:19 EST -- Warren, you were saying that you were interested in this functionality for RHEL? -- Additional comment from wtogami on 2008-04-06 21:09 EST -- Hi Jon, was this rejected because of the DKMS purpose of building out-of-tree drivers? 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 wtogami on 2008-04-06 21:19 EST -- BTW, why is this in kernel.spec instead of within mkinitrd like Fedora 9? -- Additional comment from matt_domsch 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 matt_domsch 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 hooks. -- Additional comment from ltroan 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.