vmware-server 1.0.9 on Fedora 10

In previous postings, I have talked about using VMware-Workstation.  I also use VMware-server, VMware’s free application.  Specifically I use version 1.0.x but 1.0.x is getting a little long in the tooth to work on most current versions of Fedora. VMware-server 2.0.x is the current version but it is quite a big application.  The RPM is 4x the size of the 1.0.x version and I’ve not had the time and patience to get it working on Fedora.  I guess I have not had any need, since 1.0.x still works for what I use it for.

Earlier this week I was on the VMware website and noticed there is a newer version of server, 1.0.9.  So I downloaded it and started to install it.  The last few times I’ve installed 1.0.7 or 1.0.8, I had to hack it to get it to run.  I finally decided it was time to sit down and document all of these hacks.  Some have been found on the web, but not all of them in one location or related to Fedora.  So here goes …

The first problem you run into is the compilation of the kernel modules.  This is when you run the vmware-config.pl command for the first time after installing or updating the RPM.  The compilation error looks like this:

/tmp/vmware-config1/vmmon-only/./include/compat_semaphore.h:5:27: error: asm/semaphore.h: No such file or directory

There is an easy solution for this posted here. The problem is the vmware kernel modules that come with VMware-server 1.0.x are for very old kernels (pre 2.6.27), nothing that current versions of Fedora run.  Once you apply the newer kernel module sources, this solution gets you to the point the kernel modules can be compiled.  This will allow you to start your vmware service.

The next problem is starting up the vmware console application itself:

/usr/lib/vmware/bin/vmware: symbol lookup error: /lib/libgio-2.0.so.0: undefined symbol: g_thread_gettime

Vmware is using its own libglib-2.0 instead of the system one and libgio needs symbols that were not in vmware’s version.  The solution is to copy your system’s version of libglib-2.0.so.0 to /usr/lib/vmware/lib/libglib-2.0.so.0/.

The third problem is also a shared library issue, but this time vmware needs a custom shared library that does not come with the package.  That shared library is libX11.so.6.  When launching the vmware console application, you get this error:

/usr/share/themes/Nodoka/gtk-2.0/gtkrc:37: error: unexpected character `@’, expected string constant
Locking assertion failure. Backtrace:
…

I removed the backtrace.  The solution is to find an older version of libX11.so.6 (not sure where I found mine), create a directory /usr/lib/vmware/lib/libX11.so.6 and put the library file in there.  Then you need to patch /usr/lib/vmware/lib/wrapper-gtk24.sh with this patch:

— wrapper-gtk24.sh.orig       2008-11-05 08:44:56.000000000 -0500
+++ wrapper-gtk24.sh    2008-11-05 08:45:21.000000000 -0500
@@ -63,6 +63,7 @@
vm_append_lib ‘libfreetype.so.6’
vm_append_lib ‘libXft.so.2’
vm_append_lib ‘libXrender.so.1’
+   vm_append_lib ‘libX11.so.6’

# FontConfig is actually fairly well behaved but the fonts.conf that we
# force when VMWARE_USE_SHIPPED_GTK=yes generates seemingly harmless

This patch tells vmware to use your older libX11.so.6 library instead of the system library.  You will still get the gtkrc error, but you will not get the backtrace and vmware console will start.  You now have successfully installed vmware-server 1.0.x on a current version of Fedora.