FS#62879 - [dkms] new dkms messages break alpm-hook

Attached to Project: Arch Linux
Opened by Chris Severance (severach) - Wednesday, 12 June 2019, 06:01 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 27 May 2020, 12:25 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

dkms 2.7.1-1 has some new messages

dgrp, 1.9.39, 3.16.68-1-lts316, x86_64: installed (WARNING! Diff between built and installed module!)
dgrp, 1.9.39, 4.14.125-1-lts414, x86_64: installed (original_module exists)

This breaks the regex in /usr/lib/dkms/alpm-hook which prevents module removal. A quick fix is to remove the EOL '$' from the regex in dkms_remove(). I suspect the '$' should be removed from the regex in check_dependency().

Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
These messages show up on most of my kernel modules.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Wednesday, 27 May 2020, 12:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  dkms 2.8.1-3
Comment by Chris Severance (severach) - Wednesday, 12 June 2019, 07:07 GMT
I'm making a shell script to clean up the dkms mess but it doesn't work yet because the bugs in 2.7.1 are too severe. I can clean and rebuild but not everything gets installed.

The main problem is that 2.7.1 switched to .xz compression (dgrp.ko.xz) without adding fixup code to remove the old modules (dgrp.ko). This litters /usr/lib/modules with orphaned kernel folders.

The error (original_module exists) means that there are two kernel modules of the same but different names, usually dgrp.ko and dgrp.ko.xz.

I've also figured out the error (WARNING! Diff between built and installed module!) means that the built module was not placed in the /usr/lib/modules/kernel/... folder for this kernel even though it built with no error. Modules are installed for kernel>=4.14 and not installed for kernel<=4.9.

Downgrading to dkms 2.5-4 and rebuilding with the fixer script makes a complete set of modules in the expected folders.
Comment by Chris Severance (severach) - Thursday, 13 June 2019, 00:56 GMT
Module compression was added to set_module_suffix. An errant set_module_suffix that was harmless before the compression update gets the suffix for the currently running kernel $(uname -r) rather than the -k specified kernel. Installation fails on kernels where the module is built as a .gz appropriate for the specified kernel version but copied as an .xz appropriate for the running kernel version.
Comment by Térence Clastres (Terence) - Wednesday, 25 September 2019, 12:26 GMT
Any update on this? The regex here https://git.archlinux.org/svntogit/packages.git/tree/trunk/hook.sh?h=packages/dkms#n121 doesn't work if the package has built/installed + something after it like "(original module exists)".
Comment by Chris Severance (severach) - Wednesday, 25 September 2019, 14:19 GMT
https://github.com/dell/dkms/issues/86

While Arch could improve shell scripts to handle the messages it isn't really necessary. The bug of mismanaging compression suffixes is squarely on dkms and so far they haven't taken any action. Once fixed, the only issue is whether I post my dkms rebuilder or not. The bug leaves dkms folders in a huge mess.
Comment by Sébastien Luttringer (seblu) - Thursday, 21 May 2020, 08:25 GMT
The regexp issue should be better in 2.8.1-3. Package is in testing. Feedback welcomed!

Loading...