Believe or not, Fedora’s release upgrade is always troublesome, partially because of the package management imposed, which is initially designed to ease the update for binaries. After the painful experience from Fedora 19 to 20, I have just gone thru another one from 20 to 21. This post will talk about the pitfalls and solutions pre/after the release upgrade. NOTE: this is NOT an official release upgrade procedure, which can be found anywhere else.

0. yum update –skip-broken

Before start, a ‘yum update’ is needed to make sure all the stuffs are the latest, including fedup. However, there has been a lot of breakage since my last update from 19 to 20, which means ‘yum update’ would not work until ‘–skip-broken’ was appended. So far, the best working solution (for me) is:

rpm -e X –nodeps
yum install X

1. Keys…

Yes, similar things happened again for rpmfusion repo. If fedup complains about GPG keys, either missing or not used, need to either ‘ln -s existingOne missingOne‘ or ‘rpmkeys -import missingOne‘. More details can refer to here.

2. Oh, no…

After the restart, my Fedora told me this. Actually, it is not helpful at all. The only useful thing behind this stupid message is that Gnome login shell crashed! Don’t panic like Fedora does. Let us go debugging: Ctrl-Alt-F2 into single user mode. Then, go to /var/log/messages.

3. SELinux

According to the latest logging, SELinux was preventing the startup for “console-kit-daemon‘ from access to certain file. This service is required by dbus and somewhat related with gdm-Xorg. Actually, you may find other preventions by SELinux. Ideally, all the polices should be updated based on the new release. However, apparently there were some mess up after fedup. For now, let us change the SELinux from enforcing mode to permissive mode, making sure SELinux is not the showstopper:

vim /etc/selinux/config

4. module ‘nv’/Nvidia

After reboot, the annoying ‘Oh, no’ was still there. So we need to move on. As the issues was limited into gdm/Xorg, because of the login shell. We need to make sure if gdm-Xorg was doing alright. Then we found this:

gdm-Xorg-:0: (EE) Failed to load module “nv” (module does not exists, 0)

Some googling told us this ‘nv’ module is the Nvidia proprietary driver. (Yes, I am using a Nvidia video card). This is weird as I have uninstalled that driver and the system should be using ‘nouveau’ now. Later on, we will see the root cause was still the Nvidia driver. But for now, let us fix this “nv” module issue by telling Xorg to load ‘nouveau’ explicitly, creating a new file /etc/X11/xorg.conf.d/20-nouveau.conf

Section “Device”
[tab]Identifier “Nvidia card”
[tab]Driver “nouveau”
EndSection

5. AIGLX error/Nvidia

Now the Xorg was using the right driver. But still we got ‘Oh, no’. Moving on hunting for gdm-Xorg logging, after ‘nouveau’ was loaded, there were 2 more errors:

gdm-Xorg-:0: (EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dir.so failed …
gdm-Xorg-:0: (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed …

Till now, we probably are confident to say these errors were the root cause, as these libraries are the core of ‘nouveau’ driver. One can imagine if they are failed to load. So what happened here? Fortunately, I am not the one having the same problem – https://bugs.freedesktop.org/show_bug.cgi?id=26799 shows similar issue and the hint is located in ‘nouveau’ troubleshooting. In general, there were still Nvidia driver legacy libraries messing up with Xorg.

If you still have kept the Nvidia driver installer, the best way would be using that installer to uninstall again, which should have a clean sweep for all the Nvidia libraries. This solution comes from https://bbs.archlinux.org/viewtopic.php?id=188772. Otherwise, we have to clean the libraries manually. According to the ‘nouveau’ troubleshooting, we need to clean libGL.so, libGLcore.so and libglx.so from Nvidia. NOTE, Xorg and Mesa also have their own libGL.so and libglx.so (AND this is the reason why for the ‘Oh, no’ failure – Xorg was trying to use these libraries provided by Nvidia). One hint here is libraries provided by Nvidia driver are usually appended with version number, such as .304.5. Remove these evil Nvidia legacy and make sure the corresponding libraries are pointing to the right ones:

ldconfig -p | grep libGL.so

If you are not able to tell what is the Nvidia legacy lib, try to remove all and then reinstall Xorg and Mesa, which should install the corresponding libraries again.