Every so often, I get bored with the stability of my home PC and, in the absence of Microsoft to break it for me, decide to mix things up a bit by jumping to a newer Red Hat release. The multiple upgrade attempts! The disk corruption! Reconfiguring all the services! Clearing up all those *.rpmnew files! Ah yes, it keeps me entertained for days afterwards and ensures that I have no excuse for doing any real work. Plus, my Glamorous Research Assistant (GRA) is so desperate to get her email back that she lets me work uninterrupted on the computer for hours without complaint.

Following another update from 7.2 to 9, I’ve begun to suss the process. Here are my tips for this particular release: * Always boot the CD with “ide=nodma” to avoid the infamous IDE corruption bug, which hangs the install midway and shafts your root filesystem. I heard it was fixed a few times and subsequently discovered it wasn’t, so now I just swallow the overhead and save time spent otherwise running fsck. * Don’t bother customising the package install list. This is a guarantee that the upgrade process will fail midway and require another attempt, thus wasting all that time you spent selecting packages. Sort out the RPMs manually after the upgrade completes. (Don’t forget to add the GTK2 devel RPMs if you often compile additional apps.) * If you have a customised sendmail.cf, move it to /etc/mail/ (new location - a standard config is installed by default). Ideally, rebuild it from the current sendmail.mc template, otherwise you may get unresolvable “Permission denied” errors when it updates your hash maps (something to do with the RunAsUser stuff in recent versions). * Watch the links via /etc/alternatives/. I found several (connected to the mail system) that weren’t made; this may be a consequence of installing the alternatives RPM from 7.3 on 7.2 earlier, without the rest of the release. * Sigh. Once again, edit cupsd.conf and add the necessary ACLs & listen directives to enable remote access by clients on your network.

One other slight funny I noticed on a newly installed RHL9 system. GTK+ applications suffered corrupt font displays, with square blocks appearing between each character. A quick check by running the same apps remotely on a different X server (with the same symptoms) confirmed it wasn’t an X display problem. It turned out to be caused by the use of UTF-8 locales in /etc/sysconfig/l18n; removing the utf-8 extensions from the locale names fixed the problem. Presumably GTK+ and GNOME are compatible with the extended locales, but the GRA just wanted her audio player working and I don’t debug weird Unicode issues at home for fun.