Because the definition of UTS_RELEASE is missing in <linux/version.h> of new vanilla-sources-2.6.18-rc2, vmware-config.pl script returns the following error : The directory of kernel headers (version @@VMWARE@@) does not match your running kernel (version 2.6.18-rc2!). Even if the module were to compile successfully, it would not load into the running kernel. To fix this issue, users should add #define UTS_RELEASE "2.6.18-rc2" to /usr/src/linux/include/linux/version.h VMWare seems to run fine with this new kernel release!
*** Bug 140848 has been marked as a duplicate of this bug. ***
Assigning this to kernel folks; if this borkage is intentional, feel free to bounce back to maintainers. Ebuilds known to be affected - vmware, rlocate. I'm pretty sure there're more, just noone tried w/ 2.6.18 yet. :(
*** Bug 141094 has been marked as a duplicate of this bug. ***
Intentional, it went into utsrelease.h
I have tried with 2.6.18rc1 and rc2
Just wondering the status of this? Not complaining or trying to rush.
The vmware team is in the process of migrating over a new set of ebuilds that will vastly ease maintenance of vmware ebuilds (such as vmware-workstation, etc) and introduces a new module system. Once that's in place, updates and fixes to the modules can be applied quite quickly. There is now a fixed version of the generic modules that the new ebuilds will use available, and once the new ebuilds have been migrated to the main tree, the fix for this problem should follow shortly after. Unfortunately the expected time-scale is probably about a week or two. Sorry for the inconvenience...
*** Bug 142073 has been marked as a duplicate of this bug. ***
*** Bug 142845 has been marked as a duplicate of this bug. ***
Created attachment 93460 [details, diff] files/vmmon-linux-2.6.18-utsrelease.patch Cross-posting my patch from bug #142845 as per Jakub's request.
Created attachment 93461 [details] vmware-modules-1.0.0.13-r1.ebuild Cross-posting my ebuild from bug #142845 as per Jakub's request.
Marti, thanks for your patch. We'll be moving vmware-modules-1.0.0.{8,11,13} over to the latest vmware-any-any update soon (version 103, rather than 101). This should fix the problems currently seen with the 2.6.18 kernel and the vmware-modules. I will probably however use this patch for the vmware-modules-1.0.0.15 (those used for vmware-server), so thanks! 5:) It should go into the overlay for testing sometime this weekend, and get put into the main ebuild by the end of this coming week. The new version of vmware-any-any should go into the main tree at the start of this coming week...
Marti, as it turns out 2.6.18 is already supported by the vmware-server supplied modules, so 1.0.0.15 won't require your patch, but thank you for submitting it anyway. As I say, a fixed vmware-modules eclass should go into the tree in the next couple of days...
(In reply to comment #14) Ok, that's good. I only created the patches so that I could get VMware running for myself yesterday, and figured I might as well upload them. :)
Thanks, they were very much appreciated. Any user contributions are appreciated, even if we aren't able to use them. Keep it up! 5:)
(In reply to comment #13) > Marti, thanks for your patch. We'll be moving vmware-modules-1.0.0.{8,11,13} > over to the latest vmware-any-any update soon (version 103, rather than 101). > This should fix the problems currently seen with the 2.6.18 kernel and the > vmware-modules. Looks like there are some problems with vmware-modules-1.0.0.13 when using vmware-workstation: /var/tmp/portage/vmware-modules-1.0.0.13/work/vmmon-only/linux/hostif_compat.h: In function
(In reply to comment #13) > Marti, thanks for your patch. We'll be moving vmware-modules-1.0.0.{8,11,13} > over to the latest vmware-any-any update soon (version 103, rather than 101). > This should fix the problems currently seen with the 2.6.18 kernel and the > vmware-modules. Looks like there are some problems with vmware-modules-1.0.0.13 when using vmware-workstation: /var/tmp/portage/vmware-modules-1.0.0.13/work/vmmon-only/linux/hostif_compat.h: In function properties: /var/tmp/portage/vmware-modules-1.0.0.13/work/vmmon-only/linux/hostif_compat.h:513: error: expected : or ) before UTS_RELEASE make[2]: *** [/var/tmp/portage/vmware-modules-1.0.0.13/work/vmmon-only/linux/hostif.o] Error 1 make[1]: *** [_module_/var/tmp/portage/vmware-modules-1.0.0.13/work/vmmon-only] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.18-rc2' make: *** [vmmon.ko] Error 2 Here is my output of emerge --info: emerge --info Portage 2.1.1_pre4-r3 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.18-rc2 i686) ================================================================= System uname: 2.6.18-rc2 i686 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.4 ccache version 2.4 [enabled] app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: [Not Present] sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -msse2 -pipe -O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /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/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -msse2 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X acpi alsa apache2 apm arts avi bash-completion bitmap-fonts bzlib caps cdr cli crypt cups dbus divx4linux dlloader dri dvd dvdr dvdread eds elibc_glibc encode esd ffmpeg fortran ftp gcj gdbm gif gimp gpm gstreamer gtk gtk2 hal imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog java javascript jpeg kde kdeenablefinal kernel_linux libg++ libwww linguas_de mad matroska mikmod mmx motif mp3 mpeg ncurses nls no-seamonkey nocd nptl nptlonly nsplugin ogg oggvorbis opengl oss pcre pdf pdflib perl png pppd python qt qt3 qt4 quicktime readline real reflection samba scanner sdl session spell spl sse sse2 ssl svg theora tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l vcd video_cards_r300 video_cards_radeon video_cards_vesa videos vorbis win32codecs wxwindows xcomposite xinerama xml xml2 xmms xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Would be nice if the file in portage could be fixed since I can't update world with this problematic dependency of vmware-modules. The fix seems to be needed for 1.0.0.13, too, and not only for vmware-server.
Take care if you install vmware-module-1.0.0.13 & vmware-workstation-5.5.1-19175-r4 ... portage will ask to upgrade vmware-module-1.0.0.13 to version 1.0.0.15 (which one breaks the vmware-workstation package). See http://bugs.gentoo.org/show_bug.cgi?id=142848
Nils, you're correct, it is needed for 1.0.0.13, but if you read the earlier comments you'll see that a (different) fix is already in the vmware overlay for testing, and that it'll be added to portage at the start of the week. Francois, as the bug you filed mentioned, this will *only* occur if you have vmware-modules listed in world directly, rather than simply as a dependency. You can cure your problems by simply removing vmware-modules from your world file (unmerge it and then re-merge it using --oneshot).
This has now been fixed in the tree, please try resyncing the tree in a few hours (to give the mirrors time to catch up) and then compiling the vmware-modules package in question again. If the problem still occurs, please reopen this bug...
fixed, thanks.
*** Bug 148442 has been marked as a duplicate of this bug. ***
