[arch-general] DKMS question around removal of kernel modules
When I install a new kernel, I notice that DKMS removes previous kernel modules as well as adding them to the new kernel.
In the real old days these were not removed at all - so removal is a good thing. The issue is that the old kernel is still running and until machine is rebooted the modules wont be available I would think. I wonder - Is there a way to mark the deletion to happen after the new kernel is booted ?
I may well be missing something of course.
Installed 4.6.2 kernel while 4.6.1 running - pacman says:
(1/1) Remove DKMS modules ==> dkms -q remove -q -m vboxguest -v 5.0.20_OSE -k 4.6.1-2-ARCH
==> dkms -q remove -q -m vboxhost -v 5.0.20_OSE -k 4.6.1-2-ARCH
...==> dkms -q install -m vboxguest -v 5.0.20_OSE -k 4.6.2-1-ARCH
==> dkms -q install -m vboxhost -v 5.0.20_OSE -k 4.6.2-1-ARCH
...
Thanks for any thoughts.
gene
Le 08/06/2016 à 20:03, Genes Lists via arch-general a écrit :
When I install a new kernel, I notice that DKMS removes previous kernel modules as well as adding them to the new kernel.
In the real old days these were not removed at all - so removal is a good thing. The issue is that the old kernel is still running and until machine is rebooted the modules wont be available I would think. I wonder - Is there a way to mark the deletion to happen after the new kernel is booted ?
I may well be missing something of course.
Installed 4.6.2 kernel while 4.6.1 running - pacman says:
(1/1) Remove DKMS modules ==> dkms -q remove -q -m vboxguest -v 5.0.20_OSE -k 4.6.1-2-ARCH
==> dkms -q remove -q -m vboxhost -v 5.0.20_OSE -k 4.6.1-2-ARCH
...==> dkms -q install -m vboxguest -v 5.0.20_OSE -k 4.6.2-1-ARCH
==> dkms -q install -m vboxhost -v 5.0.20_OSE -k 4.6.2-1-ARCH
...
Thanks for any thoughts.
gene
That’s expected, and in fact the same thing happens for normal kernel module. I don’t see why DKMS module should be treated differently. ;)
Bruno
On 06/08/2016 02:03 PM, Genes Lists via arch-general wrote:
When I install a new kernel, I notice that DKMS removes previous kernel modules as well as adding them to the new kernel.
In the real old days these were not removed at all - so removal is a good thing. The issue is that the old kernel is still running and until machine is rebooted the modules wont be available I would think. I wonder - Is there a way to mark the deletion to happen after the new kernel is booted ?
I may well be missing something of course.
Well, you'd think it would be nice if the actual kernel itself wasn't removed until the machine is rebooted. Because not all the modules you need were installed with dkms -- most of them come together with the kernel. ;)
Note that any modules which are already loaded will be available, you just can't modprobe a module that no longer exists on disk.
...
There is actually a task on the bugtracker for keeping old kernels: https://bugs.archlinux.org/task/16702
This is probably the best solution -- also, I'm not sure how you'd get rid of dkms modules after the fact, without a way of keeping track of which modules are orphaned. That's kind of why the old service was switched to a pacman hook in the first place.
On Wed, 08 Jun 2016 14:03:18 -0400, Genes Lists via arch-general wrote:
Is there a way to mark the deletion to happen after the new kernel is booted ?
I may well be missing something of course.
What you're missing is, that the directory names in /lib/modules/ differ, but not the kernel names in /boot/.
$ ls -Ggh /boot/vm* -rw-r--r-- 1 4.3M May 11 22:23 /boot/vmlinuz-linux -rw-r--r-- 1 4.4M Nov 18 2015 /boot/vmlinuz-linux-rt -rw-r--r-- 1 4.0M Nov 27 2014 /boot/vmlinuz-linux-rt-lts
If you upgrade the new kernel has got the file name "vmlinuz-linux*", too, so the old kernel must be removed first. However, this could be done without running dkms remove, IOW keeping the directory of the old kernel in /lib/modules/ is possible, but then dkms remove fails later, after the old kernel is removed. By this approach you later need to tidy up /var/lib/dkms/ and /lib/modules/ with the rm command.
If the kernel file names in /boot/ would differ, then it would require to manually remove old kernels and to handle links or to edit boot loader configs. Arch Linux users not necessarily install GRUB2 by their Arch installs and even if they would, they not necessarily want to allow that the config is edited automatically.
It doesn't harm to at least install two different kinds of kernels (e.g. mainline and longterm) and to add at least one kernel to IgnorePkg in /etc/pacman.conf and to upgrade this kernel only, after another kernel was successfully used. So there usually is no reason to collect several versions of the same kind of kernel and the approach that the file names in /boot/ don't differ is usually wanted. IMO it's not an issue to reboot, if a kernel was upgraded and additional modules need to be loaded, that were removed for the currently running kernel. If a reboot would be an issue, then upgrading the kernel later might be the better approach, IOW adding all installed kernels to IgnorePkg could solve this issue.
Regards, Ralf
On Wed, 2016-06-08 at 20:05 +0200, Bruno Pagani wrote:
Le 08/06/2016 à 20:03, Genes Lists via arch-general a écrit :
When I install a new kernel, I notice that DKMS removes previous kernel ...
That’s expected, and in fact the same thing happens for normal kernel module. I don’t see why DKMS module should be treated differently. ;)
Bruno
Thanks for comments all ... makes sense :-)
g
participants (4)
-
Bruno Pagani
-
Eli Schwartz
-
Genes Lists
-
Ralf Mardorf