Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 67804

Summary: ${KV} contains wrong kernel version for kernels from 2.6.9 on.
Product: Gentoo Linux Reporter: Bernd Wurst <bugzilla-gentoo>
Component: [OLD] Core systemAssignee: Portage team <dev-portage>
Severity: critical CC: brianpankey, gentoo, henrik, kernel, ogunden, polyhead
Priority: High Keywords: InVCS
Version: unspecified   
Hardware: All   
OS: All   
Package list:
Runtime testing required: ---
Attachments: fix-portage-kernel-localversion.patch

Description Bernd Wurst 2004-10-16 12:50:22 UTC
Kernel versions 2.6.9-rc and later do have the ability to set a version 
appendix in the configuration, so that you don't have to edit the makefile any 

This breaks *all* kernel related ebuilds, because ${KV} contains the wrong 

See the kernel Makefile:
LOCALVERSION = $(subst $(space),, \
               $(shell cat /dev/null $(localversion-files)) \
               $(subst ",,$(CONFIG_LOCALVERSION)))


So ${KV} should either to the same thing, the makefile does or should use 
$(uname -r) for kernel version.

And no, it's not an option to replace ${KV} with $(uname -r) in all related 
ebuild files. ;-)
Comment 1 John Mylchreest (RETIRED) gentoo-dev 2004-10-17 04:46:43 UTC
uname -r won't be an acceptable solution as it goes against policy.
Comment 2 Daniel Drake (RETIRED) gentoo-dev 2004-10-24 12:52:22 UTC
*** Bug 68728 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2004-10-27 15:43:04 UTC
John, any progress on this? Would like to see it fixed..
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2004-10-28 14:14:36 UTC
$KV is defined in so I'm reassigning to them.

Here's the story:

2.6.9 introduced a new kernel config option allowing the user to define their own custom string to append to the kernel version string. For example, development-sources-2.6.9 normally has a version string of "2.6.9", but if I set the new CONFIG_LOCALVERSION option to "-dsd" then my version string would be "2.6.9-dsd". (there are other ways to set localversion, read on..)

When I do "make modules_install" from the kernel source tree, modules get installed in "/lib/modules/2.6.9-dsd". I reboot into my new kernel, modprobe correctly finds the modules at that location and loads them without problem.

I then come to install an external module available in portage (e.g. nvidia-kernel). I emerge this, portage detects my kernel version string as "2.6.9" so installs the module under "/lib/modules/2.6.9". I then come to "modprobe nvidia", and modprobe can't find the module.

Here's what needs to be done:

The function "ExtractKernelVersion" in needs to be extended to parse the localversion. This is quite tricky, perhaps there is a better solution?
When defining the localversion, the kernel makefile will first search for files at /usr/src/linux/localversion* and read them in alphabetical order, appending each one to the localversion string. It will then read the value of CONFIG_LOCALVERSION found in /usr/src/linux/.config and append that. If any spaces are present in any localversion, they will be removed.

For example:
/usr/src/linux/localversion-a reads "-gen too"
/usr/src/linux/localversion-b reads "-test"
/usr/src/linux/.config contains the following line: CONFIG_LOCALVERSION="-dsd"
The localversion here would be "-gentoo-test-dsd". Assuming the kernel source was standard 2.6.9, when I then boot into my kernel, the version string would be "2.6.9-gentoo-test-dsd" and modules would be placed at "/lib/modules/2.6.9-gentoo-test-dsd".

Remember that on an unconfigured kernel, a .config file will not exist. And obviously, there might not be any localversion* files existing.

So perhaps extending "ExtractKernelVersion" for all this isn't the best idea. How would you guys propose that we handle this?
Comment 5 Jason Stubbs (RETIRED) gentoo-dev 2004-10-29 06:20:45 UTC
Most things that require the kernel version require the kernel to be configured and compiled, no? I can't think of anyting that doesn't and, if there is, it wouldn't be a kernel module right?

I'm pretty sure extending ExtractKernelVersion to follow the logic you've described will suffice. After all, if the kernel isn't configured and compiled, there won't be a localversion (beyond the files defined if any).
Comment 6 Jason Stubbs (RETIRED) gentoo-dev 2004-10-29 06:21:12 UTC
Please confirm this by the way...
Comment 7 Daniel Drake (RETIRED) gentoo-dev 2004-10-30 03:35:38 UTC
Sounds good. As long as portage doesn't bail out if no .config exists or something like that - it should do its best to construct the localversion out of what is present.
Comment 8 Henrik Brix Andersen 2004-10-30 11:37:37 UTC
Many ebuilds already rely on building against a configured kernel - all external kernel modules do this.
Comment 9 Daniel Drake (RETIRED) gentoo-dev 2004-10-31 05:06:32 UTC
Created attachment 43002 [details, diff]

Jason, you rock!

Just tested it out, and found a couple of problems. the localversion files
weren't being read, and portage produces a traceback when no .config exists.

I've fixed it with this patch.. but bear in mind that its the first python code
i've ever touched :)
Comment 10 Jason Stubbs (RETIRED) gentoo-dev 2004-11-02 07:24:49 UTC
Added the patch to CVS and will add the lot to portage_2_0 now.
Comment 11 SpanKY gentoo-dev 2004-11-11 17:41:56 UTC
*** Bug 70906 has been marked as a duplicate of this bug. ***
Comment 12 Owen Gunden 2004-11-11 17:47:12 UTC
I reported the duplicate bug 70906.. sorry I missed this one.  I also wrote a patch for it attached there, if anyone cares to check it out.  But it looks like you guys pretty much have it solved..
Comment 13 Daniel Drake (RETIRED) gentoo-dev 2004-11-18 01:17:38 UTC
*** Bug 71626 has been marked as a duplicate of this bug. ***
Comment 14 John Mylchreest (RETIRED) gentoo-dev 2004-11-30 08:40:32 UTC
thanks to all those involved.
I think since then it has been agreed that portage is the wrong place to be setting KV, and linux-info is already in the tree to cater for this.