Bug 250377 - External modules of removed kernels are not removed
External modules of removed kernels are not removed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-01 04:20 EDT by Piergiorgio Sartor
Modified: 2008-05-14 10:10 EDT (History)
12 users (show)

See Also:
Fixed In Version: 2.6.25-14.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-14 10:10:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2007-08-01 04:20:02 EDT
Description of problem:
When a kernel, with some external modules installed using dkms, is removed, for
example following an update, the external modules are not removed, neither
immediately nor the next reboot.

Version-Release number of selected component (if applicable):
dkms-2.0.16-1.fc7

How reproducible:
Always.

Steps to Reproduce:
1.
Install a module with dkms, for example the nvidia driver from freshrpms.
2.
Remove the corresponding kernel (of course, the kernel should have the module
installed and should be removable, i.e. it should not be running).
  
Actual results:
The module is not removed, neither the next reboot, when it is installed in the
new kernel.

Expected results:
Well, one option would be to invoke dkms remove during (before) kernel uninstall.
Another would be to run a cleanup the next reboot, removing all modules of
non-existing kernels. This option might anyway not be optimal, since the
directory tree in /var/lib, belonging to the non-existing kernel will probably
stay (which is not wanted), unless a further rmdir option will be included.

Additional info:
Comment 1 Matt Domsch 2007-08-01 10:17:02 EDT
I agree this is a problem.
On Ubuntu, there are hooks in the kernel and kernel-headers packages to allow
apps such as DKMS to get run on package upgrade and removal.  Red Hat and
Novell/SuSE kernel packages have never had such a hook for DKMS to get notified
of these events (and no, I'm not setting up rpm triggers).

I talked with Jon Masters a while back, and he was open to trying to get such
hooks added to the kernel package, but I never followed up to do so.  On Ubuntu,
there are directories /etc/kernel/postinst.d/ and /etc/kernel/preinst.d/ and
soon /etc/kernel/header_postinst.d/ where apps can drop their scripts to be run
via run-parts on these events.  That's the model I would like for the Fedora kernel.

Re-assigning to the kernel package.  After such time as the kernel has this
feature, we can re-assign it to DKMS to make use of the hooks.
-Matt 
Comment 2 Piergiorgio Sartor 2007-08-03 04:04:28 EDT
Uhm, what about running, at each reboot, after the dkms install, something like:

dkms status | grep -v `uname -r` | gawk -F', ' '{print "dkms remove -m "$1" -v
"$2" -k "$3}' | bash

This should remove all modules not belonging to the current running kernel, i.e.
only modules belonging to the current running kernel are preserved.
It might not be optimal, since each reboot with a different kernel will require
a rebuild, but is this a critical condition?

Also because this is what I'm doing, manually, at each kernel upgrade.

It could be a temporary solution, until the hooks are available.

What do you think? Any drawbacks?
Comment 3 Matt Domsch 2007-08-11 19:13:46 EDT
It's better to remove all DKMS installed or built kernel modules for all kernels
that no longer are installed, rather than the currently-running kernel.  That's
what we'll do once we've got the kernel package uninstall hook.

The drawback is that with your suggestion, you'll remove modules for kernels you
may still have installed and may run again in the future.
Comment 4 Jarod Wilson 2007-08-13 16:18:48 EDT
Has anyone approached davej or cebbert about this idea to get their thoughts? I've got a pretty good idea 
how to implement this, but we certainly need to hear from them (and probably fesco) before doing this...
Comment 5 Matt Domsch 2007-08-13 19:26:59 EDT
This is logged against the kernel package right now, so I'd assume DaveJ or 
someone from the kernel team will take a look at some point.  Ideally, it 
would be done just as on Debian/Ubuntu, with directories owned by the kernel 
package, into which DKMS and other apps can drop scripts to be executed at the 
appropriate times.  kernel package install and uninstall, kernel-devel install 
and uninstall.  Passing in the kernel version and architecture as args to the 
script.
Comment 6 Matt Domsch 2007-08-13 19:27:09 EDT
This is logged against the kernel package right now, so I'd assume DaveJ or 
someone from the kernel team will take a look at some point.  Ideally, it 
would be done just as on Debian/Ubuntu, with directories owned by the kernel 
package, into which DKMS and other apps can drop scripts to be executed at the 
appropriate times.  kernel package install and uninstall, kernel-devel install 
and uninstall.  Passing in the kernel version and architecture as args to the 
script.
Comment 7 Jarod Wilson 2007-08-14 17:27:04 EDT
(In reply to comment #1)
> of these events (and no, I'm not setting up rpm triggers).

For the casual observer, can you provide the reasoning behind objecting to the
use of rpm triggers?
Comment 8 Matt Domsch 2007-08-15 00:56:28 EDT
The technical reason is that I need to know the version of the kernel and
kernel-headers package being installed/uninstalled, so DKMS can take appropriate
action (build modules for the newly-installed kernel, or erase modules for the
to-be-erased kernel).  RPM triggers don't provide this level of information at
runtime to the triggered application.

In addition, the usual admonishments against triggers can be found.

Linux Standard Base rules specify "thou shalt not use triggers".
http://www.linux-foundation.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.html

Triggers (scripts contained in one package but run in response to an action done
to a different package) introduce levels of complexity that defy reasonable QA
efforts.
http://www.rpath.com/technology/techoverview/

Comment 9 Michel Alexandre Salim 2007-09-09 17:52:45 EDT
Matt, the bug is still assigned to you; perhaps that's why no kernel developer
has taken a look?
Comment 10 Piergiorgio Sartor 2007-12-11 11:12:23 EST
Any advance on this side, now that Fedora 8 is out?
Comment 11 Piergiorgio Sartor 2008-01-08 10:43:01 EST
I took the freedom to change the version from 7 to 8 and the severity from low
to medium.

Second issue.
Is the "kernel maintainer list" the correct assignment for the resolution?

I do not see anybody else in the CC list, neither Matt (Domsch), Jarod, Michel,
nor myself...
I guess something wrong happened...

So I'll re-assign it to dkms, hoping to get the people back...

It case you, Matt, would like to stay completely out of this business, please
re-assign again to the kernel without yourself (and let me know).
If you like to follow it, please re-assign it (if necessary) and make sure
you're still CC.

Sorry for any inconvenience and thanks a lot in advance.
Comment 12 Piergiorgio Sartor 2008-01-08 10:46:10 EST
OK, after that, I can see the CC list again...

I hope I did not make a mistake with all these operations!

Sorry again, if that was the case.
Comment 13 Till Maas 2008-01-08 10:55:10 EST
(In reply to comment #11)
> I took the freedom to change the version from 7 to 8 and the severity from low
> to medium.

Why the change from 7 to 8? Fedora 7 is still supported and this is not yet
fixed there.


> Second issue.
> Is the "kernel maintainer list" the correct assignment for the resolution?

The kernel maintainer list is the default assignee for the kernel package, where
maybe this bug needs to be fixed.

> I do not see anybody else in the CC list, neither Matt (Domsch), Jarod, Michel,
> nor myself...
> I guess something wrong happened...

I guess you were not logged in.

> So I'll re-assign it to dkms, hoping to get the people back...
> 
> It case you, Matt, would like to stay completely out of this business, please
> re-assign again to the kernel without yourself (and let me know).
> If you like to follow it, please re-assign it (if necessary) and make sure
> you're still CC.
 
I reassigned it to kernel, because I see no reason to change it. Additionally I
CC'ed Matt, but maybe he is already on the kernel-maintainer list.
Comment 14 Matt Domsch 2008-01-08 11:17:27 EST
I'm not on kernel-maint list.  Adding more Dell folks as I expect Charles Rose 
will investigate and implement any changes deemed necessary to DKMS.

Jon Masters told me he has prepared a patch against the new-kernel-package 
tool which was being discussed on kernel-maint to address this.  The idea 
being to implement a %posttrans hook similar to how the Ubuntu kernel packages 
behave, with scripts being run from /etc/kernel/postinst.d that DKMS could 
hook into.  Not being on kernel-maint, I don't know the status of that.  jcm 
is on cc:.
Comment 15 Piergiorgio Sartor 2008-01-08 11:25:58 EST
(In reply to comment #13)

> > I do not see anybody else in the CC list, neither Matt (Domsch), Jarod, Michel,
> > nor myself...
> > I guess something wrong happened...
> 
> I guess you were not logged in.

Well, it could be...

Just for the sake of conversation, everything started searching (advance search)
for bugs where I'm the reporter or in the CC list, and this one, strangely, was
not found (of this, I'm pretty sure).

Anyhow, I'm glad to see the thing did not fall off the table and it is
proceeding as proposed.

Thanks a lot!
Comment 16 Bug Zapper 2008-05-14 09:48:01 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Matt Domsch 2008-05-14 10:10:38 EDT
This is resolved in the Fedora 9 kernel.  It won't be resolved in earlier 
kernels.  Please upgrade to Fedora 9 to see the expected behavior.
Thanks,
Matt

Note You need to log in before you can comment on or make changes to this bug.