on kernel-update, dkms errors out and can only be installed after reboot

[Termuellinator]

First of all: thank you for the driver! :D

The only issue i encounter is that the dkms modules can't be installed on kernel update because dkms is trying to install them in the old kernel:

[2021-09-21T00:12:44+0200] [ALPM-SCRIPTLET] ==> dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.14.6-2-MANJARO
[2021-09-21T00:12:44+0200] [ALPM-SCRIPTLET] Error! Bad return status for module build on kernel: 5.14.6-2-MANJARO (x86_64)
[2021-09-21T00:12:44+0200] [ALPM-SCRIPTLET] Consult /var/lib/dkms/hid-tmff2/0.8/build/make.log for more information.
[2021-09-21T00:12:44+0200] [ALPM-SCRIPTLET] ==> Warning, `dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.14.6-2-MANJARO' returned 10
[2021-09-21T00:12:44+0200] [ALPM-SCRIPTLET] ==> dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.10.67-1-MANJARO
[2021-09-21T00:12:45+0200] [ALPM-SCRIPTLET] Error! Bad return status for module build on kernel: 5.10.67-1-MANJARO (x86_64)
[2021-09-21T00:12:45+0200] [ALPM-SCRIPTLET] Consult /var/lib/dkms/hid-tmff2/0.8/build/make.log for more information.
[2021-09-21T00:12:45+0200] [ALPM-SCRIPTLET] ==> Warning, `dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.10.67-1-MANJARO' returned 10
[2021-09-21T00:12:45+0200] [ALPM-SCRIPTLET] ==> dkms install --no-depmod -m hid-xpadneo -v 0.9.1 -k 5.14.6-2-MANJARO

as i only encounter this behaviour with hid-tmff2, i would assume it's something in your dkms.conf (i have no experiencing in packaging dkms though). One thing that i notice when looking at the dkms.conf file and comparing it to xpadneo's .conf-file (which works as expected here) is the MAKE line:
MAKE[0]="make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src VERSION=$PACKAGE_VERSION modules"
maybe that has something to do with it?

[Kimplul]

Hi, thanks for the report. I'm not too familiar with dkms myself, but could you post the output of /var/lib/dkms/hid-tmff2/0.8/build/make.log?

[Termuellinator]

There is no build folder in 0.8, just folders for every kernel. In those we have /x86_64/log/make.log files with content:

