The modules are not kernel specific.
On the contrary, they very much are. Even without CONFIG_MODVERSIONS, you'll get an -EINVAL trying to init_module() a module for another kernel. CONFIG_MODVERSIONS provides some additional protection against this (look at the "vermagic" string for any module in the output of modinfo).
In this case, though, it would be a matter of a single missing symlink, assuming the kernel package in question doesn't create it.
No, you can't just make this symlink into your own module tree and expect things to work. You really need to compile these modules against your own kernel.
]]>/usr/lib/modules/3.5.6-1-ARCH # ls -l
...
lrwxrwxrwx 1 root root 24 Oct 7 12:39 extramodules -> ../extramodules-3.5-ARCH/
...
pacman -Qo shows:
/usr/lib/modules/3.5.6-1-ARCH/extramodules is owned by linux 3.5.6-1
You're right that it's all or nothing, but the way Arch sets up the system, it's "all".
]]>In this case, though, it would be a matter of a single missing symlink, assuming the kernel package in question doesn't create it.
Why would the kernel package create a module-specific symlink? Unless you're talking about symlinking the extramodules folder, which would problematic since that would be all-or-nothing in terms of which modules are available.
]]>Are Arch's patches that extensive that they make major changes to the kernel headers? If not, the modules are not kernel specific, they're version specific (within reason). Assuming the modules are for the correct version of the kernel, the one kernel you're using has loadable module support, and it doesn't have major patching itself, the modules are very likely to work. The issue here has nothing to do with the modules themselves but with how pacman handles dependency resolution.
The modules are not kernel specific. Their location is. Arch packages aren't simply files, they're files in particular locations. AFAICR kernels search for modules only within specific directories by default.
Of course, it would be possible to make modules general with an expansion of the current extramodules structure, but that's beyond the scope of this topic (not to mention, IMO, a really bad idea).
@silverwind - please mark the topic as [solved] by editing your first post and changing the title
]]>silverwind wrote:I'm still not sure what the core problem here is really
You're trying to install a module which is specifically for the ARCH kernel (see my previous post) and expecting your own non-stock kernel to magically detect that module even though its not in the correct extramodules-*-* folder.
In general, EVERY module is kernel specific. Pre-compiled kernel modules will only work on the stock ARCH kernel (or on an abs-modified version of it).
Ah, that clears it up then. No reason to try force installing these modules then. Thanks!
]]>I'm still not sure what the core problem here is really
You're trying to install a module which is specifically for the ARCH kernel (see my previous post) and expecting your own non-stock kernel to magically detect that module even though its not in the correct extramodules-*-* folder.
In general, EVERY module is kernel specific. Pre-compiled kernel modules will only work on the stock ARCH kernel (or on an abs-modified version of it).
]]>I really wonder if the simplest solution is just to build the modules yourself through the abs.
]]>Here's the package again:
pacman -Si virtualbox-host-modules
Name : virtualbox-host-modules
Version : 4.2.0-5
Depends On : linux>=3.5 linux<3.6
And here the running kernel:
pacman -Qi kernel-netbook
Name : kernel-netbook
Version : 3.5.2-1
Provides : linux
And the 3.6, also from AUR:
pacman -Qi linux-mainline
Name : linux-mainline
Version : 3.6-1
Provides : kernel26-mainline=3.6
Does 3.6 which provides kernel26 make the dependancy check fail?
Oh, and sorry for not mentioning the installed 3.6 earlier.
the virtualbox packages don't depend on "kernel26", though, they depend on "linux".
You asked for a cleaner way https://bbs.archlinux.org/viewtopic.php … 3#p1172743 - you can specify either linux or the old kernel26 as a dependency.. I guess this way old stuff that depended on kerlen26 may still work.
Hmm, not sure what the # operator does in that script.
${parameter#word}
${parameter##word}
Remove matching prefix pattern. The word is expanded
to produce a pattern just as in pathname expansion. If
the pattern matches the beginning of the value of
parameter, then the result of the expansion is the
expanded value of parameter with the shortest matching
pattern (the ``#'' case) or the longest matching pat‐
tern (the ``##'' case) deleted. If parameter is @ or
*, the pattern removal operation is applied to each
positional parameter in turn, and the expansion is the
resultant list. If parameter is an array variable sub‐
scripted with @ or *, the pattern removal operation is
applied to each member of the array in turn, and the
expansion is the resultant list.
In this case, the result is '' - i.e. nothing.
]]>]]>Hmm, not sure what the # operator does in that script.
pkgver=3.6.1
...
provides=("kernel26${_kernelname}=${pkgver}")
$ pacman -Qi linux | grep Provides
Provides : kernel26=3.6.1
(I'm using [testing]).
]]>