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.

The two repo packages tp_smapi and -lts contain an entry for /usr/lib/modules-load.d but this one does not. Could you please add this? And thanks for packaging!

Seriously, why is this not in the official repo -.-

Yep, I used totsilence's patch and this built successfully on linux-hardened. If that could be included, that would be neato.

Could you please add this patch:

https://github.com/evgeni/tp_smapi/commit/76c5120f7be4880cf2c6801f872327e4e70c449f.patch

for Linux 4.15? Thanks!

PKGFILE and dkms.conf updated according to the recommendations in https://wiki.archlinux.org/index.php/DKMS: https://paste.pound-python.org/raw/Ny1siod0FOgP6zO5xByW/ https://paste.pound-python.org/raw/MB5uVltk1gDMyTrfhydo/ tp_smapi-dkms.install is no longer needed. Tested to work on my machine with the -hardened kernel.

Does not seem to work, the module is not auto-loaded neither for the mainline nor the -ck kernel for me. Headers are installed and there were no errors reported, but the sysfs entries aren't there...

Pleas use a hook, dkms now have a hook to trigger dkms buildings at install, so the dkms building in the install file is unnedded now and just trigger the dkms building twice.

Reported out of date. Calculated sums not correct anymore and patching fails.

Have put the PKGBUILD and the install file in a pastebin for better readability: http://pastebin.archlinux.fr/1730692 http://pastebin.archlinux.fr/1730693

Improved PKGBUILD: _pkgname=tp_smapi pkgname=${_pkgname}-dkms pkgver=0.41 pkgrel=7 pkgdesc="DKMS controlled modules for ThinkPad's SMAPI functionality" arch=(any) url="http://www.thinkwiki.org/wiki/Tp_smapi" license=('GPL') depends=('dkms') conflicts=('tp_smapi') provides=("tp_smapi=${pkgver%.*}") options=(!strip) install='tp_smapi-dkms.install' source=("https://github.com/x539/tp_smapi/archive/tp-smapi/${pkgver}.tar.gz" 'dkms.conf' 'kbase.patch') sha256sums=('7b7008c2d1cb0849d51fc9791b23dd1f36cf80c899fd4d802878f56abf87516a' '4d2a4804fbacd606d4d9c4f7ab307fa1522d35e021c58ac565ec895483ef4f75' 'b0e53ad7192c9b01bd0897128a1b2453bc28685ad1bd365477eac472065d9d89') prepare() { # patch Makefile for recent kernel module directory change cd "${srcdir}/${_pkgname}-${_pkgname/_/-}-${pkgver}/" patch -p2 < ${srcdir}/kbase.patch sed -i 's/KVER/KERNELRELEASE/g' Makefile } package() { cd "${srcdir}/${_pkgname}-${_pkgname/_/-}-${pkgver}/" mkdir -p "${pkgdir}/usr/src/${_pkgname}-${pkgver}" cp -a {*.{h,c},Makefile} "${pkgdir}/usr/src/${_pkgname}-${pkgver}" cp ${srcdir}/dkms.conf "${pkgdir}/usr/src/${_pkgname}-${pkgver}" } In the dkms.conf set: PACKAGE_NAME="tp_smapi" And in the install file remove all the -dkms suffixes: ver=0.41 post_install() { DKMS=`which dkms 2>/dev/null` echo ">>> DKMS: Module add, build, and install " $DKMS add -m tp_smapi -v $ver for kver in /usr/lib/modules/* do if test -e ${kver}/build then kver="`basename $kver`" $DKMS build -m tp_smapi -v $ver -k $kver $DKMS install -m tp_smapi -v $ver -k $kver echo ">>> Updating kernel modules..." depmod -a $kver fi done } pre_upgrade() { pre_remove } post_upgrade() { post_install } pre_remove() { DKMS=`which dkms 2>/dev/null` echo ">>> DKMS: Module uninstall " line=`$DKMS status -m tp_smapi` if echo "$line" | grep -E 'added|built|installed'; then version=`echo "$line" | sed "s/tp_smapi,\([^,]*\)[,:].*/\1/;t;d"` $DKMS remove -m tp_smapi -v $version --all fi } post_remove() { /sbin/depmod -a } Actually, the install file needs some more work to do: Since you are receiving the module version as a parameter, the first line (ver=) can be omitted.

tp_smapi-ck is a static package. The module is built during makepkg and that's it. This package ships the complete source of the module and some instructions for dkms to build it. That's why this package works with every kernel and why I won't add a specific kernels headers as deps.

I understand. I didn't know that this package is also meant for -ck users. I expected them to use tp_smapi-ck.

> Doesn't everyone use the linux package as it provides the kernel? Nope, for example if someone (like me) has only linux-ck{,-headers} installed, there's no linux{,-headers} present on the system.

@TamCore Thanks for your comment. > even if they don't use the linux package Doesn't everyone use the linux package as it provides the kernel? How can it be an optional dependency only if it was required to have it installed in order to install this package?

No, sorry. This would would require everyone to install linux-headers, even if they don't use the linux package. Also linux-headers is already listed as an optional dependency for dkms.

Can you please add linux-headers as a dependency? Thanks!

master.tar.gz should be tp_smapi-master.tar.gz now.

Any reason this is not arch=('any')?

This package may need to patch Makefile for recent kernel module directory change: KBASE := /lib/modules/$(KERNELRELEASE) to KBASE := /usr/lib/modules/$(KERNELRELEASE)

Please add line `provides=("tp_smapi=${pkgver%.*}")` to the pkgbuild. After this modification, it can be used as dependency by packages, that needs `tp_smapi`.

Changed. Thanks!

This fails to build when invoked right after a kernel install. Needs the below patch: --- dkms.conf.old 2011-08-30 18:36:08.000000000 +0530 +++ dkms.conf.new 2012-05-26 18:16:57.068802873 +0530 @@ -2,7 +2,7 @@ PACKAGE_NAME="tp_smapi-dkms" AUTOINSTALL="yes" -MAKE="make HDAPS=1" +MAKE="make KVER=${kernelver} HDAPS=1" CLEAN="make clean" BUILT_MODULE_NAME[0]="hdaps"

Doesn't build properly. $ makepkg -si ==> ERROR: install file (('tp_smapi-dkms.install')) does not exist. You have to change this line in PKGBUILD: -install=('tp_smapi-dkms.install') +install='tp_smapi-dkms.install'

@TamCore: Could you modify your PKGBUILD to use the latest git snapshot, like in the 'tp_smapi' package (https://aur.archlinux.org/packages/tp/tp_smapi/PKGBUILD)? It supports some of the newer laptops, such as the Lenovo w520/t520/t420, which the current release does not support.