Thursday, July 31, 2008

Thinking Outside the (Virtual) Box (2)

Previously I described how I installed WinXP Pro on a VirtualBox virtual PC, as a last ditch attempt to get MS Office running on my box. It turned out that VirtualBox is amazingly fast, even on my old laptop, so I decided to go ahead and install MS Office. But first there were several lesser chores to complete: Window$ Update and installing a printer.

Windows Update was easy enough - but tedious: my installation media is from 2002 (SP1). Several hundred megabytes and a few virtual reboots later, and the upgrade process was complete. Installing the printer, however, was less of a picnic.

Our HP Officejet 5510 all-in-one is connected via USB to my laptop, driven by HPLIP and managed by CUPS. My plan was to setup an IPP printer on the virtual Windows machine, similar to the setup on my wife's real laptop.

HP ships an installation CD with its printers with shit-load of useless software, which takes forever to install. It was only after installing and using HPLIP that I realized how shitty it really is on Windows. What's really strange about this is that HP provides the software for both Windows and Linux. Go figure.

Anyhow, my point is that the CD isn't required: HP provides a "corporate" version of the printing drivers, a lean 34MB (!?) package, that you can download from their website, in case you need to install the printer in a "corporate environment" (read: when the printer is not directly connected to your computer).

I did not anticipate any problem here:
  1. download the corporate driver package (it's a self extracting archive),
  2. launch it, (it should happily extract itself to C:\temp)
  3. find the freshly extracted setup.exe and launch it,
  4. connect a printer directly to the USB port, and let plug-n-play do its stuff.

This very same procedure worked nicely on my wife's laptop. But not on the virtual PC. That setup.exe just died several seconds after starting - no error message, no BSOD, it just dies.WTF?

What do you do when you have no decent logging, no source code and no strace to help you start figuring out what's wrong? easy: you guess. Oh, and you're very likely to guess wrong and end up doing some damage before hitting the right solution, if at all.

Guess #1: a corrupted download. It took a while to verify - my link to the HP website was damn slow at the time - but both md5sum and sha1sum insisted that I got all the bits and in the right order.

Guess #2: just before it died, the installer seemed to setup a recovery point. Maybe that's the problem? I disabled the system restore feature (and, in the process, lost any previously created recovery point) and tried again. Same result.

Guess #3: it suddenly dawned on me - the installer dies because it can't find any USB controller. The Open-Source Edition of VirtualBox does not support USB. This seemed like a plausible explanation, yet I had no supporting evidence. I also had my doubts: this was the corporate driver package, which should support a network-printer configuration.

And if this theory was right, what do I do now? it looked hopeless. But I had an idea: maybe there's a software only virtual USB controller out there, that can be used to fool the installer into thinking that there's USB on my virtual PC?

As improbable as this may seem, such a beast does exist - it's called the Device Simulation Framework - and is written by none other than Microsoft itself. It's also freely distributed as part of the WDK - the Windows Driver Kit. Getting the WDK ISO image is a bit of a chore, but it can be done. Eventually.

Once downloaded, you only need to mount the ISO image into a virtual optical drive, and follow the DSF installation instructions:
  1. double click dsfx86runtime.msi in the \dsf directory,
  2. create a virtual USB controller:
    • open a Command Prompt window,
    • navigate to the \Program Files\dsf\softehci folder,
    • run softehcicfg /install


This time around the installer did not die. I guessed right. Whew.

My next problem was to convince the plug-n-play machinery that the printer drivers should actually be installed, so that I could specify it as the IPP printer's driver. With my wife's PC it was easy: I simply hooked up the printer directly to one of its USB ports, and a new printer icon was automagicly installed. But, as we already know, VirtualBox OSE does not have USB...

I tried double clicking some of the .inf files that were installed, I tried running some of the setup executables that were also installed. I shouldn't have done that - but it was late at night, and I wasn't thinking straight. Luckily nothing happened. Which was also unfortunate.

It took another guess to get this done: I shared the USB printer on my wife's laptop (which isn't really connected to anything - I kept it installed just in case), and added a printer on the virtual PC that points to this shared printer. The drivers were then automatically installed, and I could then create yet another printer to point to the real printer via its CUPS URL.

