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.
Many expected packages missing from DVD / network installations
One of the Fedora 18 features is a major rework of package groups. In Fedora 18 Alpha, this rework is not yet complete, and the package groups for the major desktops - especially GNOME - are not yet finalized. There is also a bug in the Fedora 18 Alpha installer. On the package selection screen, when you pick a 'major' package group on the left hand side, there is a mechanism by which some more package groups associated with that group may appear on the right hand side. In Alpha, however, this mechanism is broken. For instance, when you pick the GNOME package group, some extra sets of packages associated with GNOME should appear in the list on the right, but due to this bug, this does not happen. When installing some package groups from the DVD / network install in Alpha, especially GNOME, you will end up with a much smaller set of packages installed than you might expect (and that you would have got in previous releases).
One way to 'work around' this is to install from the live images, which have more complete package sets at this point in time. You can also specify any combination of package groups and packages for installation using a kickstart-driven install. Finally, of course, you can simply install the packages and package groups you want to use after system installation.
The fix for the problem with optional package groups not showing up was identified prior to Alpha, but not included in the Alpha release for fear of destabilizing it. It will be included in the Beta release. The package groups themselves will also be further refined for Beta.
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.
UEFI installation fails to boot
This issue is distinct from the one above. On some UEFI-capable systems, a UEFI native installation of Fedora 18 Alpha (performed using one of the methods which produces a bootable installer) will fail to boot: the installation process will proceed successfully and a 'Fedora' UEFI boot manager entry will be present, but it will fail to successfully boot the system. What exactly happens when you try and boot it will depend on your system's firmware, but usually it will either hang at a black screen, reboot or leave you at the firmware management interface.
This problem occurs because the UEFI boot manager entry for the Fedora installation does not have a leading \ in the path to the boot image. Some UEFI implementations are capable of handling this error, but others are not and will simply fail to boot.
A fix for this issue has already been created. If you are affected by it, you can solve the problem by re-installing using an anaconda updates image which includes the fix for the problem. To do so, boot the installer, hit 'e' at the bootloader menu to edit the default entry, and add the parameter
updates=http://pjones.fedorapeople.org/updates-rhbz856938.img to the end of the linuxefi line and boot by hitting F10. Then complete installation as normal, and the installed system should now boot successfully.
Alternatively, if you are familiar with adjusting UEFI boot manager entries using the
efibootmgr tool you may be able to add the leading \ to the entry yourself.
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.
The system is very slow
Fedora ships a kernel with debugging options enabled during the Alpha release. This allows us to get useful information about various hardware problems, but slows down the system performance substantially. It influences all areas of the system, like CPU performance, HDD performance, graphics rendering performance and others. More information are provided in KernelDebugStrategy, together with a guide how to check whether your kernel has debugging options enabled and how to find and install a non-debug kernel.
Fedora 18 Beta will not include a debug kernel and the performance will raise considerably.
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.