Nov 082008
 

Well I decided it was time to upgrade my main workstation to Ubuntu 8.10 from 8.04. This was a somewhat nervous upgrade because the SATA disks are connected to a controller that gives me trouble when booting … the last few times I rebooted the machine I have had to re-assemble one of the mirrors at the “miniroot” (the shell you get from the initrd environment).

Given the trouble I wanted the option to revert back to the current install if everything went wrong … something I have described in the past.

Environment

I have four SATA disks in my main workstation that are mirrored and encapsulated into a single volume group with numerous logical volumes. So /dev/md0 is constructed of a mirror of /dev/sda2 and /dev/sdb2 and /dev/md1 is constructed of a mirror of /dev/sdc1 and /dev/sdd1. /dev/sda1 is used as /boot and /dev/sdb1 is “spare”.

The volume group datavg has two “physical disks” in it – /dev/md0 and /dev/md1. In that volume group are (amongst others) two logical volumes of interest – 804root and 804var.

Preparation

First I ensured that /dev/sdb1 contained an up to date copy of /boot :-

mkfs -t ext2 /dev/sdb1
mount /dev/sdb1 /mnt
star -copy /boot /mnt
umount /mnt

The next step was to create two new logical volumes to be used (eventually) for the new release of Ubuntu :-

lvcreate --size 12G -name 810root /dev/datavg
lvcreate --size 3G --name 810var /dev/datavg
mkfs -t xfs /dev/datavg/810root
mkfs -t xfs /dev/datavg/810var

The next step was to copy the filesystems across – at this point no further non-upgrade activity took place :-

mount /dev/datavg/810var /mnt
star -copy -xdev /var /mnt
mount /dev/datavg/810root /mnt
star -copy -xdev / /mnt
(edited /mnt/etc/fstab to change references to 804 to 810)
umount /mnt

At this point the remaining task (or so I thought) was to change the references in /boot/grub/menu.lst so that Grub would boot the kernel with 810root as the root filesystem.

I then rebooted to check the functionality and discovered that for some reason /var/run/network had not been created on the new /var but that seemed to be the only issue. I re-created this directory and rebooted to be sure (and Linux without a loopback device behaves very strangely!).

I then in theory had an environment I could revert to with a bit of fiddling with grub so was happy to attempt the upgrade.

The Upgrade Itself

I then started the upgrade (sudo update-manager -d) only to be told I did not have enough disk space with the suggestion that I run sudo apt-get clean to free up enough space. I tried this and the update started on the next time through. Why doesn’t the upgrade process automatically run apt-get clean ? In fact why doesn’t the upgrade process realise that it is on a system with LVM available (with plenty of free space) and create a new LVM especially for the upgrade files ?

Anyway the second attempt to run update-manager did start downloading files so I settled down for a well earned beer.

After the files had downloaded the actual upgrade process began. At some point the process stopped whilst a certain upgtade (libpam) asked whether it should restart certain services (including gdm which is the graphical login). Unfortunately it did not explain clearly what it was doing, why, or even if restarting gdm would terminate the current X session. Perhaps it is something that would only “worry” someone with a dangerous amount of knowledge, but perhaps the prompt could be improved slightly.

As a later example of how it should be done, the dialog warning about changing the ssl certificate was ideal … basically saying “if this doesn’t mean much to you, don’t worry about it”.

The use of dialogs during the upgrade does raise a couple of issues though :-

  1. Apparently not “stopping the clock” whilst waiting for the user to respond to dialogs caused the estimate of how long the upgrade would take place to increase dramatically. Just after dealing with that libpam prompt I was slightly alarmed by the estimate of 6 further hours to complete (as it was already 21:30) only to be reassured by the rapid drop to 2 hours.
  2. From a users perspective it would be preferable to ask all questions at the beginning or at the end of a long process. Keeping an eye on the upgrade whilst it was churning through the bulk of the upgrade (which took place without user intervention) was somewhat tedious.

The unfortunate thing was that at this point, the upgrade process ran out of space. It also left my machine in an unbootable state … from what little investigation I made it would appear that the initrd file was not created. Perhaps because of the lack of space, but others have also encountered this problem.

Obviously the Ubuntu upgrade process should be a little more careful about estimating the amount of space available. It would also be nice if it would notice that it was installed on an LVMed system with free space available … it could create a new LVM of an appropriate size and use that.

Recovery

Fortunately my preparation left me with a root filesystem that I could revert to by selecting one of the older kernels in the grub menu, editing the command used to boot, and by replacing the root filesystem with “804root”. This resulted in a system almost identical to that before the upgrade process.

I re-tried the “Preparation” stage, ensuring that /var was a little bigger and restarted the upgrade process …

Upgrading (The Second Attempt)

The second upgrade went through pretty much the same process as the first … except that it did not run out of disk space. This let it complete apparently normally with a warning about removing several hundred packages (!).

Finally it suggested rebooting to finish the upgrade.

The First Boot

The first boot was a triffle problematic … firstly I still had to manually assemble /dev/md0 and the process that built /boot/grub/menu.lst hadn’t noticed that an invalid root filesystem was specified. Whilst the later was my fault, it would be nice if it had realised that it was invalid and had warned me. The former is a long standing problem and is not the result of the upgrade.

Apart from that, the standard user interface looked ok, but it had messed around with the Enlightenment window manager. I had to re-install the package, my settings and menus had disappeared. Whilst I am an “unusual” user in not using the standard user interface, this was not something I was happy with!