You are not logged in.
If I recall this correctly, modprobe would search for modules in the main module directory, and also in the extramodules directory. Somehow I can't get it to pay attention to the extramodules directory any more ... what am I doing wrong?
Kernel module: nuc_led (drives the LEDs on the Intel NUC), built like this: https://github.com/uboslinux/ubos-devic … d/PKGBUILD
It puts nuc_led.ko.gz into /usr/lib/modules/extramodules-ARCH/
where modprobe cannot find it:
modprobe: FATAL: Module nuc-led not found in directory /lib/modules/4.17.12-arch1-1-ARCH
The module itself loads fine if I use insmod rather than modprobe or move it into that directory.
Maybe two questions:
What exactly is /usr/lib/modules/extramodules-ARCH/ for?
Is /lib/modules/$(uname -r) the only place where modprobe looks?
Last edited by jernst (2018-08-12 23:18:19)
Offline
Not an Installation issue, moving to Kernels...
Offline
Are you sure you haven't updated to linux-4.17.13.arch1-1, and forgot to reboot after it?
Offline
# pacman -Qi linux
Name : linux
Version : 4.17.12.arch1-1
# uname -r
4.17.12-arch1-1-ARCH
Offline
And the extramodules symlink is correct?
# readlink /lib/modules/4.17.12-arch1-1-ARCH/extramodules
../extramodules-ARCH
Other than that, I'm out of ideas. /lib/modules/extramodules-ARCH is correct for out of tree kernel modules, and /lib/modules/$(uname -r) should be the only module look up path for modprobe.
Offline
The symlink is there just as you have it. But here's a tidbit:
I decided to run "strace modprobe nuc-led". The output is surprisingly short, and it only touches these (of the relevant) files:
openat(AT_FDCWD, "/lib/modules/4.17.12-arch1-1-ARCH/modules.dep.bin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/modules/4.17.12-arch1-1-ARCH/modules.alias.bin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/modules/4.17.12-arch1-1-ARCH/modules.symbols.bin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/modules/4.17.12-arch1-1-ARCH/modules.builtin.bin", O_RDONLY|O_CLOEXEC) = 3
So I ran "depmod -a" and voila, it works.
Which poses the question: who is supposed to run depmod -a? Feels wrong that I have to do that myself ...
Addition: there is a pacman hook: 60-linux.hook, which runs
/usr/bin/depmod --quick 4.17.12-arch1-1-ARCH
It should have done the depmod for me, no?
Last edited by jernst (2018-08-11 02:09:09)
Offline
I tried installing intel-nuc-led with the PKGBUILD, and the 60-linux.hook did run fine during post-transaction.
Offline
I confirm that the hook is running, but I think it's the "--quick" that is getting in my way.
If understand the man page correctly, this causes depmod to compare the date on the module with the date on the dependencies file. So if my kernel module was built before (but installed after) the depedencies file was last updated, we're out of luck, no?
Is there something special that a package containing a kernel module should do, e.g. in a post_install script? Like trigger depmod itself?
Offline
You could override the hook in /etc/pacman.d/hooks/ with a version that does not use --quick as a test.
If that works as expected then somehow the modules mtime is older than that of the modules.dep.
Offline
It appears the --quick flag was introduced just a few days ago in this commit:
https://git.archlinux.org/svntogit/pack … 2fa00de6fe
which would explain why this used to work for me :-)
Offline
File a bug report asking for the quick option to be dropped or CONFIG_MODVERSIONS to be disabled which would force strict version matching so the module would have to be built after the kernel.
Offline
Offline