kernel posttrans and preun hooks for other packages

[Matt Domsch]

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.)


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

--- kernel.spec.orig	2008-02-15 21:06:33.000000000 -0600
+++ kernel.spec	2008-02-16 00:07:36.000000000 -0600
@@ -1610,11 +1610,35 @@
 %{nil}
 
 #
+# This macro defines a %%posttrans script for a kernel package.
+#	%%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>]
<mkinitrd-args>
+# More text can follow to go at the end of this variant's %%posttrans.
+#
+%define kernel_variant_posttrans(v:) \
+%{expand:%%posttrans %{?-v*}}\
+for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/%{KVERREL}%{?-v*} ; do \
+    if [ -d "${d}" ]; then \
+       for f in $(ls ${d}/); do \
+       	   [ -x "${d}/${f}" ] && "${d}/${f}"
%{KVERREL}%{?-v*} /boot/vmlinuz-%{KVERREL}%{?-v*} \
+       done \
+    fi \
+done \
+exit 0\
+%{nil}
+
+#
 # This macro defines a %%preun script for a kernel package.
 #	%%kernel_variant_preun <subpackage>
 #
 %define kernel_variant_preun() \
 %{expand:%%preun %{?1}}\
+for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/%{KVERREL}%{?1} ; do \
+    if [ -d "${d}" ]; then \
+       for f in $(ls ${d}/); do \
+       	   [ -x "${d}/${f}" ] && "${d}/${f}" %{KVERREL}%{?1}
/boot/vmlinuz-%{KVERREL}%{?1} \
+       done \
+    fi \
+done \
 /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\
 #if [ -x /sbin/weak-modules ]\
 #then\
@@ -1624,12 +1648,15 @@
 
 %kernel_variant_preun
 %kernel_variant_post -s kernel-smp -r kernel
+%kernel_variant_posttrans
 
 %kernel_variant_preun smp
 %kernel_variant_post -v smp
+%kernel_variant_posttrans -v smp
 
 %kernel_variant_preun PAE
 %kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE
+%kernel_variant_posttrans -v PAE
 
 %kernel_variant_preun debug
 %kernel_variant_post -v debug
@@ -1644,6 +1671,8 @@
     /sbin/ldconfig -X || exit $?
 fi
 
+%kernel_variant_posttrans -v xen
+
 ###
 ### file lists
 ###

[Jeremy Katz]

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

[Matt Domsch]

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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Matt Domsch]

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


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Matt Domsch]

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

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux


--- kernel.spec.orig	2008-02-15 21:06:33.000000000 -0600
+++ kernel.spec	2008-02-17 23:30:06.000000000 -0600
@@ -1590,13 +1590,13 @@ fi\
 %{nil}
 
 #
-# This macro defines a %%post script for a kernel package and its devel package.
-#	%%kernel_variant_post [-v <subpackage>] [-s <s> -r <r>]
<mkinitrd-args>
+# This macro defines a %%posttrans script for a kernel package and its devel package.
+#	%%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>]
<mkinitrd-args>
 # More text can follow to go at the end of this variant's %%post.
 #
-%define kernel_variant_post(s:r:v:) \
+%define kernel_variant_posttrans(s:r:v:) \
 %{expand:%%kernel_devel_post %{?-v*}}\
-%{expand:%%post %{?-v*}}\
+%{expand:%%posttrans %{?-v*}}\
 %{-s:\
 if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
    [ -f /etc/sysconfig/kernel ]; then\
@@ -1623,22 +1623,22 @@ fi}\
 %{nil}
 
 %kernel_variant_preun
-%kernel_variant_post -s kernel-smp -r kernel
+%kernel_variant_posttrans -s kernel-smp -r kernel
 
 %kernel_variant_preun smp
-%kernel_variant_post -v smp
+%kernel_variant_posttrans -v smp
 
 %kernel_variant_preun PAE
-%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE
+%kernel_variant_posttrans -v PAE -s kernel-smp -r kernel-PAE
 
 %kernel_variant_preun debug
