Handling a Boot Failure Caused by the Proprietary AMD Catalyst 14.4 (fglrx) Driver in Fedora 20

Public Service Announcement

When updating your Fedora 20 kernel version while running the proprietary AMD Catalyst 14.4 (fglrx) driver, be sure to follow the below procedure:

  1. Execute sudo aticonfig –uninstall
  2. Reboot
  3. Update the kernel (sudo yum update).
  4. Reboot.
  5. Assuming you followed the instructions to the previous post in order to get this far, execute the ati-installer.sh file as described in that post to reinstall the driver in the new kernel environment:
sudo your_path_here/ati-installer.sh 14.10 --install

End Public Service Announcement

 

Of course, that’s not what I did; I skipped step 1 and 2 above, performed 3, then 4, and upon rebooting into my new kernel environment with fglrx installed for the previous environment, found that the boot process would pass the pretty blue Fedora 20 loading bars without apparent issue, but a black screen would show rather than the KDE Desktop Manager login screen (where you put your username and password).  Regardless of the kernel version I chose (3.14.4-200, 3.14.3-200, 3.14.2-200), I would encounter the same result.  Not even Magic SysRq key combinations would allow me to switch to another terminal, for the system is attempting to boot into graphical mode and the display is failing catastrophically.

You basically have two options here.  First (and most easily), you could try changing the runlevel at boot using GRUB.  At the GRUB menu (where you select the kernel version to boot into), highlight the latest kernel version and press “e” to edit the menu entry (only for this boot, that is).  About 3/4 of the way down the entry, find the line that looks like:

linux /vmlinuz-3.14.4-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8

Just tack a space and a 3 onto the end of it so that it now looks like:

linux /vmlinuz-3.14.4-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8 3

And press F10 to boot.  You should be greeted by a text-only prompt for authentication.  Once you gain access to the system, you should first make sure fglrx is actually your problem.  If it is, you’ll likely find a line like this in /var/log/kdm.log:

(WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found

If a log entry such as this is found in your /var/log/kdm.log file, you can be sure fglrx is the cause of the KDM’s failure to start at boot, and you can simply uninstall it:

sudo aticonfig --uninstall

After you do that, reboot your machine as you normally would, loading your newest kernel version, and you should notice that the KDM comes up as expected.  The proprietary AMD Catalyst driver will be uninstalled, and you’ll need to simply reinstall the driver (step 5 in the Public Service Announcement above).

Your second option (listed here purely for academic purposes unless some situation prevents the above option from working for you) is to boot into a rescue environment of some sort.  Many people have rescue USB drives created out of Fedora 20 Live CD images, but built into Fedora 20 is the convenient creation of a rescue image by a facility called “dracut.”  In the GRUB boot menu, you need only choose the “Fedora, with Linux 0-rescue” GRUB entry, and into the rescue image you go.  (Note:  You will need your root password to continue)

What you’re doing is choosing to execute an archived initramfs image which will, in turn, load an archived version of the kernel image used to install the system.  This data was archived and configured as bootable in GRUB by the dracut facility when Fedora 20 was first installed.  The primary reason for this rescue image’s existence (and the rationale for the dracut facility) is as follows:

When a system boots Fedora 20, GRUB builds an initial RAM file system in memory (so it’s not on your hard disk).  The only purpose of this initial RAM file system is to contain the utilities and functionality necessary to launch the initial process (init, PID 1) which will complete the rest of the tasks required to load the system.

In order to optimize boot speed in Fedora 20, dracut is used to create “hostonly” initramfs images for kernels, stripping them of modules containing drivers for hardware not present on your system.

The benefit is boot speed; the initramfs image takes time to load into memory, and the image created by dracut is less than half the size of a standard initramfs image containing all the kernel modules required for the vast array of potential end user hardware.  On my system, the dracut-trimmed initramfs image is 19 MB compared to the 38 MB used for the full-fledged initramfs, and that’s with an older and smaller kernel.

The cost is that you may not have the proper drivers in your kernel if you perform a significant hardware change (a processor, perhaps).

To resolve this issue, you are provided with a GRUB boot entry allowing you to load an initramfs image taken of the initial kernel initramfs on your system when you built it, with all of the standard kernel modules loaded, so that the vast majority of hardware would be detectable and mountable with it.

Because this rescue initramfs image loads a rescue kernel image made from the kernel used to install the system, you’ll be running a fully functional (if a bit outdated) environment without any troublesome modules (including proprietary graphics drivers).  You can then use this environment to perform the uninstallation of your driver (as outlined above).  Reboot, and you should be in good shape.

Advertisements
This entry was posted in Information Technology and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s