therning.org/ magnus

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

I’ve been keeping the entries for Ubuntu backports in my sources.list for a long time now. They always been commented out though, since I don’t really trust them enough to keep my system up to date with backports. It wasn’t very elegant though so I decided to see if pinning could do the trick. After an email to the Ubuntu user list my /etc/apt/preferences now look like this:

Explanation: Make sure backports is not installed be default
Package: *
Pin: origin ubuntu-backports.mirrormax.net
Pin-Priority: 499

This means that I can keep the backports’ entries in sources.list enabled without being bothered with updating the entire system when doing an apt-get upgrade.

There’s only a minor detail—update-notifier thinks that there are updates available, but once I click it no upgrades are found. I guess there are two pieces of code that checks for upgrades, one doesn’t handle pinning and one does.

[Edited] It seems my whinging about update-notifier's inability to handle pinning was a little premature. It seemed it just needed some time to adapt. Now it’s correctly respecting my whishes not to upgrade any packages available in backports.

I know there’s a UbuntuWiki page for building a java package. However it’s difficult to read and it’s outdated.

The process is:

1. Download the binary installer from (Sun)[http://java.sun.com/].
2. Make sure fakeroot, java-package and java-common is installed.

3. Execute

   fakeroot make-jpkg –full-name “My Name” –email “My@e.mail”

It will work for both the JDK and the JRE.

I’ve received the Ubuntu Hoary CDs

The first one is already passed out—to my brother.

I installed the Ubuntu build of 2.6.11 yesterday and noticed that my touchpad didn’t work properly. It felt sluggish and tapping it didn’t work at all. A bit of googling turned up this and this.

I didn’t bother with the Synaptics driver for X.org, mostly since I wasn’t sure the suggested kernel patches are in the Ubuntu kernel. Also, I can live with 2.6.10 until Breezy Badger… with the focus on laptops I’ve seen on the Ubuntu dev-list I can’t imagine they’d let such an obvious thing as a non-functioning touchpad slip through.

In this post I described my udev setup. The one drawback with using udev that way is that I need to cll pmount manually everytime. Yesterday I stumbled across some posts on the the Ubuntu mailing list and I’ve started liking Gnome’s Volume Manager a little better since.

Using e2label I set the label on my ext2 partition. This causes pmount to mount the partition using that name.

Then of course I didn’t want the device itself (/dev/sda in most cases) to be mounted. As an experiment I modified my udev rule to only apply to the device:

BUS="usb", SYSFS{serial}="070B000514B09F0", KERNEL="sd?", NAME="%k", \
  SYMLINK="usbstick_priv"

As expected having udev add the link somehow prevents pmount from mounting the device.

Now all that is left is to set the label of the VFAT partition on my USB stick.

I just discovered FreeNX today

I’ve been using VNC for a while at work now, and mostly I’ve been happy with it. Being on a fast internal network with the server literally at my feet hasn’t made me swear at the lack of speed. The only thing that has irritated me a little is that my VNC sessions aren’t properly secured. I don’t have anything to hide really, but working with security it just didn’t feel right. Sure, I could, and I did for a while, secure it using SSH, but since the client is a Windows machine it makes it all a bit clunky. Requiring a PuTTY instance with port forwarding to be running is plain ugly. An encrypted connection really should be built into VNC by now. So, I decided to take FreeNX for a ride.

Unfortunately FreeNX isn’t in Ubuntu Hoary, however there is a page in the Ubuntu Forum, which is a bit outdated–it covers Warty mostly. Some of the comments in the forum did point me to the Backports project. I don’t really like the Backports (I managed to screw my system up a bit a while ago) but they do seem to have grown up a bit by now. Anyway, I only added the repos to my sources.list long enough to install the packages I needed.

Installation was a breeze. I chose to use custom keys, sorting out the client-side problems created by that turned out to be simple as well. No extra tinkering with the config files seemed necessary.

For the Windows client I am using NoMachine‘s Windows client. In order to use it with my server I needed to copy the public key (on the server: /var/lib/nxserver/home/.ssh/client.id_dsa.key) to the share dir on the client side (you’ll find it’s a subdir to the install dir of the client software). That’s it, password-less remoting of my Linux desktop with the security of SSH. Brilliant.