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.

Release Notes

Read the F19_release_announcement and the Fedora 19 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)

Installation issues

Installer screens sometimes do not appear at full screen width

link to this item - Bugzilla: #869364

Sometimes when you visit a screen in the Fedora 19 Beta installer (a 'spoke') more than once, it will display incorrectly - it will be squeezed into an area less than the full width of the screen, and sometimes less than the full height also. We have been attempting to fix this bug for a while but it is a difficult one to pin down.

Usually you can still use the screen in the reduced size version, though it may look very strange. If you get completely stuck, though, you will unfortunately be required to reboot and restart the installation process. We apologize for any inconvenience.

Sadly, we were unable to resolve this issue ahead of the final release of Fedora 19. We were unable to diagnose the cause of the issue, so without any idea how long it might take to fix or how difficult the fix may be, we could not consider adjusting the release schedule. We will attempt to make sure the issue is fixed for the release of Fedora 20.

USB stick from which install is running appears as a possible install target

link to this item - Bugzilla: #874381

In some circumstances, when you are installing Fedora 19 from a USB stick, the stick itself will show up as a possible 'target disk' on the Installation Destination screen where you choose which disk(s) to install onto. This is not intended to happen. It is not possible to install to the USB stick from which the installation is running: if you attempt to do this, the installation will fail. Naturally, therefore, we recommend you simply avoid selecting the stick on this screen.

'Selected' state for disks is indicated with a small and easily missed check mark

link to this item - Bugzilla: #967682

On the installer screen where you choose which disks will be used for Fedora 19 installation, disks that are selected as installation targets are marked with a fairly small black check mark in the lower right hand corner; disks that are not selected do not have the check mark.

This has been changed since Fedora 18, when disks that were selected were highlighted in blue, and now the blue highlight simply means the UI element is selected. So if you click on a disk that was previously selected as an install target, then you have just de-selected it - so the check mark goes away - but the UI element is active, so it is highlighted in blue.

Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.

Please be aware that the check mark not the blue highlight indicates the disks selected as targets. We will endeavour to improve this interface before the final release of Fedora 19.

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 does not warn of failure to create a user account

link to this item - Bugzilla: #965797

In Fedora 19, 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.

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

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

link to this item - Bugzilla: #952666

It has been reported that the xorg-x11-drv-qxl driver in Fedora 19 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 or 7 (pre-release) 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. This is really a bug on the host side rather than the guest side, and updates for RHEL should be made available soon after Fedora 19's release that should resolve this problem.

X may crash when using the qxl driver in a Fedora 19 virtual machine on a Fedora 19 host

link to this item - Bugzilla: #978612

Some testers have reported X.org crashes in Fedora 19 KVM virtual machines running on Fedora 19 hosts when using the qxl graphics driver. The issue seems to be triggered by a resolution change in the guest, but some testers have observed it happening during an installation from the KDE live image: we are not yet sure why. This issue does not seem to affect all testers, and seems to affect some worse than others.

If you find yourself suffering from this issue, there are a couple of possible workarounds. You can configure your virtual machine to use the cirrus video adapter rather than qxl and the VNC display method rather than SPICE (though this may cause issues with GNOME Shell), or you can use the Basic graphics mode option from the Fedora 19 bootloader menu (or simply pass the parameter nomodeset on the kernel command line).

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

su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-qxl'

and then reboot the guest system. Of course, this will not be useful for the initial installation of a Fedora 19 virtual machine: for that phase, try one of the workarounds mentioned above.

Crash when GNOME introductory video attempts to play

link to this item - Bugzilla: #962092

When a user logs into GNOME 3.8 (as included in Fedora 19) for the first time, a short introductory video is intended to play. Fedora 19 testing has indicated that, sometimes, there is a crash, and the video fails to play. On first login to a user account, you may notice a crash report for the /usr/libexec/gnome-initial-setup-player process. Aside from the crash report and the failure of the video to play, this bug appears to have no further consequences. We have not yet identified the circumstances under which the crash occurs.

"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 and later, 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 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. The MATE maintainer is currently working to resolve this issue with updated packages.

X crashes on Fedora 19 32-bit VirtualBox guests with Guest Additions installed

link to this item - Bugzilla: #972095

Several testers have reported that if you install a 32-bit edition of Fedora 19 to a VirtualBox virtual machine and install the Guest Additions, X will no longer start up successfully.

Please note that Fedora does not officially support or recommend the use of the VirtualBox platform. A fix for this issue is unlikely to come from the Fedora project, but the VirtualBox developers may address it in future releases. To work around the issue, do not install the Guest Additions, or install a 64-bit edition of Fedora 19 rather than a 32-bit edition.