Another Year, Another Linux Upgrade
As I mentioned last year, I annually upgrade my home Linux machine to the latest version of Fedora around the first of the year. The real motivation is to stay on a release that is receiving updates (particularly security fixes) and to pick up a few new features here and there. This year the upgrade was from Fedora 12 to Fedora 14. Since I benefited from many others’ blog posts and other material online, I want to return the favor and describe my experiences, in the hopes that someone else may run into some of the same issues.
Preparing for the upgrade
The end of the year is also a good time for a backup snapshot of my system, which I stored on my network-attached storage device. I also made backups of both the MySQL and PostgreSQL databases just to make sure that there wouldn’t be database problems as a result of the upgrade (as happened with PostgreSQL last year). I also read, or at least skimmed, the release notes for both Fedora 13 and 14 to know what to expect.
The upgrade process itself
Downloading the upgrade was, as usual, very smooth. I downloaded the complete DVD .iso file using BitTorrent, which I keep running from time to time to provide the image to others. I made a DVD+R of the image, and also loaded it onto a share on my network-attached storage device in case I had problems booting the image as I did last year.
Since I was prepared, of course the image booted smoothly. Running off the upgrade DVD, I was able to tell it to upgrade my system from Fedora 12. The upgrade reported that there were several hundred “packages” (software components) that would be upgraded. I left and did some other chores while the upgrade happened.
Some time later, I returned to find that the upgrade had failed about halfway through. Nice touch, Fedora people, to have a blue background when that happened. I tried rebooting the target system, which seemed not to work. So I retested the upgrade DVD, and started the upgrade anew. It seemed to pick up where it left off. Woot!
When the upgrade had completed, I booted the system normally and it seemed to almost come up. Recalling last year’s challenged with my Nvidia graphics board, I hit <ctrl><alt>F2 to get to a non-graphics TTY, and the system was indeed up.
Here is where I did my first consultation with the Internet. After trying to patch things together with the custom Nvidia driver as I did with Fedora 12, I read that my graphics board is now supported with the open-source ‘nouveau’ driver that I had disabled last year. So I reenabled the nouveau driver, but still no X11 graphics.
More searching for relevant hints revealed that the display configuration file, /etc/X11/xorg.conf, might be incorrect. This made sense because it was referencing the proprietary Nvidia driver. Using the instructions found here, I created and installed a new xorg.conf.
One of the first things I needed was to be able to receive mail. Dovecot was running, but I use SSL for the IMAP connections from my mail clients, and I got an error indicating that the certificate being presented was incorrect. To make a long story short, it turned out that the Dovecot configuration files had been extensively reorganized between Fedora 12 and 14. The files were broken up into a directory (/etc/dovecot/conf.d) of configuration files. Fortunately the monolithic configuration file I had been using had been saved as dovecot.conf.rpmnew, so I was able to edit my changes into the new-format config files. Presumably this was in the release notes somewhere, but I hadn’t seen it.
One other thing that’s slightly odd is that now the daily Logwatch process is reporting all of my disconnects from Dovecot. No big deal, but these messages are routine and probably don’t need to be reported.
One thing I found very quickly was that I was getting a tremendous number of error messages whenever doing anything with the yum package update manager. One thing that seemed particularly curious was that it seemed to want to install Fedora 12 versions of things, and wasn’t upgrading any of the installed packages. When I used yum to list a package, it would show both the Fedora 12 and Fedora versions of the package as installed. Apparently something bad had happened when the upgrade bombed out. I went to bed thinking that it was probably time to install from scratch because piling annual upgrade on top of annual upgrade had finally caught up with me. But this would be a lot of work.
I woke up about 3 am and couldn’t sleep, so I got up and decided to give it one last try. Apologies for not taking good notes (it was 3 am!) but I looked at yum to try to figure out why it thought I was still on Fedora 12. Some posts suggested that I hardcode the release version in /etc/yum.conf, but I found that it uses a particular package, fedora-release, to set $releasever, and there were two copies of fedora-release (one for Fedora 12 and one for Fedora 14) installed. I got rid of the Fedora 12 fedora-release, and yum started acting like I was really on Fedora 14.
There were still hundreds of packages that showed up as “double installed” (both the Fedora 12 and 14 versions installed, resulting in an error). While I could perhaps have deleted the Fedora 12 packages, I decided to be conservative and ‘yum reinstall’ the packages instead. This removed the Fedora 12 version and made sure that the Fedora 14 version was correct. This had to be done in just a certain order to make sure that the filed that had dependencies were reinstalled before the things that they depended on. This was a very time-consuming process, and took several hours to complete. While the great majority of these were simple duplicateions, there were a few cases where conflicts were created by packages that had been renamed, and a couple of old packages (from Fedora 8 ) that just needed to be deleted.
Python was upgraded to version 2.6, which meant that a couple of non-standard libraries needed to be copied over into /usr/lib/python2.6/site-packages. No big deal.
With the upgrade to Firefox 3.6, the Java plugin no longer seemed to work. I downloaded the latest Java from
Sun Oracle and tried setting up the symbolic links to point to the JVM plugin that I had installed. I wasn’t entirely sure where this link went (/usr/lib/mozilla? /usr/lib/firefox-3.6?) so I tried a number of things and no luck. Fortunately I have this great resource called the Internet to help.
I found this article (thanks, Rob Holland, whoever you are) that describes how to use the ‘alternatives’ system to configure the choice of Java and plugin to use. This is the first time I remember encountering or using alternatives. In any case, the instructions worked perfectly (with the appropriate change in Java version number) and everything started working. Hello, weather radar animations!
Overall, with the exception of the unexpected crash during the upgrade process and the resulting package confusion, everything went as well as can be expected. Having upgraded all the way from Fedora Core 2 to Fedora 14, I keep wondering how long I can keep this streak alive before I need to start with a fresh Fedora installation. But this wasn’t the year. Whew.