DKMS make.log for hid-tmff2-0.8 for kernel 5.14.6-2-MANJARO (x86_64)
Di 21. Sep 08:44:39 CEST 2021
make -C hid-tminit 
make[1]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird betreten
make -C /lib/modules/5.14.6-2-MANJARO/build M=/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit modules
make[2]: Verzeichnis „/usr/lib/modules/5.14.6-2-MANJARO/build“ wird betreten
  CC [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tminit/hid-tminit.o
  MODPOST /var/lib/dkms/hid-tmff2/0.8/build/hid-tminit/Module.symvers
  CC [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tminit/hid-tminit.mod.o
  LD [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tminit/hid-tminit.ko
  BTF [M] /var/lib/dkms/hid-tmff2/0.8/build/hid-tminit/hid-tminit.ko
make[2]: Verzeichnis „/usr/lib/modules/5.14.6-2-MANJARO/build“ wird verlassen
make[1]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird verlassen
make -C /lib/modules/5.14.6-2-MANJARO/build M=/var/lib/dkms/hid-tmff2/0.8/build modules
make[1]: Verzeichnis „/usr/lib/modules/5.14.6-2-MANJARO/build“ wird betreten
  CC [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tmt300rs.o
  MODPOST /var/lib/dkms/hid-tmff2/0.8/build/Module.symvers
  CC [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tmt300rs.mod.o
  LD [M]  /var/lib/dkms/hid-tmff2/0.8/build/hid-tmt300rs.ko
  BTF [M] /var/lib/dkms/hid-tmff2/0.8/build/hid-tmt300rs.ko
make[1]: Verzeichnis „/usr/lib/modules/5.14.6-2-MANJARO/build“ wird verlassen

That's from the dkms autoinstall this morning though.
No sign of the failed install through the pacman hook from yesterday nights update though - probably the /0.8/build/make.log got auto-cleaned? When i checked that file after update it said something like "folder not found" and referred to folders for the old, currently active kernel (that of course got removed during update) instead of the new, updated kernel version. I'm note sure why the same is happening for 5.10 as thate one was not loaded but still shows the same error.

[Kimplul]

I'm not entirely sure if this is the issue but I noticed that when reinstalling the module with dkms, it alternates between using the MAKE[0] command and some predefined one, i.e. the one in your dkms autoinstall. In my Makefile I check the kernel source directory by using uname -r, which only gets the current running kernel, so if dkms tries to build for a kernel that was just installed, it might fail under some circumstances when executing MAKE[0], but succeeds when using the predefined one. I think.

Anyway, I made some changes to the dkms.conf based on this theory. Seems to still work on my machine, although I'm not sure how it behaves when push comes to shove. Should be the newest commit in the master branch, try installing it and please report back if you see similar issues with it.

[Termuellinator]

Thanks, will try and report back after the next kernel update! :)

[Termuellinator]

Unfortunately, still the same issue:

==> dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.10.68-1-MANJARO
Error! Bad return status for module build on kernel: 5.10.68-1-MANJARO (x86_64)
Consult /var/lib/dkms/hid-tmff2/0.8/build/make.log for more information.
==> Warning, `dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.10.68-1-MANJARO' returned 10
==> dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.14.7-2-MANJARO
Error! Bad return status for module build on kernel: 5.14.7-2-MANJARO (x86_64)
Consult /var/lib/dkms/hid-tmff2/0.8/build/make.log for more information.
==> Warning, `dkms install --no-depmod -m hid-tmff2 -v 0.8 -k 5.14.7-2-MANJARO' returned 10

/var/lib/dkms/hid-tmff2/0.8/build/make.log:

DKMS make.log for hid-tmff2-0.8 for kernel 5.14.7-2-MANJARO (x86_64)
Do 23. Sep 13:01:36 CEST 2021
make -C hid-tminit 
make[1]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird betreten
make -C /lib/modules/5.14.6-2-MANJARO/build M=/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit modules
make[2]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird betreten
make[2]: *** /lib/modules/5.14.6-2-MANJARO/build: Datei oder Verzeichnis nicht gefunden.  Schluss.
make[2]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird verlassen
make[1]: *** [Makefile:5: all] Fehler 2
make[1]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird verlassen
make: *** [Makefile:17: hid-tminit] Fehler 2

what i notice is that the dkms.conf file in the build dir still has MAKE[0]="'make'" instead of the lines in your new commit?
edit: i see /usr/src/hid-tmff2-0.8/ still contains the same dkms.conf so i guess something went wrong when i updated the driver, my bad.

edit 2: i removed (what a hassle with a broken state...) the modules and installed it again, verifying to have the correct dkms.conf - now i get a slightly different error:

[sudo] Passwort für termy: 
Creating symlink /var/lib/dkms/hid-tmff2/0.8/source -> /usr/src/hid-tmff2-0.8
Error! Your kernel headers for kernel 5.14.6-2-MANJARO cannot be found at /usr/lib/modules/5.14.6-2-MANJARO/build or /usr/lib/modules/5.14.6-2-MANJARO/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.
Error! Your kernel headers for kernel 5.14.6-2-MANJARO cannot be found at /usr/lib/modules/5.14.6-2-MANJARO/build or /usr/lib/modules/5.14.6-2-MANJARO/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.

5.14.6-2 is the currently running, "old" kernel, so it seems it's trying to install it twice (for 5.14 and 5.10), but still resorting to the currently running kernel version setting the paths.

Looking through the repo i notice that your makefile uses KDIR ?= /lib/modules/$(shell uname -r)/build which would explain this behaviour i think?
Xpadneo (that i can confirm working through updates) uses a different approach that doesn't depend on uname -r - i guess that explains the difference?

[Kimplul]

Looking through the repo i notice that your makefile uses KDIR ?= /lib/modules/$(shell uname -r)/build which would explain this behaviour i think?

The commit I pushed a couple days ago sets the KDIR variable to $kernel_source_dir in dkms.conf, so it should behave the same way as xpadneo's make line. I would assume at least, mainly I'm a bit confused about the error message in your edit as that one seems to be from dkms itself and not my makefile.

[Termuellinator]

I don't think thats the same - xpadneo uses /usr/src/linux als variable KERNEL_SOURCE_DIR, not $kernel_source_dir which is probably giving out the source dir for the running kernel?
I'm not sure why /usr/src/linux should work though as that dir doesn't exist here 🤔

[Kimplul]

I think we're talking past eachother. If you look into xpadneo's dkms.conf, you'll see that their MAKE[0] is

MAKE[0]="make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src VERSION=$PACKAGE_VERSION modules"

It seems like they completely skip running their own makefile and instead directly use the one found in $kernel_source_dir. At the moment my dkms.conf doesn't skip my makefile, but it does set KDIR=$kernel_source_dir, which is used as the argument for the -C flag in my makefile.

I still don't understand the error message from dkms itself, this one:

Error! Your kernel headers for kernel 5.14.6-2-MANJARO cannot be found at /usr/lib/modules/5.14.6-2-MANJARO/build or /usr/lib/modules/5.14.6-2-MANJARO/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.

It seems like dkms is trying to compile hid-tmff2 against an old kernel version, whose headers have already been removed. Does the compilation succeed if you try to run dkms with the newer kernel running?

[Termuellinator]

That's what i think, too - the errors in the make.log also point to the directories of the "old" (but at that moment still running) kernel versions. And those got removed during the update to a newer kernel version of course - same with the headerfiles in the dkms-error.
After rebooting, it successfully installs for the currently running kernel, but not for the other ones (both when trying dkms autoinstall and your dkms-install.sh) - the other ones are installed correctly when i explicitly issue sudo dkms install hid-tmff2/0.8 -k 5.10.68-1-MANJARO though.

[Kimplul]

Could you clarify the last command:

sudo dkms install hid-tmff2/0.8 -k 5.10.68-1-MANJARO

From what I've understood so far, when updating the kernel the headers for the old kernel are removed by pacman. If you manually tell dkms to compile for an older kernel, it succeeds?

That shouldn't be possible, as the compilation depends on the headers for the specified version.

[Termuellinator]

i have both linux510 and linux514 installed, so that's not an old version that is removed but the currently installed version of linux510 - headers for both kernel series are installed.
But when updating, dkms is trying to use the older kernel-versions (both for 5.14 that is running as well as 5.10 that is not running) - whose files (including headers of course) have been removed.

During the update, the pacman-hook tries to install it for the current version
but according to the make.log, it is trying to build it in the directory of the no longer installed version:

DKMS make.log for hid-tmff2-0.8 for kernel 5.14.7-2-MANJARO (x86_64)
Do 23. Sep 13:01:36 CEST 2021
make -C hid-tminit 
make[1]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird betreten
make -C /lib/modules/5.14.6-2-MANJARO/build M=/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit modules
make[2]: Verzeichnis „/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit“ wird betreten
make[2]: *** /lib/modules/5.14.6-2-MANJARO/build: Datei oder Verzeichnis nicht gefunden.  Schluss.

see the version in the first line and the directory it's trying to use in the 5th line.
I would assume that it's the same for the 5.10 series, but the make.log of that probably gets overwritten by the make.log of the 5.14 series immediately.
xpadneo gets successfully installed for every updated kernel series on update. I've used some other dkms modules in the past (corefreq, zenpower and new-lg4ff, though with new-lg4ff i'm not 100% sure if it went through a kernel update, only had it a short while), but never observed this behaviour.

Looking at those though, they also use uname -r in either makefile or dkms.conf, so that shouldn't be it then 🤔

[Kimplul]

Oh, right, thanks, that clears things up.

I tried installing a new kernel on debian, and from the dkms log I can see

'make' KDIR=/lib/modules/5.10.0-8-rt-amd64/build

and in the corresponding make.log

make -C /lib/modules/5.10.0-8-rt-amd64/build M=/var/lib/dkms/hid-tmff2/0.8/build/hid-tminit modules

with my current running kernel being 5.10.0-8-amd64. In short, works on my machine™. I'm a bit stumped to be honest.

Could you still check dkms status if there's something weird going on there? In theory it should only show installed for all kernel versions of the module.

[Termuellinator]

~ >>> dkms status
hid-tmff2/0.8, 5.10.68-1-MANJARO, x86_64: installed
hid-tmff2/0.8, 5.14.7-2-MANJARO, x86_64: installed

very strange behaviour indeed - i'm tempted to setup a manjaro-vm and see if i can replicate the behaviour there or if it's something weird (whatever on earth that might be) with my machine...maybe i'll find time for that tomorrow. Would still be strange that only hid-tmff2 seems affected.

Where do you find the dkms log? I can't find any information about that?

[Kimplul]

Sorry, unclear wording. I meant that that was the output of dkms when I updated my kernel with apt. In my case the output can be seen in /var/log/apt/term.log, pacman apparently has something similar in /var/log/pacman.log. Or just piping the output of pacman to a file.

Would still be strange that only hid-tmff2 seems affected.

I don't rule out the possibility of an issue with my dkms.conf, but there isn't a lot to go wrong there and as stated, can't replicate on Debian, so not sure where to even start looking for solutions. If you find out something, please give me an update.

[Kimplul]

Hang on, I might've overlooked something massive. hid-tminit has to be compiled as well, and I though MAKECMDGOALS would contain the whole argument line passed to make. Turns out that no, that's not what it does, it just contains the rules that should be built, i.e. all or clean or whatever. In essence, KDIR wasn't being updated in hid-tminit and it was still using uname -r. I pushed a new commit that updates the KDIR in hid-tminit as well. Sorry, I apparently misread the make documentation when I came up with my idea to use MAKECMDGOALS.

[Termuellinator]

Good catch!
I just tried downgrading linux510 with that change and it installed properly, as well as when upgrading back to the current version - so from that it seems that this indeed fixes the problem! :D
I'll wait for the next real-world update and report back (and hopefully close the issue ^^)
Thanks for your effort!

[Termuellinator]

Good news! Finally another real update and it worked as expected 👍
Thanks again!

[Kimplul]

Nice, thanks for the help.