Summary: | linux-info.eclass fails to locate the kernel sources properly | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anders Eriksson <aeriksson> |
Component: | Current packages | Assignee: | John Mylchreest (RETIRED) <johnm> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | ikelos, kernel |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
lihnux src Makefile
The Makefile in the build directory |
Description
Anders Eriksson
2007-04-20 19:39:40 UTC
Does that symlink point to a built kernel, or just the latest sources? -Alec Ok, this would be a linux-info issue, since vmware-modules imports that for all of it's kernel jiggery-pokery. Johnm appears to be classed as the maintainer for that eclass, but I'll have a go at trying to solve it... Anders, The linux-info eclass will return the error you've seen if it can't determine the kernel version number properly from the Makefile in the specific kernel directory . Please check the top of the Makefile from your /usr/src/kernel/linux directory and ensure it features a VERSION, PATCHLEVEL and SUBLEVEL line. If it doesn't, then it looks like you're using a modified kernel, and I'd recommend reinstalling vanilla-sources (which it appears you're using) to get a clean set of sources to work with. If the makefile does seem fine, please attach it to this bug and we'll take a look and see if we can figure out what's going ok. Thanks... 5:) Created attachment 116886 [details]
lihnux src Makefile
Created attachment 116888 [details]
The Makefile in the build directory
Hi again, More info... I manage /usr/src/kernel/linux/ myself (via "ketchup -G 2.6"), and not via an ebuild (such as vanilla-sources). I'll attach the Makefiles from /usr/src/kernel/linux and /usr/src/linux-obj/ /usr/src/kernel/linux is actually ro nfs mounted from another box, if that matters... Ok, well that explains the failure. It appears that the second makefile you sent doesn't contain a SUBLEVEL, which is probably what's been causing the linux-info eclass to have problems. As a temporary work around, could you please add a SUBLEVEL line to the generated Makefile and see if that solves the problem? Unfortunately, if it does work, then to fix the issue it'll require either a change in the kernel source (whose generated Makefile doesn't include the SUBLEVEL line), or a change in the linux-info (which probably wouldn't be possible), or it will require you to fix up the generated makefile every time you make a new one. Sadly it looks like the last option will be your best bet. Still, first off, let's see if the kernel can build all the modules successfully with just that extra information... Ok, the Makefile in the kernel build directory now starts out with: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 20 KERNELSRC := /usr/src/kernel/linux KERNELOUTPUT := /usr/src/linux-obj .... That didn't help one bit though: latitude ~ # emerge -av vmware-workstation These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-emulation/vmware-modules-1.0.0.15-r1 0 kB [ebuild N ] app-emulation/vmware-workstation-5.5.3.34685 108,914 kB Total: 2 packages (2 new), Size of downloads: 108,914 kB Would you like to merge these packages? [Yes/No] >>> starting parallel fetching >>> Emerging (1 of 2) app-emulation/vmware-modules-1.0.0.15-r1 to / * vmware-any-any-update108.tar.gz RMD160 ;-) ... [ ok ] * vmware-any-any-update108.tar.gz SHA1 ;-) ... [ ok ] * vmware-any-any-update108.tar.gz SHA256 ;-) ... [ ok ] * vmware-any-any-update108.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking vmware-any-any-update108.tar.gz ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/kernel/linux/ * Could not detect kernel version. * Please ensure that /usr/src/kernel/linux/ points to a complete set of Linux s ources. =================== now reading the error message it seems it's unhappy about the kernel src dir, not the build dir... The kernel src dir these days is supposed to be totally read-only, so I'm really surprised that it's unhappy with it. Back in the days, you were at times asked to do a 'make config' to kickstart a version variable or something. Isn't all that history now? At any rate, it should look for the effects of such efforts in the build dir, not the src dir. Hmmmm, that's even more odd. The code appears to be failing because one of VERSION, PATCHLEVEL or SUBLEVEL are coming back empty, and the relevant code to determine these values is as follows: cd "<kernel-source-dir>" echo -e "e:\\n\\t@echo \$(<variable-name>)\\ninclude <Makefile-filname>" | \ make M="<module-source-dir>" ${BUILD_FIXES} -s -f - 2>/dev/null This should then return the correct values on stdout. I'd expect BUILD_FIXES to be empty, and module-source-dir can probably be anything, whilst Makefile-filename is just Makefile is most cases. I was wondering if you could run this within your kernel source directory and let me know if it returns any errors? It might be an issue of mount points and symlinks, but I just can't quite tell yet... Getting closer: Inside the kernel source dir: latitude linux # echo -e "e:\\n\\t@echo \$(<variable-name>)\\ninclude Makefile" | make M="." ${BUILD_FIXES} -s -f - 2>/dev/null ERROR: Kernel configuration is invalid. include/linux/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. Doing the same thing in the build dir turns up nothing: latitude linux-obj # echo -e "e:\\n\\t@echo \$(<variable-name>)\\ninclude Makefile" | make M="../kernel/linux/" ${BUILD_FIXES} -s -f - <no output> Do notice that I've referred to the kernel source dir for the module-source-dir variable. Is that ok? Hiya Anders, yep referring to the kernel source dir rather than the module source dir should be fine (in the demo I ran on my machine, I used blah which didn't exist and it still output ok...) 5:) I realized I forgot to note that <variable-name> should be replaced with VERSION, PATCHLEVEL and SUBLEVEL, but I'm guessing you caught that one, and it doesn't look like it would make a difference in the case of the kernel source attempt you made. Could you try running a "make prepare" on the kernel-source directory without giving it a valid .config file please? It'd also be interested to know what files it created/changed if that worked. If it didn't work, or if the modules still don't build after a make prepare, then it appears that linux-info is looking in the wrong place for its version information. Unfortunately I'm not well enough versed in that area to be able to fix it, but I'll CC the kernel herd to see if they can help... Embarrassment strikes. No, I didn't substitute the right variables in there. Doing that latitude linux # echo -e "e:\\n\\t@echo \$(SUBLEVEL)\\ninclude Makefile" | make M="../kernel/linux/" ${BUILD_FIXES} -s -f - 2>/dev/null ERROR: Kernel configuration is invalid. include/linux/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. 20 ================ make it quite different! So.... We get the variables out of it, but it complains about not having the auto* stuff right. IMHO, there should be no requirement to have run make prepare prior to this step (both from a logical standpoint, you just want the version, and from a practical standpoint, you do get the variable's value). It seems a good approach is to either make the test not trig the kernel's makefile's itch about the auto* files, or just "egrep -v '\t'" the output to mask it off. Ideas? Got to go, back tomorrow... No, I'd be out of my depth changing the linux-info eclass, I'm going to have to defer this to the kernel guys... Fair enough. How do we contact them? Ahhhhhhh! Digging further into this I discovered I had mis-named my KBUILD directory. Fixing that, fixed it all. A stupid user error. |