If you have troubles installing on the newest Fedora, here is the workaround:
vmware-workstation 9.0.1.894247
Fedora Core 18 Release (Vanilla) kernel 3.7.2-201.fc18.x86_64
Just do:
sudo yum install kernel-*
sudo cp /usr/src/kernels/3.7.2-201.fc18.x86_64/include/generated/uapi/linux/version.h /lib/modules/3.7.2-201.fc18.x86_64/build/include/linux/
hope it helps
Thanks, this solved it for me.
Thanks! Worked perfectly
Hello.
This is for installing VMWare in Fedora and not backwards
I clearly didn't read the original post clearly enough, as I am running Fedora 18 in Workstation. This fix allowed me to install Tools which weren't working prior to the change.
The fix worked bothi ways. Installed WS 9 on Fedora 18 host - kernel 3.7- and install VMware Tools on a Fedora 18 guest running on an Ubuntu 13.04 host. Now if I can find a fix that will work with Ubuntu and openSUSE hosts to allow WS install on kernel 3.7! As usual VirtualBox works on any kernel as well as Oracle extentions and guest tadd-ons.
No worries - it works now, thanks much for your help!
Disabling "3D Graphics Acceleration" in the Display section of the configuration will fix the problem. However, this will cause Fedora 18 to feel very sluggish. Anybody know how to get Fedora 18 to work with 3D Graphics Acceleration enabled?
thanks,
Chris
Have look uname -a and found that I has 3.7.4-204.fc18.x86_64 . What I can do? Only back to original?
Try this
sudo yum install kernel-*
sudo cp /usr/src/kernels/$(uname -r)/include/generated/uapi/linux/version.h /lib/modules/$(uname -r)/build/include/linux/
I'm still struggling to get 3D acceleration to work in Fedora 18 with Workstation 9/Player 5 (on a Windows 7 host). I've seen reports suggesting that the problem is with the OpenGL libraries or display drivers on Fedora, and that I need to enable blacklisted drivers. However, 3D acceleration seems to work just fine with Ubuntu 10.4 running on exactly the same host. Does anybody know what the differences are between Fedora and Ubuntu that enable this to work with Ubuntu but not with Fedora?
Thanks,
Chris
Although this workaround worked with 3.7.2-201.fc18.x86_64/ it failed with 3.7.2-204.fc18.x86_64 which was normal update. When updating a kerenel Fedora replaces the devel files of the earlier kernel so you can't go back to it (perhaps one might find in some rpm search). WS would not compile for me with the 204 kernel because of the problem that WS cannot find the heaaders. I have found a work around for that by installing the debug version of the kernel - but that is slower of course.
You must change the path in the source and destination for the cp command to work.
The REVISED cp command that nrivoli posted Feb 1, 2013 7:36 AM should always work as long as youv'e rebooted since updating your kernel and if you haven't you should.
Yes I did reboot and yes I did change the path to reference the 204 kernel. I alwalys reboot after a kernel upgrade in any Linux flavor. Perheps I should not have removed the 201 kernel since WS was working under that . Unforuntaly if I did have to re-install WS for any reason I could not do after the upgrade as Fedora wipes out the devel files and upgrades them enve though it leaves the kernel alone. Even if you find the header rpm in a rpmnfind serach you can't reinstall them because the newer version is already installed. The same thing happlens in openSUSE. The .h are greyed out and so apparently inaccessible to WS even if you point to thiem. I have given up try to install WS on openSUSE 12.2 and Fedora 18 with 3.7 or 3.8 kernels until the kernel developers post on what to do. Haven't tried rolling my own kernel however.
Ifoufind a solution please please let me know.
-----------------------------
Actually I did get the instgall working but orgot that I'd p[osted it already. I installed the debug version of the kenrel (3.7.x) and chanaged the pathi accordinaly. Too bad I wasn't realy intersted in debug version versions of a kernel - theyi are invariably slower (as for that matter prerealeased versions of WS). Extra debugging code. Guess the kernel developers need to find the .h files if they deblug the kernel. :smileylaugh: