Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#72135 - [dkms] Pacman hook fails to clean modules in 'added' status

Attached to Project: Arch Linux
Opened by gamezelda (gamezelda) - Tuesday, 14 September 2021, 19:33 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 19 September 2021, 08:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To S├ębastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


(NOTE: This looks similar to FS#72046 but is actually a different bug, that already happened in releases before dkms 2.8.6-1, like dkms 2.8.5-1)


In addition to the 'built' and 'installed' status, DKMS can show an 'added' status for on 'dkms status' output, for kernel modules that have been added to DKMS but has not been successfully built for any kernel version.

An easy (and probably common) way to leave a module in 'added' status is to build a package containing a DKMS module that does never build. For convenience I attach a package with a broken module that you can use for testing.

Ideally the DKMS pacman hook should be able to completely clean up the broken module from DKMS when the package with the broken module is uninstalled, but currently when attempting to remove the package, the DKMS module will print messages saying it can't be removed, the module will remain in status 'added' in 'dkms status' and leftover files will remain in /var/lib/dkms/.

(The module can be cleaned manually with 'dkms remove modulename/1.2.3 --all').

Additional info:
* package version(s): dkms 2.8.5-1
* config and/or log files etc.: N/A / Check below
* link to upstream bug report, if any: Not an upstream bug

Steps to reproduce:

$ tar xf broken-dkms.tar.gz
$ cd broken-dkms/
$ makepkg -si --noconfirm
(2/2) Install DKMS modules
==> dkms install --no-depmod -m broken -v 1.0.0 -k 5.14.2-arch1-2
Error! Bad return status for module build on kernel: 5.14.2-arch1-2 (x86_64)
Consult /var/lib/dkms/broken/1.0.0/build/make.log for more information.
==> Warning, `dkms install --no-depmod -m broken -v 1.0.0 -k 5.14.2-arch1-2' returned 10
==> depmod 5.14.2-arch1-2
$ sudo dkms status
broken, 1.0.0: added
$ pacman -Rns broken-dkms
(1/1) Remove DKMS modules
==> Unable to remove module broken/1.0.0 for kernel 5.14.2-arch1-2: Not found in dkms status output.
$ sudo dkms status
broken, 1.0.0: added
$ ls /var/lib/dkms/broken/1.0.0/
build source
$ # Manual cleanup
$ sudo dkms remove broken/1.0.0 --all

Deleting module version: 1.0.0
completely from the DKMS tree.
$ sudo dkms status
$ ls /var/lib/dkms/broken/1.0.0/
ls: cannot access '/var/lib/dkms/broken/1.0.0/': No such file or directory
This task depends upon

Comment by gamezelda (gamezelda) - Tuesday, 14 September 2021, 19:46 GMT
As far as I can tell the problem is not just that the line in 'dkms status' does not match the regex in ( compare vs ), but that conceptually a module in 'added' status is not associated with any kernel version, but does not seem to take this in mind.

I think the logic should be:

If removing a kernel = all paths in usr/lib/modules/... => Call dkms remove -m "$mod" -v "$mver" -k "$kver" (current logic)
If removing a module = at least one path in usr/src/... => Call dkms remove -m "$mod" -v "$mver" --all" (missing logic)