therning.org/ magnus

Recently VMWare announced the release of a free (as in beer) “player”. (No link since it’s so easy to find using Google.) I thought this might be a way to finally install Linux on my most powerful machine. If I could use VMWare to run the VirtualPC images I use for work then I can throw out Windows altogether. Well, it was worth a shot anyway.

Major disappointment though! It turns out VMWare Player can’t handle VirtualPC images unless you run VMWare on Windows. It doesn’t even seem to be possible to use a VMWare on a Windows machine to convert the VirtualPC images to VMWare images. So, VMWare Player is useless to me, and I’ll be stuck running Windows a bit longer on my other machine…

I’ve moved the development data and my APT repo to a mate’s computer. The main reason is that I still am computerless and this way I’ll have better access to it all, especially from work. The downside is that my mate isn’t taking his server’s certificate as serious as he should and given that https is the only protocol allowed through his firewall it is a bit disconcerting. I’m still trying to educate him I’ll see him again at Christmas so if nothing has happened by then I’ll be bringing the gas torch.

I wrote a post on using udev together with Gnome Volume Manager (GVM). My recent upgrade to Ubuntu Breezy revealed that my hack was just that, a hack, and a bad hack at that. It doesn’t work in Breezy!

It turns out there’s a right way of doing this—use HAL! As so often I could have saved some time by simply reading the comments in the configuration files in /etc. (BTW, this is exactly the reason why I love Debian/Ubuntu. The configuration files are their own documentation. Brilliant, simply brilliant.) Anyway, playing around a little with HAL’s fdi files wasn’t a bad thing I guess. In the end I retired my udev setup from my earlier post and put the following lines in /etc/hal/fdi/policy/local.fdi:

<device>
  <match key="volume.uuid" string="60CA-2822">
    <merge key="storage.automount_enabled_hint"
      type="bool">false</merge>
  </match>
</device>

This hint is honoured by GVM and the device isn’t mounted.

RedHat published quite a useful introduction to hal. The hal specification is also a good place to find information.

I’ve been walking around for a while wondering if I should dare upgrade my machine to Breezy. Given that my home machine still isn’t back (and it might never be actually) I didn’t have any place to check if upgrading Hoary to Breezy really worked—if I were to do it, it’d have to be on my work machine. I really didn’t want my work machine to be out of commission, running Linux in a Windowsshop has made me feel like I need to show just how stable Linux is, having to spend a day to re-install Hoary just because an upgrade to Breezy failed wasn’t really an option. Today I took the plunge, and it worked just fine!

I started with downloading all the needed packages:

$ sudo apt-get dist-upgrade -d

Quite some time later I had a /var partition that was 93% full. I dropped out to a console and changed to single-user mode. I got myself a root shell with

$ sudo su -

And then started the upgrade. I did get two failures and dpkg bailed out but a simple apt-get -f install repaired it all and I could continue the upgrade. All in all I issued the following command:

# apt-get dist-upgrade
# apt-get -f install
# apt-get dist-upgrade
# apt-get -f install
# apt-get dist-upgrade

After the last dist-upgrade there was still one package that wasn’t upgraded, rhythmbox. Installing it explicitly took care of its dependencies:

# apt-get install rhythmbox

After some clean-up in /etc I was ready to reboot. Not a single problem

A small problem at work, with a silly little solution. This really should be filed under silly-but-I-have-such-a-bad-memory. For some strange reason I can’t always get the Linux system in Virtual PC to use NTP properly. However, it seems my regular Linux machine doesn’t suffer from the problem. I could set up an NTP server, but I’m a bit lazy… it’s also not that important to have exact time.

My current solution looks like this:

$ ssh root@virtual.pc "date -s \"$(date)\""