-%kernel_variant_post -v debug
+%kernel_variant_posttrans -v debug
 
-%kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug
+%kernel_variant_posttrans -v PAEdebug -s kernel-smp -r kernel-PAEdebug
 %kernel_variant_preun PAEdebug
 
 %kernel_variant_preun xen
-%kernel_variant_post xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a !
-e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}`
+%kernel_variant_posttrans xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen
-a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}`
 if [ -x /sbin/ldconfig ]
 then
     /sbin/ldconfig -X || exit $?




--- new-kernel-pkg.orig	2008-02-15 13:22:46.000000000 -0600
+++ new-kernel-pkg	2008-02-17 20:20:47.000000000 -0600
@@ -183,6 +183,15 @@ install() {
 	[ -n "$verbose" ] && echo "$liloConfig does not exist, not
running grubby"
     fi
 
+    local d
+    local f
+    for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/$version ; do
+	if [ -d $d ]; then
+	    for f in $(ls $d/); do
+       		[ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version
+	    done
+	fi
+    done
 }
 
 remove() {
@@ -193,6 +202,16 @@ remove() {
 	return
     fi
 
+    local d
+    local f
+    for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/$version ; do
+	if [ -d $d ]; then
+	    for f in $(ls $d/); do
+       		[ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version
+	    done
+	fi
+    done
+
     if [ -n "$cfgGrub" ]; then
 	[ -n "$verbose" ] && echo "removing $version from
$grubConfig"
 	$grubby --remove-kernel=$bootPrefix/$kernelName-$version

[Jeremy Katz]

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

[Matt Domsch]

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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

--- kernel.spec.orig	2008-02-15 21:06:33.000000000 -0600
+++ kernel.spec	2008-02-18 09:12:02.000000000 -0600
@@ -1590,12 +1590,23 @@ fi\
 %{nil}
 
 #
+# This macro defines a %%posttrans script for a kernel package.
+#	%%kernel_variant_posttrans [-v <subpackage>] [-s <s> -r <r>]
<mkinitrd-args>
+# More text can follow to go at the end of this variant's %%post.
+#
+%define kernel_variant_posttrans(s:r:v:) \
+%{expand:%%posttrans %{?-v*}}\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+%{nil}
+
+#
 # This macro defines a %%post script for a kernel package and its devel package.
 #	%%kernel_variant_post [-v <subpackage>] [-s <s> -r <r>]
<mkinitrd-args>
 # More text can follow to go at the end of this variant's %%post.
 #
 %define kernel_variant_post(s:r:v:) \
 %{expand:%%kernel_devel_post %{?-v*}}\
+%{expand:%%kernel_variant_posttrans %{?-v*}}\
 %{expand:%%post %{?-v*}}\
 %{-s:\
 if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\



--- new-kernel-pkg.orig	2008-02-15 13:22:46.000000000 -0600
+++ new-kernel-pkg	2008-02-18 09:04:44.000000000 -0600
@@ -96,7 +96,7 @@ usage() {
     echo "       [--kernel-args=<args>] [--remove-args=<args>]"
>&2 
     echo "       [--banner=<banner>] [--multiboot=multiboot]" >&2
     echo "       [--mbargs=mbargs] [--make-default]" >&2
-    echo "       <--install | --remove | --update>
<kernel-version>" >&2
+    echo "       <--install | --remove | --update | --rpmposttrans>
<kernel-version>" >&2
     echo "       (ex: `basename $0` --mkinitrd --depmod --install 2.4.7-2)"
>&2
     exit 1
 }
@@ -185,6 +185,19 @@ install() {
 
 }
 
+rpmposttrans()
+{
+    local d
+    local f
+    for d in /etc/kernel/postinst.d /etc/kernel/postinst.d/$version ; do
+	if [ -d $d ]; then
+	    for f in $(ls $d/); do
+       		[ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version
+	    done
+	fi
+    done
+}
+
 remove() {
     # FIXME: is this a good heuristic to find out if we're on iSeries?
     if [ -d /proc/iSeries ]; then
@@ -193,6 +206,16 @@ remove() {
 	return
     fi
 
+    local d
+    local f
+    for d in /etc/kernel/prerm.d /etc/kernel/prerm.d/$version ; do
+	if [ -d $d ]; then
+	    for f in $(ls $d/); do
+       		[ -x $d/$f ] && $d/$f $version $bootPrefix/$kernelName-$version
+	    done
+	fi
+    done
+
     if [ -n "$cfgGrub" ]; then
 	[ -n "$verbose" ] && echo "removing $version from
$grubConfig"
 	$grubby --remove-kernel=$bootPrefix/$kernelName-$version
@@ -379,7 +402,7 @@ while [ $# -gt 0 ]; do
 done
 
 # make sure the mode is valid
-if [ "$mode" != "--install" -a "$mode" !=
"--remove"  -a "$mode" != "--update" ] ; then
+if [ "$mode" != "--install" -a "$mode" !=
"--remove"  -a "$mode" != "--update" -a "$mode" !=
"--rpmposttrans" ] ; then
     usage
 fi
 
@@ -451,6 +474,8 @@ elif [ "$mode" == "--remove" ]; then
     remove
 elif [ "$mode" == "--update" ]; then
     update
+elif [ "$mode" == "--rpmposttrans" ]; then
+    rpmposttrans
 fi
 
 exit 0

[Matt Domsch]

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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux


--- installkernel.orig	2008-02-18 09:58:14.000000000 -0600
+++ installkernel	2008-02-18 09:58:42.000000000 -0600
@@ -79,4 +79,5 @@ ln -fs ${RELATIVE_PATH}$INSTALL_PATH/Sys
 
 if [ -n "$cfgLoader" -a -x /sbin/new-kernel-pkg ]; then
 	/sbin/new-kernel-pkg --mkinitrd --depmod --install $KERNEL_VERSION
+	/sbin/new-kernel-pkg --rpmposttrans $KERNEL_VERSION
 fi

[Don Zickus]

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

[Bill Nottingham]

Matt Domsch (Matt_Domsch(a)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

[Matt Domsch]

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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Matt Domsch]

On Mon, Feb 18, 2008 at 12:45:05PM -0500, Bill Nottingham wrote:
>  Matt Domsch (Matt_Domsch(a)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
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Bill Nottingham]

Matt Domsch (Matt_Domsch(a)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

[Matt Domsch]

On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote:
>  Matt Domsch (Matt_Domsch(a)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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Jason L Tibbitts III]

> >>>> "MD" == Matt Domsch
> <Matt_Domsch(a)dell.com&gt; 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<

[Don Zickus]

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

[Don Zickus]

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(a)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

[Matt Domsch]

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(a)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.


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Bill Nottingham]

Jason L Tibbitts III (tibbs(a)math.uh.edu) said: 
>  >>>>> "MD" == Matt Domsch
> <Matt_Domsch(a)dell.com&gt; 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

[Peter Jones]

(Adding Panu to the Cc)

Jason L Tibbitts III wrote:
> >>>>> "MD" == Matt Domsch
> <Matt_Domsch(a)dell.com&gt; 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?

-- 
   Peter

[Jason L Tibbitts III]

> >>>> "PJ" == Peter Jones
> <pjones(a)redhat.com&gt; 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<

[Peter Jones]

Peter Jones wrote:
>  (Adding Panu to the Cc)
>  
>  Jason L Tibbitts III wrote:
> >>>>>> "MD" == Matt Domsch <Matt_Domsch(a)dell.com&gt;
> 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.

-- 
   Peter

[Matt Domsch]

On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote:
>  >>>>> "PJ" == Peter Jones
> <pjones(a)redhat.com&gt; 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.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Matt Domsch]

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(a)redhat.com&gt;
> 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

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Thorsten Leemhuis]

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

[Matt Domsch]

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(a)redhat.com&gt;
> 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?

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Mark McLoughlin]

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.