For some reason I can't print a test page from the printer's property pages, but otherwise printing works just fine.

The rest of the story is rather boring: I installed MS Office, and then ran Microsoft Update several times, until no updates were left to install.

Finally, I installed the VirtualBox Guest Additions. The Guest Additions provide shared folders, auto screen resize, auto input focus for keyboard and mouse, and the cool-yet-useless seamless mode.

Next time: running a live-HDD under VirtualBox.

Thursday, July 24, 2008

Tracing a Daemon

I've recently needed to run a daemon under strace, in an attempt to figure out what was making it fail.

Tracing a running process is simple enough - just attach strace to it:
strace -p <pid>
(replace <pid> with the process id). But in this case I wanted to start the daemon under strace, which is a bit tricky.

A daemon is typically (always?) started from an init script located in /etc/init.d/ via a program called start-stop-daemon, e.g.
start-stop-daemon --start --exec $DAEMON -- $ARGS

where $DAEMON is the executable being launched and $ARGS are its command line arguments (optional).

The idea is to replace that line in the init script with something else that launches an strace-d daemon, that can later be stopped with start-stop-daemon. I've tried various combinations of start-stop-daemon, strace and $DAEMON, before I hit the following incantation:
start-stop-daemon --oknodo --start --exec $DAEMON --background --startas /usr/bin/strace -- -f -o /tmp/$NAME.strace $DAEMON $ARGS

This will trace the executable and any of its forked child processes (-f) to a file named /tmp/$NAME.strace.

Note that a daemon may be started in several places in the init script ("start" and "restart").

Monday, July 14, 2008

Are We Running on AC Power ???

I once mentioned that I use the script on_ac_power from the powermgmt_base package to determine whether my laptop is running on AC power.

Well, following a kernel upgrade to version 2.6.25, that script stopped working (see bug #473629). Here's a (debian-specific-works-on-my-machine) replacement script, based on the output of acpi:


#! /bin/bash
# this is a drop-in replacement for /usr/bin/on_ac_power
check_ac_power()
{
local ret=255
if [ -x /usr/bin/acpi ]; then
status=$(/usr/bin/acpi -aB | cut -d' ' -f 6)
case "$status" in
on-line)
ret=0
;;
off-line)
ret=1
;;
*)
;;
esac
fi
return $ret
}

check_ac_power

Note that I'm assuming that the system has a single AC power supply.

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?

OpenOffice.org. Please don't talk to me about OpenOffice.org: 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
^D
$ 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.

Amazing.

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:
LOAD_VBOXDRV_MODULE=1

Friday, July 11, 2008

ZoneAlarm Hotfix

A recent Windows Update has killed Internet access from my wife's laptop. The connection was restored as soon as I disabled the ZoneAlarm Firewall.

A hotfix for this issue is already available.

Thursday, July 10, 2008

Mount may Fail for UUID Entries in /etc/fstab

I was just hit by a nasty bug (#487758, #487783), in blkid that may cause mount to fail, for UUID style entries in /etc/fstab, e.g.

UUID=de018d5f-4dbc-4ed6-9724-4d5c793658aa /boot ext3 defaults 0 2

Yes! this is the boot partition on my live-HDD, which must be specified in UUID style, because the device path (/dev/sd*) is dynamically determined, depending on the current system configuration and boot sequence.

The workaround, until the fixed version of e2fsprogs trickles down to Testing is to specify UUID style entries like this:

/dev/disk/by-uuid/de018d5f-4dbc-4ed6-9724-4d5c793658aa /boot ext3 defaults 0 2

Thursday, July 3, 2008

One Liner: Disable/Enable GNOME Screensaver

Here's how to disable the GNOME screensaver from the console (or script):

gconftool-2 --set -t boolean /apps/gnome-screensaver/idle_activation_enabled false

Replace false with true in order to enable it again.