Common F18 bugs
This page documents common bugs in Fedora 18 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.
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)
Installer reformats target disks without warning
The Anaconda installer for Fedora 18 will format the entire disk unless custom partitioning is selected.
In Fedora 18 Alpha, if you select a disk or disks to which to install Fedora in the Installation destination screen and hit 'Continue' at the 'INSTALLATION OPTIONS' dialog without checking Let me review & customize the partitioning of the disks anyway, then complete the installation, the installer will reformat all disks selected without any further warning. There is no option presented to use free space on the disks or resize existing partitions, all existing data on the disks will be lost.
Checking the Let me review & customize the partitioning of the disks anyway box allows you to enter the custom partitioning screen, where you may be able to create a viable layout without destroying existing data. Be aware, however, that the custom partitioning screen is far from complete and known to be buggy. We strongly advise you to install Fedora 18 Alpha only on systems or virtual machines which contain no data of value to you.
This is not the final design of the partitioning process for Fedora 18, and it will be improved for the Beta and Final releases.
No upgrade function available from Fedora 17 to Fedora 18 Alpha
There is no upgrade function available in the Fedora 18 Alpha installer, nor is preupgrade yet capable of upgrading from Fedora 17 to Fedora 18. The upgrade code for the new version of the installer was not completed in time for the Alpha release.
If you are intent upon upgrading an installed Fedora 17 system to Fedora 18 Alpha you may attempt to upgrade using yum, following these instructions - make sure to read the section specific to the Fedora 18 upgrade. Please be aware that yum upgrades can have problems and you should not attempt this on any system containing data of any value to you.
This issue will be addressed for Fedora 18 Beta. Upgrade code will be in place at the time of the Beta release.
Installer crashes instead of presenting an error dialog when disk is too small (or other errors)
If you try to install Fedora 18 Alpha to a very small disk, the installer will likely crash with an error PartitioningError: not enough free space on disks. In general, there are several cases where there is code in the installer to catch errors, but no 'error handling' code to present a dialog to the user with appropriate options when one of these errors occurs.
There is no workaround for this kind of problem, but in any case where this happens, it indicates some kind of problem in your installation attempt. You may be able to tell from the error message and traceback what the error is, and correct it in another attempt to install. For this specific error, the problem is that the target disk is too small.
Error handling code will be implemented in the installer for Fedora 18 Beta.
Installer crashes when using automatic partitioning option with no free space available
If you enter the custom partitioning screen of the Fedora 18 Alpha installer (by checking Let me review & customize the partitioning of the disks anyway) and attempt to use the Click here to create them automatically option if there is no unpartitioned space available, the installer will crash with the error NoDisksError. Another reporter has reported that this can also be triggered by entering the 'Installation destination' screen and immediately clicking Back without making any selection.
This bug is an instance of the lack of error handling described above. It can be worked around by ensuring there is unpartitioned space available before attempting to use the automatic partitioning option (if your target disk is fully partitioned, delete one or more existing partitions before attempting to use the automatic partitioning option). As explained above, proper error handling will be implemented for the Fedora 18 Beta release.
UEFI boot of DVD/network install media fails
Native UEFI booting of the Fedora 18 Alpha DVD / network install images is known to be broken in certain cases. If you write the DVD or network install image to an optical disc, or to a USB stick using the
dd (direct copy) method, the resulting medium will not succeed in starting the installer if booted via UEFI. You will be dropped to a rescue shell with the error message dracut-initqueue: Warning: /dev/root does not exist.
To avoid this issue, use one of the other methods of producing UEFI-bootable install media. Live images written to optical discs, with
dd, or with
livecd-iso-to-disk --efi should all boot successfully. If you wish to use the DVD or network install images, the
livecd-iso-to-disk --efi method should result in a USB medium that will boot successfully.
See How_to_create_and_use_Live_USB for detailed instructions on the various methods of writing USB media.
The cause of this problem has been identified and it will be resolved for the Fedora 18 Beta release.
Reboot fails after live installation
Multiple testers reported that, after completing a live installation of Fedora 18 Alpha, rebooting fails. If you hit Esc to see the console messages, you will see 'Dependency failed for Reboot.' and, at the end, 'Reached target Shutdown.'
Once the system has reached this point it is quite safe to hit the physical reset button or turn the power off. There is no known workaround for the issue besides simply rebooting or powering off manually.
Problems with start or display of login manager or desktop on NVIDIA graphics adapters
There is a problem in the nouveau kernel module in Fedora 18 Alpha which can cause various symptoms that ultimately prevent you from reaching a usable desktop, when booting the live image or an installed system. The login manager and/or desktop may fail to appear at all (though ps and systemctl will show that they are running), or they may appear but with the cursor missing and/or visual corruption issues.
To work around this issue for live system boot or first boot of an installed system, edit the kernel parameters at boot time and remove 'rhgb'. This should result in a fully working boot.
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 to Bodhi whether it solves the problem. To test the update, run this command:
su -c 'yum --enablerepo=updates-testing update kernel'
GNOME crashes when unlocking screen (usually in a KVM)
When running Fedora 18 Alpha in a KVM virtual machine using the 'qxl' video adapter and 'xorg-x11-drv-qxl' video driver, using the GNOME desktop, if the screen is locked either by the user or after an inactivity timeout, GNOME will crash back to the login screen a few seconds after the screen is unlocked.
Note that a few reporters have reported similar behaviour with other video adapters and drivers (on real machines, not virtual ones), but these issues likely have different causes and should be reported separately.
To workaround this issue you can disable screen locking, or - if you require screen locking - use a different video adapter and/or driver in the virtual machine, which will allow you to use screen locking but give you poorer video performance. The combination of the 'cirrus' adapter and the 'xorg-x11-drv-modesetting' driver also has problems, so if you are going to use an alternative combination, we recommend the 'vga' adapter.
Some testing suggests that updating to the latest GNOME packages from the updates-testing repository may resolve this issue.
PackageKit-based package management tools cannot import Fedora GPG key
After installing Fedora from the traditional installer, the Fedora GPG key is not included in the RPM keyring: the first time you perform any package operation, the tool you are using should prompt you to import the Fedora GPG key. (When installing from a live image, the key is already imported and this problem does not occur).
In Fedora 18 Alpha, PackageKit-based tools, such as the GNOME and KDE package installer and update applications, are not able to import the key. They will prompt you, but will not actually manage to import the key. This will mean you cannot complete any package management operation, such as installing a package or updating the system, with these tools.
The workaround for this is simply to perform any package install or update with the
yum tool. This will prompt you to import the Fedora GPG key, and via yum, the import will be successful. After this, you can use PackageKit-based tools successfully.
A fix for this issue has been identified, but not yet incorporated into a Fedora package. This should be done soon.
Cursor frequently jumps to the edges of the screen, triggering overview in GNOME, especially in virtual machines
Multiple testers reported an issue in Fedora 18 Alpha where the overview mode of GNOME Shell is triggered inadvertently. This issue especially affects virtual machines, both KVM and VirtualBox, though it can also affect real hardware.
The cause of this issue is a bug in the X server which causes the cursor to jump to the edges of the screen when a so-called 'absolute input device' is connected to the system. As moving to the top-left edge of the screen triggers the overview in GNOME, the bug can cause that to happen. The bug particularly affects virtual machines because they use virtual tablet devices to represent mouse input from the host (this has certain benefits over using a virtual mouse). It therefore also affects real hardware configurations that involve an absolute input device, like a tablet.
The issue can be worked around by removing the absolute input device from the system (whether virtual or real). No other workaround has yet been discovered. Work on fixing the issue is ongoing.
Font in grub console (when editing boot options) is large and not monospaced, cannot be seen at all at 640x480 (in virtual machines)
In Fedora 18 Alpha, the font used for the grub (bootloader) console - what you see when you hit 'e' at the bootloader menu, which allows you to edit the boot configuration - is poorly chosen. It is not a monospace font, and it is too large. This makes it difficult to read the screen, leads to bugs in cursor placement, and when grub renders at 640x480 resolution - which is the case in many virtual machine configurations - makes the screen completely unusable, no text is visible.
A fix for this issue has been identified, and will be a part of the next grub2 package released for Fedora 18.
Various issues in desktop sessions started via startx
If you start a graphical session in Fedora 18 Alpha by logging into a virtual terminal and running the
startx command, you may find that at first all appears to be fine, but various small issues appear. Some effects that have been noted are issues with the GNOME lock screen, issues running virtual machines, the Suspend option not appearing in the User menu when holding the alt key, and several other issues related to session handling.
The root issue here is that session handling is not done correctly for desktop sessions started via startx. Using the command
startx -- vt01 instead of plain
startx will resolve several of the issues, though possibly not all of them.