This page documents common bugs in Fedora 21 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 21 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 21 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 F21_Alpha_release_announcement for specific information about changes in Fedora 21 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. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
- 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
Network install images offer all package groups and default to Cloud Server
link to this item - Bugzilla: #1134524
It is intended that, for Fedora 21, network install images should be tuned to a specific Product by default. That is, the network install image for Fedora Server should offer the package groups intended to form a part of that product, and the network install image for Fedora Workstation should offer the package groups intended to form a part of that product. Access to other package groups will be available by specifying a custom repository URL.
For Fedora 21 Alpha, however, due to some complex implementation issues, we were not able to make this the case. Both Server and Workstation network install images will function as 'universal' images by default, offering all package groups. They do not install from a frozen Alpha package repository; they use the fedora repository which contains the whole set of packages and which is updated with new builds regularly.
As a consequence of this, the default package set for both images is 'Cloud Server'. This is quite simply because it comes alphabetically first in the set of package groups that has the highest priority! You can, of course, choose to install the 'Server' or 'Workstation' package set, or any other, from the Software Selection spoke of the installer.
If you wish to see what a Product-specific network installation will look like, you can enter the Software Sources installer spoke and change the main repository URL to {{{1}}} (change 'server' to 'workstation' if desired, and choose the correct arch, and check the "this URL refers to a mirror list" box).
link to this item - Bugzilla: #986731
If you have an existing UEFI-native operating system and do a UEFI-native install of Fedora alongside it, attempting to boot the previously existing OS from Fedora's bootloader may fail consistently. The reason for this failure is that os-prober currently fails to set the correct boot options for the previously existing OS in the GRUB menu.
You may be able to use your system firmware's interface to the UEFI boot manager to boot the previously existing OS directly. This boot menu is often accessible at reboot time by interrupting the boot process and choosing to boot from a different device, but implementations vary between firmwares. The Windows boot option is often named Windows Boot Manager.
Alternatively, you can use the efibootmgr command from Fedora to direct the system to boot a particular UEFI boot manager entry on the next reboot. efibootmgr should list all the UEFI boot manager entries. Identify the one for Windows, and run su -c 'efibootmgr -n XXXX', where XXXX is the (hexadecimal) number that follows the word Boot in the efibootmgr output for that entry. For instance, if efibootmgr showed:
[user@host ~]# efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0002 Boot0000* Fedora Boot0002* Windows Boot Manager
then you could run su -c 'efibootmgr -n 0002' to instruct the system to boot Windows on the next startup.
You may also be able to manually edit the Fedora bootloader (GRUB) configuration to supply the parameters required to boot the previously existing OS from the Fedora boot menu.
KDE issues
Display sometimes does not update in KDE
link to this item - Bugzilla: #1142862
Some testers have reported an issue where the KDE desktop appears to freeze. However, it is only the display that is frozen; mouse clicks, keypresses and so on will take effect, and the display may unfreeze some time later. This issue has most often been seen during Fedora installation from the KDE live image, but some testers have reported seeing it in normal KDE use as well.
No reliable workaround is yet known for this bug besides working blind or waiting for the issue to resolve itself, although it may help to disable desktop effects with Alt+Shift+F12.
Grubby does not update or add Device tree entry in extlinux.conf on ARM
Bugzilla: #1088933 Support for Device Tree in Grubby has not yet been added. For Fedora 21 Alpha disk image users will need to manually update the extlinux.conf (/boot/extlinux/extlinux.conf) with the correct kernel version after a new kernel has been installed. By default it will use the kernel version included in the Alpha release, once that kernel is removed the system will no longer boot. Anaconda installations will lack the 'fdtdir' entry and it will need to be manually added or the system will not boot. Recommended work around for Anaconda installations is with the use of a kickstart where the 'fdtdir' can be added in post.
PackageKit not included in default KDE installation
link to this item - Bugzilla: #1003122
Due to a packaging error, default KDE installations of Fedora 21 Alpha do not include the 
PackageKitsu -c 'yum install PackageKit', or update the system as usual after installation.