This page documents common bugs in Fedora 19 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 19 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 19 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
Read the F19 Alpha release announcement and the Fedora 19 Alpha Release Notes for specific information about changes in Fedora 19 and other general information.
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
UEFI install fails with BootLoaderError: failed to set new efi boot target
link to this item - Bugzilla: #949786
Some UEFI-native installations of Fedora 19 Alpha may fail near the end of installation, with the error BootLoaderError: failed to set new efi boot target (or a similar error).
Systems with UEFI firmwares contain a small amount of NVRAM (non-volatile RAM) storage, into which certain UEFI configuration and other data can be written by the firmware or by UEFI-native operating systems. This error usually indicates that the kernel considers the NVRAM storage area to be full, and is refusing to write anything to it when the Fedora installer attempts to write an EFI boot manager entry for the newly installed Fedora system.
In Fedora 19 Alpha (in fact, in all recent kernel builds - this behaviour is not specific to Fedora, though it is very new), the kernel actually refuses to write to the NVRAM once it reports that it is 50% full. This is intended to avoid triggering the recently-publicised bug in some Samsung firmwares, which will refuse to boot if the NVRAM storage is more than 50% full. Unfortunately, this does mean that installation will fail on non-Samsung systems whose NVRAM is more than 50% full, but still has more than enough space for a Fedora boot entry.
As of yet the kernel developers have been unable to figure out a way to use the full NVRAM space on non-buggy firmwares while avoiding 'bricking' systems with buggy firmwares, so for the present, we are erring on the side of caution and refusing to write beyond 50% of NVRAM space on any UEFI firmware.
If you are affected by this problem, there are several things you can try. The Fedora 19 Alpha installer attempts to delete non-essential data from the NVRAM prior to writing a boot manager entry. However, it cannot force the firmware to do garbage collection after requesting the deletion. In some cases, several reboots may be required to trigger garbage collection. So the first thing to try if you are affected by this is to reboot the system several times, and then re-try the installation.
If that does not help, you may try resetting the firmware to defaults, or updating or reinstalling the firmware. However, note that doing so can reset the EFI boot manager to its default state, which may remove entries for any UEFI native operating systems you have installed!
If all else fails, you may be forced to install Fedora 19 Alpha in BIOS emulation mode rather than UEFI native mode.
We will continue to work on this issue to see if we can improve the situation in any way for the Beta and Final releases.
Note for journalists: this issue has nothing at all to do with Secure Boot. Please be careful in distinguishing Secure Boot from UEFI.
UEFI install fails on Macs
link to this item - Bugzilla: #953447
Testing has indicated that Fedora 19 Alpha images are highly likely to fail to boot in UEFI native mode on Apple Mac systems. All Macs tested so far displayed this bug. The symptom is that the boot halts just after GRUB, showing a black screen with the message "Secure boot not enabled" (this message is incidental, and not related to the bug, which is not believed to have anything to do with Secure Boot).
We are still investigating this issue and will attempt to fix it prior to the Beta release. There is as of yet no known workaround for installation of Fedora 19 Alpha on affected systems, besides using BIOS emulation (which has its own significant problems). Possibly the best course of action if you are determined to test Fedora 19 on an affected system would be to install Fedora 18 and then upgrade to Fedora 19 using yum: this is not usually a recommended upgrade method, but prior to Beta, it is more likely to succeed than using fedup.
Installation to a blank disk fails with FormatDestroyError: error wiping old signatures
link to this item - Bugzilla: #953329
Some installations of Fedora 19 Alpha to a completely blank or wiped disk may fail during filesystem creation with the error FormatDestroyError: error wiping old signatures. This issue affected some tests, but did not prove to be reliably reproducible - so far we have not yet isolated the precise conditions that trigger the problem.
If you are affected by this issue, simply reboot and re-try the installation: in both of the affected tests, a second attempt at installation succeeded. On the second installation attempt, you will find the disk is now populated with some partitions created during the first, failed attempt - you can simply tell the installer to delete these.
Network installation fails with ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf
link to this item - Bugzilla: #906031
Fedora 19 Alpha network installations sometimes fail with the error message ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf. This bug seems to be intermittent and difficult to pin down. It comes and goes in different circumstances for different reporters. As of yet we have been unable to pinpoint the precise circumstances which trigger the bug, though it may be to do with either the contents of the repository at the time of installation, the packages selected for installation, the speed of the system, or any combination of the above.
If you encounter this bug, we recommend first simply re-trying the installation - a second attempt may well succeed. If that does not succeed, you may try waiting a few hours or a day and re-trying the install again; many reporters have hit the problem several times on a given day, but then been unable to reproduce it when they tried again the next day. You can also install from a live image or from the DVD image without using remote repositories: the bug does not appear to affect either of those cases.
We are still investigating this bug and will aim to fix it before the Beta release.
Bootloader password is required on each boot
link to this item - Bugzilla: #840160
If you set a bootloader password during installation of Fedora 17 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.
Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.
Hardware issues
Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420)
link to this item - Bugzilla: #752613 Kernel bugzilla: #43054
Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 17 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.
Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the VT-d advanced virtualization feature, the X2APIC level APIC, and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.
So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter nox2apic. In this way, you should be able to determine which of the features you want to use.
The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.
Software issues
GDM and GNOME render incorrectly on older systems
link to this item - Bugzilla: #909473
Some testing has indicated that Fedora 19's llvmpipe-based software 3D rendering does not work properly on older CPUs (those without SSE2 or equivalent instructions; SSE2 was introduced by Intel with the Pentium 4 in 2001, and AMD added support for it with the introduction of the Opteron and Athlon 64 lines in 2003). If your graphics card is not sufficient for GNOME 3 - which may well be the case on older machines - Fedora will try and use software rendering to display GDM and GNOME, but due to this bug, it may fail entirely or render incorrectly. GNOME 3.8, as included in Fedora 19, no longer has a non-accelerated 'fallback mode' for use on systems where 3D acceleration does not work correctly.
At present the only workaround for this problem is to use a non-3D accelerated login manager and desktop. KDM is probably the most robust alternative login manager. The KDE, Xfce, LXDE and MATE desktops all work without 3D acceleration and would be possible alternatives to GNOME.
"Updates available" notification runs online updater
link to this item - Bugzilla: #863592
Fedora 18 introduced a feature called offline system updates. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18, at least when using GNOME. However, the feature's implementation is still somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.
This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 19, and you can use the online update mechanism as safely in Fedora 19 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.
If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.