emerge -av vmware-workstation 100%[====================================>] 296,976 5.52K/s ETA 00:00 21:32:13 (5.52 KB/s) - `/var/cache/distdir/vmware-any-any-update108.tar.gz' saved [296976/296976] * 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 sources. !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1630: Called dyn_setup ebuild.sh, line 702: Called qa_call 'pkg_setup' ebuild.sh, line 38: Called pkg_setup ebuild.sh, line 1304: Called vmware-mod_pkg_setup vmware-mod.eclass, line 31: Called linux-mod_pkg_setup linux-mod.eclass, line 464: Called linux-info_pkg_setup linux-info.eclass, line 554: Called die !!! Unable to calculate Linux Kernel version !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/temp/build.log'. latitude ~ # ls /usr/src/kernel/linux/ COPYING MAINTAINERS arch fs kernel scripts CREDITS Makefile block include lib security Documentation README crypto init mm sound Kbuild REPORTING-BUGS drivers ipc net usr latitude ~ # cat /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/temp/build.log * 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 sources. !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1630: Called dyn_setup ebuild.sh, line 702: Called qa_call 'pkg_setup' ebuild.sh, line 38: Called pkg_setup ebuild.sh, line 1304: Called vmware-mod_pkg_setup vmware-mod.eclass, line 31: Called linux-mod_pkg_setup linux-mod.eclass, line 464: Called linux-info_pkg_setup linux-info.eclass, line 554: Called die !!! Unable to calculate Linux Kernel version !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/temp/build.log'. Reproducible: Always Actual Results: Eve though i have the kernel sources in place, the ebuild fails to find them. i guess the ebuild actually wants the kernel build directory... *** Deprecated use of action 'info', use '--info' instead Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.20 i686) ================================================================= System uname: 2.6.20 i686 Pentium III (Coppermine) Gentoo Base System release 1.12.9 Timestamp of tree: Fri, 20 Apr 2007 01:00:01 +0000 distcc 2.18.3 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /home/mythtv/ /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -march=pentium3 -fomit-frame-pointer" DISTDIR="/var/cache/distdir" FEATURES="ccache confcache distcc distlocks metadata-transfer parallel-fetch sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en en_GB sv" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib alsa autoipd avahi bash-completion berkdb bitmap-fonts bzip2 cairo ccache cdr cli cracklib crypt curl daap dbus djbfft dri dtaus dvd dvdr dvdread eds emboss encode esd fam firefox flac gdbm gif gpm gstreamer gtk iconv imagemagick ipv6 isdnlog jpeg kde libcaca libg++ libsamplerate live mad mdnsresponder-compat midi mikmod mmx mmxext mng mozcalendar mozdevelop moznomail mozsvg mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg oss pcre perl png ppds pppd python qt3 quicktime readline real reflection rtc samba sdl se_swedb session spell spl sse ssl tcpd tiff truetype truetype-fonts tv_check tv_pick_cgi type1-fonts unicode vdr visualization vorbis win32codecs x86 xml xorg xpm xv zlib" ALSA_CARDS="CS4281" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB sv" USERLAND="GNU" VIDEO_CARDS="mach64" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
