From Fedora Project Wiki

m (add category)
 
(86 intermediate revisions by 15 users not shown)
Line 1: Line 1:
<!--  
<!-- The section headers are part of a template, which seems to mess with MW's mind when you try to edit a section, so disable the edit section links. -->
This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_prerelease]] at the time of page creation: <nowiki>{{subst:Common_bugs_header_prerelease}}</nowiki>. Please do this rather than copy/pasting. At the time a release goes stable, replace this entire header with a '''SUBSTITUTION''' of [[Template:Common_bugs_header_stable_release]]: <nowiki>{{subst:Common_bugs_header_stable_release}}</nowiki>.
__NOEDITSECTION__


*** INSTRUCTIONS ON ADDING ENTRIES TO THIS PAGE. FOLLOW THIS FORMAT FOR ALL ENTRIES PLEASE. ***
<!--
This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_stable_release]] at the time the release goes stable: <nowiki>{{subst:Common_bugs_header_stable_release}}</nowiki>. This should replace the entire pre-release header text. Please do this rather than copy/pasting. If you are making improvements to the header text, please make them also in the [[Template:Common_bugs_header_stable_release]], [[Template:Common_bugs_header_prerelease]] and [[Template:Common_bugs_header_shared]] templates as appropriate, so future pages will contain the same improvements.
-->
{{autolang|base=yes}}
 
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, ''please 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 [[F21_release_announcement|Fedora 21 release announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/21/html/Release_Notes/ Fedora 21 release notes] for specific information about changes in Fedora 21 and other general information.
 
{{Common_bugs_header_shared}}
 
== Installation issues ==
{{Common bugs issue|bootloader-target-disk|Cannot place bootloader target partition (e.g. {{filename|/boot/efi}}) on a disk other than the first in custom partitioning|1168118}}
 
You may encounter this bug when doing custom partitioning with more than one disk, and installing on a system whose firmware requires a partition as the location for the bootloader stage1 - e.g. {{filename|/boot/efi}} for UEFI systems, {{filename|/boot/uboot}} for some ARM systems, or a PReP boot partition for PowerPC systems.


{{Anchor|Issue-Foo}}
If you attempt to create the partition on a disk other than the first (which will be the disk shown furthest to the left on the disk selection screen), the installer may complain that a valid bootloader partition has not been created.
=== Issue Foo (example) ===
<small>[[#Issue-Foo|link to this item]] - [[rhbug:XXXXXX|Bugzilla: #XXXXXXX]]</small>


Words words words. Blah blah blah. Include a good explanation of the problem, and any available workarounds.
A simple way to work around this is to place the boot partition on the first disk, if this is not inconvenient or impossible for your desired layout.


When adding issues to this page, ensure to add the CommonBugs keyword to the bug report, and add the anchor link to the entry on this page in the Whiteboard field on the bug report.
If you do want or need the boot partition to be on a later disk, you can work around the error. To do this, configure the desired layout, and complete custom partitioning despite the error message (by clicking ''Done'' twice). Go back into the ''Installation Destination'' screen, and click ''Full disk summary and bootloader...''. Select the disk on which you placed the boot partition, and click ''Set as Boot Device''. Click ''Close'', then click ''Done'', and click ''Done'' again on the custom partitioning screen without changing anything. This should clear the error condition and cause the installer to be happy with the boot partition being on the chosen disk.


If a build which may fix the problem is made available via updates-testing, add this text to the description (appropriately customized for the issue):
Note that selecting the desired 'boot disk' before entering custom partitioning and creating your layout will not work (though it ought to - the fact that it does not is a related bug). You must use this slightly more unusual workaround instead. We do apologize for the inconvenience.


An updated [http://admin.fedoraproject.org/updates/(name)-(EVR) (name)] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [http://admin.fedoraproject.org/updates/(name)-EVR report to Bodhi] whether it solves the problem. To test the update, run this command:
An [[Anaconda/Updates|installer updates image]] which fixes this bug is also available at https://adamwill.fedorapeople.org/updates/updates-1168118.img .
<pre>su -c 'yum --enablerepo=updates-testing update (name)'</pre>


If a scratch build which may fix the problem is made available via Koji (rather than in updates-testing), add this boilerplate paragraph (appropriately customized for the issue):
{{Common bugs issue|chromebook-boot-fail|Fedora 21 images do not boot on Chromebook systems|1135793}}


A test build that should resolve this problem is available from Koji: [http://koji.fedoraproject.org/koji/taskinfo?taskID=XXXXXXX packagename-EVR]. If you are affected by this issue, please test this update and report your results to the [[rhbug:XXXXXX|bug report]].
Several people have reported that they cannot boot Fedora 21 images on various Chromebook systems. At present our best theory is that this is an issue affecting the firmware code used to allow boot of other operating systems on Chromebook hardware. No solution or workaround has yet been found, but it has been reported that Fedora 20 images boot successfully, and it is possible to install Fedora 20 and [[Upgrading|upgrade to Fedora 21]], and the upgraded system will boot successfully.


If the page is in pre-release state and a documented problem has been fixed in Branched repos but no newer pre-release has yet come out, add this boilerplate paragraph (appropriately customized for the issue):
{{Common bugs issue|anaconda-initramfs-regeneration|All initramfs files in shared {{filename|/boot}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> re-generated during install|1074358}}


This issue was fixed in the updated ''(name)-(EVR)'' package. To solve the issue, update your (pre-release name, e.g. "{{<includeonly>safesubst:</includeonly>FedoraVersion|long|next}} Beta") installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|(name)}}.
If you use a {{filename|/boot}} partition shared with another installation of Fedora or any other Linux distribution, the Fedora 21 installation process will likely attempt to re-generate all the initramfs files present on the partition. In some cases, the re-generated initramfs files may not work correctly.


When the page is in pre-release state and a new pre-release becomes available, simply remove any issues that are now fixed from the page entirely.
Due to the issue we would strongly advise against the use of shared {{filename|/boot}} partitions with Fedora 21. If you do wish to use one, we would recommend you back up all its contents before installing Fedora 21, so that you can recover from any issues caused by the installation process.
-->
 
{{autolang|base=yes}}
{{Common bugs issue|anaconda-part-multi|Various issues caused by multiple trips through ''Installation Destination'' (partitions re-ordered on ''Reclaim Space'' screen, crash during install)|1158975|1166598}}
 
Some circumstances have been discovered in Fedora 21 testing where multiple trips through the ''Installation Destination'' installer spoke can cause problems. One known case involves various scenarios where you select different sets of disks as install targets on multiple trips, and visit the ''Reclaim space'' screen each time. Sometimes, when doing this, partitions will be displayed in a different order on the ''Reclaim space'' screen. In some particular circumstances, the attributes of different partitions - their numbers and sizes - may be confused. In this case, we would recommend rebooting and restarting the installation process to avoid any possibility of inadvertently deleting or resizing the wrong partition.
 
[[rhbug:1158975|Bug #1158975]] reports two or three cases where multiple trips through ''Installation Destination'' and ''Reclaim space'' resulted in the installation process crashing during the partitioning phase.
 
In general we would recommend you try to avoid too many trips through the ''Installation Destination'' spoke. If you do run into either problem, retrying the installation without multiple trips through the spoke should result in a successful installation.
 
The installer development team is investigating various possible approaches to reducing the likelihood of the installer being confused by complex cases such as this for future releases.
 
{{Common bugs issue|anaconda-ext-fsck|Installer pauses for a long time shortly after starting up with existing ext storage volumes|1170803}}
 
There is an issue in the Fedora 21 installer which causes it to unnecessarily run a full filesystem consistency check (fsck) on all ext (ext2, ext3, ext4) storage volumes present on the system (it does this in the belief it's required before their minimum size for resizing purposes can be determined). Depending on the size and number of ext volumes, this can take some time, and there is no indication in the installer interface of what is happening while the checks are being run.
 
If the installer seems to be hung or frozen, and you have ext storage volumes - especially many, or large ones - this is likely the cause. The checks will eventually complete and the installer will continue to function as normal, so just be patient and wait for things to clear. We do apologize for the inconvenience.
 
This issue will be resolved in the next Fedora release.
 
{{Common bugs update released|FEDORA-2015-2511|noupdate}}
 
{{Common bugs issue|custom-part-german|Custom partitioning screen resizes and becomes unusable during German install at lower resolutions (possibly other languages)|1170275}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
{{Common bugs update anaconda|https://dshea.fedorapeople.org/1170275.img}}
 
This issue is most commonly encountered with German, but may affect other languages too. It's related to the lengths of text strings and the resolution of the screen. With longer text strings and lower resolutions, a bug can occur which causes the screen to resize and become more or less unusable. German is particularly affected due to its use of long words and sentences.
 
The best way to avoid this issue is to use the updates image above. If for any reason you cannot, the only known ways to deal with this issue are to avoid using custom partitioning (perhaps using a kickstart instead), use a different language (English, for instance, if you can speak it), or use a higher-resolution display if possible (if you are using virtualization, look into how you can configure your virtual machine to use a higher resolution 'display'; the higher the horizontal resolution, the less likely this issue is to occur). We do apologize for the inconvenience.
 
{{Common bugs issue|grub-secure-boot|Cannot boot other operating systems from Fedora boot menu with Secure Boot enabled|1170245}}
 
If you have Secure Boot enabled (remember: [[Unified_Extensible_Firmware_Interface|UEFI]] and [[Unified_Extensible_Firmware_Interface#Will_Secure_Boot_eat_my_babies.3F|Secure Boot]] are not the same thing), and you install Fedora 21 alongside other operating systems, you will probably find that the other operating systems will not boot from the Fedora boot menu, even if it adds entries for them.
 
You ''should'' be able to boot the other operating systems successfully from the system firmware interface. Firmware interfaces vary widely between systems, so we cannot provide precise instructions on how exactly to choose and boot another operating system on your particular computer. Please refer to your system firmware's documentation for instructions.
 
If your system's firmware does not make it easy or even possible to select a different operating system, you can use the {{command|efibootmgr}} command from Fedora to instruct the system which OS to boot on the next startup. Running {{command|efibootmgr}} alone will list the available boot choices on your system. Each has a number, shown in this output at the start of the line, like {{code|Boot0001}}: in that case, the number is {{code|0001}}. Note these numbers are in hex, so you may see e.g. {{code|Boot000A}}. To tell the system to boot a specific entry the next time it starts up, you can run {{command|efibootmgr -n (number)}}, e.g. {{command|efibootmgr -n 0001}} to boot the {{code|Boot0001}} entry.
 
It is unlikely that we will be able to fix this issue in Fedora 21, but it may be fixed in future releases.
 
{{Common bugs issue|custom-escape-done|Cannot leave custom partitioning screen by clicking ''Done''|1167014}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
In some unusual situations, you may find that you seem to be unable to leave the installer's custom partitioning screen by clicking the ''Done'' button. If you find yourself in this situation, clicking the ''Update settings'' button on the right hand side of the screen should resolve the issue, allowing you to leave the next time you click ''Done''.
 
This bug happens when the ''Done'' button does not refresh the screen's state in the same way as the ''Update settings'' button does (which it is intended to do), and then the installer refuses to leave the screen because the state is not consistent.
 
{{Common bugs issue|kickstart-groups-gui|In a GUI kickstart install which lists both environment groups and regular groups, regular groups are not installed|1173350}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
If you use a kickstart whose %packages sections lists both an environment group:
@^some-environment-group
and one or more package groups:
@group1
@group2
and run a GUI install, the regular groups will not be installed. The environment group will be installed. Kickstarts that list only package groups (not environment groups) are not affected by this bug.
 
To work around this bug, run the installation in text mode rather than GUI mode: add {{command|text}} to the kernel parameters. The bug is in the installer's GUI code, and the TUI code does not have the same bug.
 
{{Common bugs issue|os-prober-vista|Windows 7 mis-identified as Windows Vista in boot menu|1172405}}
 
Due to a bug in the {{command|os-prober}} utility used to discover other operating systems, if you install Fedora 21 to a system which contains a Windows 7 installation, it may be misidentified as "Windows Vista" in the boot menu produced by the Fedora install. This is a cosmetic bug only, and the entry should boot Windows just fine (unless Secure Boot is enabled, as mentioned [[#grub-secure-boot|above]]). The issue may affect other Windows versions too. You can safely manually edit the bootloader configuration file to correct this issue, if you would like to.
 
{{Common bugs update released|FEDORA-2014-17566|noupdate}}
 
{{Common bugs issue|netinst-universal|Network install image offers all package groups|1134524}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
This is no longer considered a bug, exactly, but remains documented here for clarity. Initial Fedora 21 plans envisaged Server and Workstation releases each having their own network install images which, by default, would offer only the package groups relevant to that Flavor. However, it became clear that this design was difficult to implement and not really particularly desired by anyone.


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.
For Fedora 21 Final, there will be a single designated network install image, built from the [[Server]] tree, which defaults to the Fedora Server package set but allows installation of all package groups. In practical terms it is little different from the network install image shipped with Fedora 20 and earlier except that it defaults to the Server package group rather than the GNOME desktop, and has Server visual branding.
Despite this branding, in practice it is a universal network install image allowing deployment of all Fedora package sets. It can be used for doing network installs of the [[Workstation]] flavor in cases where this is preferable to installing from the live image (e.g. mass deployments).


{{admon/note|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).}}
{{Common bugs issue|i686-server-branding|32-bit Server DVD and network install images use generic installer artwork|1170582}}


== Release Notes ==
The 32-bit Server DVD and network install images use the generic installer artwork (down the side or across the top of the various screens) which simply uses the Fedora logo, rather than the Server flavor logo seen on the 64-bit versions of the same media. This is an entirely cosmetic issue, and the images are clearly identified as Server in various text labels.
Read the [[F21_Alpha_release_announcement]] <!--and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/{{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}}/html/Release_Notes/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} release notes]--> for specific information about changes in Fedora 21 and other general information.


{{Common_bugs_header_shared}}
== Upgrade issues ==
{{Common bugs issue|fedup-product-firewall|Firewall configuration overwritten on upgrade to Server or Workstation|1172862}}


== Installation issues ==
If you pass {{command|--product server}} or {{command|--product workstation}} to {{command|fedup}} when upgrading, the {{package|firewalld-config-server}} or {{package|firewalld-config-workstation}} package will be installed. These contain the default firewall configurations for those Flavors. Unfortunately, these default configurations will replace - rather than merging with - your existing configuration, including any changes you have made to the defaults.


{{Anchor|netinst-universal}}
The Cloud flavor and "nonproduct" use the {{package|firewalld-config-standard}} package, which specifies no actual ports or services, and so existing configurations aren't replaced when fedup is run with {{command|--product nonproduct}} or {{command|--product cloud}}.
=== Network install images offer all package groups and default to Cloud Server ===
<small>[[#netinst-universal|link to this item]] - [[rhbug:1134524|Bugzilla: #1134524]]</small>


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 [[Server|Fedora Server]] should offer the package groups intended to form a part of that product, and the network install image for [[Workstation|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.
If you do want your upgraded system to be Fedora Workstation or Fedora Server, but you wish to maintain your firewall configuration modifications, you should note your existing configuration before the upgrade, and re-apply it with {{command|firewall-cmd}} or {{command|firewall-config}} after the upgrade process. We apologize for the inconvenience, and if possible we will release an update to resolve this issue for future upgrades.


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.
{{Common bugs issue|fedup-freeipa|FreeIPA configuration upgrade required after fedup}}


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 upgrade a system running as a FreeIPA server to Fedora 21 using fedup, FreeIPA will not be able to entirely complete its configuration updates during the upgrade process. As explained in [http://www.freeipa.org/page/Releases/4.1.1 the FreeIPA release notes], you must run {{command|su -c 'ipa-ldap-updater --upgrade'}} followed by {{command|su -c 'ipa-upgradeconfig'}} after booting the upgraded system. Until you complete the update in this way, various elements of FreeIPA will not work correctly (including the web interface), and there will be error messages in the system logs.


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 {{filename|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).
{{Common bugs issue|fedup-journald|Fedup copies the whole journal during upgrade|1161366}}


{{Anchor|uefi-windows-dual}}
After the upgrade is finished, fedup appends a copy of the whole journal to <tt>/sysroot/var/log/upgrade.log</tt>, instead of limiting that to just the current boot during which upgrade was run. This step will be slow on systems which have a large number of existing journal files. If you have a rotational drive, are low on disk space, and don't care about old logs, you might want to consider removing old journal files with
=== Booting previously installed OS (including Windows) from the Fedora bootloader menu may fail after UEFI installation ===
<small>[[#uefi-windows-dual|link to this item]] - [[rhbug:986731|Bugzilla: #986731]]</small>


If you have an existing [[Unified_Extensible_Firmware_Interface|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.
{{command|su -c bash -c 'rm -v /var/log/journal/*/*@*.journal*'}}


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''.
== GNOME issues ==
{{Common bugs issue|gis-keyboard-crash|GNOME Initial Setup crashes if no keyboard is selected|1154171}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


Alternatively, you can use the {{command|efibootmgr}} command from Fedora to direct the system to boot a particular UEFI boot manager entry on the next reboot. {{command|efibootmgr}} should list all the UEFI boot manager entries. Identify the one for Windows, and run {{command|su -c 'efibootmgr -n XXXX'}}, where ''XXXX'' is the (hexadecimal) number that follows the word ''Boot'' in the {{command|efibootmgr}} output for that entry. For instance, if {{command|efibootmgr}} showed:
On first use of a Fedora 21 Workstation system (or other Fedora 21 installation with the GNOME desktop), an 'initial setup' process is run (the same as described in the previous issue). One of the early stages asks you to pick a keyboard layout. Depending on your earlier choice of language and location, it is possible that no layout will be pre-selected on the initial list of layout choices. If no layout is selected, and you do not select one but simply click Next, the initial setup tool will crash.
<pre>
[user@host ~]# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* Fedora
Boot0002* Windows Boot Manager
</pre>
then you could run {{command|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.
The workaround for this issue is to make sure you select a keyboard layout. If none of the layouts is the one you want, clicking the '...' choice at the bottom of the list will cause the full list of layouts to be provided.


== KDE issues ==
== KDE issues ==
{{Common bugs issue|kde-default-failsafe|Default KDE session after installation or on re-login to live session is failsafe|1164783}}
{{Common_bugs_update_released|FEDORA-2014-16304}}
Due to an issue with how the sddm session manager orders desktop sessions, the failsafe session - "KDE Plasma (failsafe)" - will be the default session for interactive logins. This means that after installing Fedora 21 KDE but before installing the update, or if you log out from a live session and log in again through the login screen, the default session choice will be the failsafe session. However, the session used on initial boot of the live image is not affected.
To work around this issue, simply select the "KDE Plasma Workspace" session instead of "KDE Plasma (failsafe)" when you log in to KDE. You should only need to make this choice once for each user account - when you select a session, that session is stored as that user's default choice, so subsequent logins with that user will use the same session until you choose another.
{{Common bugs issue|widget-drag-crash|Crash when adding new widget to panel via drag-and-drop|1170535}}
You may encounter a crash in the Plasma Desktop Shell while adding a widget to the panel. If you open the 'Add widgets...' panel pop-up and try to drag a new widget from it to the panel, if you cross the button for a running application in the task manager widget while dragging, the crash will be triggered. The shell will respawn automatically and the session will continue to work correctly.
To work around this issue simply be careful not to cross the task manager area of the panel when dragging. The Fedora KDE team will work to come up with a fix for this issue as soon as possible.
{{Common bugs issue|kde-apper|Graphical package manager missing some PackageKit features|1098735}}
In Fedora 21 Beta, {{package|apper}} (KDE's default graphical package manager and update tool) is missing some features, due to the replacement of the backend it previously used. Notably the ability to search within package groups is missing.
A source code fix has been submitted to the PackageKit project. As a result, updated {{package|PackageKit}} packages resolving this issue should become available for testing shortly.
== Network issues ==
{{Common bugs issue|dhcp-identifier-fail|IP address discovery via DHCP does not work|1154200}}
Several users have reported that Fedora 21 does not successfully discover an IP address via DHCP on their systems. An investigation of this issue has indicated that badly-behaving routers are the source of the problem, but some commonly-used router hardware and software appear to have the problematic behaviour by default. This at least appears to affect systems connected to Cisco RV320 routers, and possibly Windows Server systems acting as network routers. The issue may be more likely to occur in cases where the router is configured to assign specific IP addresses to specific systems based on their MAC addresses.
To work around the issue, create a file {{filename|/etc/dhcp/dhclient.conf}} with the contents:
send dhcp-client-identifier = hardware;
or add that line to the file, if it already exists, and then try establishing the network connection again.
Both upstream and downstream engineers agree that dhclient's behavior here is correct according to the relevant [http://www.ietf.org/rfc/rfc4361.txt RFC 4361], and that the only way to 'fix this bug' would be to break RFC compliance, and therefore they do not believe it is the right thing to do. If one end of a connection is spec compliant and the other is not, and the compliant end cannot handle the other end's non-compliance without becoming non-compliant itself, it is the non-compliant end that should change its behaviour. Fedora will attempt to notify router hardware/software vendors whose products suffer from this issue on behalf of our users.
== Hardware issues ==
{{Common bugs issue|lenovo-nvidia-hang|Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W530)|752613}}
This issue has been present [[Common_F19_bugs#lenovo-nvidia-hang|since at least Fedora 19]].
Multiple testers have reported that various Thinkpad models - including at least the W530, and likely the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 19, 20, or 21 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 [http://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io VT-d advanced virtualization feature], the [https://en.wikipedia.org/wiki/X2APIC 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.
== ARM issues ==
== Fedora Server issues ==
{{Common bugs issue|rolekit-entropy|Rolekit fails to deploy a Domain Controller on a VM, returning error 256}}
Creation of a Domain Controller role requires the system to have a sufficient amount of entropy available to securely create the keys for the included certificate authority and Kerberos key distribution center. It is very common when deploying on a virtual machine that has just been created that there will not be sufficient entropy available, which will result in the Domain Controller deployment timing out waiting on <code>/dev/random</code> and then failing with error code 256.
On VM hosts that support it (such as KVM on Fedora 20 and 21), it is recommended to create the VM using the virt-RNG device (which the Fedora Server 21 guest will automatically detect). This will allow it to collect entropy from the host machine and should reduce the likelihood of encountering this issue. As a workaround (if you do not have a host capable of providing entropy), you can also run {{command|su -c '/usr/sbin/rngd -r /dev/urandom'}} to make the system use the <b>less-secure</b> /dev/urandom entropy device.
{{Common bugs issue|ipa-start-race|FreeIPA startup fails due to timing issues|1071356}}
This bug appears to occur only occasionally. Sometimes, startup of a FreeIPA server - {{filename|ipa.service}} - may fail, apparently due to some kind of race / timing issue between it, {{filename|named.service}} and {{filename|dirsrv.target}}. It does appear to happen only rarely, and when it happens, just starting {{filename|ipa.service}} again should succeed.
== Other issues ==
{{Common bugs issue|environment-product-conflicts|Installation of 'environment groups' fails due to conflicts between fedora-release packages|1160917}}
Due to some limitations in how Fedora's package group mechanism works and some changes made to support the introduction of "Flavors" in Fedora 21, you may often encounter conflicts when trying to install the 'environment groups' seen in {{command|yum grouplist}} after installing Fedora 21. If you install a Fedora Flavor - Workstation, Cloud, or Server - it is likely that attempting to install any other 'environment group' will fail. If you use a non-Flavor install - for instance, install from a desktop live image - it is likely that you will be able to successfully install other non-Flavor environment groups, but not the environment groups associated with each Flavor.
The most common case in which you're likely to encounter this is trying to add extra desktops to a Workstation or other desktop installation. If you install Workstation and then want to add any other desktop, or install another desktop and then want to add GNOME and decide to try and use the 'Workstation' group, you will likely run into this problem.
Fortunately there is a fairly simple workaround for this problem: use the command {{command|yum groupinstall (group) --exclude fedora-release\*}}, e.g. {{command|yum groupinstall kde-desktop-environment --exclude fedora-release\*}}. Note that '''you must use exactly''' {{command|yum groupinstall}}. {{command|yum group install}} will not work.
It may not be possible to resolve this fully for Fedora 21. The bug report contains the detailed explanation of the problem, and solutions for it will likely be discussed there, if you wish to keep up to date.
== Resolved issues ==
{{Common bugs issue|rendering-assamese-bengali|Rendering problems of Assamese and Bengali language content|1170135}}
{{Common bugs update released|FEDORA-2014-16196}}
A rendering issue was found in Lohit Assamese and Bengali last upstream release 2.91.0. Due to this issue conjucts break if followed by any Bengali matra. Unfortunately this got detected during the final phase of Fedora 21 release, and had to be fixed with an update.
Anyone creating or viewing Assamese or Bengali language content in Fedora would have encountered this issue.
{{Common bugs issue|libhif-packagekit-broken|Offline update does not work (and other issues in PackageKit-based software managers)|1181501|1183010}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
{{admon/tip|Fix released, but special procedure may be needed to update|[https://admin.fedoraproject.org/updates/FEDORA-2015-0921/PackageKit-1.0.4-1.fc21,libhif-0.1.8-1.fc21 An update has been released to fix this problem]. After you update your system, and possibly reboot, you should no longer be affected by it.
However, as the bug itself affects the update mechanism, you may need to apply the update in a different way than usual. The 'offline update' mechanism is the default for the Fedora Workstation flavor, and may be broken by this issue.
If you are affected by this issue and cannot update to the fixed package in the usual way, you can install it using the command-line {{command|yum}} tool. Run {{command|<nowiki>su -c 'yum update --advisory=FEDORA-2015-0921'</nowiki>}} (if you have set a root password) or {{command|<nowiki>sudo yum update --advisory=FEDORA-2015-0921</nowiki>}} (if you are a user with administrative privileges) to install the update.
If you continue to encounter issues which seem to meet this description after installing the update, try running {{command|pkcon repair}} and rebooting the system.}}
Version 0.1.7 of the {{package|libhif}} library, used by PackageKit, passed initial testing and was released as an update for Fedora 21. Unfortunately, it later transpired that it had several bugs which can cause multiple issues. In particular, it could often cause offline updates to fail. Offline updates are the standard update system for Fedora Workstation, where a notification of available updates appears and asks you to reboot the system to install them. After libhif 0.1.7 has been installed, you may find that any attempt to do an offline update results in failure (as reported by a notification).
Further testing identified some other issues which could cause other package management operations, like installing or removing packages, using PackageKit-based applications - e.g. GNOME Software, Apper, and {{command|pkcon}} - to fail and/or crash.
We do apologize for inconvenience caused by this broken update.
{{Common bugs issue|fedup-repo-keys|Downloading failed: Didn't install any keys|1066044}}
If you have enabled any third party repositories that are not included with the default installation of Fedora, you may run into this issue. If you did not import the GPG key for a particular repository after you installed it, fedup will fail because it does not have the necessary keys imported.
A quick and easy way to fix this is to just reinstall the repository package. You can use the command {{command|su -c 'yum reinstall packagename'}} to reinstall the package. When it prompts you to import the key, press y, and afterwards, try running the fedup tool again.
{{Common bugs update released|FEDORA-2015-6520}}


{{Anchor|kde-display-update}}
{{Common bugs update released|FEDORA-2015-6555}}
=== Display sometimes does not update in KDE ===
<small>[[#kde-display-update|link to this item]] - [[rhbug:1142862|Bugzilla: #1142862]]</small>


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.
{{Common bugs issue|eclipse-crash-bluejeans|Eclipse crashes when the proprietary Bluejeans browser plug-in is installed|1160411}}


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.
Since the release of bluejeans plugin 2.90.616.8, this should no longer be a problem.


{{Anchor|kde-qt-packagekit}}
This issue occurs only when the Bluejeans proprietary browser plug-in is installed.


=== PackageKit not included in default KDE installation ===
Eclipse may crash when using hover-help, or when a Javadoc pop-up is about to be shown, or when using Eclipse's built-in web-browser view. This is due to the Bluejean plug-in crashing when any part of Eclipse uses the GTK Webkit widget.
<small>[[#kde-qt-packagekit|link to this item]] - [[rhbug:1003122|Bugzilla: #1003122]]</small>


Due to a packaging error, default KDE installations of Fedora 21 Alpha do not include the {{package|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. {{command|su -c 'yum install PackageKit'}}, or update the system as usual after installation.
The recommended workaround is to make Eclipse use the experimental Webkit2 support, which runs browser plug-ins out-of-process so that a crash inside Bluejeans will not cause Eclipse to exit. To enable this workaround, you must edit your {{command|/etc/eclipse.ini}} file and change the '''--launcher.GTK_version''' option from '''2''' to '''3''' and then launch Eclipse with the following command:
  SWT_WEBKIT2=1 eclipse


=== Grubby does not update or add Device tree entry in extlinux.conf on ARM ===
[[Category:Common bugs]]
<small>[[rhbug:1088933|Bugzilla: #1088933]]</small>
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.

Latest revision as of 23:58, 14 March 2018


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, please 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 Fedora 21 release announcement and the Fedora 21 release notes 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

Cannot place bootloader target partition (e.g. /boot/efi) on a disk other than the first in custom partitioning

link to this item - Bugzilla: #1168118

You may encounter this bug when doing custom partitioning with more than one disk, and installing on a system whose firmware requires a partition as the location for the bootloader stage1 - e.g. /boot/efi for UEFI systems, /boot/uboot for some ARM systems, or a PReP boot partition for PowerPC systems.

If you attempt to create the partition on a disk other than the first (which will be the disk shown furthest to the left on the disk selection screen), the installer may complain that a valid bootloader partition has not been created.

A simple way to work around this is to place the boot partition on the first disk, if this is not inconvenient or impossible for your desired layout.

If you do want or need the boot partition to be on a later disk, you can work around the error. To do this, configure the desired layout, and complete custom partitioning despite the error message (by clicking Done twice). Go back into the Installation Destination screen, and click Full disk summary and bootloader.... Select the disk on which you placed the boot partition, and click Set as Boot Device. Click Close, then click Done, and click Done again on the custom partitioning screen without changing anything. This should clear the error condition and cause the installer to be happy with the boot partition being on the chosen disk.

Note that selecting the desired 'boot disk' before entering custom partitioning and creating your layout will not work (though it ought to - the fact that it does not is a related bug). You must use this slightly more unusual workaround instead. We do apologize for the inconvenience.

An installer updates image which fixes this bug is also available at https://adamwill.fedorapeople.org/updates/updates-1168118.img .

Fedora 21 images do not boot on Chromebook systems

link to this item - Bugzilla: #1135793

Several people have reported that they cannot boot Fedora 21 images on various Chromebook systems. At present our best theory is that this is an issue affecting the firmware code used to allow boot of other operating systems on Chromebook hardware. No solution or workaround has yet been found, but it has been reported that Fedora 20 images boot successfully, and it is possible to install Fedora 20 and upgrade to Fedora 21, and the upgraded system will boot successfully.

All initramfs files in shared /boot re-generated during install

link to this item - Bugzilla: #1074358

If you use a /boot partition shared with another installation of Fedora or any other Linux distribution, the Fedora 21 installation process will likely attempt to re-generate all the initramfs files present on the partition. In some cases, the re-generated initramfs files may not work correctly.

Due to the issue we would strongly advise against the use of shared /boot partitions with Fedora 21. If you do wish to use one, we would recommend you back up all its contents before installing Fedora 21, so that you can recover from any issues caused by the installation process.

Various issues caused by multiple trips through Installation Destination (partitions re-ordered on Reclaim Space screen, crash during install)

link to this item - Bugzilla: #1158975 - Bugzilla: #1166598

Some circumstances have been discovered in Fedora 21 testing where multiple trips through the Installation Destination installer spoke can cause problems. One known case involves various scenarios where you select different sets of disks as install targets on multiple trips, and visit the Reclaim space screen each time. Sometimes, when doing this, partitions will be displayed in a different order on the Reclaim space screen. In some particular circumstances, the attributes of different partitions - their numbers and sizes - may be confused. In this case, we would recommend rebooting and restarting the installation process to avoid any possibility of inadvertently deleting or resizing the wrong partition.

Bug #1158975 reports two or three cases where multiple trips through Installation Destination and Reclaim space resulted in the installation process crashing during the partitioning phase.

In general we would recommend you try to avoid too many trips through the Installation Destination spoke. If you do run into either problem, retrying the installation without multiple trips through the spoke should result in a successful installation.

The installer development team is investigating various possible approaches to reducing the likelihood of the installer being confused by complex cases such as this for future releases.

Installer pauses for a long time shortly after starting up with existing ext storage volumes

link to this item - Bugzilla: #1170803

There is an issue in the Fedora 21 installer which causes it to unnecessarily run a full filesystem consistency check (fsck) on all ext (ext2, ext3, ext4) storage volumes present on the system (it does this in the belief it's required before their minimum size for resizing purposes can be determined). Depending on the size and number of ext volumes, this can take some time, and there is no indication in the installer interface of what is happening while the checks are being run.

If the installer seems to be hung or frozen, and you have ext storage volumes - especially many, or large ones - this is likely the cause. The checks will eventually complete and the installer will continue to function as normal, so just be patient and wait for things to clear. We do apologize for the inconvenience.

This issue will be resolved in the next Fedora release.

Fix released
An update has been released to address this problem. However, as this issue manifests before the system can be updated, you may still have to work around it as described here.

Custom partitioning screen resizes and becomes unusable during German install at lower resolutions (possibly other languages)

link to this item - Bugzilla: #1170275

Updates image available
An installer update image has been made available which resolves this issue. To use it, hit e or Tab on the installer boot menu to edit the boot options, and add the following: inst.updates=https://dshea.fedorapeople.org/1170275.img

This issue is most commonly encountered with German, but may affect other languages too. It's related to the lengths of text strings and the resolution of the screen. With longer text strings and lower resolutions, a bug can occur which causes the screen to resize and become more or less unusable. German is particularly affected due to its use of long words and sentences.

The best way to avoid this issue is to use the updates image above. If for any reason you cannot, the only known ways to deal with this issue are to avoid using custom partitioning (perhaps using a kickstart instead), use a different language (English, for instance, if you can speak it), or use a higher-resolution display if possible (if you are using virtualization, look into how you can configure your virtual machine to use a higher resolution 'display'; the higher the horizontal resolution, the less likely this issue is to occur). We do apologize for the inconvenience.

Cannot boot other operating systems from Fedora boot menu with Secure Boot enabled

link to this item - Bugzilla: #1170245

If you have Secure Boot enabled (remember: UEFI and Secure Boot are not the same thing), and you install Fedora 21 alongside other operating systems, you will probably find that the other operating systems will not boot from the Fedora boot menu, even if it adds entries for them.

You should be able to boot the other operating systems successfully from the system firmware interface. Firmware interfaces vary widely between systems, so we cannot provide precise instructions on how exactly to choose and boot another operating system on your particular computer. Please refer to your system firmware's documentation for instructions.

If your system's firmware does not make it easy or even possible to select a different operating system, you can use the efibootmgr command from Fedora to instruct the system which OS to boot on the next startup. Running efibootmgr alone will list the available boot choices on your system. Each has a number, shown in this output at the start of the line, like Boot0001: in that case, the number is 0001. Note these numbers are in hex, so you may see e.g. Boot000A. To tell the system to boot a specific entry the next time it starts up, you can run efibootmgr -n (number), e.g. efibootmgr -n 0001 to boot the Boot0001 entry.

It is unlikely that we will be able to fix this issue in Fedora 21, but it may be fixed in future releases.

Cannot leave custom partitioning screen by clicking Done

link to this item - Bugzilla: #1167014

In some unusual situations, you may find that you seem to be unable to leave the installer's custom partitioning screen by clicking the Done button. If you find yourself in this situation, clicking the Update settings button on the right hand side of the screen should resolve the issue, allowing you to leave the next time you click Done.

This bug happens when the Done button does not refresh the screen's state in the same way as the Update settings button does (which it is intended to do), and then the installer refuses to leave the screen because the state is not consistent.

In a GUI kickstart install which lists both environment groups and regular groups, regular groups are not installed

link to this item - Bugzilla: #1173350

If you use a kickstart whose %packages sections lists both an environment group:

@^some-environment-group

and one or more package groups:

@group1
@group2

and run a GUI install, the regular groups will not be installed. The environment group will be installed. Kickstarts that list only package groups (not environment groups) are not affected by this bug.

To work around this bug, run the installation in text mode rather than GUI mode: add text to the kernel parameters. The bug is in the installer's GUI code, and the TUI code does not have the same bug.

Windows 7 mis-identified as Windows Vista in boot menu

link to this item - Bugzilla: #1172405

Due to a bug in the os-prober utility used to discover other operating systems, if you install Fedora 21 to a system which contains a Windows 7 installation, it may be misidentified as "Windows Vista" in the boot menu produced by the Fedora install. This is a cosmetic bug only, and the entry should boot Windows just fine (unless Secure Boot is enabled, as mentioned above). The issue may affect other Windows versions too. You can safely manually edit the bootloader configuration file to correct this issue, if you would like to.

Fix released
An update has been released to address this problem. However, as this issue manifests before the system can be updated, you may still have to work around it as described here.

Network install image offers all package groups

link to this item - Bugzilla: #1134524

This is no longer considered a bug, exactly, but remains documented here for clarity. Initial Fedora 21 plans envisaged Server and Workstation releases each having their own network install images which, by default, would offer only the package groups relevant to that Flavor. However, it became clear that this design was difficult to implement and not really particularly desired by anyone.

For Fedora 21 Final, there will be a single designated network install image, built from the Server tree, which defaults to the Fedora Server package set but allows installation of all package groups. In practical terms it is little different from the network install image shipped with Fedora 20 and earlier except that it defaults to the Server package group rather than the GNOME desktop, and has Server visual branding. Despite this branding, in practice it is a universal network install image allowing deployment of all Fedora package sets. It can be used for doing network installs of the Workstation flavor in cases where this is preferable to installing from the live image (e.g. mass deployments).

32-bit Server DVD and network install images use generic installer artwork

link to this item - Bugzilla: #1170582

The 32-bit Server DVD and network install images use the generic installer artwork (down the side or across the top of the various screens) which simply uses the Fedora logo, rather than the Server flavor logo seen on the 64-bit versions of the same media. This is an entirely cosmetic issue, and the images are clearly identified as Server in various text labels.

Upgrade issues

Firewall configuration overwritten on upgrade to Server or Workstation

link to this item - Bugzilla: #1172862

If you pass --product server or --product workstation to fedup when upgrading, the firewalld-config-server or firewalld-config-workstation package will be installed. These contain the default firewall configurations for those Flavors. Unfortunately, these default configurations will replace - rather than merging with - your existing configuration, including any changes you have made to the defaults.

The Cloud flavor and "nonproduct" use the firewalld-config-standard package, which specifies no actual ports or services, and so existing configurations aren't replaced when fedup is run with --product nonproduct or --product cloud.

If you do want your upgraded system to be Fedora Workstation or Fedora Server, but you wish to maintain your firewall configuration modifications, you should note your existing configuration before the upgrade, and re-apply it with firewall-cmd or firewall-config after the upgrade process. We apologize for the inconvenience, and if possible we will release an update to resolve this issue for future upgrades.

FreeIPA configuration upgrade required after fedup

link to this item

If you upgrade a system running as a FreeIPA server to Fedora 21 using fedup, FreeIPA will not be able to entirely complete its configuration updates during the upgrade process. As explained in the FreeIPA release notes, you must run su -c 'ipa-ldap-updater --upgrade' followed by su -c 'ipa-upgradeconfig' after booting the upgraded system. Until you complete the update in this way, various elements of FreeIPA will not work correctly (including the web interface), and there will be error messages in the system logs.

Fedup copies the whole journal during upgrade

link to this item - Bugzilla: #1161366

After the upgrade is finished, fedup appends a copy of the whole journal to /sysroot/var/log/upgrade.log, instead of limiting that to just the current boot during which upgrade was run. This step will be slow on systems which have a large number of existing journal files. If you have a rotational drive, are low on disk space, and don't care about old logs, you might want to consider removing old journal files with

su -c bash -c 'rm -v /var/log/journal/*/*@*.journal*'

GNOME issues

GNOME Initial Setup crashes if no keyboard is selected

link to this item - Bugzilla: #1154171

On first use of a Fedora 21 Workstation system (or other Fedora 21 installation with the GNOME desktop), an 'initial setup' process is run (the same as described in the previous issue). One of the early stages asks you to pick a keyboard layout. Depending on your earlier choice of language and location, it is possible that no layout will be pre-selected on the initial list of layout choices. If no layout is selected, and you do not select one but simply click Next, the initial setup tool will crash.

The workaround for this issue is to make sure you select a keyboard layout. If none of the layouts is the one you want, clicking the '...' choice at the bottom of the list will cause the full list of layouts to be provided.

KDE issues

Default KDE session after installation or on re-login to live session is failsafe

link to this item - Bugzilla: #1164783

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

Due to an issue with how the sddm session manager orders desktop sessions, the failsafe session - "KDE Plasma (failsafe)" - will be the default session for interactive logins. This means that after installing Fedora 21 KDE but before installing the update, or if you log out from a live session and log in again through the login screen, the default session choice will be the failsafe session. However, the session used on initial boot of the live image is not affected.

To work around this issue, simply select the "KDE Plasma Workspace" session instead of "KDE Plasma (failsafe)" when you log in to KDE. You should only need to make this choice once for each user account - when you select a session, that session is stored as that user's default choice, so subsequent logins with that user will use the same session until you choose another.

Crash when adding new widget to panel via drag-and-drop

link to this item - Bugzilla: #1170535

You may encounter a crash in the Plasma Desktop Shell while adding a widget to the panel. If you open the 'Add widgets...' panel pop-up and try to drag a new widget from it to the panel, if you cross the button for a running application in the task manager widget while dragging, the crash will be triggered. The shell will respawn automatically and the session will continue to work correctly.

To work around this issue simply be careful not to cross the task manager area of the panel when dragging. The Fedora KDE team will work to come up with a fix for this issue as soon as possible.

Graphical package manager missing some PackageKit features

link to this item - Bugzilla: #1098735

In Fedora 21 Beta, apper (KDE's default graphical package manager and update tool) is missing some features, due to the replacement of the backend it previously used. Notably the ability to search within package groups is missing.

A source code fix has been submitted to the PackageKit project. As a result, updated PackageKit packages resolving this issue should become available for testing shortly.

Network issues

IP address discovery via DHCP does not work

link to this item - Bugzilla: #1154200

Several users have reported that Fedora 21 does not successfully discover an IP address via DHCP on their systems. An investigation of this issue has indicated that badly-behaving routers are the source of the problem, but some commonly-used router hardware and software appear to have the problematic behaviour by default. This at least appears to affect systems connected to Cisco RV320 routers, and possibly Windows Server systems acting as network routers. The issue may be more likely to occur in cases where the router is configured to assign specific IP addresses to specific systems based on their MAC addresses.

To work around the issue, create a file /etc/dhcp/dhclient.conf with the contents:

send dhcp-client-identifier = hardware;

or add that line to the file, if it already exists, and then try establishing the network connection again.

Both upstream and downstream engineers agree that dhclient's behavior here is correct according to the relevant RFC 4361, and that the only way to 'fix this bug' would be to break RFC compliance, and therefore they do not believe it is the right thing to do. If one end of a connection is spec compliant and the other is not, and the compliant end cannot handle the other end's non-compliance without becoming non-compliant itself, it is the non-compliant end that should change its behaviour. Fedora will attempt to notify router hardware/software vendors whose products suffer from this issue on behalf of our users.

Hardware issues

Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W530)

link to this item - Bugzilla: #752613

This issue has been present since at least Fedora 19.

Multiple testers have reported that various Thinkpad models - including at least the W530, and likely the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 19, 20, or 21 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.

ARM issues

Fedora Server issues

Rolekit fails to deploy a Domain Controller on a VM, returning error 256

link to this item

Creation of a Domain Controller role requires the system to have a sufficient amount of entropy available to securely create the keys for the included certificate authority and Kerberos key distribution center. It is very common when deploying on a virtual machine that has just been created that there will not be sufficient entropy available, which will result in the Domain Controller deployment timing out waiting on /dev/random and then failing with error code 256.

On VM hosts that support it (such as KVM on Fedora 20 and 21), it is recommended to create the VM using the virt-RNG device (which the Fedora Server 21 guest will automatically detect). This will allow it to collect entropy from the host machine and should reduce the likelihood of encountering this issue. As a workaround (if you do not have a host capable of providing entropy), you can also run su -c '/usr/sbin/rngd -r /dev/urandom' to make the system use the less-secure /dev/urandom entropy device.

FreeIPA startup fails due to timing issues

link to this item - Bugzilla: #1071356

This bug appears to occur only occasionally. Sometimes, startup of a FreeIPA server - ipa.service - may fail, apparently due to some kind of race / timing issue between it, named.service and dirsrv.target. It does appear to happen only rarely, and when it happens, just starting ipa.service again should succeed.

Other issues

Installation of 'environment groups' fails due to conflicts between fedora-release packages

link to this item - Bugzilla: #1160917

Due to some limitations in how Fedora's package group mechanism works and some changes made to support the introduction of "Flavors" in Fedora 21, you may often encounter conflicts when trying to install the 'environment groups' seen in yum grouplist after installing Fedora 21. If you install a Fedora Flavor - Workstation, Cloud, or Server - it is likely that attempting to install any other 'environment group' will fail. If you use a non-Flavor install - for instance, install from a desktop live image - it is likely that you will be able to successfully install other non-Flavor environment groups, but not the environment groups associated with each Flavor.

The most common case in which you're likely to encounter this is trying to add extra desktops to a Workstation or other desktop installation. If you install Workstation and then want to add any other desktop, or install another desktop and then want to add GNOME and decide to try and use the 'Workstation' group, you will likely run into this problem.

Fortunately there is a fairly simple workaround for this problem: use the command yum groupinstall (group) --exclude fedora-release\*, e.g. yum groupinstall kde-desktop-environment --exclude fedora-release\*. Note that you must use exactly yum groupinstall. yum group install will not work.

It may not be possible to resolve this fully for Fedora 21. The bug report contains the detailed explanation of the problem, and solutions for it will likely be discussed there, if you wish to keep up to date.

Resolved issues

Rendering problems of Assamese and Bengali language content

link to this item - Bugzilla: #1170135

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

A rendering issue was found in Lohit Assamese and Bengali last upstream release 2.91.0. Due to this issue conjucts break if followed by any Bengali matra. Unfortunately this got detected during the final phase of Fedora 21 release, and had to be fixed with an update.

Anyone creating or viewing Assamese or Bengali language content in Fedora would have encountered this issue.

Offline update does not work (and other issues in PackageKit-based software managers)

link to this item - Bugzilla: #1181501 - Bugzilla: #1183010

Fix released, but special procedure may be needed to update
An update has been released to fix this problem. After you update your system, and possibly reboot, you should no longer be affected by it.

However, as the bug itself affects the update mechanism, you may need to apply the update in a different way than usual. The 'offline update' mechanism is the default for the Fedora Workstation flavor, and may be broken by this issue.

If you are affected by this issue and cannot update to the fixed package in the usual way, you can install it using the command-line yum tool. Run su -c 'yum update --advisory=FEDORA-2015-0921' (if you have set a root password) or sudo yum update --advisory=FEDORA-2015-0921 (if you are a user with administrative privileges) to install the update.

If you continue to encounter issues which seem to meet this description after installing the update, try running pkcon repair and rebooting the system.

Version 0.1.7 of the libhif library, used by PackageKit, passed initial testing and was released as an update for Fedora 21. Unfortunately, it later transpired that it had several bugs which can cause multiple issues. In particular, it could often cause offline updates to fail. Offline updates are the standard update system for Fedora Workstation, where a notification of available updates appears and asks you to reboot the system to install them. After libhif 0.1.7 has been installed, you may find that any attempt to do an offline update results in failure (as reported by a notification).

Further testing identified some other issues which could cause other package management operations, like installing or removing packages, using PackageKit-based applications - e.g. GNOME Software, Apper, and pkcon - to fail and/or crash.

We do apologize for inconvenience caused by this broken update.

Downloading failed: Didn't install any keys

link to this item - Bugzilla: #1066044

If you have enabled any third party repositories that are not included with the default installation of Fedora, you may run into this issue. If you did not import the GPG key for a particular repository after you installed it, fedup will fail because it does not have the necessary keys imported.

A quick and easy way to fix this is to just reinstall the repository package. You can use the command su -c 'yum reinstall packagename' to reinstall the package. When it prompts you to import the key, press y, and afterwards, try running the fedup tool again.

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.
Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

Eclipse crashes when the proprietary Bluejeans browser plug-in is installed

link to this item - Bugzilla: #1160411

Since the release of bluejeans plugin 2.90.616.8, this should no longer be a problem.

This issue occurs only when the Bluejeans proprietary browser plug-in is installed.

Eclipse may crash when using hover-help, or when a Javadoc pop-up is about to be shown, or when using Eclipse's built-in web-browser view. This is due to the Bluejean plug-in crashing when any part of Eclipse uses the GTK Webkit widget.

The recommended workaround is to make Eclipse use the experimental Webkit2 support, which runs browser plug-ins out-of-process so that a crash inside Bluejeans will not cause Eclipse to exit. To enable this workaround, you must edit your /etc/eclipse.ini file and change the --launcher.GTK_version option from 2 to 3 and then launch Eclipse with the following command:

 SWT_WEBKIT2=1 eclipse