The Fedora update odyssey continues on new hardware. The time between Fedora 20 and 21 saw my long-running, much-updated Fedora image migrated to two new environments: laptop and virtual machine.

fedup --network 21 --product=nonproduct
fedup --network 21 --product=workstation

Curious, I tried “nonproduct” on laptop and “workstation” on VM, with end result the same. Fedup blocked at some RPM transaction errors that were easily cleaned up with some uninstalls, and flagged a few dozen packages as lacking updates (from prior Fedora releases), but was uneventful otherwise. Reboot completed the upgrade.

The biggest issue for both environments was broken GDM and Gnome:
gnome_oh_no

(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)

KDE/KDM and XFCE worked fine. Removing some leftover packages and miscellaneous cleanup was called for anyway, but after other tweaks and config changes targeted at fixing this bore no fruit, I opened a bug. One difference from the other desktop environments is that modern Gnome/GDM requires OpenGL. This ultimately narrowed down to a library issue:

# ls -l /usr/lib/libGL.so*
lrwxrwxrwx  1 root root     14 Jan 24 09:00 /usr/lib/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx  1 root root     18 Feb 12 11:01 /usr/lib/libGL.so.1 -> libGL.so.173.14.27
-rwxr-xr-x  1 root root 776588 Jan 24 09:01 /usr/lib/libGL.so.1.2.0
-rwxr-xr-x. 1 root root 667528 Aug 19  2010 /usr/lib/libGL.so.173.14.27
# rpm -q --whatprovides /usr/lib/libGL.so
mesa-libGL-devel-10.4.3-1.20150124.fc21.i686
# rpm -q --whatprovides /usr/lib/libGL.so.1
mesa-libGL-10.4.3-1.20150124.fc21.i686
# rpm -q --whatprovides /usr/lib/libGL.so.1.2.0 
mesa-libGL-10.4.3-1.20150124.fc21.i686
# rpm -q --whatprovides /usr/lib/libGL.so.173.14.27 
file /usr/lib/libGL.so.173.14.27 is not owned by any package

Close inspection shows that libGL.so.1 is a symlink to libGL.so.173.14.27, which is not owned by any package. This if from an old Nvidia proprietary driver install dating to the installation’s life on prior hardware and setup from many years ago. Interestingly, libraries are linked just this way in Fedora 20, but something in the upgrade exposed it as a problem. The proper fix:

# rm /usr/lib/libGL.so.173.14.27
# ldconfig
# ls -l /usr/lib/libGL.so*
lrwxrwxrwx 1 root root     14 Dec 30 05:42 /usr/lib/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Feb 18 00:06 /usr/lib/libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 776580 Dec 30 05:44 /usr/lib/libGL.so.1.2.0

Removing or moving the file entirely prevents ldconfig from subsequent upgrades and even reboots from re-linking that old library.

One remaining issue to track down on one of the machines was booting to multi-user.target (aka runlevel3) instead of graphical.target (aka runlevel5):

# systemctl status default.target
  multi-user.target - Multi-User System
   Loaded: loaded (/lib/systemd/system/multi-user.target; enabled)
   Active: active since Thu 2015-02-19 20:48:36 EST; 3min 41s ago
     Docs: man:systemd.special(7)

Most online documentation indicates that all that is needed to change default target/runlevel is akin to the following:

# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

However, this does not enable the display manager automatically if it has been disabled, as I had done somewhere along the way. The system will boot to command-line, but indicate that graphical.target is active:

# systemctl status gdm
  gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; disabled)
   Active: inactive (dead)
# systemctl enable gdm.service
Created symlink from /etc/systemd/system/display-manager.service to /usr/lib/systemd/system/gdm.service.

With gdm enabled, the system properly boots to graphical environment. Still trucking, and adjusting to life with systemd.