DKMS module removed completely when last kernel removed

[ian-abbott]

I'm not sure if this is a bug. If a DKMS module/module-version has been added, built and installed for a single kernel/arch, and is then removed for that kernel/arch it is removed completely and cannot be built and installed for another kernel/arch until it is added again manually.

The relevant part of the dkms script is:

    # Delete the $module_version part of the tree if no other $module_version/$kernel_version dirs exist
    if ! find $dkms_tree/$module/$module_version/* -maxdepth 0 -type d 2>/dev/null | egrep -qv "(build|tarball|driver_disk|rpm|deb|source)$"; then
        echo $""
        echo $"------------------------------"
        echo $"Deleting module version: $module_version"
        echo $"completely from the DKMS tree."
        echo $"------------------------------"
        rm -rf "$dkms_tree/$module/$module_version"
        echo $"Done."
    fi

This looks as if the module/version should not be removed completely if $dkms_tree/$module/$module_version/source is a directory. It is usually a symbolic link, and the above find command will not find it in that case. Perhaps the above find command should use the -H or -L option so that it finds the source symlink. Or perhaps the module version should not be removed completely unless the --all option is given.

[GoPerry]

@ian-abbott
When you remove the dkms module with dkms remove -m xxx -v xxx,then if you want to build and install again. firstly you need to run dkms add command.

[ian-abbott]

@yuzaipiaofei
The trouble I'm having is that the remove command does two different things. It acts like an "uninstall&unbuild" step, and then, if no more kernels are using it, it forgets the module/version entirely. I'm looking for some mechanism that skips the "forget the module/version entirely" part.

On Debian, if you reinstall a kernel package, it first removes the DKMS modules for the kernel, which may result in DKMS forgetting the module/version entirely. Then after the kernel is reinstalled and DKMS is triggered to rebuild the modules, the module/version is no longer present. This requires manual use of the dkms commands afterwards to re-add and reinstall the desired modules.

[GoPerry]

@ian-abbott
So your issue is failed to rebuild and reinstall the modules when you were updating your kernel image?
0c19129#diff-aad3509f2a95a1bef3d5a4dcd105e1fd

How do you remove your kernel image?

then which dkms version you are using ?

[ian-abbott]

@yuzaipiaofei
I'm using the dkms 2.3-2 package from Debian "Stretch". I'm running it on an embedded ARM system with custom-built linux-image and linux-headers .deb packages installed with dkpg -i. The problem occurs when the linux-image package for the same kernel version (but possibly a different deb package revision) is reinstalled with dpkg -i. In that case, the /etc/kernel/prerm.d/dkms script from Debian's dkms package (not part of the upstream dkms sources) gets run, which removes all dkms modules for the kernel being reinstalled. SInce I only have one kernel version installed, the dkms remove command removes the module/version completely.

I think I have a clue what is going wrong. The custom linux-image debian package includes a "prerm" script that gets run by the dpkg command during upgrade/reinstallation or removal, and it is this script that runs the /etc/kernel/prerm.d/* scripts, including /etc/kernel/prerm.d/dkms. The first parameter of the package's "prerm" script is the operation type, e.g. "upgrade" or "remove". The "prerm" script in my custom-built linux-image package is running the /etc/kernel/prerm.d/* scripts regardless of the operation type, whereas the standard, shipped, Debian linux-image packages only run those scripts when the operation type is "remove". So I could fix it by replacing the "prerm" script in my custom linux-image package somehow. (The "prerm" script I am using is actually output by scripts/package/builddeb in the Linux kernel sources, run as part of the "deb-pkg" target of the Linux kernel Makefile, so it's not that bizarre!)

Still, it would be nice if the dkms remove command had an option (suggested name: --keep) to not undo the dkms add when the final kernel/arch is removed for the module/version.

[vmspike]

I have the same issue on upgrade between recent official Raspbian kernels.
/etc/kernel/prerm.d/dkms call (with dkms remove ... inside) completely remove all modules from dkms tree on kernel upgrade because it calls when new kernel headers are unavailable yet.

As a workaround for specific module some additional directory can be created in $dkms_tree/$module/$module_version/, for example /var/lib/dkms/mymodule/0.1/workaround_full_dkms_remove. This way we deceive this dkms check: if ! find $dkms_tree/$module/$module_version/* -maxdepth 0 -type d 2>/dev/null | egrep -qv "(build|tarball|driver_disk|rpm|deb|source)$"; then .

[ian-abbott]

So the main problem seems to be that Debian's dkms is based on dkms 2.3, and doesn't have the changes from commit 0c19129 that made it into dkms 2.4. That changed the "uninstall" functionality to also effectively unbuild the module (by deleting the build directory), despite what the man page says, and changed the kernel_prerm.d_dkms script to do an "uninstall" instead of a "remove".

So Debian should probably cherry-pick that commit and update its own dkms kernel prerm script accordingly.

[evelikov]

MR #117 provides for a clear separation, allowing you to reach what you're looking for.

Namely, there are three commands each removing:

• the symlinks/copy of the kernel module(s) in /lib/modules (uninstall)
• all the build module(s) in /lib/modules and /var/lib/dkms (unbuild)
• removing everything (remove)

[evelikov]

With the above MR, one can use "remove" or "unbuild" depending on their need.
I believe that resolves this issue and we can close this.

[RalfGoebel]

Is there any reason why the "unbuild" command is not used in the kernel prerm script?

dkms/kernel_prerm.d_dkms

Line 10 in 1194db8

dkms remove -m "$name" -v "$vers" -k "$inst_kern" -a "$arch"

[evelikov]

Good question @RalfGoebel - the script prerm seems to be Debian specific and my Debian knowledge is rather limited. I would encourage you to open a MR with some context behind the change.

As follow-up you might also want to help reduce (remove really) the Debian patchset and scripts - they have 12 year old, prerm duplicate 😱