This weekend was the day to upgrade my internal mail server from Feisty to Hardy. I've already done this on several servers and didn't expect any major problems.
Step 1: Upgrade Feisty with all latest packages:
apt-get update;apt-get dist-upgrade
Followed by a reboot. Went perfectly!
Step 2: Upgrade Fesity to Gutsy. If you're more than one version behind, you really have to take it in stages. Replace all occurrences in /etc/apt/sources.list of "feisty" with "gutsy", then:
apt-get update;apt-get dist-upgrade
followed by a reboot. Went mostly perfectly - it overwrote the newer version of eGroupware I'd installed with something that wouldn't run, so I restored my version of eGroupware and made sure everything worked.
Step 3: Upgrade Gutsy to Hardy LTS. Replace all occurrences in /etc/apt/sources.list of "gutsy" with "hardy" then:
apt-get update;apt-get dist-upgrade
Then things went downhill. During installation, I ran into the locales bug. The system froze on the upgrade completely. The fix? You need physical access to the machine so thankfully this wasn't one of my colocated servers.
First, do a hard reboot of the box, because CTRL-C isn't going to unhang it any time soon. During boot, at Grub select the previous kernel version from the boot menu. After it boots, log in as root (I hope you have a root password set!) then continue the upgrade process using:
dpkg --configure -a
After it completed, I rebooted and found that it had yet again replaced my eGroupware install (no surprise) so I restored that yet still couldn't authenticate. Trying to restart saslauthd reported:
* Short name (NAME) undefined in /etc/default/saslauthd, using default
* No run directory defined for default, cannot stop
* Starting default
* No run directory defined for default, not starting
Turns out, the configuration file format for saslauthd (which my Cyrus server uses) had changed. I renamed my old configuration, and replaced it with the one that came with the upgrade (as root or use sudo):
mv /etc/default/saslauthd /etc/default/saslauthd-old
cp /etc/default/saslauthd.dpkg-dist /etc/default/saslauthd
After that, everything seems to be working fine.
You'd think that with a bug report being filed in March that this would have been addressed by now by Canonical.