I just upgraded my Ubuntu box from 7.04 (Feisty Fawn) to 7.10 (Gutsy Gibbon), and after 3 upgrades (I started out with Dapper Drake) I remain impressed with how easy and painless it is. This time there was a hiccup, though. But, it’s not something that I’d expect an average user to encounter.

First, a bit of background. My desktop machine gets a lot of its files via NFS from a remote server. The server runs a base of Debian Etch with a bunch of stuff from the testing/unstable trees. The two computers are both on the same LAN, and the server currently runs kernel v. 2.6.20.1. Ubuntu 7.10 currently uses 2.6.22.

After completing the upgrade, I rebooted my machine into Ubuntu 7.10 for the first time, and logged on. It took about 5 minutes for all my menus and apps to come up (some of the apps came up before I had any menus, making me wonder if the upgrade had botched something.. but everything did finally appear). I quickly figured out the cause of the problem: all of my NFS mounts were timing out.

I did a few more tests, and I found out that I had no problem mounting and unmounting NFS directories from the server. But when I tried to run ‘ls’, my terminal just froze and I got ‘NFS server blah.blah not responding’ in the kernel log. No amount of rebooting, re-exporting filesystems, etc. seemed to help. I wondered if it was some sort of subtle incompatibility between the two different kernel versions, although I’d never had this kind of issue with NFS before in my almost 20 years of dealing with it. (Wow, has it really been that long?)

I’m aware that there are two versions of NFS nowadays, the older version 3 and the newer version 4. The 2.6 kernel supports both versions, but I’ve always run version 3 because it has always worked for me, and I’ve never seen a need to change. Plus, when I go to configure my kernel, all of the NFS v4 stuff is labeled as EXPERIMENTAL, which makes me shy away from it. This time, though, rather than futzing around trying to get my old NFS v3 setup to work again, I decided to try v4. I built it into the server’s kernel and rebooted the server. I then followed the very helpful Ubuntu NFSv4 Howto, which explained the differences between v3 and v4 and walked me through the setup.  It worked, and it doesn’t hang any more.

It’s a little troubling not knowing why the upgrade broke my NFS v3 setup.  Searching around on Google wasn’t too helpful.  I suspect it’s some kind of issue with the 2.6.22 kernel, but I did not want to spend a lot of time troubleshooting it..  I just need my computer to work.  So I’m glad NFS v4 fixed it for me, otherwise I’d probably have to downgrade back to Feisty.

NFS issue aside, the Gutsy upgrade was very smooth, and I continue to be happy with Ubuntu.

I just finished upgrading the hard drive on my Ubuntu machine, and it wasn’t as easy or straightforward as I was expecting.  So I figured I’d write up some notes for the next time I do it.

First I backed everything up. Then I shut down the computer, put the new drive in, and booted up with a copy of Knoppix I had lying around. Under Knoppix, I opened up a shell and mounted my old root filesystem:

# mount /dev/hda1 /mnt

I then mounted the new root filesystem on /mnt2, and copied all the files over:

# mount /dev/hdb1 /mnt2
# cd /mnt
# tar cvpf - . | (cd /mnt2; tar xpf -)

Then, I installed the grub boot loader in the MBR of the new drive:

# grub
# root (hd1,0)
# setup (hd1)

At that point, I shut down the computer, removed the old drive, installed the new one in its place, and attempted to boot back up. Happily, it found the grub boot loader and proceeded to load the kernel. But then it hung trying to mount the root filesystem.

It turns out that a couple releases ago, Ubuntu started referring to disk partitions by UUID rather than using a specific device name such as /dev/sda1 or /dev/hda1. Both /boot/grub/menu.lst and /etc/fstab still contained UUID references for the old hard drive, so I had to go through and painstakingly replace all the old UUID references with the updated UUID for the new disk. I just used vi and did a search-and-replace, although there’s probably an easier way. Once I did this, everything booted up just fine.

I can see the advantages to using UUIDs, but it does add an extra layer of complexity when doing something like this. At least I know what to expect the next time around.

Coming soon: my adventures upgrading from Ubuntu 7.04 (Feisty Fawn) to 7.10 (Gutsy Gibbon).  There were a couple of snags, but it was mostly painless.