PKGBUILD for a module already present in the kernel

s1gma · 2010-09-05 08:45:10

I'm trying to package a svn version of a kernel module: the module is already in the stable kernel, but I'd like to have the latest build. My PKGBUILD works, except that the package won't install, because the .ko file is alreay in the filesystem, and is owned by kernel26.

$ sudo pacman -U line6linux-svn-685-1-x86_64.pkg.tar.xz
Password: 
resolving dependencies...
looking for inter-conflicts...

Targets (1): line6linux-svn-685-1

Total Download Size:    0.00 MB
Total Installed Size:   0.32 MB

Proceed with installation? [Y/n] 
checking package integrity...
(1/1) checking for file conflicts                  [##########################] 100%
error: failed to commit transaction (conflicting files)
line6linux-svn: /lib/modules/2.6.35-ARCH/kernel/drivers/staging/line6/line6usb.ko exists in filesystem
$ pacman -Qo /lib/modules/2.6.35-ARCH/kernel/drivers/staging/line6/line6usb.ko 
/lib/modules/2.6.35-ARCH/kernel/drivers/staging/line6/line6usb.ko is owned by kernel26 2.6.35.4-1

What is the proper way to solve this ? Install the newer .ko in another directory ?

Last edited by s1gma (2010-09-05 15:29:39)

.:B:. · 2010-09-05 11:37:23

Remove the module before you install your package? Either way, you don't want to have two different versions of the same module in your module tree - how will the kernel decide which one to ignore and which one to load?

tomk · 2010-09-05 12:11:40

Even if you install to a different path, you still have to delete the original module. Alternatively, you can pacman -Uf your package.

s1gma · 2010-09-05 15:33:05

Or maybe I could install it in another location, and then manually unload the old one and load the new one with insmod.
Is there any location like that ?

I don't really want to force pacman, the goal is to make a PKGBUILD. Other users might not want to delete the original module.

.:B:. · 2010-09-05 16:22:31

As I said, you can't keep two modules. The kernel can distinguish between them probably, but not by path, just by the info that's in them (concerning version etc.). Nor can you tell the kernel to blacklist the old module, unless you just put it in the modules array and load the other module manually with insmod (which takes a path, don't think modprobe does). That still leaves the question how the kernel will respond to two modules with the same name though (depmod will probably complain about that).

As tomk said, if you would install the module into a different subdir, then you'd need to ask the user to remove the old one manually. Every approach has its drawbacks.

xduugu · 2010-09-05 19:55:15

Actually, you can override kernel modules by path. Just create a directory "updates" in /lib/modules/<kernel_version> and put your module there.

I don't know where it's documented and never tried it myself (or I've forgot), just read it somewhere. This is the first reference I found. The interesting part:

These steps will create the e1000.k[o] in the e1000/src directory but will not automatically install the kernel module. The remaining steps are:
copy the e1000.k[o] file from the e1000/src directory into the /lib/modules/<KERNEL VERSION>/updates directory. If the updates directory doesn't exist, create it.
# depmod
This will not overwrite the old e1000 kernel module. The newest module will be loaded from the updates directory. If you need to roll back, all you would need to do is delete the e1000.k[o] file from the /lib/modules/<KERNEL VERSION>/updates directory and run depmod.

ngoonee · 2010-09-06 00:58:14

xduugu wrote:

Actually, you can override kernel modules by path. Just create a directory "updates" in /lib/modules/<kernel_version> and put your module there.
I don't know where it's documented and never tried it myself (or I've forgot), just read it somewhere. This is the first reference I found. The interesting part:
These steps will create the e1000.k[o] in the e1000/src directory but will not automatically install the kernel module. The remaining steps are:
copy the e1000.k[o] file from the e1000/src directory into the /lib/modules/<KERNEL VERSION>/updates directory. If the updates directory doesn't exist, create it.
# depmod
This will not overwrite the old e1000 kernel module. The newest module will be loaded from the updates directory. If you need to roll back, all you would need to do is delete the e1000.k[o] file from the /lib/modules/<KERNEL VERSION>/updates directory and run depmod.

Now THAT is something interesting that I've never heard of before.

@OP - this should solve your problems pretty elegantly.

s1gma · 2010-09-07 13:01:05

This indeed did the job !
Fellow guitar / bass players, the PKGBUILD is there ==> http://aur.archlinux.org/packages.php?ID=40604

Allan · 2010-09-07 13:35:28

ngoonee wrote:

xduugu wrote:
Actually, you can override kernel modules by path. Just create a directory "updates" in /lib/modules/<kernel_version> and put your module there.
I don't know where it's documented and never tried it myself (or I've forgot), just read it somewhere. This is the first reference I found. The interesting part:
These steps will create the e1000.k[o] in the e1000/src directory but will not automatically install the kernel module. The remaining steps are:
copy the e1000.k[o] file from the e1000/src directory into the /lib/modules/<KERNEL VERSION>/updates directory. If the updates directory doesn't exist, create it.
# depmod
This will not overwrite the old e1000 kernel module. The newest module will be loaded from the updates directory. If you need to roll back, all you would need to do is delete the e1000.k[o] file from the /lib/modules/<KERNEL VERSION>/updates directory and run depmod.
Now THAT is something interesting that I've never heard of before.
@OP - this should solve your problems pretty elegantly.

This is the solution I use for some patched modules needed for my computer. It works perfectly.

Arch Linux

#1 2010-09-05 08:45:10

PKGBUILD for a module already present in the kernel

#2 2010-09-05 11:37:23

Re: PKGBUILD for a module already present in the kernel

#3 2010-09-05 12:11:40

Re: PKGBUILD for a module already present in the kernel

#4 2010-09-05 15:33:05

Re: PKGBUILD for a module already present in the kernel

#5 2010-09-05 16:22:31

Re: PKGBUILD for a module already present in the kernel

#6 2010-09-05 19:55:15

Re: PKGBUILD for a module already present in the kernel

#7 2010-09-06 00:58:14

Re: PKGBUILD for a module already present in the kernel

#8 2010-09-07 13:01:05

Re: PKGBUILD for a module already present in the kernel

#9 2010-09-07 13:35:28

Re: PKGBUILD for a module already present in the kernel

Board footer