Saturday, July 12, 2008

Thinking Outside the (Virtual) Box (1)

I managed to drop a heavy book on my wife's laptop, and now its Z key is busted. I hooked a spare USB keyboard to the laptop, so that my wife can continue using it. But now it's more "desktop" than "laptop".

With its DVD drive already busted, it seemed prudent that we should send the laptop to be fixed, as long as it's still covered by warranty. The only problem with this plan is that my wife needs the laptop for work, and the turn-around can as long as 7 work days (excluding UPS shipping to and from the lab).

We considered our options:
  1. copy the documents she's currently working on to a USB flash drive, and continue working on a computer at her malware infested workplace,
  2. move her stuff to my Debian box, and work there.

The only problem with the latter option is MS Office - how do I get that to run on my box? Please don't talk to me about this piece of crapware simply doesn't cut it even when it comes to mildly complex documents that were generated with the rival moneyware crapware. The compatibility issues become painfully apparent with bi-directional text (specifically Hebrew and English). And all of my wife's colleagues use MS Office, so there's no real choice here.

Wine. I tried installing MS Word 2003 under Wine. The installer wizard is localized, so all the messages appear in Hebrew, but aligned to the left instead of to the right. I ignored that and just pressed the Next button until the installation was completed. I then launched MS Word with Wine. I got an error dialog box saying that there was an installation problem. I promptly dismissed it, and MS Word came up, and seemed be functioning. Except for one little issue: Hebrew text is reversed! How useless.

I spent some time searching the 'Net for relevant tips. It turns out that Wine does not support BiDi text rendering. It used to have BiDi support, but it was dropped due to various technical reasons. There are several open bugs about BiDi support in the Wine bug tracking system, but there's no real effort to fix them. The BiDi support maintainer does not have time to do the necessary work. Actually, it seems that he's looking for someone to sponsor (read: pay) him. And nobody seems to care. Bottom line: it's a No-Go.

Virtual PC. I didn't consider setting up a virtual PC, because I assumed it would be nearly impossible to interact with an emulated Window$ machine running on top of my already slow Debian box. But I had nothing to lose (except my time...), so I tried installing VirtualBox OSE.

It wasn't easy: together with VirtualBox, aptitude decided to auto-install a 486 Linux kernel image, presumably because VirtualBox requires a kernel module to be installed on the host machine, and the default flavor is probably 486. I dunno. I removed that module and the 486 kernel image and selected to install the 686 specific module.

Time to launch it:

$ virtualbox
WARNING: You are not a member of the vboxusers group. Please add yourself
to this group before starting VirtualBox.

You will not be able to start VMs until this problem is fixed.

Why isn't this done automatically? nevermind:

$ adduser zungbang vboxusers

Ahh, I have to login again... OK, done...

$ virtualbox
WARNING: The character device /dev/vboxdrv does not exist.
Please install the virtualbox-ose-modules package for your kernel and
load the module named vboxdrv into your system.

You will not be able to start VMs until this problem is fixed.

WTF? didn't I spend a few minutes doing just that?

$ su -
# modprobe vboxdrv
$ virtualbox

Nirvana. Time to setup a virtual PC. It's rather easy actually. VirtualBox is nice in that way.

But when I started the virtual PC VirtualBox told me that the kernel module version does not match its own. WTF? Didn't I ... ahh, I get the drift - time to visit the Debian BTS. Not surprisingly, it's a known issue, and the solution is to install the source code for the host module, compile and install it:

rmmod vboxdrv
aptitude purge virtualbox-ose-modules-2.6.24-1-686
aptitude install virtualbox-ose-source
module-assistant prepare virtualbox-ose
module-assistant auto-install virtualbox-ose
modprobe vboxdrv
echo vboxdrv >> /etc/modules

Finally, I used forbid-version (F) in aptitude to prevent the module package from being "upgraded" from version 1.6.2 (source code module version) to 1.5.6 (the version of the binary package).

This time around the virtual PC came up just fine, booting from my Windows XP Professional installation CD. Installation took about an hour to complete, and was uneventful. The virtual PC crashed during the final reboot, but it booted fine after a manual restart.

At this point I was pleasantly surprised: VirtualBox is damn fast. I have no idea how it's done. Maybe it's just my sleepless brain that's playing tricks on me. But even before I installed the Guest Additions, WinXP seemed to run at least as fast on this virtual PC, as it ran on the host PC when it was natively installed.


To be continued.

[15 Dec. 2008] UPDATE: As you may have noticed, I added the vboxdrv kernel module to /etc/modules, in order to load it when my computer starts up. A recent post on the debian-user mailing list pointed me to a better way of doing this: open (as root) /etc/default/virtualbox-ose for editing, and edit it so that it contains the following line:

No comments:

Post a Comment