Linux Kernel from 2.6.22 introduces some changes in the file skbuff.h. Vmware-modules (the vmnet module) doesn't compile with these changes. Reproducible: Always
Created attachment 122533 [details, diff] vmware-modules-1.0.0.15-r1-kernel-2.6.22.patch A proposed patch for 1.0.0.15-r1 build
Created attachment 122535 [details, diff] vmware-modules-1.0.0.16-kernel-2.6.22.patch A proposed patch for 1.0.0.16 build.
Comio, The vmware team has already been assigned the bug and does not also need to be CCed into the bug. Thanks for the patch, we're looking into them to ensure they have no undesirable side effects. We generally do not support -rc patch kernels, and 2.6.22 is currently on -rc5. We will endeavor to support it ones a gentoo-sources package is released for the final 2.6.22. Generally we try to use an unpatched version of the vmware-any-any-update patchset, which often fixes issues in specific kernel versions, and we're hoping the next one will fix issues with 2.6.22. As such we won't be applying these patches immediately, but hopefully they'll be of some use to cutting edge users... Thanks again for taking the time to track down the issues, and report the bug... 5:)
*** Bug 182828 has been marked as a duplicate of this bug. ***
I suggest you to install the app-portage/portage-bashrc-ng (from the Gechi Overlay http://gechi-overlay.sourceforge.net/) and enable the "perpackage" module to apply the patches without change the original ebuilds. See this url: http://sourceforge.net/forum/forum.php?forum_id=664937
Degrading the kernel to 2.6.21.5 seems to allow the installation to finish.
hehh did you even read what Mike wrote ? :)
2.6.22 is now released and this bug is in effect... W
I have a solution for VMware Modules on 2.6.22. Modify vmware.eclass to use ANY_ANY update of 110 instead of 109. Download ANY_ANY update from: http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update110.tar.gz (Above URL is the correct primary location; the ebuilds are configured to use a mirror rather than the primary. ftp://ftp.cvut.cz/vmware/ is not the primary FTP site.) Regenerate the vmware-modules ebuild digest. Patch your kernel with attached patch. The patch does not change anything but some C semantics to be strictly compliant instead of using GCC extensions. Again: it fixes compilation, but does not change anything significant. emerge, vmware-config.pl, and enjoy!
Created attachment 124345 [details, diff] combined with any-any 110, fixes 2.6.22 compilation
(In reply to comment #3) > We generally do not support -rc patch kernels, and 2.6.22 is currently > on -rc5. We will endeavor to support it ones a gentoo-sources package is > released for the final 2.6.22. Respectfully, this is not the best strategy. I understand it for alpha and beta releases but not for RC. Anyway, gentoo-sources-2.6.22-r1 is still affected apparently.
Ok everybody, sorry for the long delay, but I finally managed to get some time to try and sort out the module issues (and yes, since gentoo-sources-2.6.22 came out, this is now quite an issue). Comio, thank you very much for your patches (and I'm sorry I took quite so long in responding). I've now added the 1.0.0.16 patch to the vmware-overlay, for all the workstation-6 users. For server & workstation-5, I've bumped the vmware-any-any-update to 110 which apparently solves post-2.6.21 compilation issues. I would *not* recommend patching the kernel, since if it's a kernel bug they should fix it upstream, and otherwise it's something that should be fixed in the vmware-any-any-update package. So, I'd like to ask for people to start testing the vmware overlay's vmware-modules packages and tell me if there are any issues or problems with it on this bug. Thanks very much, and once again I apologize for the delay...
Giovanni, the vanilla-source RC releases come out approximately every two weeks during the development cycle and there are often changes from one RC to the next, so attempting to correctly patch the ebuilds for each RC every couple of weeks simply isn't feasible, especially given the small size of the vmware herd. I understand your frustration, since the lack of vmware-server ebuilds is what led me to become a gentoo developer. If you'd like to get the modules working as quickly as possible, I'd recommend setting up a private overlay and trying out the various patches supplied by users such as Comio (thanks again!). If you're waiting for someone else to do it for you, then you'll have to abide by their decisions in how to support it. At the moment, that means that RC releases are unlikely to be supported. I hope that helps you understand our position a little better...
(In reply to comment #13) > I understand your frustration, since the lack of vmware-server ebuilds is > what led me to become a gentoo developer. Mike, I'm not frustrated, much less do I wish to find fault with the way you chose to manage this task. I was only suggesting that you could perhaps be a bit more 'daring' in the case of release candidates, since it's relatively unlikely that any work you do will be voided by subsequent releases. In any case, thanks a lot.
I agree with Mike. It's not possible to create a new patch for each rc kernel release (gentoo is based on volunteers). I posted the patch just to signaling the future problems derived from kernel changes and to provided a "quick&dirty" solution to people that need last kernel and vmware server. In my modest opinion, each ebuild that creates kernel modules (like vmware-modules) must block all the not-tested (and potentially not compatible) kernels by means of a "PRETEND=!..." statement. The correct behavior is that vmware-modules-1.0.0.16 should block the kernel 2.6.22. luigi I(In reply to comment #13) > Giovanni, the vanilla-source RC releases come out approximately every two weeks > during the development cycle and there are often changes from one RC to the > next, so attempting to correctly patch the ebuilds for each RC every couple of > weeks simply isn't feasible, especially given the small size of the vmware > herd. > > I understand your frustration, since the lack of vmware-server ebuilds is what > led me to become a gentoo developer. If you'd like to get the modules working > as quickly as possible, I'd recommend setting up a private overlay and trying > out the various patches supplied by users such as Comio (thanks again!). If > you're waiting for someone else to do it for you, then you'll have to abide by > their decisions in how to support it. At the moment, that means that RC > releases are unlikely to be supported. I hope that helps you understand our > position a little better... >
(In reply to comment #12) > So, I'd like to ask for people to start testing the vmware overlay's > vmware-modules packages and tell me if there are any issues or problems with it > on this bug. Thanks very much, and once again I apologize for the delay... > Working on app-emulation/vmware-modules-1.0.0.15-r1 I installed the vmware overlay from sunrise using layman. Then: emerge app-emulation/vmware-modules gives lots of attempts to download vmware-any-any-update110.tar.gz - can't find it. I the downloaded the file manually from the link given in comment #9. This allowed compilation to proceed. Patching worked, but compilation still failed here: * Preparing vmmon module ...snip... include/asm/page.h: In function ‘pte_t native_make_pte(long unsigned int)’: include/asm/page.h:112: error: expected primary-expression before ‘)’ token include/asm/page.h:112: error: expected ‘;’ before ‘{’ token include/asm/page.h:112: error: expected primary-expression before ‘.’ token include/asm/page.h:112: error: expected `;' before ‘}’ token make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o] Error 1 Messages from further up: * Found sources for kernel version: * 2.6.22-gentoo-r1 Regards Ian
Thanks Ian, looks like it's back to the drawing board for 2.6.22, I'll investigate applying Comio's patches to the vmware-any-any-update modules we use. I do need to update the update location, since it seems the main site hasn't yet mirrored 110 for some reason. I'm kind of hoping they'll bring out 111 soon that works completely with workstation-6...
(In reply to comment #16) > I the downloaded the file manually from the link given in comment #9. > This allowed compilation to proceed. > Patching worked, but compilation still failed here: > * Preparing vmmon module > ...snip... > include/asm/page.h: In function ‘pte_t native_make_pte(long unsigned int)’: (In reply to comment #17) > Thanks Ian, looks like it's back to the drawing board for 2.6.22. This was already addressed by my kernel patch and my comments. AGAIN: the ebuilds use the wrong mirror. The any-any author uses a different FTP URI for the master. The mirror you are using -- he hasn't bothered to update. The Herd should contact him if they want that fixed. Original announcement by any-any author: http://www.vmware.com/community/thread.jspa?messageID=76957&tstart=0 AGAIN: page.h in the Linux 2.22.x kernel uses a GCC syntax extension that violates C standards. The provided patch (by ME) adjusts the syntax to a more proper C (ISO/ANSI/?). IMHO this could go into genpatches if upstream ignores the issue. IMHO it is completely trivial and obvious :-). Why is it back to the drawing board? Regards.
Timothy, first off thank you for re-iterating the points you had already made previously, again. Back to the drawing board was perhaps a poor turn of phrase. I simply meant there was more work to be done. I've seen your patches but, as I stated before (or "again" if you prefer), if there is a problem with the kernel sources themselves, they should be presented upstream at the linux kernel mailing list. If they are rejected, and you still feel they should be included in the gentoo-sources, then please post a separate bug about them. Applying the patch only to the gentoo-sources would knowingly stop the modules from running correctly under the vanilla-sources, and would likely result in further bug reports that would still require a solution. Whilst I do not intend to support the RC releases, I will not knowingly break functionality for unpatched kernels. It will make diagnosing and fixing bugs more difficult, and it's for this same reason I don't recommend people patch their own kernels manually. The mirror location is also on my todo list, however I decided to prioritize and attempt to get the package compiling properly first. I will fix the mirror locations when I'm next able to find the time. I wish you luck with you LKLM post.
(In reply to comment #19) > Thanks for your explanation. Sounds good. :-)
FYI: Upstream bugzilla entry. Will take to mailing lists if upstream prefers. http://bugzilla.kernel.org/show_bug.cgi?id=8741
Upstream does not support kernel modules written in C++. That is the crux of the whole problem. Ideas are: - somehow spoof page.h with -Iinclude - rewrite task.c to be non-c++ - find a gcc flag to enable the extension (not possible AFAIK) A minimalistic approach (partially tested) appears to patch hostKernel.h: - # include <asm/page.h> + # include "page-fix.h" Copy linux asm/page.h to local include directory. Rename to page-fix.h. Patch to change GCC syntax. From reading the debugging efforts of other Gentoo forums and other distros, it appears that the C++ / C language conflict is unavoidable without using a modified page.h. Good luck :-).
vmmon of vmware player 6 and it passes compilation. vmnet of any-any-110 passes compilation and seems to work. I am using vmware-server and I guess something in the new vmware player modules does not work correctly. The vmnet of vmware player does not work because it lacks an abstraction layer of networking...
(In reply to comment #9) > I have a solution for VMware Modules on 2.6.22. > > Modify vmware.eclass to use ANY_ANY update of 110 instead of 109. works perfectly 4me, thx mate! vmware-server here, and kernel 2.6.22 gentoo-sources. hmm, i see the kernel bug has been rejected, but what the heck. IMHO simply the eclass should be updated, and off we go? if there is an ANY_ANY 110, this is probably for a resaon?
(In reply to comment #24) > works perfectly 4me, thx mate! > vmware-server here, and kernel 2.6.22 gentoo-sources. It does not work for me... :( Have you done something except that?
Please look at: /var/log/vmware/vmware-serverd.log I get: Msg_Post: Version mismatch with vmmon module: expecting 138.0, got 161.0.
So I'm a little confused here. What am I supposed to do to get this working? W
OK, quite strange... as if I remove the page.h header file it works... I don't know if it is good or bad... lots of warnings that seem unrelated. I am using now vmware-any-any 110 and the following: sed -i 's!# include <asm/page\.h>!!g' vmmon-only/common/hostKernel.h
(In reply to comment #28) > OK, quite strange... as if I remove the page.h header file it works... I don't > know if it is good or bad... lots of warnings that seem unrelated. > > I am using now vmware-any-any 110 and the following: > sed -i 's!# include <asm/page\.h>!!g' vmmon-only/common/hostKernel.h > It would be interesting to compare the cc1plus (gcc) warnings between: - no page.h - patched page.h If they're sufficiently identical, then the above may very well be an approach to creating a solution ...
(In reply to comment #25) > (In reply to comment #24) > > works perfectly 4me, thx mate! > > vmware-server here, and kernel 2.6.22 gentoo-sources. > > It does not work for me... :( > Have you done something except that? no, i just patched the eclass file, thats it. oh, i am @amd64 and i do not get those mismatch warnings in the log
Why does it take so long to resolve this bug?
(In reply to comment #31) > Why does it take so long to resolve this bug? as you might have read, simply patching the ECLASS doesnt work for everyone, hmm..
2.6.22-r1 on ~amd64 and just editing the eclass for 110 made it build the modules. very freaking strange that it doesn't work for some folks.
Another data point: With 2.6.22 on ~amd64 machine, merely editing vmware.eclass to use 110 fixes compilation. No kernel patching or other steps required.
(In reply to comment #33) > 2.6.22-r1 on ~amd64 and just editing the eclass for 110 made it build the > modules. very freaking strange that it doesn't work for some folks. > Not surprising. Kernel patching might only be required for i386. After all, page.h is in include/asm which is a symbolic link to an architecture dependent directory. :-)
wow. Amd64 here, and here's what I tried: 1. Downloaded new "any-any" update from http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update110.tar.gz and stuck it in /usr/portage/distfiles (where I noticed there were some other "any-any" files. 2. Made an overlay of app-emulation/vmware-modules and the /eclasses directory (don't know if this was necessary but jic) 3. copied over and edited /eclasses/vmware.eclass into overlay directory-- Changed "109" to "110" in vmware.eclass 4. ebuild vmware-modules-1.0.0.16.ebuild manifest 5. ebuild vmware-modules-1.0.0.15-r1.ebuild manifest. That was it. Then I could emerge vmware-modules (1.0.0.15-r1) fine and ran vmware-config.pl. I have no idea why it worked, but it seems to have worked. No special kernel patching required for amd64. Now I'm gonna try unmasking 1.0.0.16 and see what happens....DAMN! CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/driver.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/hub.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.o /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.c: In function ‘VNetCopyDatagramToUser’: /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.c:630: error: ‘const struct sk_buff’ has no member named ‘h’ /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.c:630: error: ‘const struct sk_buff’ has no member named ‘nh’ /var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.c:636: error: ‘const struct sk_buff’ has no member named ‘h’ make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only/userif.o] Error 1 make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.16/work/vmnet-only] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r1' make: *** [vmnet.ko] Error 2 !!! ERROR: app-emulation/vmware-modules-1.0.0.16 failed. Call stack: ebuild.sh, line 1621: Called dyn_compile ebuild.sh, line 973: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1311: Called linux-mod_src_compile linux-mod.eclass, line 516: Called die !!! Unable to make auto-build VMWARE_VER=VME_V6 KERNEL_DIR=/usr/src/linux KBUILD_OUTPUT=/lib/modules/2.6.22-gentoo-r1/build. !!! 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.16/temp/build.log'. This ebuild used the following eclasses from overlays: /usr/local/portage/eclass/vmware.eclass --- Maybe it's only 1.0.0.16 that needs the kernel patch? Dunno. I'll stick with 15-r1 until this is all sorted out. W
(In reply to comment #36) i can be mistaken, but AFAIK 1.0.0.16 is not supposed to work with vmware-server AFAIK it is supposed to work with vmware-workstation 6(!) and vmware-player 2(!) at least thats whats the changelog says.
(In reply to comment #35) > Not surprising. Kernel patching might only be required for i386. After all, > page.h is in include/asm which is a symbolic link to an architecture > dependent directory. :-) ah, that explains it, thx. however, this could be catched by the ebuild? "if arch = amd64 require any_any 110" - thats it. at least for the amd64 fellows. PS: yeah, in easy words, i dont know that much about ebuilds, but i am almost sure that you can have different arguments for different architectures.
Guys, For those of you that wish to test the vmware-any-any-update110, it is already available in the vmware overlay (which can be easily installed using 'layman -a vmware'). The same is true of the 2.6.22 patch for vmware-workstation 6 (the 1.0.0.16 modules). So, people using this overlay should now be able to install the modules, all except x86 users of vmware-server or vmware-workstation-5.5, who may still be experiencing difficulty. We are working to find a working solution for everybody, please bear with us...
Re: Comment #39... I just used layman, unmasked vmware-modules-1.0.0.16 and vmware-player-2.0.0.45731 and emerged them sucsessfully. However, $ /opt/vmware/player/bin/vmplayer /opt/vmware/player/lib/bin/vmplayer: symbol lookup error: /opt/vmware/player/lib/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN3Gtk13RecentManager11get_defaultEv This is with kernel linux-2.6.21-gentoo-r2
Peter, that's not in any way related to the modules. If you'd like to file another bug you can (or you may find a relevant one elsewhere that already answers you), but before you do, please have a go at ensuring gtkmm is built with USE="accessibility", that gtk+-2.10 or greater is installed and then re-emerging libview, libsexy. Hopefully that'll help, and save another bug being filed. Thanks... 5:)
(In reply to comment #40) There is also the environment variable: VMWARE_USE_SHIPPED_GTK to play with. Read vmware forums for details.
Re: Comment #41 Thanks, that worked!
Re: Comment #43 Thanks again - vmware-player now works OK with linux-2.6.22-gentoo-r1 kernel!
(In reply to comment #39) > Guys, > > For those of you that wish to test the vmware-any-any-update110, it is already > available in the vmware overlay (which can be easily installed using 'layman -a > vmware'). The same is true of the 2.6.22 patch for vmware-workstation 6 (the > 1.0.0.16 modules). So, people using this overlay should now be able to install > the modules, all except x86 users of vmware-server or vmware-workstation-5.5, > who may still be experiencing difficulty. We are working to find a working > solution for everybody, please bear with us... > I use app-emulation/vmware-modules-1.0.0.15-r1 on ~x86 (trying 2.6.22-r1), but had a go anyway. 1.0.0.15 compilation fails with error message as reported in comment #16. 1.0.0.16 compiles fine, but then vmware console refuses to start any VM's (no error message - just refuses). So I assume that there is a version mismatch. Back to 1.0.0.15 - tried to add the patching for kernel-2.6.22.patch to the ebuild (copying the 1.0.0.16 ebuild, and the patch file), but no joy: * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/portage/local/layman/vmware/app-emulation/vmware-modules/files/1.0.0.15-kernel-2.6.22.patch * ( 1.0.0.15-kernel-2.6.22.patch ) I'd like to help get 1.0.0.15 working with kernel 2.6.22 - just short of knowledge here :-(. Regards Ian
Everbody, 1.0.0.16 will not work with vmware-server, it's currently for vmware-workstation-6 and vmware-player-2 only. The ebuild will be changed when it allows vmware-modules-1.0.0.16, and you should be automatically upgraded by portage. We used the version number to encode which products the modules will work with, so just because there is a later version does not mean that you are behind the times. If you need a later version, it will be 1.0.0.15-r2 or -r3... Ian, that error message basically means it can't locate the file you've tried to patch with. If you want to get the patch applying, you'll need to make sure that the ebuild has "inherit eutils" (or the eclass does), then you'll need to over-ride the src_unpack function (meaning you'll need to call the eclasse's unpack function, then add your epatch line in afterwards) and finally you'll need to put the patch somewhere. Most patches are put in the files directory, and are then referenced using ${FILESDIR}/<patchname>. I'm afraid I can't really give you many more ebuild tips on this bug than those, but if you're interested, there are several ebuild writing guides available on-line. Best of luck with the patching, please let me know how it goes. I'm trying to secure some time this weekend to get this whole thing sorted out...
Created attachment 125162 [details] vmware-modules-1.0.0.15-r1.ebuild modified to apply kernel-2.6.22.patch This is a modified vmware-modules-1.0.0.15-r1.ebuild from the sunrise layman overlay vmware. It includes the application of kernel-2.6.22.patch for 1.0.0.15-r1 which should be in the files directory as 1.0.0.15-kernel-2.6.22.patch. Unfortunately, just copying the patch 1.0.0.16-kernel-2.6.22.patch doesn't work - so a 1.0.0.15-r1 specific one is needed.
Created attachment 125170 [details, diff] 1.0.0.15-kernel-2.6.22.patch This is a patch derived from applying the sed command in comment #28. If this is placed in <overlaydir>/layman/vmware/app-emulation/vmware-modules/files/1.0.0.15-kernel-2.6.22.patch and the modified ebuild in comment #47 is used to replace the one in <overlaydir>/layman/vmware/app-emulation/vmware-modules and you are on ~x86 - then it compiles. This smells like a kludge to me, however compiling is a lot better than anything I've had so far, so I'm off to test if it actually works now. Regards Ian
(In reply to comment #48) > This smells like a kludge to me, however compiling is a lot better than > anything I've had so far, so I'm off to test if it actually works now. I have compiled and tested 1.0.0.15 against 2.6.21-r4 and 2.6.22-r1 (both gentoo-sources) on ~x86 only using files submitted by me (above). In both cases the modified ebuild + patch allows compilation, and resulting modules load and work with existing vmware-console. Obviously I've not tested things exhaustively, so this is probably just a temporary measure awaiting a proper fix for 1.0.0.15. Regards Ian
(In reply to comment #49) > > I have compiled and tested 1.0.0.15 against 2.6.21-r4 and 2.6.22-r1 (both > gentoo-sources) on ~x86 only using files submitted by me (above). In both cases > the modified ebuild + patch allows compilation, and resulting modules load and > work with existing vmware-console. Unfortunately, those of us who need vmware-modules for vmware-server are still SOL, if my experience is any guide... applied both your patches against gentoo-sources-2.6.22-r1 (and suspend2-sources-2.6.22, for good measure) and still ran into the exact problem detailed in comment #36: CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.o /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.c: In function 'VNetCopyDatagramToUser': /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.c:633: error: 'const struct sk_buff' has no member named 'h' /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.c:633: error: 'const struct sk_buff' has no member named 'nh' /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.c:639: error: 'const struct sk_buff' has no member named 'h' make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only/userif.o] Error 1 make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmnet-only] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r1-toi' make: *** [vmnet.ko] Error 2
(In reply to comment #50) > (In reply to comment #49) > > > > I have compiled and tested 1.0.0.15 against 2.6.21-r4 and 2.6.22-r1 (both > > gentoo-sources) on ~x86 only using files submitted by me (above). In both cases > > the modified ebuild + patch allows compilation, and resulting modules load and > > work with existing vmware-console. > > Unfortunately, those of us who need vmware-modules for vmware-server are still > SOL, if my experience is any guide... applied both your patches against > gentoo-sources-2.6.22-r1 (and suspend2-sources-2.6.22, for good measure) and > still ran into the exact problem detailed in comment #36: [...] OK, I was able to get compilation and functionality by making the vmware.eclass change (109 to 110) noted above, while keeping Ian's overlay changes.
I was able to get vmware-workstation-6.0.0.45731 and vmware-modules=1.0.0.16 to install under kernel-2.6.22-r1 without any trouble
This has all become confusing: Could a maintainer please summarize what is working which types of platforms and vmware-product? and what the non-working platforms/products are waiting for? Stable kernel wise we are now at 2.6.22.1.
Jeff, I am currently the vmware maintainer for Gentoo. Please see my comment 39 for a description of the current state of play. I am hoping to find time to work on this in the coming few days, please be patient...
Ok, as of 11:04 today, vmware-any-any-update111 was pushed out, and I've accordingly updated the vmware.eclass in the vmware overlay. This should fix 2.6.22 compilation issues for people on x86 with <=vmware-modules-1.0.0.15. Could people please test these and let me know how they work out? If they all work ok, I'll be pushing the changes to later this week. Thanks very much for your patience...
(In reply to comment #55) > Ok, as of 11:04 today, vmware-any-any-update111 was pushed out does anybody know if IRQ related issues introduced in 2.6.21 on amd64 have been fixed in this any-any update? The issue is discussed here: http://www.vmware.com/community/thread.jspa?threadID=86322 and here: http://lkml.org/lkml/2007/5/2/151 I couldn't find any changelog or history in the tar.
(In reply to comment #55) > Ok, as of 11:04 today, vmware-any-any-update111 was pushed out, and I've > accordingly updated the vmware.eclass in the vmware overlay. This should fix > 2.6.22 compilation issues for people on x86 with <=vmware-modules-1.0.0.15. > Could people please test these and let me know how they work out? At 08:30 on 23rd July 2007: Kernel: 2.6.22-gentoo-r1 app-emulation/vmware-modules: 1.0.0.15-r1 app-emulation/vmware-server: 1.0.3.44356 app-emulation/vmware-server-console: 1.0.3.44356 Process: 1) layman -d vmware 2) layman -S 3) layman -a vmware 4) emerge app-emulation/vmware-modules Compiles and installs correctly - downloads /usr/portage/distfiles/vmware-any-any-update111.tar.gz 5) emerge app-emulation/vmware-server app-emulation/vmware-server-console 6) /opt/vmware/server/bin/vmware-config.pl 7) /opt/vmware/server/console/bin/vmware-config-server-console.pl Started VM using VMWare remote console. Started OK, works OK. Looks fixed to me. Regards Ian
Well, doesn't look too good to me: gentoo-sources-2.6.22-r1 vmware-server-1.0.3.44356 vmware-modules-1.0.0.15-r1 >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.15-r1 to / * vmware-any-any-update111.tar.gz MD5 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz RMD160 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz SHA1 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz SHA256 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking vmware-any-any-update111.tar.gz ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.22-gentoo-r1/build * Found sources for kernel version: * 2.6.22-gentoo-r1 >>> Unpacking source... >>> Unpacking vmware-any-any-update111.tar.gz to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work >>> Unpacking ./vmware-any-any-update111/vmmon.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmmon-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Unpacking ./vmware-any-any-update111/vmnet.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmnet-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work ... * Preparing vmmon module Using 2.6.x kernel build system. make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules make[1]: Entering directory `/usr/src/linux-2.6.22-gentoo-r1' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/hostif.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/cpuid.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/hash.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/memtrack.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/phystrack.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++ include/asm/page.h: In function 'pte_t native_make_pte(long unsigned int)': include/asm/page.h:112: error: expected primary-expression before ')' token include/asm/page.h:112: error: expected ';' before '{' token include/asm/page.h:112: error: expected primary-expression before '.' token include/asm/page.h:112: error: expected `;' before '}' token make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o] Error 1 make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r1' make: *** [vmmon.ko] Error 2 !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1621: Called dyn_compile ebuild.sh, line 973: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1311: Called linux-mod_src_compile linux-mod.eclass, line 516: Called die !!! Unable to make auto-build VMWARE_VER=VME_S1B1 KERNEL_DIR=/usr/src/linux KBUILD_OUTPUT=/lib/modules/2.6.22-gentoo-r1/build. !!! 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'. !!! This ebuild is from an overlay: '/usr/portage/local/layman/vmware' Thanks for looking into this, greatly appreciated. ~Thomas
And here's my emerge --info: Portage 2.1.2.9 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r1 i686) ================================================================= System uname: 2.6.22-gentoo-r1 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 23 Jul 2007 07:30:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 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.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE" LC_ALL="de_DE.UTF-8" LINGUAS="de en" MAKEOPTS="-j3" 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/local/layman/sunrise /usr/portage/local/layman/enlightenment /usr/portage/local/layman/pro-audio /usr/portage/local/layman/secondlife /usr/portage/local/layman/nx /usr/portage/local/layman/vmware /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acl acpi alsa amd amr amrnb amrwb animgif ao aoss aotuv apm asf async audiofile bash-completion bcmath bcp bdf berkdb binary-drivers bitmap-fonts bittorrent bjam bl blas bluetooth bonusscripts branding buttons bzip2 cairo cap caps ccache cdaudio cdda cddb cdinstall cdparanoia cdr cdrom chardet chroot cli clock-screen colordiff console cracklib crypt css cups curl curlwrappers custom-cflags cvs dbus dga divx dri dts dvd dvdnav dvdr dvdread dvi dynamic dynamicplugin enca encode exif expat fat ffmpeg firefox flac flexresp2 fontconfig fortran fpx ftp fuse gcj gd gdbm german gif gimp gimpprint glibc-omitfp glitz gmedia gnutls gpm graphviz gre gs gtk hal hdri hfs hou icc icecast iconv icu id3 imagemagick imlib ipod ipv6 isdnlog jabber java javascript jbig jfs jikes john jpeg jpeg2k key-screen kqemu ladcca ladspa lame langpacks lcms libcaca libg++ libnotify libsamplerate libsexy linux-smp-stats lm_sensors lyrics lzo mad matroska md5 md5sum midi mikmod mime mmx mmxext mng modkit motif mouse mp2 mp3 mpd mpeg mplayer mudflap multiuser musepack ncurses network nls normalize nowin nptl nptlonly nsplugin ntfs ogg openal openexr opengl openmp oss pam pcre pda pdf perl png postgres postscript pppd prediction pulseaudio pyste python q32 q8 qt-static quicktime rar react readline real realmedia reflection reiser4 reiserfs roe rtc ruby sdl sdl-image sdl-sound sdlaudio search-screen sensord session sguil slang smp sndfile sou sox speex spell spl sqlite srt sse sse2 ssl ssse3 startup-notification svg svga syslog taglib tcl tcpd tga theora threads threadsonly tidy tiff timestats tk toolbar truetype truetype-fonts tta type1-fonts unicode usb videos vidix vnc vorbis vorbis-psy wavpack win32codecs wma wmf wmp x264 x86 xanim xcomposite xfs xine xinetd xml xorg xosd xpm xrandr xv xvid xvmc zip zlib" ALSA_CARDS="ice1712" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse joystick" KERNEL="linux" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="fbdev nv vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I realize this is a long shot, but could you please try rebuilding the modules with FEATURES="-ccache"? I'm just a little surprised the error is still showing up in task.c, since it's now two includes down (hostKernel.h has been added which seems to still import asm/page.h). If that still doesn't work, then I'll go have another think about what the problem could be...
Looks like the same error to me... # LC_ALL=C FEATURES="-ccache" emerge vmware-modules Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.15-r1 to / * vmware-any-any-update111.tar.gz MD5 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz RMD160 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz SHA1 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz SHA256 ;-) ... [ ok ] * vmware-any-any-update111.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking vmware-any-any-update111.tar.gz ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.22-gentoo-r1/build * Found sources for kernel version: * 2.6.22-gentoo-r1 >>> Unpacking source... >>> Unpacking vmware-any-any-update111.tar.gz to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work >>> Unpacking ./vmware-any-any-update111/vmmon.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmmon-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Unpacking ./vmware-any-any-update111/vmnet.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work * Applying various patches (bugfixes/updates) ... * 000_all_makefile-include-directory.patch ... [ ok ] * 020_all_epoll-def-warnings.patch ... [ ok ] * Done with patching * Converting vmnet-only/Makefile to use M= instead of SUBDIRS= ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work ... * Preparing vmmon module Using 2.6.x kernel build system. make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules make[1]: Entering directory `/usr/src/linux-2.6.22-gentoo-r1' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/driver.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/linux/hostif.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/cpuid.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/hash.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/memtrack.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/phystrack.o CC [M] /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++ include/asm/page.h: In function 'pte_t native_make_pte(long unsigned int)': include/asm/page.h:112: error: expected primary-expression before ')' token include/asm/page.h:112: error: expected ';' before '{' token include/asm/page.h:112: error: expected primary-expression before '.' token include/asm/page.h:112: error: expected `;' before '}' token make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o] Error 1 make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r1' make: *** [vmmon.ko] Error 2 !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1621: Called dyn_compile ebuild.sh, line 973: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1311: Called linux-mod_src_compile linux-mod.eclass, line 516: Called die !!! Unable to make auto-build VMWARE_VER=VME_S1B1 KERNEL_DIR=/usr/src/linux KBUILD_OUTPUT=/lib/modules/2.6.22-gentoo-r1/build. !!! 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'. !!! This ebuild is from an overlay: '/usr/portage/local/layman/vmware'
Yeah, sadly I'm not also getting the same errors. Which is a pity because I'd really thought it was working yesterday... 5:( And in fact, the changelog says it's to fix build issues on post-2.6.22 (ie 2.6.23) kernels... 5:(
(In reply to comment #62) > Yeah, sadly I'm not also getting the same errors. Which is a pity because I'd > really thought it was working yesterday... 5:( > > And in fact, the changelog says it's to fix build issues on post-2.6.22 (ie > 2.6.23) kernels... 5:( > Apologies to all :-(. My report in Comment #57 is not correct - I forgot that I had the current kernel set to linux-2.6.21-gentoo-r4. So all it proves is that the modules build under 2.6.21. This comes from trying to test while under pressure form work - not good. With kernel set to linux-2.6.22-gentoo-r1 I get the same error as in Comment #61. Sorry for misleading post. Regards Ian
Hi Guys, A few quick notes: - vmware-modules-1.0.0.16 from current vmware overlay compiles perfectly against 2.6.22.1 vanilla an ~amd64 - vmware-player-2.0.0.45731 from the overlay is broken: it comes with 2x 32bit libcrypto/libssl and therefor fails to start - after I put matching libraries (compiled via ebuild from openssl-0.9.7m, vmplayer starts, but freezes my complete system. Maybe it's a bad idea to run a VM created on another machine (amd x86). Someone else with similar problems?
Since this is a fairly long bug already, could anyone *not* reporting problems/solutions for the vmware-modules and 2.6.22+ refrain from comments? Thanks
There is An-Any patch v 1.1.2 released, maybe it could be helpfull
Miroslaw, thanks for the spotting that, I've just updated the overlay again. I've had positive results with this one (read: it actually compiled), but given how the last one got my hopes up, I'd like to ask people to test this one a bit before I say it's an actual solution. So, yep, we're now on any-any-update112 (which is allegedly capable of handling workstation 6 as well, but I've left that using the built in modules due to a problem under amd64). Please go test it out and let me know how it turns out, thanks... 5:)
Just so you know: Since two days ago, this works for me on ~amd64: vanilla-sources-2.6.22.1 from portage [I] app-emulation/vmware-workstation Installed versions: 6.0.0.45731[1](13:43:51 24/07/07) [I] app-emulation/vmware-modules Installed versions: 1.0.0.16[1](14:24:51 23/07/07)(kernel_linux) from the vmware overlay as of two days ago. My freezes with both vmplayer-2 and vmware-workstation-6 apparently are related to a faulty vm; I copied it from an ~x86 system with vmware 5. After cloning&updating the vm it works. I have to check KVM though; I remember I disabled it for testing (in the BIOS).
(In reply to comment #67) > So, yep, we're now on any-any-update112 (which is allegedly capable of handling > workstation 6 as well, but I've left that using the built in modules due to a > problem under amd64). Please go test it out and let me know how it turns out, > thanks... 5:) > Tested like this - on ~x86: 1) layman -S 2) layman -d vmware 3) app-emulation/vmware-modules: 1.0.0.15-r1 in /usr/portage/local/layman/vmware 4) ian2 ~ # eselect kernel list Available kernel symlink targets: [1] linux-2.6.21-gentoo-r4 [2] linux-2.6.22-gentoo-r1 * (given previous track record worth being explicit :-/) 5) emerge app-emulation/vmware-modules >>> Merging app-emulation/vmware-modules-1.0.0.15-r1 to / ..... >>> /lib/modules/2.6.22-gentoo-r1/misc/vmmon.ko >>> /lib/modules/2.6.22-gentoo-r1/misc/vmnet.ko 6) ian2 ~ # uname -r 2.6.22-gentoo-r1 7) /etc/init.d/vmware stop stopped all OK. 8) /etc/init.d/vmware start started all OK 9) Started VM using vmware-server-console (1.0.3.44356) Started OK - network OK - looks good. Hopefully I have contributed a meaningful test this time :-/. Regards Ian
Works for me. Thanks a lot!
Working here, too. (vmware-modules-1.0.0.15-r1 and eclasses from the overlay with vmware-server-1.0.3.44356 running on kernel 2.6.22-gentoo-r1)
(In reply to comment #71) > Working here, too. (vmware-modules-1.0.0.15-r1 and eclasses from the overlay > with vmware-server-1.0.3.44356 running on kernel 2.6.22-gentoo-r1) > Same. No kernel patching required. Issues appear resolved.
I'll be pushing in 2.6.22-stabling direction in the next few days. It would be nice to see this in portage soon.
Ok, hopefully that patched 1.0.0.16, and the vmware-any-any-update112 version of 1.0.0.15 will be hitting the tree pretty soon, at which point this monumental bug can finally be closed... 5:) As such I'm going to mark this as fixed, please wait an hour or two, then re-"emerge --sync" and finally re-emerge vmware-modules. If there are any problems, feel free to reopen this bug, or simply comment on it if you can't. Thanks very much for your patience, and sorry for the delay...
(In reply to comment #74) > Ok, hopefully that patched 1.0.0.16, and the vmware-any-any-update112 version > of 1.0.0.15 will be hitting the tree pretty soon, at which point this > monumental bug can finally be closed... 5:) > > As such I'm going to mark this as fixed, please wait an hour or two, then > re-"emerge --sync" and finally re-emerge vmware-modules. If there are any > problems, feel free to reopen this bug, or simply comment on it if you can't. > Thanks very much for your patience, and sorry for the delay. I did emerge --sync at approx 10:00 BST. Then: ian2 proc # emerge app-emulation/vmware-modules Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.15-r1 to / * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking vmware-any-any-update109.tar.gz ;-) ... [ !! ] !!! Missing digest for 'vmware-any-any-update109.tar.gz' I then did: # ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.15-r1.ebuild digest >>> Creating Manifest for /usr/portage/app-emulation/vmware-modules digest.assumed 1 digest-vmware-modules-1.0.0.16::VMware-player-2.0.0-45731.x86_64.tar.gz and then: emerge app-emulation/vmware-modules which produced: >>> Unpacking source... >>> Unpacking vmware-any-any-update109.tar.gz to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work >>> Unpacking ./vmware-any-any-update112/vmmon.tar to /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1621: Called dyn_unpack ebuild.sh, line 753: Called qa_call 'src_unpack' ebuild.sh, line 44: Called src_unpack ebuild.sh, line 1311: Called vmware-mod_src_unpack vmware-mod.eclass, line 73: Called unpack './vmware-any-any-update112/vmmon.tar' ebuild.sh, line 404: Called die !!! ./vmware-any-any-update112/vmmon.tar does not exist !!! 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'. --- ebuild not quite there yet? Regards Ian
For me builds, and work fine too. The only exception is using of ralink 2500 wireless card. When I try to use rt2x00 git driver with vmware on my amd64, all interrupts stop. I will try to get latest git version of the driver, and report if that problem get solved.
Just to verify that it's not just him, I have the same issue as Ian P.
Chris and Ian, please verify that you've removed the vmware overlay, that /usr/portage/eclass/vmware.eclass contains the line: export ANY_ANY="vmware-any-any-update112" and please also ensure that in /usr/portage/app-emulation/vmware-modules there's no mention of update109: grep -ir 109 * which should only return two entries, from the changelog. It sounds more like a metadata issue (ie, your /usr/portage/metadata/cache is out of date), which may be a problem we have to fix, but in the interim, you can try: emerge --metadata
(In reply to comment #78) > Chris and Ian, please verify that you've removed the vmware overlay, that > /usr/portage/eclass/vmware.eclass contains the line: > > export ANY_ANY="vmware-any-any-update112" > > and please also ensure that in /usr/portage/app-emulation/vmware-modules > there's no mention of update109: > > grep -ir 109 * > > which should only return two entries, from the changelog. > > It sounds more like a metadata issue (ie, your /usr/portage/metadata/cache is > out of date), which may be a problem we have to fix, but in the interim, you > can try: > > emerge --metadata > PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/local/portage" ian2 ~ # ls -al /usr/local/portage total 0 drwxr-xr-x 6 root root 152 2007-06-17 10:13 . drwxr-xr-x 10 root root 312 2005-08-24 07:38 .. drwxr-xr-x 3 root root 80 2007-01-09 10:44 dev-perl drwxr-xr-x 2 root root 48 2007-06-18 08:30 net-im drwxr-xr-x 4 root root 128 2007-07-10 16:08 net-misc drwxr-xr-x 2 root root 48 2007-01-09 10:20 perl-gcpan ian2 layman # pwd /usr/portage/local/layman ian2 layman # tree | grep vm | |-- libvmime | | | `-- libvmime-0.8.1-gnutls_ssl-detection.patch | | |-- libvmime-0.8.1.ebuild ---> vmware overlay thus fully removed. At 10:00BST: emerge --sync emerge --metadata ian2 ~ # grep 112 /usr/portage/eclass/vmware.eclass export ANY_ANY="vmware-any-any-update112" ian2 vmware-modules # pwd /usr/portage/app-emulation/vmware-modules ian2 vmware-modules # grep -ir 109 * ChangeLog: Remove unnecessary patch, that's now part of any-any109. ChangeLog: Redigest for vmware-any-any109. Manifest:EBUILD vmware-modules-1.0.0.16.ebuild 736 RMD160 31ead4ad925e473431f3dd1291b3b6752a3e2fad SHA1 33a4d8abb4b3ad304b15e657b24df5109929a432 SHA256 40f1b7539e34a8f152ddde99316f67304af99ff10469570f378d8a82fcc017e8 ian2 eclass # emerge -pv app-emulation/vmware-modules These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-emulation/vmware-modules-1.0.0.15-r1 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB ian2 eclass # emerge app-emulation/vmware-modules Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.15-r1 to / * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking vmware-any-any-update109.tar.gz ;-) ... [ !! ] !!! Missing digest for 'vmware-any-any-update109.tar.gz' ----- I have also done a diff between the overlay vmware.eclass and vmware-mod.eclass and the copies in /usr/portage/eclass: ian2 eclass # diff vmware-mod.eclass /usr/portage/local/layman/vmware/eclass/vmware-mod.eclass 3c3 < # $Header: /var/cvsroot/gentoo-x86/eclass/vmware-mod.eclass,v 1.13 2007/07/28 18:00:42 ikelos Exp $ --- > # $Header: /var/cvsroot/gentoo-x86/eclass/vmware-mod.eclass,v 1.11 2007/07/12 23:57:42 wolf31o2 Exp $ ian2 eclass # diff vmware.eclass /usr/portage/local/layman/vmware/eclass/vmware.eclass 3c3 < # $Header: /var/cvsroot/gentoo-x86/eclass/vmware.eclass,v 1.25 2007/07/28 17:29:56 ikelos Exp $ --- > # $Header: /var/cvsroot/gentoo-x86/eclass/vmware.eclass,v 1.24 2007/04/28 09:40:42 ikelos Exp $ 274c274 < for p in /bin/vmware-ping /lib/bin/vmware-vmx /lib/bin-debug/vmware-vm /sbin/vmware-authd; --- > for p in /bin/vmware-ping /lib/bin/vmware-vmx /lib/bin-debug/vmware-vmx /sbin/vmware-authd; ---- just that one line that doesn't seem to be part of the problem.. I'm stumped. If I add the overlay vmware back again (after all the above), it works, and as far as I can see there is no difference between what is in the overlay and the standard e-build. Regards Ian
I had the same symptoms - all portage trees clear of mention of any-any 109, yet the ebuild used the wrong source. It turns out: /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 is the culprit. Removing it allows successful compilation. As to why portage failed here, I do not know - and yes I had done "emerge --metadata" before hand.
(In reply to comment #80) > I had the same symptoms - all portage trees clear of mention of any-any 109, > yet the ebuild used the wrong source. > > It turns out: > /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 > is the culprit. Removing it allows successful compilation. > > As to why portage failed here, I do not know - and yes I had done "emerge > --metadata" before hand. > I can confirm that deleting /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 lets the compilation work OK. Its strange, because the file will appear again after doing an 'emerge --metadata': ian2 ~ # rm /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 ian2 ~ # ls -l /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 ls: cannot access /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1: No such file or directory ian2 ~ # emerge --metadata >>> Updating Portage cache: 100% ian2 ~ # ls -l /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 -rw-rw-r-- 1 root portage 1201 2007-07-12 08:05 /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 ... and then emerge app-emulation/vmware-modules fails with the 109 problem. Also after an emerge --sync (at 13:52 BST) the file re-appears and causes 109 problem. Regards Ian
The local cache is generated from the tree-based cache it seems, so removing both: /usr/portage/metadata/cache/app-emulation/vmware-modules-1.0.0.15-r1 and: /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 Stops the problem coming back when you "emerge --metadata". The portage tree's cache needs to be updated, unless it was caused by an unfortunately timed commit? No idea, but it's fixed-for-me(tm) now!
(In reply to comment #82) > The local cache is generated from the tree-based cache it seems, so removing > both: > > /usr/portage/metadata/cache/app-emulation/vmware-modules-1.0.0.15-r1 > > and: > > /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 > > Stops the problem coming back when you "emerge --metadata". > > The portage tree's cache needs to be updated, unless it was caused by an > unfortunately timed commit? No idea, but it's fixed-for-me(tm) now! > Works for me (tm) as well :-). Deleted both the files and they stayed deleted after an emerge --sync;emerge --metadata Many thanks Regards Ian
It works now. However, when I go to "power on" my virtual machine, it hard-locks my system, keyboard and all. I tried downgrading my nvidia drivers several steps, and it still locks, so it isn't that. At this point I'm willing to just do without it. It does, however, merge and vmware itself runs.
(In reply to comment #84) > It works now. However, when I go to "power on" my virtual machine, it > hard-locks my system, keyboard and all. I tried downgrading my nvidia drivers > several steps, and it still locks, so it isn't that. For me it did the same, until I cloned+converted it (upgraded from vmware 5 to 6). The converted VM runs perfectly though.
*** Bug 187181 has been marked as a duplicate of this bug. ***
Hi guys, this bug is now FIXED, so unless you have a specific problem that looks exactly like this bug, please look for and, if one doesn't exist, file a new bug. For those of you experiencing digest problems, this should now be fixed, but please attach yourself to bug 187129. For those of you featuring hard locks, please be aware that Amd64 boxes have a known problem that will cause them to hardlock, and there also seems to be some issues with machines that have not been upgraded to vmware 6. For anything else, look for an existing bug first, and then file a new one if you can't find one that exists. Thanks...
kali ~ # grep 112 /usr/portage/eclass/vmware.eclass export ANY_ANY="vmware-any-any-update112" kali ~ # rm /usr/portage/metadata/cache/app-emulation/vmware-modules-1.0.0.15-r1rm: cannot remove `/usr/portage/metadata/cache/app-emulation/vmware-modules-1.0.0.15-r1': No such file or directory kali ~ # rm /var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1 rm: cannot remove `/var/cache/edb/dep/usr/portage/app-emulation/vmware-modules-1.0.0.15-r1': No such file or directory kali ~ # emerge --sync;emerge --metadata kali ~ # grep -ir 109 /usr/portage/app-emulation/vmware-modules /usr/portage/app-emulation/vmware-modules/ChangeLog: Remove unnecessary patch, that's now part of any-any109. /usr/portage/app-emulation/vmware-modules/ChangeLog: Redigest for vmware-any-any109. /usr/portage/app-emulation/vmware-modules/Manifest:EBUILD vmware-modules-1.0.0.16.ebuild 736 RMD160 31ead4ad925e473431f3dd1291b3b6752a3e2fad SHA1 33a4d8abb4b3ad304b15e657b24df5109929a432 SHA256 40f1b7539e34a8f152ddde99316f67304af99ff10469570f378d8a82fcc017e8 kali ~ # layman -d vmware * Overlay "vmware" does not exist! kali ~ # ls -d /usr/portage/local/layman/* /usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml /usr/portage/local/layman/make.conf /usr/portage/local/layman/overlays.xml /usr/portage/local/layman/xen kali ~ # FEATURES="-ccache" emerge -pv vmware-modules 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 Total: 1 package (1 new), Size of downloads: 0 kB kali ~ # eselect kernel list Available kernel symlink targets: [1] linux-2.6.19-gentoo-r5 [2] linux-2.6.20-gentoo-r8 [3] linux-2.6.21-gentoo-r4 [4] linux-2.6.22-gentoo-r2 * kali ~ # FEATURES="-ccache" emerge -v vmware-modules 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 Total: 1 package (1 new), Size of downloads: 0 kB >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/vmware-modules-1.0.0.15-r1 to / * vmware-any-any-update112.tar.gz RMD160 ;-) ... [ ok ] * vmware-any-any-update112.tar.gz SHA1 ;-) ... [ ok ] * vmware-any-any-update112.tar.gz SHA256 ;-) ... [ ok ] * vmware-any-any-update112.tar.gz size ;-) ... [ ok ] [...] cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++ /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c: In function `int Task_InitCrosspage_TOT(VMDriver*, InitBlock*)': /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c:337: error: '->' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c:337: error: `&' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c:353: error: '->' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c:353: error: `&' cannot appear in a constant-expression In file included from /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.c:1193: /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task_compat.h: In function `int Task_InitCrosspage_V6(VMDriver*, InitBlock*)': /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task_compat.h:352: error: '->' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task_compat.h:352: error: `&' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task_compat.h:368: error: '->' cannot appear in a constant-expression /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task_compat.h:368: error: `&' cannot appear in a constant-expression make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only/common/task.o] Error 1 make[2]: *** [_module_/var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work/vmmon-only] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r2' make: *** [vmmon.ko] Error 2 !!! ERROR: app-emulation/vmware-modules-1.0.0.15-r1 failed. Call stack: ebuild.sh, line 1632: Called dyn_compile ebuild.sh, line 983: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1322: Called linux-mod_src_compile linux-mod.eclass, line 516: Called die !!! Unable to make auto-build VMWARE_VER=VME_S1B1 KERNEL_DIR=/usr/src/linux KBUILD_OUTPUT=/lib/modules/2.6.22-gentoo-r2/build. !!! 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'.
I tried using the vmware layman and got the same problem :(
layman -d cd /var/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r1/work patch -p0 </tmp/attachment.cgi\?id\=125170 # 1.0.0.15-kernel-2.6.22.patch patching file vmmon-only/common/hostKernel.h Same problem and even 2.6.20 or 2.6.21 is broken now.
Sulla, please be aware that vmware-modules will no longer build against gcc-3.x, and requires gcc-4.x to compile. This bug's original compilation problems are not the same as yours. Please see bug 187292 instead.
(In reply to comment #91) > Sulla, please be aware that vmware-modules will no longer build against > gcc-3.x, and requires gcc-4.x to compile. This bug's original compilation > problems are not the same as yours. Please see bug 187292 instead. > Then why isn't there any notes or dependency requirement against gcc-4.x? I wasted hours today because of this ommission and why have you deleted the previous ebuilds? so I couldn't even roll back to a working version.
The package manager is only capable of knowing which versions of GCC are on your system, not which is being used. Now, this isn't a discussion forum. If you are not experiencing this exact bug, it doesn't belong here. Thanks
Created attachment 144529 [details] ebuild new
CC [M] /var/portage/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r2/work/vmnet-only/bridge.o /var/portage/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r2/work/vmnet-only/bridge.c: In function ‘VNetBridgeUp’: /var/portage/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r2/work/vmnet-only/bridge.c:949: error: implicit declaration of function ‘sock_valbool_flag’ make[3]: *** [/var/portage/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r2/work/vmnet-only/bridge.o] Error 1 make[2]: *** [_module_/var/portage/tmp/portage/app-emulation/vmware-modules-1.0.0.15-r2/work/vmnet-only] Error 2 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.25-rc1' make: *** [vmnet.ko] Error 2 * * ERROR: app-emulation/vmware-modules-1.0.0.15-r2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3226: Called linux-mod_src_compile * environment, line 2433: Called die
Barbu, You compilation failure had no associated description, and also this bug has been marked as closed an fixed. Please ensure you are attempting to compile vmware-modules-1.0.0.15-r1.ebuild from the main portage tree (not an ebuild) and if you're still experiencing a problem, file a new bug providing some text surrounding what problem you're having exactly, a copy of the build failure (just like your most recent comment) and a copy of the output from emerge --info. Please avoid putting any further comments on this bug unless they are directly related and you provide text explaining why the bug is still present. Thanks... 5:)
