Arch Linux User Repository

@ryshglene Thank you so much for your detailed explanation and patch. It seems to work collectly. I updated this package to 0.43-4 to merge your patch.

If you've been using this package for a while, you should also have a bunch of leftover "restored" hdaps.ko.xz files under /lib/modules from older kernel versions (which there shouldn't be)

I confirmed there's a bunch of leftovers... Thanks for your advice.

I think I've found the issue.

TLDR: tp_smapi Makefile deletes the original hdaps module. DKMS backs it up, so it should be fine, but it doesn't know how to restore it correctly. So it restores it under /lib/modules/$(uname -r)/updates. This results in leftover files under /lib/module by DKMS when removing or upgrading the package. See patch below for fix.

Edit: wrong dir in TLDR

One of the commands DKMS will run during install is make install. Because we set HDAPS=1, one of the things that command will do is remove the original module from the source tree and install its own, as we can see from the Makefile here:

install: modules
        @( [ `id -u` == 0 ] || { echo "Must be root to install modules"; exit 1; } )
        rm -f $(MOD_DIR)/$(TP_DIR)/{thinkpad_ec,tp_smapi,tp_base}.ko
        rm -f $(MOD_DIR)/drivers/firmware/{thinkpad_ec,tp_smapi,tp_base}.ko
        rm -f $(MOD_DIR)/extra/{thinkpad_ec,tp_smapi,tp_base}.ko
ifeq ($(HDAPS),1)
        rm -f $(MOD_DIR)/drivers/platform/x86/hdaps.ko
        rm -f $(MOD_DIR)/extra/hdaps.ko
endif
        $(MAKE) -C $(KBUILD) M=$(PWD) O=$(KBUILD) modules_install
        depmod $(KERNELRELEASE)

Despite removing modules from the kernel package, that's actually all well and good, because DKMS will restore it later for us, when we do dkms remove on the package.

Now, the problem arises when we run dkms remove. As I've seen from your (and my) logs, it looks like, since DKMS installs the module under /lib/modules/$(uname -r)/updates, it also thinks when it has to restore later, it can restore the original module on that same location.

We know this isn't the case, because the kernel package installs its hdaps module under /lib/modules/$(uname -r)/drivers/platform/x86, whereas this package installs its patched hdaps under /lib/modules/$(uname -r)/updates via DKMS.

This disconnect in installation and restore location, causes the issue I've described earlier. And, surprisingly, it's already been observed years ago on this Fedora bug report I've found (albeit with a different module).

The solution I've found is simple. Since we want DKMS to restore under /lib/modules/$(uname -r)/drivers/platform/x86, we also tell DKMS to install on that same location. That way, we won't have to deal with DKMS not knowing how to put things back where it got them from.

Applying this patch solves the issue for me. Please update the package if you get the same results.

diff --git a/PKGBUILD b/PKGBUILD
index ee11257..bd4d05e 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,7 +13,7 @@ source=("https://github.com/linux-thinkpad/tp_smapi/releases/download/tp-smapi%2
         'dkms.conf'
         'kbase.patch')
 sha256sums=('bcef9cd045d52a74d719b2a67ac4f5324994a856f123c0fbc55f1d769d367110'
-            'ad75d30622f7d40ad00daa784776bb595c2ac4736fa58f492d7f0d6948e0a832'
+            '43aa280c078fc5ba0ee229b9c71238e215313315711f3d3caae7b9bd0ab24dbe'
             '4bcce516a9f3c486a934cfe6e3d3c92443833f4094ec008ce25264d1a5b66097')

 prepare() {
diff --git a/dkms.conf b/dkms.conf
index ae2ccd4..57d3175 100644
--- a/dkms.conf
+++ b/dkms.conf
@@ -5,7 +5,7 @@ CLEAN="make clean"
 AUTOINSTALL="yes"

 BUILT_MODULE_NAME[0]="hdaps"
-DEST_MODULE_LOCATION[0]="/updates"
+DEST_MODULE_LOCATION[0]="/kernel/drivers/platform/x86"

 BUILT_MODULE_NAME[1]="thinkpad_ec"
 DEST_MODULE_LOCATION[1]="/extra"

Edit2: I'm not sure if you've noticed, but your logs clearly shows DKMS moving back files where it shouldn't be:

hdaps.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/
 - Original module
   - Archived original module found in the DKMS tree
   - Moving it to: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/

If you've been using this package for a while, you should also have a bunch of leftover "restored" hdaps.ko.xz files under /lib/modules from older kernel versions (which there shouldn't be):

$ find /lib/modules -name hdaps.ko.xz

Ah, no, I'm misunderstanding. dkms will delete module on pre-transaction hook in pacman -R...

I manually call dkms remove --no-depmod -m tp_smapi-dkms and it shows hdaps.ko.xz is restored from DKMS tree; maybe it's not provided by this package.

sudo dkms remove --no-depmod -m tp_smapi-dkms -v 0.43 -k 5.12.6-hardened1-1-hardened

