fedora core 3 on vmware
[![/space/vmware.png](/space/vmware.png)](http://vmware.com/)[![/space/redhat.jpg](/space/redhat.jpg)](http://redhat.com/)[![/space/fedora.png](/space/fedora.png)](http://fedora.redhat.com/)

I
recently upgraded to [VMWare](http://vmware.com/) 4.5.2, with [Fedora Core
3](http://fedora.redhat.com/) as the guest and Windows XP as the host. It was
much smoother than I expected, but it still needed a few tweaks. Here's what I
did to whip it into shape.

_Since I wrote this, I've upgraded to VMware 6.0.0 and switched from FC3 to
[Ubuntu](http://ubuntu.com/) Dapper (6.06), then later to Feisty (7.04). Almost
all of these tips still apply, though!_

  * The kernel that shipped with FC3, 2.6.9-1.667, was slower than mud. X
windows was especially bad, and would routinely use 50-60% of the CPU for
nothing more than typing in Emacs. Kerneltrap's
[keithmo](http://kerneltrap.org/user/1638) provided a ["minimal" 2.6.9 kernel
config](http://kerneltrap.org/node/4030), which I used to build my own kernel.
It was better, but still much slower than it should have been. A few people
[blamed the 4G/4G kernel
patch](http://www.vmware.com/community/thread.jspa?forumID=19&threadID=16154&messageID=174172#174172),
which can perform poorly and was dropped in later FC3 kernels. Sure enough,
**yum update kernel** bumped me to 2.6.11-1.14\_FC3, which was just as fast
under VMWare as my old, trusty RH9.

  * ...except that it broke X windows. X would start and the mouse driver would
load, but it wouldn't start my window manager or anything else. I was stuck with
a black screen and a mouse cursor. Worse, the keyboard driver didn't load, so I
couldn't Alt-F1 or Ctrl-Alt-Backspace to get back to a tty! I looked at
/var/log/Xorg.0.log, but didn't see any obvious errors. After an hour of poking
at xorg.conf and vmware-config-tools.pl, I finally tried **yum update
xorg-x11**. It gave me version 6.8.2-1.FC3, which worked beautifully.

  * The 2.6 kernel and VMWare 4.5.2 also fought over the system clock.
Specifically, the clock in the Linux guest ran 2-5x slower than real time. This
affects everything time-based, including the keyboard repeat delay, which is
very annoying. The problem
[is](http://www.vmware.com/community/thread.jspa?threadID=4254)
[well](http://www.vmware.com/community/thread.jspa?forumID=19&threadID=6561&messageID=92759)
[documented](http://www.vmware.com/community/thread.jspa?threadID=10158) on the
VMWare forums, and there are a couple solutions. First, try the **clock=pit**
kernel option. (Append it to the **kernel** line in /etc/grub.conf). If that
doesn't work, download the source for your kernel, change the **HZ** constant in
include/asm-i386/param.h from 1000 to 100, and rebuild. **clock=pit** didn't
work for me, but changing **HZ** to 100 did.

  * [Shared
folders](http://www.vmware.com/support/ws5/doc/ws_running_shared_folders.html)
didn't work out of the box. Evidently, VMWare's hgfs driver doesn't get along
with recent Linux 2.6 kernels. This is well documented on the VMWare and RedHat
forums...and luckily, one intrepid hacker has [posted a
fix](http://www.vmware.com/community/thread.jspa?forumID=19&threadID=7556&messageID=57559).
To apply it, [download the
patch](/space/vmware_tools_hgfs_linux_2.6_guest.patch),
then apply it to the vmhgfs driver source and re-run the VMWare Tools config
script. When it asks if you want to compile the hgfs module from source, say
yes. Here are the commands:

        tar xf /usr/lib/vmware-tools/modules/source/vmhgfs.tar
        patch -p 0 < vmware\_tools\_hgfs\_linux\_2.6\_guest.patch
        tar cf vmhgfs.tar vmhgfs-only/
        cp vmhgfs.tar /usr/lib/vmware-tools/modules/source/
        /usr/bin/vmware-config-tools.pl


  * [Yum](http://yum.baseurl.org/) is the preferred package
manager for FC3. It's fairly similar to
[apt-get](http://apt4rpm.sourceforge.net/), which I'd used for a while. Once I
added the [Fedora Extras](http://fedoraproject.org/wiki/Extras_2fUsingExtras),
[FreshRPMs](http://ayo.freshrpms.net/), and
[Dag](http://dag.wieers.com/home-made/apt/FAQ.php#B3) repositories, I was able
to install almost everything I needed, including...

  * ...[ion](/space/ion), my window manager! It's not exactly mainstream, so I'd
always had to build it from source, but now there's an
[RPM](http://rpm.pbone.net/index.php3/stat/4/idpl/1753782/com/ion-20040729-2mdk.i586.rpm.html).
It requires lua-5.0.2 and lua-devel-5.0.2, which yum will kindly install for
you.

  * Yum also found an RPM for [Pine](http://washington.edu/pine/), my email
client. Unfortunately, it complained that it couldn't find libldap.so.2. A quick
**ln -s /usr/lib/libldap.so /usr/lib/libldap.so.2** made it happy.

  * FC3 came with [Firefox](http://getfirefox.org/) 1.0PR1, which was dog slow.
It literally took 5-10 seconds to load a page, switch from one tab to another,
etc. I used **yum update firefox** to upgrade to 1.0.2, which is much better.

  * I use Ian Macdonald's wonderful
[acoc](http://www.caliban.org/ruby/acoc.shtml) tool, which adds color to most
command-line \*nix utilities. However, it didn't quite install out of the box. I
installed the [ruby-term-ansicolor
rpm](http://www.caliban.org/files/redhat/RPMS/i386/ruby-term-ansicolor-1.0.0-1.i386.rpm),
but acoc still complained that it couldn't find ansicolor.rb. Turned out it was
looking in /usr/lib/ruby/site\_ruby/1.8/term, but acoc wanted it in
/usr/lib/ruby/1.8/term. A quick mkdir -p and a ln -s fixed this.

  * **xview** is my image viewer of choice, and it came with RH9, but not with
FC3. This wouldn't be a big deal, except it took me a while to figure out which
package it came in. Turns out it's part of **xloadimage**, which yum happily
installed for me.

  * I use [GNU Emacs](http://gnu.org/software/emacs/), and I use
[Subversion](http://subversion.tigris.org/), so I expect them to work together.
I use vc-svn.el, which provides VC-mode in Emacs for Subversion. However, the
Subversion folks are currently handing that hot potato over to the Emacs folks,
and in FC3, _neither_ package has it! This was easily remedied, though. Download
the [last version of
vc-svn.el](http://svn.collab.net/viewcvs/*checkout*/svn/trunk/contrib/client-side/vc-svn.el?rev=9195)
from the Subversion web-based repository and put it in
**/usr/share/emacs/site-lisp**.

  * I also use **savehist.el** in Emacs, which saves and restores most session
history. It's in xemacs-edit-utils-pkg, which ships with
[XEmacs](http://xemacs.org/). However, finding a version that's compatible with
GNU Emacs is iffy at best. So, I'm hosting it here: [savehist.el 0.4 for GNU
Emacs](/space/savehist.el).

  * I work from home occasionally. To do this, I ssh to
[work](http://google.com/), run programs on my RH9 workstation remotely, and
display them on my local X server through the ssh tunnel. Unfortunately FC3 has
[xorg-x11](http://x.org/), RH9 has [XFree86](http://xfree86.org/), and they
don't play well together out of the box. Luckily, this turned out to be easy to
fix. I just needed to add **ForwardX11Trusted yes** to my **~/.ssh/config**.
Voila! Happy remote X display.

  * FC3 thoughtfully includes [mplayer](http://mplayerhq.hu/) in its base
distribution. However, it doesn't include the optional codecs, such as
[RealPlayer](http://real.com/). To install them, [download the
codecs](http://www.mplayerhq.hu/MPlayer/releases/codecs/rp9codecs-20050115.tar.bz2)
from the mplayer page and extract them into /usr/lib/win32. (The mplayer docs
have [more information](http://mplayerhq.hu/DOCS/HTML/en/codecs.html#realvideo),
but you shouldn't need it.)

  * Both FC3 and [Ubuntu](http://ubuntu.com/), my new distro, use
[GDM](http://gnome.org/projects/gdm/). I don't mind GDM and X sessions, but I
prefer a console login and [xinit](http://xfree86.org/current/xinit.1.html). To
turn off GDM on Ubuntu, run
**update-rc.d -f gdm remove; update-rc.d gdm stop 20 2345**. On FC3, comment
out this line in **/etc/inittab**:

        x:5:respawn:/etc/X11/prefdm -nodaemon

  * [HGFS](http://www.vmware.com/support/ws4/doc/running_sharefold_ws.html),
VMWare's Linux filesystem for shared folders, is quirky about permissions with
Linux guests on Windows hosts. Windows and *nix filesystems handle permissions
differently. *nix's are generally richer, so when the physical filesystem is
on Windows, HGFS allows full access too all files for all users, but exposes
their permissions as 700 and owned by root:root. This means that stat thinks
you can't read them! This often crops up when running a `configure` script (or
`autogen.sh`, `autoconf`, and `automake`) to build a program from source. I've
[asked VMWare about this](http://www.vmware.com/community/thread.jspa?threadID=85594&tstart=0),
but for now, it looks like the only workaround is not to use HGFS. :/