This page documents common bugs in Fedora 17 and, if available, fixes or workarounds for these problems. If you find your problem in this page, do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.

Fedora 17 pre-releaseFedora 17 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 17 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).

Release Notes

My bug is not listed

Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.

To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.

If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:

Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source.

Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes

a summary of the problem

any known workarounds

an assessment on the impact to Fedora users

For reference, you can query Bugzilla for bugs tagged CommonBugs:

CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)

CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)

Installation issues

Installation crashes if another Linux distribution or other Unix-style operating system is present

Due to a bug in the Fedora installer, installation will fail (and the installer will crash) if you attempt to install to a system which has another operating system installed, if that operating system contains a /etc/fstab file but no /etc/redhat-release file. The traceback will include the error TypeError: float() argument must be a string or a number, and if you report the crash, it will be found to be a duplicate of Bugzilla: #791317.

Alternatively, as a workaround, you can create a /etc/redhat-release file for each operating system with a /etc/fstab, of the general format the installer is looking for: Fedora release 17 (Beefy Miracle).

Installation crashes if btrfs chosen as format for any target partition, or any btrfs-formatted partition is already present on a target disk

Due to a bug in the Fedora installer, if you choose btrfs as the format for any target partition as part of a Fedora 17 Alpha installation, or if any btrfs partition is present on a disk on the system to which you are attempting to install, the installer will crash with an error IndexError: list index out of range.

At present, there is no known workaround for this issue.

PXE install can have problems with RAID arrays or encrypted devices

When installing Fedora 17 Alpha via PXE, some kernel parameters are not passed which are passed with other installation methods and, with previous releases, were automatically passed on PXE installations as well. These parameters prevent RAID arrays and encrypted partitions from being activated at initramfs initialization time, which interferes with their analysis and/or use by the installer.

If you are performing a PXE install to a system with RAID devices or LUKS-encrypted partitions, you should add the following kernel parameters to ensure the installer does not encounter problems: rd.luks=0 rd.md=0 rd.dm=0. If you do not, you may encounter an installer crash with an error RuntimeError: device is already mapped, or similar problems.

DVD or network install image written to USB stick with livecd-iso-to-disk does not boot via UEFI

If you write the Fedora 17 Alpha DVD or network install image to a USB drive using the livecd-iso-to-disk tool provided in the livecd-tools package (whatever version of Fedora you write the image from), using the --efi parameter which should result in a drive that can be booted via UEFI, it will not in fact succeed in booting the installer if booted via UEFI. After the bootloader menu is displayed, you will see a Error 15: File not found message.

An updated livecd-tools package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report whether it solves the problem. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update livecd-tools'

The update is currently available only for Fedora 17, but if testing is successful it will be made available for Fedora 15 and Fedora 16. The drive will boot correctly to the installer if booted via BIOS or UEFI BIOS emulation, and if you specifically need to boot via UEFI, an image written via dd or a live image written via livecd-iso-to-disk --efi should work.

Software issues

Sound does not work due to missing ConsoleKit

Sound will not work out of the box with Fedora 17 Alpha on all systems. This is due to PulseAudio's default configuration expecting ConsoleKit to be present, whereas it has in fact been removed from the default installation as part of the ConsoleKit removal feature. We had planned to implement a quick fix for this as part of the Alpha release, but PulseAudio's assembler code does not compile with GCC 4.7, and fixing this is a substantial undertaking that could not be completed in time, so we could not perform a new build of PulseAudio.

Fortunately, working around the issue is simple. Just comment out, or entirely remove, the following lines from /etc/pulse/default.pa:

.ifexists module-console-kit.so
load-module module-console-kit
.endif

Alternatively, you can install the ConsoleKit package, but ideally we would prefer if Alpha users run without ConsoleKit in order to help catch any other bugs caused by its removal.

Poor performance issues

A bug was identified in the kernel included in Fedora 17 Alpha which seems to cause very poor performance on certain systems. Not all systems are affected, but on those that are, almost all operations seem to be affected.

An updated kernel package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report whether it solves the problem. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update kernel'

Please note also that, up until Beta, Fedora kernels are usually built with debugging options enabled. Some testers have noticed that debugging options appear to cause a higher performance overhead with more recent kernel versions (since approximately 2.6.39 or 3.0). You may notice a visible impact on performance with any Fedora kernel with debugging options enabled, but this is not really a bug. At Beta release time, we will switch to building kernels with debugging options disabled, and performance will improve.

GNOME Shell frequently crashes when used in a KVM virtual machine

If you install Fedora 17 Alpha with the default GNOME desktop in a virtual machine using Fedora's standard virtualization stack on a Fedora 16 or Fedora 17 host (i.e., a qemu/kvm-based virtual machine with Spice as the display protocol and using the qxl graphics driver in the guest, rather than VNC and cirrus), you will likely find that the GNOME Shell crashes frequently enough to make the desktop unusable. This is caused by bugs in the still-new llvmpipe-based software rendering of GNOME Shell.

Using the VNC/cirrus display combination is one possible workaround for this. Another is to continue using Spice/qxl, but switch to GNOME's fallback mode instead of using the software-accelerated Shell. It is possible to do this through the GNOME Control Center, but you will likely find Shell crashes before you can make it to the configuration toggle! It is therefore easier to toggle the fallback mode with the following shell command:

gsettings set org.gnome.desktop.session session-name 'gnome-fallback'

run from your user account, not the root account. You can do this from a GNOME terminal or from a virtual terminal. After running the command, log out and back in, and you should be in fallback mode rather than the Shell.