Fedora 16 Upgrade Experiences

As in past years, the end of the year is the time for me to upgrade my home Linux server to a new version of Fedora (Fedora 16 this year). And as in past years, this process didn’t go  smoothly, and to deal with that I lean heavily on search engines that lead me (frequently) to the blogs of others who have dealt with and fixed the same problems. As I did last year and the year before, I’m writing this article to contribute back my experiences in hopes that I may help someone else who runs into the problems I do.

As background, Fedora Linux versions are issued every six months or so, and no longer receive patches after version+2 is released. So I have been upgrading my system every two versions (every year) for the past several years. Particularly with respect to security vulnerabilities, it’s important to keep up to date with the latest patches.

So here’s a summary of my experience:

Distribution media boot problems

As I have done before, I downloaded the distribution DVD image via BitTorrent and burned a DVD+R. Last year the DVD booted smoothly, but this year it did not.  I tried several things to rule out DVD drive problems:  I booted last year’s Fedora 14 disk, and that worked fine, and I burned a Fedora 16 install disk using the drive on my MacBook Pro, and it failed to boot exactly the same as the one I burned directly on my Linux machine. My machine is somewhat older than my DVD drive, so it may not be a fully supported configuration, but that doesn’t explain why last year’s image booted OK. I unpacked the installation disk onto a partition on my network-attached storage, intending to use that for installation as I did two years ago.

So I downloaded and burned a network-install CD, which booted beautifully.  However, I got ahead of myself somehow and ended up doing the upgrade directly from the Internet.  It was perhaps a bit slower, but the upgrade went smoothly.

Graphics

As in the past, when the system did come up, the X Window System did not.  As suspected, this was due to my graphics card (NVIDIA GeForce 6200) not being configured properly on Fedora 16.  Some sort of a configuration problem has happened on each of the last two upgrades, so I was somewhat expecting this.  This time, I disabled the default nouveau driver and downloaded and enabled the NVIDIA proprietary driver.  Again no luck until I eventually recognized that the X11 configuration file, /etc/X11/xorg.conf, had the wrong name for the driver: “nv” instead of “nvidia”.  After also making sure that the ModulePath included the NVIDIA modules (/usr/lib/xorg/modules/extensions/nvidia), the display came up.

However, after logging in, Gnome 3 announced that my graphics driver wasn’t supported and it was operating in fallback mode.  I’m still not sure what I’m missing by being in fallback mode, but from reading some of the commentary on the Internet about Gnome 3, many people are happier with the fallback mode than the “real thing”. So I just forced fallback mode in System Info -> System Settings -> Displays, and I don’t get the annoying message any more.  Some day I may try to get out of fallback mode, but it’s not a priority right now, because of problems with…

Networking

With the exception of the Mac, my experience with user graphical environments has generally been that they operate at a “higher layer” than the network stuff underneath. They generally accept whatever they’re given by the network, and with the exception of some graphical tools to make configuration easier, don’t mess with the network configuration much.

That has apparently all changed with Gnome 3. Perhaps in an effort to act “Mac-like”, Gnome 3 attempts to reconfigure the network interfaces and creates new logical interfaces. Because my interfaces were set as “unmanaged”, Gnome (specifically the NetworkManager application) didn’t actually do this, but I had trouble getting applications like Firefox and Thunderbird to connect to the network. I reconfigured them to Managed, and suddenly I lost the static IP configuration I had. I had to manually reconfigure them to get back to “normal”.

However, I noticed that I was getting a LOT of syslog messages.  Every minute or so, syslog reported a configuration action including a number of errors such as:

NetworkManager[5700]: <error> [1325458737.135085] [nm-system.c:1061] nm_system_replace_default_ip6_route(): (eth2): failed to set IPv6 default route: -1

Despite the errors, IPv6 was working just fine, but I didn’t want the system generating all of these errors, so I disabled IPv6 and the errors stopped. I got busy with the search engines, and it appears that this is a problem that is shared with some other Unix variants, including Arch Linux and Debian. I haven’t seen any resolution to this; I have also submitted a question to the Fedora Forums regarding this problem.  It appears that every time my router sends an IPv6 route advertisement, this error cycle restarts.  It shouldn’t be doing anything unless the route advertisement has changed.

Following the disabling of IPv6, I got a lot of errors from named (the BIND name server) not being able to reach IPv6 addresses in the course of resolving addresses. I added the -4 option in /etc/sysconfig/named to cause it to only use IPv4 for the time being.

Bottom line: IPv6, for me at least, is basically unusable in Fedora 16.  This is a serious deficiency.

Services

Fedora 16 has changed the way that system services (daemons, etc) are managed.  While in the past this was done directly with the service and chkconfig commands, this is now done with the systemctl command.  Fortunately, service commands are still accepted and translated into systemctl commands for those of us for whom habits die slowly.

One of the first things I noticed on upgrading to Fedora 16 is that dovecot, the IMAP server I use, no longer worked. It turns out that the service was disabled for some unknown reason. Re-enabling and starting the service solved the problem

But after a day or so I noticed that I was no longer receiving logwatch emails. It turns out that the crond process had similarly been disabled and was not running. While dovecot is something that not everyone uses, I am really puzzled about why cron would have been disabled.

Summary

This year’s Fedora upgrade involved about the same level of problems as previous years, with some chronic problems (boot, graphics) and some unique problems (networking, services). I am quite unhappy at having to disable IPv6 to keep the system from reconfiguring the network every minute or so; I hope this problem is fixed soon. Otherwise, this seems to have been an OK upgrade, but I’m glad this only happens once a year.