{"id":739,"date":"2015-02-21T18:55:24","date_gmt":"2015-02-21T23:55:24","guid":{"rendered":"http:\/\/blog.fritzhardy.com\/?p=739"},"modified":"2015-03-19T15:50:07","modified_gmt":"2015-03-19T19:50:07","slug":"fedora-upgrade-f20-f21","status":"publish","type":"post","link":"https:\/\/blog.fritzhardy.com\/?p=739","title":{"rendered":"Fedora Upgrade: F20 -> F21"},"content":{"rendered":"<p>The <a href=\"https:\/\/blog.fritzhardy.com\/?p=27\">Fedora update odyssey<\/a> continues on new hardware.  The time between Fedora 20 and 21 saw my long-running, much-updated Fedora image migrated to two new environments: <a href=\"https:\/\/blog.fritzhardy.com\/?p=549\">laptop<\/a> and <a href=\"https:\/\/blog.fritzhardy.com\/?p=709\">virtual machine<\/a>.<\/p>\n<pre>\r\nfedup --network 21 --product=nonproduct\r\nfedup --network 21 --product=workstation\r\n<\/pre>\n<p>Curious, I tried &#8220;nonproduct&#8221; on laptop and &#8220;workstation&#8221; 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.<\/p>\n<p>The biggest issue for both environments was broken GDM and Gnome:<br \/>\n<a href=\"https:\/\/blog.fritzhardy.com\/wp-content\/uploads\/2015\/02\/gnome_oh_no.png\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/blog.fritzhardy.com\/wp-content\/uploads\/2015\/02\/gnome_oh_no-300x161.png\" alt=\"gnome_oh_no\" width=\"300\" height=\"161\" class=\"alignnone size-medium wp-image-740\" srcset=\"https:\/\/blog.fritzhardy.com\/wp-content\/uploads\/2015\/02\/gnome_oh_no-300x161.png 300w, https:\/\/blog.fritzhardy.com\/wp-content\/uploads\/2015\/02\/gnome_oh_no.png 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<pre>\r\n(EE) AIGLX error: dlopen of \/usr\/lib\/dri\/swrast_dri.so failed (\/usr\/lib\/dri\/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)\r\n<\/pre>\n<p>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 <a href=\"https:\/\/bugzilla.redhat.com\/show_bug.cgi?id=1192127\">bug<\/a>.  One difference from the other desktop environments is that modern Gnome\/GDM requires OpenGL.  This ultimately narrowed down to a library issue:<\/p>\n<pre>\r\n# ls -l \/usr\/lib\/libGL.so*\r\nlrwxrwxrwx  1 root root     14 Jan 24 09:00 \/usr\/lib\/libGL.so -> libGL.so.1.2.0\r\nlrwxrwxrwx  1 root root     18 Feb 12 11:01 \/usr\/lib\/libGL.so.1 -> libGL.so.173.14.27\r\n-rwxr-xr-x  1 root root 776588 Jan 24 09:01 \/usr\/lib\/libGL.so.1.2.0\r\n-rwxr-xr-x. 1 root root 667528 Aug 19  2010 \/usr\/lib\/libGL.so.173.14.27\r\n<\/pre>\n<pre>\r\n# rpm -q --whatprovides \/usr\/lib\/libGL.so\r\nmesa-libGL-devel-10.4.3-1.20150124.fc21.i686\r\n# rpm -q --whatprovides \/usr\/lib\/libGL.so.1\r\nmesa-libGL-10.4.3-1.20150124.fc21.i686\r\n# rpm -q --whatprovides \/usr\/lib\/libGL.so.1.2.0 \r\nmesa-libGL-10.4.3-1.20150124.fc21.i686\r\n# rpm -q --whatprovides \/usr\/lib\/libGL.so.173.14.27 \r\nfile \/usr\/lib\/libGL.so.173.14.27 is not owned by any package\r\n<\/pre>\n<p>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&#8217;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:<\/p>\n<pre>\r\n# rm \/usr\/lib\/libGL.so.173.14.27\r\n# ldconfig\r\n<\/pre>\n<pre>\r\n# ls -l \/usr\/lib\/libGL.so*\r\nlrwxrwxrwx 1 root root     14 Dec 30 05:42 \/usr\/lib\/libGL.so -> libGL.so.1.2.0\r\nlrwxrwxrwx 1 root root     14 Feb 18 00:06 \/usr\/lib\/libGL.so.1 -> libGL.so.1.2.0\r\n-rwxr-xr-x 1 root root 776580 Dec 30 05:44 \/usr\/lib\/libGL.so.1.2.0\r\n<\/pre>\n<p>Removing or moving the file entirely prevents ldconfig from subsequent upgrades and even reboots from re-linking that old library.<\/p>\n<p>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):<\/p>\n<pre>\r\n# systemctl status default.target\r\n  multi-user.target - Multi-User System\r\n   Loaded: loaded (\/lib\/systemd\/system\/multi-user.target; enabled)\r\n   Active: active since Thu 2015-02-19 20:48:36 EST; 3min 41s ago\r\n     Docs: man:systemd.special(7)\r\n<\/pre>\n<p>Most online documentation indicates that all that is needed to change default target\/runlevel is akin to the following:<\/p>\n<pre>\r\n# ln -sf \/usr\/lib\/systemd\/system\/graphical.target \/etc\/systemd\/system\/default.target\r\n<\/pre>\n<p>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:<\/p>\n<pre>\r\n# systemctl status gdm\r\n  gdm.service - GNOME Display Manager\r\n   Loaded: loaded (\/usr\/lib\/systemd\/system\/gdm.service; disabled)\r\n   Active: inactive (dead)\r\n# systemctl enable gdm.service\r\nCreated symlink from \/etc\/systemd\/system\/display-manager.service to \/usr\/lib\/systemd\/system\/gdm.service.\r\n<\/pre>\n<p>With gdm enabled, the system properly boots to graphical environment.  Still trucking, and adjusting to life with systemd.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 &#8211;network 21 &#8211;product=nonproduct fedup &#8211;network 21 &#8211;product=workstation Curious, I tried &#8220;nonproduct&#8221; on laptop and &#8220;workstation&#8221; on VM, with end result the same. Fedup blocked [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-739","post","type-post","status-publish","format-standard","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/posts\/739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=739"}],"version-history":[{"count":9,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/posts\/739\/revisions"}],"predecessor-version":[{"id":752,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=\/wp\/v2\/posts\/739\/revisions\/752"}],"wp:attachment":[{"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=739"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.fritzhardy.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}