Common F19 bugs

Click here to set up this language box

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 pre-release
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 Beta release announcement and the Fedora 19 Beta 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
  1. a summary of the problem
  2. any known workarounds
  3. 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)

Resolved issues

Native UEFI Fedora installation fails to boot after upgrade to Fedora 19

link to this item - Bugzilla: #966586

If you had a UEFI native installation of Fedora 18 with the default bootloader configuration, and you upgraded to a Fedora 19 package set that includes a version of grub2 earlier than grub2-2.00-18.fc19, the upgraded system will likely fail to load grub correctly at boot. This is due to a bug which caused initialization of grub2 in graphical mode to fail on UEFI systems. The bug was worked around for fresh installs by having grub2 configured in console instead of graphical mode, but as upgraded systems use the old bootloader configuration, the bug still affected upgrades.

This issue was fixed in the updated grub2-2.00-18.fc19 package. To solve the issue if you already upgraded and are affected, you can change grub2 to console mode. Boot a live or rescue image, mount the installed system (at least the /etc and EFI system partitions), edit etc/default/grub within the mounted filesystem and change the line that starts GRUB_TERMINAL_OUTPUT to read GRUB_TERMINAL_OUTPUT="console" (or create such a line if none exists). Then run grub2-mkconfig with the -o parameter to specify the correct location for the updated configuration file within the EFI system partition. The system should now boot correctly.

After updating to grub2-2.00-18.fc19 you can return to a graphical grub2 configuration, if you like, and it should now work.

Installation issues

Installation crash if you de-select all hard disks and click Done when running from a USB stick

link to this item - Bugzilla: #959677

The Fedora 19 Beta installer has a bug which can cause it to crash with the error IndexError: list index out of range in a specific (but moderately commonly-encountered) circumstance. You will hit this crash if you:

• Boot the installer from a USB stick written with livecd-iso-to-disk or (possibly) liveusb-creator
• Intentionally or otherwise de-select all hard disks on the Installation Destination screen and click Done

It is quite easy to inadvertently do this in Fedora 19 Beta as the design used to indicate selected disks on the Installation Destination spoke is somewhat confusing. A relatively small check mark indicates disks that are selected as install targets, and if you only have a single disk, it will be pre-selected for you. It is quite easy to hit this bug if you don't notice this, click the disk to 'select' it (in fact de-selecting it) and then click Done.

If you do hit the bug, it is quite safe to simply reboot and re-try the installation. Note that this bug cannot lead to any loss of pre-existing data. This bug does not affect installs from optical media, or from USB sticks written with 'dd' or analogous methods. The status of the bug with regard to USB sticks written with third-party utilities such as unetbootin is unknown, but in general, the bug will not occur if the USB stick from which you are running the installer shows as a potential target disk on the Installation Destination screen (which should never happen, but at present does happen for dd-written sticks). It may occur if the USB stick from which you are installing is (correctly) suppressed from being shown as a possible target device.

This issue should be resolved before the final release of Fedora 19.

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 Beta 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 Beta (in fact, in all recent kernel builds - this behaviour is not specific to Fedora, though it is very new), the kernel attempts not to write to the NVRAM storage when doing so may trigger the recently-publicised bug in some Samsung firmwares, which causes the system firmware to fail if the NVRAM storage is more than 50% full. There are cases where this can interact badly with firmwares that do not do garbage collection very well, and you may therefore be affected by this problem even if your NVRAM storage area is not full and you do not use one of the affected Samsung firmwares. You may also, of course, actually have a full NVRAM storage area.

If you are affected by this problem, there are several things you can try. The Fedora 19 Beta 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 Beta 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 Final release.

Note for journalists: this issue has nothing at all to do with Secure Boot. Please be careful in distinguishing Secure Boot from UEFI.

Bootloader password is required on each boot

link to this item - Bugzilla: #840160

