Hide Forgot
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:
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
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?
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.
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...
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.
(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?
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/
Matt, the bug is still assigned to you; perhaps that's why no kernel developer has taken a look?
Any advance on this side, now that Fedora 8 is out?
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.
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.
(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.
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:.
(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!
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
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