On Mon, Feb 18, 2008 at 12:35:19PM -0500, Don Zickus wrote:
On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote:
> 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.
> 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.)
I argued against this idea in RHEL because I believe blindly running
random scripts in a directory is an unsafe thing to do (despite its best
intentions it can still be abused).
Also from a support perspective, it becomes more complicated to support
kernel installs when random user scripts can cause unknown behaviour.
This has been the argument against DKMS for 5 years now. However, in
those 5 years, how many support calls has Red Hat taken where a
DKMS-ified driver turned out to be the problem? Where it wasn't
obvious what was happening? 'dkms status' is even part of sysreport,
and has been for at least 3 years.
I'd accept a change to new-kernel-package rpmposttrans() that invokes
the DKMS script directly, as opposed to looping through a plug-in
directory, if that makes people feel any better. I suspect it doesn't
Waiting on a higher-level tool to assist the support guys ask for
'dkms status' info may be appropriate for RHEL, but not for Fedora.
Linux Technology Strategist, Dell Office of the CTO