If you set a bootloader password during installation of Fedora 19 (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.

Non-GNOME initial setup utility always shows all actions

link to this item - Bugzilla: #963935

Fedora 19 includes a new initial-setup utility which replaces the old firstboot utility as the tool that runs on the first boot after installation to complete any necessary setup tasks before normal use of the system can commence. Note that there is an alternative - and completely different - gnome-initial-setup utility which is used instead of initial-setup on the Desktop spin and on installation of GNOME from the DVD or network install images; this bug does not affect GNOME installations, which use this other utility. (If you are not sure which one you are seeing, gnome-initial-setup is a wizard-type interface which starts by asking you to choose a language, while initial-setup looks almost identical to the installer interface).

In Fedora 19 Beta installations of any graphical desktop other than GNOME, the initial-setup utility always runs, and always displays all possible actions (set date and time, set root password, and create user accounts), no matter what actions you took during installation. It is intended that actions that are not necessary or useful should not be displayed; so for instance, if you created a root password and a user account, or an administrative user account, during installation, initial-setup should not really need to run at all, but this has not yet been implemented.

We recommend you use initial-setup only to create a user account if you did not create one during installation. If you did create a user account during installation, the best thing to do is simply to quit it as soon as it runs.

Non-GNOME initial setup utility does not warn of failure to create a user account

link to this item - Bugzilla: #965797

In Fedora 19 Beta, the new initial-setup utility described in the previous entry does not present any kind of warning if you leave it without having created a user account either during installation or from initial-setup itself. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.

The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.

We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root; so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we strongly advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.

This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.

This issue is expected to be resolved before the final release of Fedora 19.

Upgrade issues

System hangs at the end of the process when upgrading to Fedora 19 with fedup

link to this item - Bugzilla: #957783

When upgrading to Fedora 19 using the recommended FedUp method, the system may hang at the end of the upgrade process, whereas it should automatically reboot into the upgraded system. The upgrade process has been completed at this point, and it is safe simply to force a reboot at this point. Barring unrelated issues, the upgraded system will be in place and working.

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 19 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.

System fails to start correctly (due to qxl driver crash) when booting 32-bit image in Fedora virtualization

link to this item - Bugzilla: #965101

Several testers have reported that, using Fedora's official virtualization stack (qemu-kvm/libvirt) with the virtual machine's video adapter set as 'qxl', if you boot a 32-bit Fedora 19 Beta image, the system will fail to boot correctly due to a crash in the xorg-x11-drv-qxl video driver.

As we do not support 32-bit systems as virtual hosts at all, there is a very simple workaround for this bug in all supported (i.e. 64-bit host) configurations: configure your guest with a 64-bit processor and boot a 64-bit Fedora 19 Beta image. If you absolutely must boot a 32-bit image for some reason, you can re-configure your virtual machine to use a different video adapter; the 'cirrus' or 'vga' models ought to work, although performance will likely be poor and there may be glitches in rendering of the GNOME desktop.

System fails to start correctly (due to qxl driver crash) when booting Fedora 19 Beta as a virtual guest on a RHEL 6 host

link to this item - Bugzilla: #967679

It has been reported that the xorg-x11-drv-qxl driver in Fedora 19 Beta crashes during X startup when trying to boot a Fedora 19 Beta image in a virtual guest configured with qxl/SPICE graphics on a Red Hat Enterprise Linux 6.4 host. This likely affects earlier versions of RHEL 6, clones of RHEL 6 such as CentOS, and possibly very old (and unsupported) Fedora releases as well.

To work around this issue, configure your guest to use cirrus/VNC or vga/VNC instead of qxl/SPICE. Developers are currently considering how this issue can be resolved before the final release of Fedora 19.

"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.

Several x-caja-desktop windows pop up on login to MATE desktop

link to this item - Bugzilla: #886029

Sometimes (the bug is due to a race condition and hence unpredictable), on boot of the Fedora 19 Beta MATE live image or first login with a user account to the MATE desktop, several useless windows labelled x-caja-desktop will open up on the desktop.

The bug has no further consequences and it is quite safe to simply close the windows and continue using the system.

This bug should be resolved for the final release of Fedora 19.