A little while ago (and again more recently) I updated my kernel to 3.7.3-101 and was stumped as to why VMware Workstation was unable to find the matching kernel headers, despite confirming they were indeed correct and installed. After lots of searching and some reading, I found the following command:

ln -s /usr/src/kernels/3.7.3-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.3-101.fc17.x86_64/include/linux/version.h

This basically creates a symbolic link in the /usr/src/kernels/<version>/include/linux/ directory for the version.h file that the VMware Workstation compiler is looking for. After running this command, I started VMware Workstation again and was greeted by the GUI compiling the necessary modules to run VMware Workstation.

I suspect the requirement for this command has something to do with re-arrangement of kernel source files in recent releases. It seems likely that VMware will update the compiler in new releases of their Workstation product.

Here’s a more recent upgrade, using the same step:

ln -s /usr/src/kernels/3.7.9-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.9-101.fc17.x86_64/include/linux/version.h

So long as you have the matching kernel headers installed, the above command should work for you just fine.

Note: On the second time around, I had troubles when running VMware Workstation as a normal user (just the compiling step, afterwards it was fine). For some reason there was an issue elevating the user to root (this happened to me on Fedora 17 x86_64) to complete the compiler process. To work around this, I simply opened a console/terminal, became root (sudo, or su – , whatever suits you) and then typed just: vmware – The compiler GUI appeared and completed, followed by VMware Workstation starting. I then closed ‘that’ VMware Workstation and started it my usual way (KDE menu for me) and it worked just fine.

Update (2013-03-25): VMware has recently released VMware Workstation 9.0.2 (2013-03-07) which has the above issue resolved. I am currently running VMware Workstation 9.0.2 build-1031769 on Fedora 17 (Kernel 3.8.3-103) and I did not have to carry out any additional steps to compile the kernel modules.

Update 2 (2013-07-10): I updated my kernel today, all the way up to 3.9.6-200-fc18 – Afterwards I was unable to compile the module again. After much searching, trouble-shooting and attempts to roll back to previous kernels, I checked something a little more fundamental; was gcc installed? Nope! It wasn’t! A quick browse through my yum logs showed it removed as a dependency when I removed something else earlier in the year. After installing gcc again, the kernel module compiled normally again 😉

Update 3 (2013-08-30): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.10.9-200.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel modules kept failing to compile (different to the previous issues). I did a quick google search for “vmware kernel 3.10.9-100” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author at http://guide.ecsmy.com/ for getting this one out there!

# tar xf /usr/lib/vmware/modules/source/vmnet.tar
# cd vmnet-only
# wget  http://communities.vmware.com/servlet/JiveServlet/download/2239207-108590/procfs.patch
# patch -p1 < procfs.patch
# cd ..
# tar -cvf vmnet.tar vmnet-only/
# cp vmnet.tar /usr/lib/vmware/modules/source/

This will patch the procfs interface.

Secondly download the vmnet patch from http://mysticalzero.blogspot.com/2013/07/vmblock-patch-for-linux-310-vmware.html. The link of the patch is here.

Or you can use the following command:

# tar xf /usr/lib/vmware/modules/source/vmblock.tar
# cd vmblock-only
# wget  https://sites.google.com/site/mysticalzerotmp/vmblock.3.10.patch
# patch -p1 < vmblock.3.10.patch
# cd ..
# tar -cvf vmblock.tar vmblock-only/
# cp vmblock.tar /usr/lib/vmware/modules/source/

Then, issue this command to compile and install the vmware player module

# sudo vmware-modconfig –console –install-all

I know it says ‘vmware player’ but trust me, it works for VMware Workstation just the same.

Update 4 (2013-10-20): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.11.4-101.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel vmblock module kept failing to compile (similar but different to the previous issue). I did a quick google search for “vmware kernel 3.11” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author (dibl) at siduction.org for getting this one out there!

The VMware module source needs to be patched to build on kernel 3.11. If you have already patched for 3.10, then only a single patch is needed. Here is the procedure:

Download the “vmblock.3.11.patch” from here.

In a root terminal, give these commands:

# cd /usr/lib/vmware/modules/source
# tar xvf vmblock.tar
# cd vmblock-only
# patch -p1 < /path/to/vmblock-3.11.patch
# cd ..
# tar cvf vmblock.tar vmblock-only/
# vmware-modconfig –console –install-all

