https://bugzilla.redhat.com/show_bug.cgi?id=433121
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.)
On Sat, 2008-02-16 at 09:53 -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.
When we talked about this, I guess at FUDCon last year, didn't we end up agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the implementation of things in the kernel package itself simple is a good thing and carrying around the explicit scripts in the kernel package's scriptlets doesn't help there.
Jeremy
On Sun, Feb 17, 2008 at 02:17:16PM -0500, Jeremy Katz wrote:
On Sat, 2008-02-16 at 09:53 -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.
When we talked about this, I guess at FUDCon last year, didn't we end up agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the implementation of things in the kernel package itself simple is a good thing and carrying around the explicit scripts in the kernel package's scriptlets doesn't help there.
I can put it in /sbin/new-kernel-pkg, but need to extend that to be called in %posttrans then, which it isn't now. %posttrans guarantees me it gets called after both kernel and kernel-devel are installed, when they're installed in the same transaction.
On Sun, Feb 17, 2008 at 06:51:49PM -0600, Matt Domsch wrote:
On Sun, Feb 17, 2008 at 02:17:16PM -0500, Jeremy Katz wrote:
On Sat, 2008-02-16 at 09:53 -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.
When we talked about this, I guess at FUDCon last year, didn't we end up agreeing to have this stuff done from /sbin/new-kernel-pkg? Keeping the implementation of things in the kernel package itself simple is a good thing and carrying around the explicit scripts in the kernel package's scriptlets doesn't help there.
I can put it in /sbin/new-kernel-pkg, but need to extend that to be called in %posttrans then, which it isn't now. %posttrans guarantees me it gets called after both kernel and kernel-devel are installed, when they're installed in the same transaction.
is there any reason why we can't just move %post to %posttrans? Current %post contains:
#!/bin/sh if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] && [ -f /etc/sysconfig/kernel ]; then /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $? fi /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.23.15-137.fc8 || exit $? #if [ -x /sbin/weak-modules ] #then # /sbin/weak-modules --add-kernel 2.6.23.15-137.fc8 || exit $? #fi
On Sun, Feb 17, 2008 at 08:16:25PM -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
two patches below, moving %post to %posttrans in the kernel packages (not -devel of course), and implementing the hooks in new-kernel-pkg.
Thanks, Matt
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader config updating as it leaves around no entries in the bootloader config after all the %preuns have been processed. I looked at this a few months ago and thought we talked about it here, but it might have just been mail between davej and myself
Jeremy
On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader config updating as it leaves around no entries in the bootloader config after all the %preuns have been processed. I looked at this a few months ago and thought we talked about it here, but it might have just been mail between davej and myself
ok, new-kernel-pkg grows a --rpmposttrans mode then to call these hooks, and we add a %posttrans to each kernel RPM.
On Mon, Feb 18, 2008 at 09:49:44AM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader config updating as it leaves around no entries in the bootloader config after all the %preuns have been processed. I looked at this a few months ago and thought we talked about it here, but it might have just been mail between davej and myself
ok, new-kernel-pkg grows a --rpmposttrans mode then to call these hooks, and we add a %posttrans to each kernel RPM.
and we need /sbin/installkernel to call it too. That's not called from within an RPM, but is called when the user manally builds a kernel.org kernel.
On Mon, 2008-02-18 at 09:49 -0600, Matt Domsch wrote:
ok, new-kernel-pkg grows a --rpmposttrans mode then to call these hooks, and we add a %posttrans to each kernel RPM.
This looks to be working fine, but let me see if I've got this straight ...
+%define kernel_variant_posttrans(s:r:v:) \ +%{expand:%%posttrans %{?-v*}}\
...
%define kernel_variant_post(s:r:v:) \ %{expand:%%kernel_devel_post %{?-v*}}\ +%{expand:%%kernel_variant_posttrans %{?-v*}}\
in this case, %{?-v*} doesn't just expand to the argument to -v, but also passes the "-v" to %kernel_variant_posttrans ?
i.e. I'd expect it to be something like:
%{expand:%%kernel_variant_posttrans %{?-v:-v %{-v*}}}\
I know spec file syntax is bizarre, but does anyone have a sensible explanation for this behaviour?
Cheers, Mark.
On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
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.
The RHEL thread started investigating the idea of a hook into an event mechanism provided by a high level install app with the appropriate logging. The idea was to clearly separate a successful kernel install from a poorly executed posttrans script. This way developers didn't waste their time trying to reproduce something that we clearly did not support.
Jon M. can probably fill you in better.
Cheers, Don
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:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
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 though.
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.
On Mon, Feb 18, 2008 at 11:48:41AM -0600, Matt Domsch wrote:
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 was unaware of this. But in rhel we have been adding more support to make it more obvious that non-rhel drivers have been installed. Perhaps that will help support. Most reports I read though usually have the statement "does it work without the 3rd-party driver".
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 though.
I would be more in favor of that provided we shipped and controled the script. Something an 'rpm -v' could verify that the script wasn't maliciously changed.
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.
My opinion is support shouldn't have to use 'dkms status' at all, it should be obvious that 3rd-party modules are loaded (i assume 'dkms status' just reports that as I'm not familiar with the tool).
Cheers, Don
Matt Domsch (Matt_Domsch@dell.com) said:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
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.
Use triggers - this functionality already exists without kernel-specific infrastructure.
Bill
On Mon, Feb 18, 2008 at 12:45:05PM -0500, Bill Nottingham wrote:
Matt Domsch (Matt_Domsch@dell.com) said:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
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.
Use triggers - this functionality already exists without kernel-specific infrastructure.
a) LSB suggests triggers are evil. b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know.
Matt Domsch (Matt_Domsch@dell.com) said:
Use triggers - this functionality already exists without kernel-specific infrastructure.
a) LSB suggests triggers are evil.
Then triggers must be the right answer.
b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know.
Hm, I wonder if this can be added to RPM.
Bill
On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote:
Matt Domsch (Matt_Domsch@dell.com) said:
Use triggers - this functionality already exists without kernel-specific infrastructure.
a) LSB suggests triggers are evil.
Then triggers must be the right answer.
:-)
b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know.
Hm, I wonder if this can be added to RPM.
c) I need them to run at the end of the transaction, when I can expect both kernel and kernel-devel to have been installed in the same transaction. Right now triggers run following the %post of the new kernel install, which is too early if both kernel-devel and kernel RPMs are being installed; there's no ordering guarantee between the two such that we know kernel-devel is always installed before kernel.
"MD" == Matt Domsch Matt_Domsch@dell.com writes:
MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering.
- J<
Jason L Tibbitts III (tibbs@math.uh.edu) said:
"MD" == Matt Domsch Matt_Domsch@dell.com writes:
MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering.
Is that good enough? It should be easily implementable.
Bill
(Adding Panu to the Cc)
Jason L Tibbitts III wrote:
"MD" == Matt Domsch Matt_Domsch@dell.com writes:
MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering.
That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do.
We've definitely mentioned that non-dependency ordering tags are an rpm wishlist item in the past. Maybe Panu has some thoughts on this?
"PJ" == Peter Jones pjones@redhat.com writes:
PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs.
Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs?
- J<
On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote:
"PJ" == Peter Jones pjones@redhat.com writes:
PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs.
Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs?
no, because if DKMS decides it needs to call mkinitrd again, it needs to have kernel installed. It really is a "both and please", hence %posttrans gets us that.
On Mon, Feb 18, 2008 at 01:50:46PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote:
> "PJ" == Peter Jones pjones@redhat.com writes:
PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs.
Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs?
no, because if DKMS decides it needs to call mkinitrd again, it needs to have kernel installed. It really is a "both and please", hence %posttrans gets us that.
So, now that this has run its course (yet again), can I ask that my patches be applied? Those that create a kernel.spec %posttrans, which invokes new-kernel-pkg --rpmposttrans, which invokes the scripts in /etc/kernel/postinst.d/ ?
If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with new-kernel-pkg explicitly doing
[ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver
but I think we've beaten the fact that RPM can't do what I need (today, that could be changed, but I don't really want to wait forever for that to happen...).
-Matt
On 21.02.2008 21:13, Matt Domsch wrote:
If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with new-kernel-pkg explicitly doing
[ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver
FYI, livna's akmods stuff (a simple script that compiles kmod srpms and install them; it's in the devel repo currently only) could benefit from something like this as well. Currently akmodsd watches rpmdb, /boot and /usr/src/kernels using inotifywatch and starts to build kmods using rpmbuild when new kernel and kernel-devel packages got installed and the rpmdb was closed. The latter is needed -- otherwise akomdsd would not be able to install the newly build kmod rpm.
CU knurd
On Thu, Feb 21, 2008 at 02:13:56PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 01:50:46PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote:
>> "PJ" == Peter Jones pjones@redhat.com writes:
PJ> That doesn't guarantee the right thing -- it's inverted. It makes PJ> it so that before kernel-devel's %post runs, kernel must be PJ> installed. What Matt needs is a guarantee that kernel-devel is PJ> installed (if it will be installed at all) before kernel's %post PJ> runs.
Well, since kernel-devel is the package that's actually the one you need to do anything, can't you just trigger on kernel-devel installs?
no, because if DKMS decides it needs to call mkinitrd again, it needs to have kernel installed. It really is a "both and please", hence %posttrans gets us that.
So, now that this has run its course (yet again), can I ask that my patches be applied? Those that create a kernel.spec %posttrans, which invokes new-kernel-pkg --rpmposttrans, which invokes the scripts in /etc/kernel/postinst.d/ ?
If running all of /etc/kernel/postinst.d/ is so scary, I'm ok with new-kernel-pkg explicitly doing
[ -x /etc/kernel/postinst.d/dkms ] && /etc/kernel/postinst.d/dkms $kernelver /boot/vmlinuz-$kernelver
but I think we've beaten the fact that RPM can't do what I need (today, that could be changed, but I don't really want to wait forever for that to happen...).
akmodsd needs this type of functionality too. I really want to see this implemented. What more can I do to push this forward?
Peter Jones wrote:
(Adding Panu to the Cc)
Jason L Tibbitts III wrote:
> "MD" == Matt Domsch Matt_Domsch@dell.com writes:
MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering.
That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do.
Actually, I guess that's not the only way -- there is %posttrans . It has some obvious downsides though, not least of which being if the transaction fails it'll never get run, it doesn't show up in any progress information, and AFAIK it's generally just not well tested.
On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote:
Matt Domsch (Matt_Domsch@dell.com) said:
Use triggers - this functionality already exists without kernel-specific infrastructure.
a) LSB suggests triggers are evil.
Then triggers must be the right answer.
:-)
b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know.
Hm, I wonder if this can be added to RPM.
c) I need them to run at the end of the transaction, when I can expect both kernel and kernel-devel to have been installed in the same transaction. Right now triggers run following the %post of the new kernel install, which is too early if both kernel-devel and kernel RPMs are being installed; there's no ordering guarantee between the two such that we know kernel-devel is always installed before kernel.
Curious, what happens if someone just wants to install the kernel, no -devel package? Does the posttrans fail? Maybe I should go re-read the patch. :)
Cheers, Don
On Mon, Feb 18, 2008 at 01:13:35PM -0500, Don Zickus wrote:
On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote:
Matt Domsch (Matt_Domsch@dell.com) said:
Use triggers - this functionality already exists without kernel-specific infrastructure.
a) LSB suggests triggers are evil.
Then triggers must be the right answer.
:-)
b) triggers don't tell me the version of the package that got installed that caused the trigger, which is what I need to know.
Hm, I wonder if this can be added to RPM.
c) I need them to run at the end of the transaction, when I can expect both kernel and kernel-devel to have been installed in the same transaction. Right now triggers run following the %post of the new kernel install, which is too early if both kernel-devel and kernel RPMs are being installed; there's no ordering guarantee between the two such that we know kernel-devel is always installed before kernel.
Curious, what happens if someone just wants to install the kernel, no -devel package? Does the posttrans fail? Maybe I should go re-read the patch. :)
no, new-kernel-pkg exits with status 0 from rpmposttrans() regardless of if the scripts it's invoking succeed or fail. No reason to hork up RPM over it.
The DKMS script itself will fail if there's no matching kernel-devel package present, or if there's no compiler present, etc.
kernel@lists.fedoraproject.org
-
Bill Nottingham -
Don Zickus -
Jason L Tibbitts III -
Jeremy Katz -
Mark McLoughlin -
Matt Domsch -
Peter Jones -
Thorsten Leemhuis