FS#49318 - [kmod] Pacman hook to update module dependencies

Attached to Project: Arch Linux
Opened by Lachlan (padfoot) - Friday, 13 May 2016, 09:33 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 11 January 2018, 03:35 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Feature request for a pacman hook to update module dependencies when an out of tree kernel module is installed/updated/removed.

Additional info:
I maintain an out of tree kernel module in the AUR, nvidiabl, and was looking at replacing the .install file with a pacman hook.
The .install file calls depmod $(uname -r) on install, update and removal of the module.
I am thinking a hook calling depmod would be more appropriate for the kmod package so other out of tree modules may benefit from it.

I have included a sample hook below to be installed in /usr/share/libalpm/hooks

Appreciate your consideration.
Lachlan.


[Trigger]
Type = File
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/modules/*/

[Action]
Description = Updating kernel module dependencies...
When = PostTransaction
Exec = /usr/bin/depmod $(uname -r)
NeedsTargets
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 11 January 2018, 03:35 GMT
Reason for closing:  Implemented
Additional comments about closing:  We now use pacman hooks provided by the kernel package itself to run depmod.
Comment by Jan de Groot (JGC) - Friday, 13 May 2016, 09:35 GMT
Using uname -r is not the correct way to run depmod. You could be installing an out-of-tree module for a kernel you didn't boot yet.
Comment by Lachlan (padfoot) - Friday, 13 May 2016, 09:57 GMT
@ Jan de Groot, thank you for advising me of that. What would you suggest as being a better way of doing it? I was looking at dkms, but I believe that results in the package losing ownership of the module?

Thanks.
Comment by Dave Reisner (falconindy) - Friday, 13 May 2016, 14:41 GMT
It needs to be even more general than that, since you can now potentially have multiple kernels affected in the same transaction. You'd need to:

1) Figure out which kernel versions are affected by inspecting the list of files passed to the hook
2) Call depmod for each kernel version

In shell, this might look something like:

```
declare -A kernels
while IFS= read -r file; do
read -r kver _ < <(modinfo -F vermagic "$file" 2>/dev/null)
[[ $kver ]] && kernels["$kver"]=1
done

for kver in "${!kernels[@]}"; do
depmod "$kver"
done

```

But this doesn't work for removal since the files will be gone... It's impossible to derive this directly from the path because it may not contain the kernel version, e.g. nvidia's modules are under /usr/lib/modules/extramodules-4.5-ARCH but might have a version of 4.5.4-1-ARCH).
Comment by Lachlan (padfoot) - Friday, 13 May 2016, 21:29 GMT
Could that be resolved by having 2 hooks? The first one runs on install/update on the specific kernel versions affected, and a hook to run on removal which more generically runs on all installed kernel versions (seeing as you can't determine which version is affected), or would that be overkill?
Comment by Eli Schwartz (eschwartz) - Thursday, 04 January 2018, 04:10 GMT
It looks like the best solution to this is to have a hook for each kernel package. This has already been implemented in linux 4.14-2, see https://git.archlinux.org/svntogit/packages.git/commit/trunk/60-linux.hook?h=packages/linux&id=b75f8b225daaa8106215f9237583d9c464767808

This seems like a pretty reasonable solution to me.

Loading...