Step one is to concatenate fragmented VMWare images. This might not me necessary in your case, but we’ll do it anyway. Let’s assume the image you want to convert is called leopard-fragmented.vmdk:

Now you’re got a rather huge VMWare disk image file, and we’ll use qemu to convert it into a raw disk image:

This will take a while, and you’ll probably end up with a less-than-huge file since this is the raw file, without any fancy compression. Now you’ll want to convert this to the VirtualBox disk format, vdi:

The vdi ended up being around 7GB – more or less the exact size of the vmdk file. The temporary bin file was 32GB though. Be sure you’re got enough room on your disk for this job.

For starters, you have to find the ISO yourself – but I’ll give you a hint: look in /usr/share/virtualbox/ After mounting the ISO image, a directory popped up. I tried double clicking on autorun.sh but nothing ever comes easy, does it? I tried running it in the terminal, and was somewhat enlightened as I realized it was looking in vain for gksu – probably a Gnome frontend for su. Luckily there seemed to be another script I could run – VBoxLinuxAdditions-amd64.run – but it whined about OpenGL direct rendering:

Before I ran the script, I made sure the newly installed CentOS was crispy by running yum upgrade. I also had a sneaking suspicion that a C compiler was required, so I made sure the system also sported gcc. The only thing I personally noticed by reading the message above, was that some missing OpenGL crap prevented the additions to be installed. As I was typing the message in this blog, I also noticed something about kernel headers. Rather embarrassing, but I really didn’t see it until now. Anyway, obviously the thing needed was kernel goodness, so I ran yum install kernel-devel. That seemed to make the VirtualBox additions script more happy and now it seems to be running flawlessly.

So, to summarize – what to do to make the damned thing work:

I rebooted as I was told to, but mouse integration didn’t seem to work. Probably due to the kernel being upgraded without rebooting and actually utilizing it. So, I ran the additions script again, rebooted again and woo – mouse integration seems to work. The clipboard doesn’t though, and the maching is still creating some really nasty spikes on my CPU graph every three seconds or so:

It’s worth mentioning that when I’m running my Windows XP guest in VirtualBox, the CPU graphs on the host system are nice and flat.

I’m not entirely pleased, but I think VirtualBox will eventually win me over from VMWare.

Aside from being a website developer, I’m also a paranoid system administrator. One of the first thing I add to my login scripts, is umask 077 – the command that sets the permission mask for newly created files. Setting this to 077 prevents anyone but the current user from being granted any rights – read, write or execution. It’s a sane thing to do, but unfortunately a lot of scripts fail to explicitly grant access to other users, especially when installing RPM packages or – in this case – running VMWare after a kernel upgrade to build new VMWare-specific kernel modules.

In this specific case, VMWare kernel modules were built by the root user, and ended up in /lib/modules/2.6.27.19-170.2.35.fc10.x86_64/misc/ which was created by the build process. Read permissions were not explicitly granted to everyone, so when running vmware as a mortal user, it was unable to actually read and verify the newly built kernel modules. The natural response to the user wasn’t “Unable to read kernel module files”, but instead “You need to build kernel modules for your specific kernel”. Makes a lot of sense, eh?

Manually granting read and execution rights on the /misc directory and the files in it fixed the issue.

Make sure you remove/disable OpenJDK:

Get the latest Java SE Runtime Environment (JRE) here. Make sure it’s the 64-bit non-RPM version. The RPM might work too, I just didn’t test it. We’ll assume it’s version 1.6.0-12. Execute the following commands to unpack it:

Accept the license agreement. The directory jre1.6.0_12 is created. Execute the following commands to move JRE and make a symbolic link to the plugin:

The new thing here is that they recently renamed the plugin from libjavaplugin_oji.so to libnpjp2.so – that set me off track for a while.

Restart Firefox and type in about:plugins and look for Java – if it’s there, you’re all set.

The udev daemon creates and renames devices according to configuration files in /etc/udev/rules.d/ called rules. One of them – 70-persistent-net.rules – specifically handles network devices. This file was screwed up badly by Anaconda, and had dupes and network devices from a previous hardware configuration. I cleaned up this file, so it had only contained rules that matched the hardware addresses of the installed network devices:

Various external “plug-and-play” helpers may add newly found network devices to this file, so if your network devices start changing names, you might want to check /etc/udev/rules.d/70-persistent-net.rules.

Install both software groups:

Installing the LXDE group also gives you Openbox. LXDE and Xfce pretty much looks like the Gnome Desktop with application menus and icons on the desktop, whereas Openbox reminds me more of the good old days, where every application launch started with right-clicking on the desktop.

To try these desktop environments out, click your username on the login screen, pick the environment you want in the Session pull-down menu at the bottom of the screen, enter your password and you’re all set.

Note: Openbox’ Logout menu item didn’t work for me, but Exit did the trick. If you get stuck, you can simply kill the whole graphics subsystem (Xorg) with CTRL+ALT+BACKSPACE.

Enable access to both the free and the nonfree repositories at RPM Fusion and run an upgrade:

Make sure the system is crisp and updated with the new repositories:

Install GStreamer plugins with stability/license issues, including support for AAC, A52, SID, MPEG2, MP4, H.264, DVD navigation etc.:

Install various alternate video players:

Install various video encoders:

In time of writing, Adobe’s Flash plugin isn’t available as RPM – at least not the lastest beta version for x86_64 – so download it from Adobe Labs, unpack and drop libflashplayer.so in ~/.mozilla/plugins/. Make sure you’ve removed any trace of NSPluginWrapper first. Example (this is a single-user install, so don’t run as root):