You should see an error-free completion of the build.

Update 5 (2013-12-14): While still on Fedora 18 (I know, Fedora 19 is well and truly out, and Fedora 20 (celebrating 10 years of Fedora Linux!) is less than three weeks away from release!), I just upgraded to Kernel 3.11.10-100. I also upgrade from VMware Workstation 9.0.2 to VMware Workstation 10.0.1 – After a reboot, no additional work required. VMware Workstation 10.0.1 simply worked ‘straight out of the box’ so to speak 😉

I recently had a requirement to remove vmware tools manually from a windows 2003 server. This is what I had to do.

  • Remove any keys with a DisplayName of VMware Tools anywhere in the following keys:
    • HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionuninstall
    • HKEY_LOCAL_MACHINESoftwareClassesInstallerProducts

 

  • Remove the keys with a ProductName of VMware Tools in the following keys HKEY_CLASSES_ROOTInstallerProducts
  • Delete the branch named VMware Tools in HKEY_LOCAL_MACHINESoftwareVMware
  • Delete the "VMware Tools" directory within in the Vmware directory under Program Files
  • Restart the server.

Props to WarOnErrors.

I spent some time setting up Microsoft Exchange 2010 Enterprise today. Following Microsoft documentation, I had to do it the ‘advanced’ (aka custom) way and found myself needing to know my ‘Active Directory Site Name’. I tried all sorts of values while trying to set up a Client Access Array on the domain contoso.com using this command:

New-ClientAccessArray -FQDN ClientArray.contoso.com -Site “Contoso” -Name “clientarray.contoso.com”

I kept getting an error message like this:

Exchange can’t find Active Directory Site Contoso. Make sure it exists.

I couldn’t for the life of me figure out what the value for ‘Your Site’ was.

I Googled and Searched and Searched and Googled.

In the end I did something extraordinary. I logged onto my Active Directory server, and loaded up the ‘Active Directory Users and Computers‘ snap in. Under ‘Domain Controllers‘ it was right in front of me…

Default-First-Site-Name – Not only had I not set a ‘Site Name‘ but I only needed to check the properties of the only domain controller in my forest to find it!

A few days ago I posted about a get of jail free card, restoring your Motorola Xoom from the original disk images, available from http://developer.motorola.com/products/software/. I noted that you should download the bundle that matches your country of residence. Well, I’m in Australia, so naturally I would select (and was selecting) the Australian bundle (Build H.6.1-38-9 for Telstra Australia). I managed to get myself in some un-bootable trouble with my Motorola Xoom in the previous 24 hours up to this post, so I figured I’d follow my own words and restore back to the stock state. Two points to keep in mind.

  1. Some bundles are actually suitable (and will work even work!) on your Motorola Xoom, despite it not being your native country. For example, I just used the ‘Build H.6.1-38-1 for Retail Europe’ bundle to restore my Xoom. Why? Read on.
  2. The Australian Bundle ‘Build H.6.1-38-9 for Telstra Australia’ has to be broken some how. Don’t ask me why, I don’t know. What I do know is that the ‘system.img’ file has an issue. I could never boot back into HoneyComb after restoring with this bundle. I’ve confirmed this by completing an entire restore with the ‘Build H.6.1-38-1 for Retail Europe’, and then restoring the system.img from the ‘Build H.6.1-38-9 for Telstra Australia’ bundle, and it won’t boot. To further confirm it, I completed an entire restore with the ‘Build H.6.1-38-9 for Telstra Australia’ bundle. It wouldn’t boot, so I restored just the system.img from the ”Build H.6.1-38-1 for Retail Europe’ bundle, and presto, I was back up and running again, SIM card recognised, the whole lot!

Following my restore with the ‘Build H.6.1-38-1 for Retail Europe’ I also noted the entire device felt much faster, and the Market app doesn’t crash anymore! Needless to say, I’m muchly enjoying my Motorola Xoom far more then I was the day I got it home and tried to add Facebook as my first app. I was not impressed when I realised I couldn’t install any apps, and Market would just keep crashing, which lead me to my hacking, and rooting attempts and finally my requirement to restore.

Had a similar experience? Why not share it in the comments?