Search Criteria
Package Details: tp_smapi-dkms 0.43-4
Package Actions
Git Clone URL: | https://aur.archlinux.org/tp_smapi-dkms.git (read-only, click to copy) |
---|---|
Package Base: | tp_smapi-dkms |
Description: | DKMS controlled modules for ThinkPad's SMAPI functionality |
Upstream URL: | http://www.thinkwiki.org/wiki/Tp_smapi |
Licenses: | GPL |
Conflicts: | tp_smapi |
Provides: | tp_smapi |
Submitter: | TamCore |
Maintainer: | nosada |
Last Packager: | nosada |
Votes: | 65 |
Popularity: | 0.058101 |
First Submitted: | 2011-08-30 13:12 (UTC) |
Last Updated: | 2021-05-30 07:40 (UTC) |
Dependencies (1)
Required by (7)
- auto-rotation-hdaps-git (requires tp_smapi)
- hdapsicon-git (requires tp_smapi)
- thinkwatt (requires tp_smapi) (optional)
- tlp-git (requires tp_smapi) (optional)
- tlp-pmu (requires tp_smapi) (optional)
- tp-battery-icon-git (requires tp_smapi) (optional)
- xfce4-hdaps (requires tp_smapi)
Latest Comments
nosada commented on 2021-05-30 07:43 (UTC)
@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.
I confirmed there's a bunch of leftovers... Thanks for your advice.
ryshglene commented on 2021-05-28 17:48 (UTC) (edited on 2021-05-28 18:23 (UTC) by ryshglene)
I think I've found the issue.
TLDR: tp_smapi
Makefile
deletes the originalhdaps
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 setHDAPS=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 theMakefile
here: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 patchedhdaps
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.
Edit2: I'm not sure if you've noticed, but your logs clearly shows DKMS moving back files where it shouldn't be:
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):nosada commented on 2021-05-26 15:33 (UTC)
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 showshdaps.ko.xz
is restored from DKMS tree; maybe it's not provided by this package.(I'm using linux-hardened 5.12.6.hardened1-1)
nosada commented on 2021-05-26 15:13 (UTC) (edited on 2021-05-26 15:13 (UTC) by nosada)
hdaps.ko.xz
is by dkms, not by this package itself. So I think it may correct thathdaps.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
:ryshglene commented on 2021-05-24 02:27 (UTC)
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 includedhdaps.ko.xz
in the repository kernel(s), but it shouldn't be deleting files from other packages.guillaumedsde commented on 2020-02-24 22:50 (UTC)
@nosada this seems to be the issue indeed, I am using a Thinkpad T470. Your latest change "fixed" it :)
nosada commented on 2020-02-24 02:46 (UTC) (edited on 2020-02-24 03:03 (UTC) by nosada)
@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 insystemd-modules-load
: https://github.com/linux-thinkpad/tp_smapi/issues/14#issuecomment-24214141I 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
.guillaumedsde commented on 2020-02-22 13:48 (UTC)
Hi @nosada
I'm also having the same issues as @akspecs:
nosada commented on 2020-02-20 14:30 (UTC) (edited on 2020-02-20 14:41 (UTC) by nosada)
@akspecs Hmm, I couldn't reproduce your comment...
FYI, belows are my status about tp_smapi-dkms and systemd-modules-load:
akspecs commented on 2020-02-19 00:33 (UTC) (edited on 2020-02-19 00:35 (UTC) by akspecs)
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.
bertptrs commented on 2020-02-10 08:10 (UTC)
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!Utini commented on 2018-12-30 10:03 (UTC)
Seriously, why is this not in the official repo -.-
CommodoreCrunch commented on 2018-02-10 10:04 (UTC)
Yep, I used totsilence's patch and this built successfully on linux-hardened. If that could be included, that would be neato.
totsilence commented on 2018-02-04 15:18 (UTC)
Could you please add this patch:
https://github.com/evgeni/tp_smapi/commit/76c5120f7be4880cf2c6801f872327e4e70c449f.patch
for Linux 4.15? Thanks!
xxxxme commented on 2017-09-28 23:29 (UTC) (edited on 2017-09-28 23:40 (UTC) by xxxxme)
Soukyuu commented on 2017-05-07 09:58 (UTC)
commented on 2017-01-02 03:10 (UTC)
parazyd commented on 2015-12-20 17:23 (UTC)
socke commented on 2015-11-24 12:21 (UTC)
socke commented on 2015-11-24 11:59 (UTC)
TamCore commented on 2015-01-21 15:29 (UTC)
orschiro commented on 2015-01-21 11:50 (UTC)
TamCore commented on 2015-01-21 10:25 (UTC)
orschiro commented on 2015-01-21 09:37 (UTC)
TamCore commented on 2015-01-21 08:33 (UTC)
orschiro commented on 2015-01-20 22:42 (UTC)
pright commented on 2013-07-10 04:00 (UTC)
eworm commented on 2012-07-18 12:06 (UTC)
felixonmars commented on 2012-07-08 00:40 (UTC)
asch commented on 2012-06-26 14:05 (UTC)
TamCore commented on 2012-05-26 12:58 (UTC)
commented on 2012-05-26 12:48 (UTC)
mazieres commented on 2012-01-30 17:16 (UTC)
chenxiaolong commented on 2011-12-13 05:59 (UTC)