-------- Uninstall Beginning --------
Module:  tp_smapi-dkms
Version: 0.43
Kernel:  5.12.6-hardened1-1-hardened (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

hdaps.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/
 - Original module
   - Archived original module found in the DKMS tree
   - Moving it to: /usr/lib/modules/5.12.6-hardened1-1-hardened/updates/

thinkpad_ec.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/extra/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


tp_smapi.ko.xz:
 - Uninstallation
   - Deleting from: /usr/lib/modules/5.12.6-hardened1-1-hardened/extra/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

Removing original_module from DKMS tree for kernel 5.12.6-hardened1-1-hardened (x86_64)

DKMS: uninstall completed.

(I'm using linux-hardened 5.12.6.hardened1-1)

hdaps.ko.xz is by dkms, not by this package itself. So I think it may correct that hdaps.ko.xz isn't deleted when uninstalling this package.

As far as I'm concerned, the followings will be deleted on removal by pacman -R tp_smapi-dkms:

$ pacman -Ql tp_smapi-dkms
tp_smapi-dkms /usr/
tp_smapi-dkms /usr/src/
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/Makefile
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/dkms.conf
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/hdaps.c
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/thinkpad_ec.c
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/thinkpad_ec.h
tp_smapi-dkms /usr/src/tp_smapi-dkms-0.43/tp_smapi.c

This package has weird behavior.

It deletes the existing hdaps.ko.xz from the kernel package, and installs its own in under /lib/modules/$(uname -r)/updates/hdaps.ko.xz.

On removal, it doesn't remove the created /lib/modules/$(uname -r)/updates/hdaps.ko.xz, which dirties the /lib/modules/ directory with some unowned files.

I'm not sure how this could be fixed yet, but I think it needs some attention. I understand that the updates directory is for overriding the included hdaps.ko.xz in the repository kernel(s), but it shouldn't be deleting files from other packages.

@nosada this seems to be the issue indeed, I am using a Thinkpad T470. Your latest change "fixed" it :)

@guillaumedsde @akspecs

I couldn't reproduce your comments yet...

But I found upstream says newer ThinkPad doesn't have SMAPI and this cause failure on modprobe, similar to one in systemd-modules-load: https://github.com/linux-thinkpad/tp_smapi/issues/14#issuecomment-24214141

I suppose you met this condition (I'm using old model: ThinkPad X201s).

For now I'll update 0.43-3 to remove /usr/lib/modules-load.d/tp_smapi-dkms.conf.

Hi @nosada

I'm also having the same issues as @akspecs:

● systemd-modules-load.service - Load Kernel Modules
     Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sat 2020-02-22 13:30:15 GMT; 18min ago
       Docs: man:systemd-modules-load.service(8)
             man:modules-load.d(5)
   Main PID: 523 (code=exited, status=1/FAILURE)

févr. 22 13:30:15 jarvis systemd[1]: Starting Load Kernel Modules...
févr. 22 13:30:15 jarvis systemd-modules-load[523]: Failed to insert module 'tp_smapi': No such device or address
févr. 22 13:30:15 jarvis systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
févr. 22 13:30:15 jarvis systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
févr. 22 13:30:15 jarvis systemd[1]: Failed to start Load Kernel Modules.

 architect@jarvis  ~  pacman -Qs tp_smapi-dkms
local/tp_smapi-dkms 0.43-2
    DKMS controlled modules for ThinkPad's SMAPI functionality
 architect@jarvis  ~  pacman -Ql tp_smapi-dkms | grep modules-load
tp_smapi-dkms /usr/lib/modules-load.d/
tp_smapi-dkms /usr/lib/modules-load.d/tp_smapi-dkms.conf
 architect@jarvis  ~  cat /usr/lib/modules-load.d/tp_smapi-dkms.conf
tp_smapi
 architect@jarvis  ~  systemctl is-active systemd-modules-load
failed
 ✘ architect@jarvis  ~  lsmod | grep tp_smapi
 ✘ architect@jarvis  ~  

@akspecs Hmm, I couldn't reproduce your comment...

FYI, belows are my status about tp_smapi-dkms and systemd-modules-load:

$ pacman -Qs tp_smapi-dkms
local/tp_smapi-dkms 0.43-2
    DKMS controlled modules for ThinkPad's SMAPI functionality

$ pacman -Ql tp_smapi-dkms | grep modules-load
tp_smapi-dkms /usr/lib/modules-load.d/
tp_smapi-dkms /usr/lib/modules-load.d/tp_smapi-dkms.conf

$ cat /usr/lib/modules-load.d/tp_smapi-dkms.conf
tp_smapi

$ systemctl is-active systemd-modules-load
active

$ lsmod | grep tp_smapi
tp_smapi               45056  0
thinkpad_ec            16384  1 tp_smapi

after the recent change in the PKGBUILD:

systemctl status systemd-modules-load.service

...

'tp_smapi': No such device or address

Feb 18 16:20:14 arch-x1hack systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE

Feb 18 16:20:14 arch-x1hack systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.

Feb 18 16:20:14 arch-x1hack systemd[1]: Failed to start Load Kernel Modules.