Common F21 bugs

Click here to set up this language box

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.

Pre-release version
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
  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

Fedora 21 Alpha images do not boot from optical media (CD, DVD)

link to this item - Bugzilla: #1141496

Many or all of the Fedora 21 Alpha release images in ISO9660 format (.iso images) do not in fact boot successfully when written to a physical optical medium, i.e. a real DVD or CD. They boot successfully from USB sticks and in virtualization, but multiple testers have now confirmed that when written to an optical medium and booted directly on a physical system, 'ISOLINUX' is briefly displayed and the system then shuts down or reboots.

No workaround for this issue is currently known besides writing the images to a USB stick instead of an optical medium (which is the much superior option if possible, in any case). We do apologize for this rather significant oversight and will certainly ensure it is resolved for Beta and Final releases.

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 https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-21&arch=x86_64 (change 'server' to 'workstation' if desired, and choose the correct arch, and check the "this URL refers to a mirror list" box).

Booting previously installed OS (including Windows) from the Fedora bootloader menu may fail after UEFI installation

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.

Upgrade issues

FedUp to Fedora 21 fails at "A start job is running for udev Kernel Device Manager"

link to this item - Bugzilla: #1099299

Multiple testers have reported that using the FedUp tool to upgrade a system to Fedora 21 Alpha fails after the updated packages have been downloaded and the user has rebooted the system to start the upgrade. When booting into the upgrade environment, boot stops with the message "A start job is running for udev Kernel Device Manager". It times out after 90 seconds, but immediately tries again - it will constantly keep retrying, and never succeed, timing out after 90 seconds each time.

One tester suggests switching to a console and running these commands as a workaround:

systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

However, the consequences of disabling those units during the upgrade may be unpredictable, so we cannot entirely recommend this.

If you encounter the bug, no harm is done to your existing system, and if you reboot, the existing Fedora installation will boot as usual.

Please be aware that upgrading is not a part of the Alpha release criteria or release validation testing plan, and it is quite common for it to be broken before the Beta release. The advice not to run Fedora pre-release, particularly Alphas, on production systems should also be borne in mind. With those disclaimers, you may possibly try upgrading with yum, if you are aware of the risks and have a recovery/fallback plan if this results in your installation becoming unusable.

Boot issues

Default boot menu (grub) entry is not updated with new kernels

link to this item - Bugzilla: #1141414

Fedora 21 Alpha installations currently configure the boot loader (grub) so that after installing a new kernel package, the default choice is not changed to the new kernel. The kernel installed with the system will still be selected by default during next boot, not the new kernel. To fix this issue, you can edit the file /etc/sysconfig/kernel and change the line:

DEFAULTKERNEL=kernel-core

to read:

DEFAULTKERNEL=kernel

and subsequent new kernel packages should become the default when installed. To make a kernel you have already installed the default, you could use the grub2-set-default command, e.g. grub2-set-default 0 to make the first kernel in the list at present the default. For more information about this issue, please read the Bugzilla comments.

Boot fails or applications crash on systems with recent Intel processors (Haswell) particularly with encrypted storage

link to this item - Bugzilla: #1146967

A processor feature called "TSX" (hardware transactional memory, Transactional Synchronization Extensions) was discovered to be faulty in recent Intel processors - so called 'Haswell' parts. This is known by Intel as errata "HSW136".

As a result, Intel issued an update to the "microcode" of affected processors which disables the feature. Fedora duly shipped this update in its microcode_ctl package, which applies microcode updates at boot time. This is Fedora update FEDORA-2014-11178, package version microcode_ctl-2.1-8.fc21. The update has since been withdrawn and never reached stable state, but it would have been installed for users running updates with updates-testing enabled (the default for pre-releases) between 2014-09-24 and 2014-09-26.

Unfortunately, it turns out that some features of Fedora - at least including encrypted storage - both take advantage of the "TSX" feature, and are activated in the boot sequence before the microcode_ctl service. This means that on boot of an affected system with encrypted storage, Fedora notes that TSX support is available and uses it for access to the encrypted storage volumes, only for the microcode_ctl service to subsequently disable the processor feature, which has the effect of preventing access to the encrypted storage.

There may also be other avenues for this issue to manifest itself. In general, it will result in processes failing with SIGILL (illegal instruction).

There is no complete fix or simple workaround for this issue yet available other than not applying the microcode_ctl update if you have not already done so (and taking your chances with the fault in the TSX feature). If you have already installed the microcode_ctl update and encountered this issue, you may be able to boot with an older kernel and at least reach an emergency shell, where you may create a file /etc/modprobe.conf.d/no_microcode.conf with the contents:

blacklist microcode

and then re-generate the initramfs files for all installed kernels (using dracut -f). This will prevent microcode_ctl from activating on boot. Again, the effect of this will be that your system will continue to use the faulty TSX feature, the results of which are beyond our control, but which at least seem to be less catastrophic than the results of microcode_ctl's attempts to disable it.

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.

Graphical package manager does not work, missing PackageKit features

link to this item - Bugzilla: #1098735

Currently apper (default graphical package manager and update tool) does not work because of missing features in new PackageKit backed, old yum backed was removed from latest PackageKit. See bug report for more information on this issue.

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 PackageKit package, which is required for full functionality of KDE's graphical package tool Apper. To resolve this issue, simply install the package with e.g. su -c 'yum install PackageKit', or update the system as usual after installation.

ARM issues

Grubby does not update or add Device tree entry in extlinux.conf on ARM

link to this item - 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 /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.