Common F20 bugs
This page documents common bugs in Fedora 20 and, if available, fixes or workarounds for these problems. If you find your problem in this page, do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to one or more Common Bugs pages)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to one or more Common Bugs pages)
System fails to boot after install using LVM Thin Provisioning
Fedora 20 introduces install-time support for LVM Thin Provisioning as a feature. Unfortunately, a late change to fix another serious bug inadvertently introduced a serious bug in this support. If you install Fedora 20 using the release packages (a live install, DVD install, or network install using a repository that contains the frozen release-time package set rather than including updates) and place any system partition (/home and other data partitions are not affected) on a thin-provisioned LV, the installed system will fail to boot. After a delay of 2-3 minutes, it will drop you an emergency mode. The cause of the bug is that tools needed for accessing thin provisioned LVs are erroneously left out of both system-specific and generic initramfs builds due to the broken change in Dracut, the tool that generates the initramfs.
There is no simple workaround for this issue if you are affected by it. Obviously, you can avoid it by not installing to thin-provisioned LVM. Network installs which include the update repository should not be affected by the issue, as the fixed dracut package is now in the stable updates repository.
If you do find yourself affected by the issue and wish to rescue the installation rather than re-install, you can use the installer's rescue mode.
Boot to rescue mode and choose Continue to mount your installed system and go to a shell. Now run the following:
chroot /mnt/sysimage /bin/bash yum update dracut dracut -f exit reboot
Crash when switching from a complete mirror repository to a DVD-based repository: NoSuchGroup: 3d-printing
This issue does not affect the simple cases of booting from the DVD and using it as the package source, or booting from the network install image and using a normal public Fedora mirror as the package source. Each of those cases works fine. You do not need to worry about this issue if this is how you plan to install Fedora 20.
However, if you set the Installation Source for a Fedora 20 installation to be a source with a complete set of packages - such as the default remote repository configuration, or any full Fedora 20 mirror - then switch to a source which contains only the restricted set of packages on the DVD image - such as a repository which simply is the DVD image, accessed via any protocol, or any other repository somehow generated solely from the DVD package set - the installer will likely crash with a NoSuchGroup: 3d-printing error.
In practice what this means is if you boot the network install image normally - so that the default remote repository is automatically configured - and then attempt to switch to, say, an NFS or HTTP repository which just contains the DVD ISO image (or has the contents of the DVD ISO image mounted or copied to it), the installer will likely crash.
There are several possible workarounds for this. You can simply set things up so your install repository contains the full package set, not the subset from the DVD image. You can pass in your desired repository configuration with the inst.repo boot parameter or using a kickstart with the repo command - this will cause your chosen repository to be configured straight away, and so avoid the bug. Or you can boot with the askmethod parameter, which has the effect of telling the installer not to try and configure the default remote repository automatically, but to wait for you to enter the Installation Source hub and choose a repository configuration yourself, which again should avoid the bug. You could even boot from the DVD image itself, though that does not seem likely to be a very useful workaround for the majority of cases where you would actually want to install from a separate repository containing only the DVD image file or contents.
389 Directory Server crashes during search operation
A tester has reported repeated crashes in Fedora 20's 389 Directory Server during search operations. This crash is currently being investigated and will be fixed as soon as possible.
Due to this and other 389 and FreeIPA issues discussed later in this page, we strongly recommend not deploying any kind of production 389 Directory Server or FreeIPA server using the Fedora 20 release at this point. Updates will be issued to resolve this and the other bugs listed on this page, and it should be safe to deploy a Fedora 20-based 389 / FreeIPA server with those updates installed. This entry will be updated when updates are available, or you can follow the relevant tickets.
/root permissions incorrect on pre-release installations
This issue does not affect systems installed with or upgraded after the release of the final release version of Fedora 20, but we are documenting it as it may be of significant interest to those who used Fedora 20 prior to release.
If you used any Fedora 20 pre-release (or test compose or release candidate build), the permissions on the /root directory are likely to be incorrect: an older version of the
package set the permissions to 0755 (users other than root can read files in the /root directory). We felt it not a good idea to try and fix this with an update, as sysadmins who manually change their /root permissions would not want us to override those changes, but we would like to make those who installed from pre-releases aware of the issue. The usual default Fedora permissions (and those set by the final release version of Fedora 20) are 0550. You can run
su -c 'chmod 0550 /root' to set those permissions, which will prevent users other than root from reading files in /root.
Problem with Installation Source spoke when installing from a partially complete kickstart
If you attempt to install Fedora 20 using a partially-complete kickstart - in particular, a kickstart which specifies a package set but no installation source - you will find that the interactive process for setting that option behaves strangely. On the Installation Source spoke, you may not be able to use the default Closest mirror option. If you are affected by this problem, you can manually enter the URL of the Fedora 20 mirror list, and check the This URL refers to a mirror list. box. The URLs for the 64-bit and 32-bit mirror lists are
Network configuration changes made after clicking Configure in installer (nm-connection-editor) are not applied unless interface is turned off and on again
The Fedora installer's network configuration screen has a button labelled 'Configure', which launches the nm-connection-editor utility to allow configuration of the network connection. Due to issues in the interaction between the installer and the separate nm-connection-editor process, configuration set in the nm-connection-editor process will not take effect unless and until you turn the connection off and then on again. We will attempt to remedy this for future Fedora releases, but it now cannot be resolved in Fedora 20, as the installer cannot be updated after release.
In custom partitioning, cannot change size of a pre-existing LV after setting a mount point for it and scheduling it to be reformatted
If you use custom partitioning while installing Fedora 20 to a system with a pre-existing LVM LV, assign a mount point to that LV, and set it to be re-formatted, you will no longer be able to request that its size be changed. Any attempts to change the 'Desired Capacity' field and hit 'Update Settings' will result in the size returning to the previous value.
This issue is easy to work around; as long as the volume is not both assigned a mount point and scheduled to be reformatted, you can successfully adjust its size (as long as that adjustment is achievable within the container, of course). So if you run into this problem, simply temporarily undo the mount point assignment and/or 'reformat' check box, make the size change, and then re-apply the mount point and 'reformat'.
In custom partitioning, cannot change size of a pre-existing partition then reset it to initial value
If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing partitions, then change the target size of any partition and subsequently change your mind and decide you did not want to resize it after all, you will not be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.
If you do run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.
In custom partitioning, cannot change size of a pre-existing LV multiple times then reset it to initial value
If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing LVM LVs, and change the target size of an LV more than once during one custom partitioning 'run', you will no longer be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.
If you're a bit indecisive about what size you want your LVs to be and run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.
Installation crashes during partitioning if disk was scanned after an encrypted volume has already been unlocked
This is a complex issue. Broadly speaking, if you somehow trigger the installer to do a disk scan after having already accessed a previously-existing encrypted storage volume, then the installation may crash during the partitioning stage with the error LUKSError: luks device not configured. The bug report contains several different possible reproduction scenarios; all are fairly involved, but it is something you may be most likely to run into when installing to a system with an existing encrypted storage volume and then running through partitioning multiple times or using the Refresh Disks function in the custom partitioning screen.
As there are various ways to encounter this issue and they are all quite involved it's difficult to suggest a precise workaround, but broadly speaking, the workaround is to reboot and try the install again, without using the Refresh Disks button (which actually rescans the disks on the system, as opposed to Reset all which just resets the custom partitioning screen to the state it was in when you first entered - it is safe to use that button) or running the installer or the partitioning phase multiple times.
If you use the Fedora 20 installer's rescue mode, and enter the interactive shell to try and rescue your installed system, then on exiting the shell it would be expected that you would return to the top-level rescue mode menu, or perhaps that the system would reboot. Instead, you wind up stuck on a screen that says Pane is dead. At this point, your partitions are still mounted, and a hard reset could possibly cause data loss. Do not do a hard shut down or reboot. You can hit ctrl-alt-f2 (or ctrl-b 2) to get a second shell and run 'reboot', or just hit ctrl-alt-del to trigger a clean reboot.
Network installation with Authoring and Publishing group selected fails
Due to an unmarked conflict between two texlive-related packages (
), Fedora 20 installations with the Authoring and Publishing package group selected (and possibly with the Font design group selected) will fail.
The offending packages (and groups) are not present on the Fedora 20 DVD, so the bug is not present there. The issue affects only network installs. It will be resolved once the conflict between the two packages is fixed with an update, so long as you enable the updates repository in your installation.
UEFI install to ms-dos ('MBR') labelled disk fails with unclear errors
As veterans of the Fedora 16 release may remember, there are two commonly-used 'disk label' or 'partition table' formats known as 'gpt' and 'ms-dos' or 'mbr'.
Fedora 20's installer effectively requires that native UEFI installations be performed to a disk with the 'gpt' format (in fact, it requires that the EFI system partition be on such a disk). In fact, this is not a requirement of the official UEFI specification: it leaves open the possibility of an EFI system partition residing on an ms-dos labelled disk, though it is possible that some firmwares may not support such a configuration.
In any case, if you attempt to do a native UEFI install of Fedora 20 such that the EFI system partition will reside on an ms-dos labelled disk, this will fail. You are likely get an error of the form you have not created a bootloader stage1 target device, possibly with the note that the volume backing the EFI system partition must have one of the following disklabel types: gpt. You may also observe unusual behaviour on the Reclaim space screen, if you use it in your installation attempt. Note that you can encounter this error message even when installing to a gpt-labelled disk if you use custom partitioning and fail to correctly configure an EFI system partition: when doing a UEFI install you must include a partition of the 'EFI system partition' type, and mount it at the path /boot/efi.
We have found that there appear to be some systems 'in the wild' with existing native UEFI operating system installations to an ms-dos labelled drive. Unfortunately, this bug means you cannot install Fedora 20 in a dual-boot configuration to the same drive as such an operating system. You would need to install to a second drive in order to dual boot.
If you wish to do a native UEFI installation of Fedora 20, it must be to a gpt-labelled disk, or you must configure your installation such that all existing partitions on the disk on which the EFI system partition will reside will be deleted (doing this will cause the installer to reformat it with a gpt disk label). Note that it is not possible to change the label format of a disk in a non-destructive way with the installer: it requires a complete re-format.
You can, however, convert it using the
gdisk utility from a live image prior to running the installer. Simply invoke
gdisk as root using your hard disk device as the first argument (e.g.
su -c 'gdisk /dev/sda1') and it will offer to convert the partition table for you. After answering "yes", type
w and press Enter to commit the changes to disk, then type
q and press Enter to exit
gdisk. Please note that conversion is a potentially risky operation; make sure you have backups before proceeding! Also, existing operating system installations may fail to boot after converting your partition table, so you may have to reinstall them (or just their bootloader if possible) in order for them to function again.
For Fedora 21, we intend to revise the installer to handle this situation in a better way. We apologize for any inconvenience it causes.
As a workaround, you can append "noefi" to the kernel boot options in the GRUB menu.
As for some laptops, there is an option in BIOS to set make it use Legacy mode instead of uefi, which makes it accept disks that aren't gpt-labelled (i.e some Lenovo models).
USB stick from which install is running appears as a possible install target
In some circumstances, when you are installing Fedora 19 from a USB stick, the stick itself will show up as a possible 'target disk' on the Installation Destination screen where you choose which disk(s) to install onto. This is not intended to happen. It is not possible to install to the USB stick from which the installation is running: if you attempt to do this, the installation will fail. Naturally, therefore, we recommend you simply avoid selecting the stick on this screen.
'Selected' state for disks is indicated with a small and easily missed check mark
On the installer screen where you choose which disks will be used for Fedora 20 installation, disks that are selected as installation targets are marked with a fairly small black check mark in the lower right hand corner; disks that are not selected do not have the check mark.
This has been changed since Fedora 18, when disks that were selected were highlighted in blue, and now the blue highlight simply means the UI element is selected. So if you click on a disk that was previously selected as an install target, then you have just de-selected it - so the check mark goes away - but the UI element is active, so it is highlighted in blue.
Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.
Bootloader password is required on each boot
If you set a bootloader password during installation of Fedora 19 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.
Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.
Non-GNOME initial setup utility does not warn of failure to create a user account
In Fedora 20, the initial-setup utility (shown after a graphical install with any desktop other than GNOME if you do not create a user account during installation) does not present any kind of warning if you leave it without having created a user account. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.
The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.
We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root, so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we strongly advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.
This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.
Upgrade fails if /var is a separate partition
/var directory on your system is a separate partition from the root filesystem (whether using regular partitions or LVM), a fedup-based upgrade may fail to work correctly. After the first stage is complete and you reboot, the upgrade environment may fail to find the /var device. Testers report that the system will in fact boot to your normal graphical environment instead of to the upgrade process, in this case.
A possible workaround which works in basic testing is to edit the file
/usr/lib/python2.7/site-packages/fedup/__init__.py and change these lines:
cachedir = '/var/tmp/system-upgrade' packagedir = '/var/lib/system-upgrade'
to point to a location on the actual root partition, before running
fedup. For instance, create the directories
/share/lib/system-upgrade, and edit those lines to read:
cachedir = '/share/tmp/system-upgrade' packagedir = '/share/lib/system-upgrade'
fedup --network 20 (or whatever upgrade command you wanted to use) and continue as usual. You may have to remove these directories and their contents manually once the upgrade is complete.
If you attempt to upgrade a system with the
package installed to Fedora 20, it will likely fail, as the package has broken dependencies in the Fedora 20 repositories. In Fedora 20, nothing else requires the package, but in Fedora 19 and earlier, some things did.
Until we resolve this problem, the workaround is to remove
and all its dependencies before upgrading, perform the upgrade, and then reinstall any of the dependencies you still wish to use. They should all install without a problem after the upgrade.
Fedup: upgrade can't start without rd.luks.uuid/rd.lvm.lv/rd.md.uuid boot args
The system may hang during the reboot after running the command
fedup --network 20 if these parameters are not specified.
Under normal circumstances, the installer would set up those arguments for you, but some people who migrated from GRUB to GRUB2 by hand have dropped those arguments - which works fine for F17 and F18, but fails for F19 and later.
The recommended fix is to restore the rd.luks.uuid/rd.lvm.lv/etc. arguments from your old grub.cfg. In a pinch, you can add "rd.auto=1" to your boot arguments to make dracut try to automatically set up every disk it finds; this isn't recommended for general use though.
ARM: HDMI output and USB peripherals not working on Beagle Bone Black
Fedora 20 GA has non functional USB/HDMI. At the moment, to use the Beagle Bone Black, you will need a serial console attached to the 6 pin serial header. There's full details here. The 3.12.5 kernel has full working usb/hdmi/network. It is currently in the kernel-nodebug repository, but there is a low expectation of support or testing of nodebug kernels. The 3.12 kernel should make it to updates-testing soon. Unofficial updated images are planned to be made available by the Fedora ARM team for the convenience of Beagle Bone Black users shortly after the 3.12 kernel lands with the only difference being the 3.12 kernel in the image.
GNOME Shell crashes after creating a keyring without a password
In Fedora 20 with the GNOME desktop, if you attempt to create a new keyring without a password or change the password of your keyring to an empty string (you may do this from the "Passwords and Keys" application, or you may be prompted to create a keyring password the first time GNOME attempts to store some kind of key), the GNOME shell will crash. The workaround for this is to always use a password on your keyring.
Testing has indicated that, in Fedora 20, it is not possible to browse SMB/CIFS shared resources - i.e. Windows or Samba file or device shares - with the default FirewallD firewall enabled, even if you enable the 'samba-client' firewalld service. By comparison, in Fedora 19, browsing appears to work even without needing to enable that service. The issue is not specific to a particular desktop or file manager utility, it seems to be an issue in the firewalling layer. You can connect to a share by entering the path explicitly, and shares that are advertised via zeroconf/Bonjour may show up when you browse.
Besides using zeroconf or simply directly entering share addresses, there are two possible workarounds for the bug, but neither is without consequences. You can simply disable the firewall (from the firewall configuration tool, or with
su -c 'systemctl stop firewalld.service'), or place the relevant network interface in the 'trusted' firewall zone (which allows all traffic to and from that interface, so is more or less identical in effect to disabling the firewall) - you can do this from your desktop's network configuration utility. Either of these approaches, obviously, results in your losing the security benefits of the firewall. Alternatively, you can configure a custom firewalld rule to accept all from source port 137/udp; this is less drastic than disabling the firewall entirely, but still possibly constitutes a slight lowering of protection.
If you do use a workaround to enable browsing, we would suggest doing so only long enough to discover the shares you wish to configure, then setting up some sort of permanent configuration / bookmark for them, so you no longer need the browsing functionality and can drop the workaround.
We are currently investigating and attempting to come up with a correct resolution for this problem.
DVD not available as a package repository after installation
In older releases of Fedora - at least older than Fedora 18 - after you installed from the DVD, it was automatically used as a repository for installing packages after system installation. Since Fedora 18, due to changes to the underlying tools, this function has no longer worked. We hope to be able to restore it soon, but cannot commit to a specific time frame.
A comment on the bug provides a partial workaround which will allow you to install packages from the DVD using the
libvirt guests are killed on host shutdown
When hosting virtual guests via libvirt in recent Fedora releases it is intended that, if you shut the host down with the guests still running, they will be suspended and then resumed when you boot the host up again. This does not currently work in Fedora 20. If you shut the host down with guests running, they will simply be uncleanly shut down (the processes are killed).
We are currently investigating to try and find a fix for this issue. In the mean time, if your virtual guests are of any value to you, please shut them down cleanly before shutting down the host. We apologize for any inconvenience this may cause.
KVM guests using the qxl graphics driver may display sluggish graphics performance on Fedora 20 hosts
With a sufficiently recent version of Fedora's virtualization stack, such as that in Fedora 20, a feature is available for guests that use the qxl virtual graphics adapter and driver which is intended to provide smooth playback of video in the guest guests. However, it seems this 'streaming' mode can erroneously be invoked when certain non-video operations happen in guest machines, and this causes very sluggish graphics performance and artifacting. In particular, the way GNOME 3 handles screen redraws means this problem affects guests running GNOME 3 very badly, but it can also be seen on other desktops in certain circumstances, such as when scrolling through a web page that contains many large images.
We have implemented a workaround for the qxl driver in Fedora 20 which means that Fedora 20 guests are not affected by this bug, and we will likely provide the workaround for Fedora 19 as an update. However, the bug may still be observed on other guest operating systems that include a qxl driver which is new enough to take advantage of the streaming feature, but does not contain this workaround. If you are unfortunate enough to be affected, you can edit the configuration of the virtual machine (e.g. via
virsh), and change the line that looks like this:
<graphics type='spice' autoport='yes'/>
to look like this instead:
<graphics type='spice' autoport='yes'> <streaming mode='off'/> </graphics>
This disables the 'streaming' feature for the virtual machine, which should completely avoid the problem occurring on any guest operating system.
Error messages about swap activation if swap is on a plain partition on a GPT disk
If your swap device is a plain partition (not LVM-backed) on a GPT-labelled disk, it appears that systemd has some trouble activating this, and you will notice errors in your system log at each boot, related to swap activation. However, testing indicates that the swap device is ultimately activated successfully. This issue is unlikely to cause any real problems, we note it purely to explain why you may see these errors in the system log. You can run the command
swapon without any parameters if you wish to check that the partition has been successfully activated.
Alternative on-screen keyboards do not work correctly in GNOME
A bug in the
window manager for GNOME 3 means that on-screen keyboards other than GNOME's own native one (available from the 'Universal Access' control panel applet or panel menu if enabled) will not work correctly: clicking on a key on the keyboard will not result in the character appearing in the currently-active application.
An updated package that addresses this issue should be available soon.
Crash in speech-dispatcher process when launching GNOME or KDE screen readers
Both GNOME and KDE desktops in Fedora 20 include a screen reader application, a tool for visually-impaired users which reads the contents of the screen aloud. GNOME's is
, KDE's is
. Commonly, when launching either of these, you will be notified of a crash in the
This may be disconcerting, but testing indicates it does not actually prevent the screen reader applications from working correctly; you can safely proceed to use them. It is not necessary to report the crash, as the issue is already known and we are attempting to find a solution, but it will not harm anything if you do.
Repeated dbus error messages logged with ModemManager.service disabled
If you have NetworkManager installed and active, but you disable ModemManager.service - which you might well choose to do if you have no cellular modem - this will result in error messages being printed to the system logs every two minutes:
Dec 14 09:27:02 localhost dbus-daemon: dbus: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 14 09:27:02 localhost dbus: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 14 09:27:02 localhost dbus: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. Dec 14 09:27:02 localhost dbus-daemon: dbus: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.
There is no more serious consequence of this problem, but you may find the log spam annoying. You can avoid it by re-enabling ModemManager.service, or by removing ModemManager entirely with
su -c 'yum remove ModemManager'.
389 Directory Server crashes after enabling FreeIPA Active Directory trust support
It has been reported that, if you set up a FreeIPA server on Fedora 20 and enable the Active Directory trust support by running
ipa-adtrust-install, the 389 Directory Server (LDAP server) can crash. In fact there are two crashes, one in 389-ds itself, and one in the
plugin. The result of this is that the FreeIPA domain will cease to function correctly, since the LDAP server component is a vital one.
Updates will arrive to resolve these issues very shortly. In the mean time, we advise you do not attempt to enable Active Directory trust support for a FreeIPA server based on Fedora 20. In fact, as there are several other significant bugs in this software stack discussed on this page, we strongly recommend you do not deploy FreeIPA or 389 Directory Server on Fedora 20 in production at all until these issues are resolved.
Users of the MyPasswordSafe application have reported that it commonly crashes on Fedora 20 when generating or entering passwords. If you submit a bug report it will likely appear as a duplicate of bug #1042667.
Using the Fedora 19 package is a possible workaround for this issue. The maintainer is currently investigating and attempting to resolve the problem. Multiple other password managers are packaged for Fedora, including some which can import MyPasswordSafe data, e.g.
, so using one of these is another option.
Eclipse crashes with Google Talk plugin installed
Multiple users have reported an unusual bug in the Eclipse IDE: it commonly crashes if the Google Talk plugin is installed.
Unfortunately, as the Google Talk plugin is closed source and no debugging symbols are available, Fedora developers cannot resolve this issue. A Google employee has stated that he has reported the issue internally, but we have received no progress reports since then.
An experimental workaround has been suggested by Roland Grunberg which may help if you really need to use both Eclipse and the Google Talk plugin together, otherwise the only workaround we can offer is to remove the Google Talk plugin.
ZIP support in PHP
In Fedora 20, support from ZIP has been dropped from main php package and is now provided in a separate php-pecl-zip package.
If you need zip support, as for any other extension, run
su -c 'yum install php-zip'.
Disabling SELinux via configuration file fails with libselinux-2.2.1-4.fc20
After the release of Fedora 20, libselinux-2.2.1-4.fc20 was submitted as an update, passed basic validation testing, and went to the stable updates repository. Unfortunately, it turns out that this update contains a bug which makes it impossible to disable SELinux via the configuration file
/etc/selinux/config. If you set:
in that file, you will instead most likely get permissive mode, rather than a completely disabled SELinux. To work around this issue, you can pass selinux=0 on the kernel command line: this will successfully disable SELinux.
Attempting to launch the application Panorama Stitcher from the KDE menus in Fedora 20 would result in it crashing. This application is only present on the menus by default if you install from DVD, not if you install from the KDE live image. The panorama function is really one of the many Kipi image manipulation plugins for KDE, and is usually expected to be accessed from a Kipi-enabled graphics manipulation application; its presence in the menus is only a convenience.
Multiple cases of "group (groupname) does not exist" errors when running yum
There were several similar and inter-related bugs in Fedora 20's Yum package manager which could cause it to print bogus warnings about groups not existing in certain circumstances. You might have seen any of these warning messages:
- Warning: group (groupname) does not exist.
- Warning: environment (groupname) does not exist.
- Warning: Environment Group (groupname) does not exist.
yum groupinstall (groupname),
yum install @(groupname), or
yum upgrade after having once installed any package or environment group with
yum groupinstall (groupname) or
yum install @(groupname). The most common and most visible case of this bug - where you saw multiple instances of the first warning - would occur only if you had updated to yum-3.4.3-120.fc20 or higher, it did not affect the initial Fedora 20 version, yum-3.4.3-106.fc20.
A less immediately visible but somewhat more significant issue was that, when you installed an "environment group", yum failed to correctly keep track of which "package groups" were installed as a part of that "environment group" - it in fact never considered any package group to have been installed as part of an environment group. This meant that running "yum group remove (environment group)" would not remove anything. Note that any such environment group installations you did with an affected version of yum - anything prior to 3.4.3-127 - will still be affected by this.
We have not yet discovered any very serious consequences of these bugs - they are mostly superficial, though they can be annoying. As far as we are currently aware, there is no possibility of data loss, or of the packaging system becoming seriously broken. It is safe to continue using your Fedora 20 system and working with packages, even if you see these messages. Some of the more advanced group functions related to the Fedora 19 "yum groups as objects" feature, however, would not perform as advertised.
Various 'workarounds' were possible, though all involve in some way interfering with the operation of the aforementioned Fedora 19 "yum groups as objects" feature. Probably the safest and most easily reversible was to run:
yum-config-manager --save --setopt=group_command=compat
This will configure yum to effectively disable the "groups as objects" feature and revert to the simple handling of groups it used prior to Fedora 19. The major drawback of this is that the
yum group remove command almost never does what you want in this configuration. Another possible workaround was to run
yum group mark remove (groupname) for each affected group. This was a little more work, and also harder to reverse in future, but it is safe. It tells yum to consider the group in question as 'not installed', but will not lead to the removal of any packages unless you run a specific command or change a configuration setting.
yum groups mark convert command recommended by yum results in many additional packages being installed on yum update
If you run certain yum commands, it may advise you to run a command
yum groups mark convert. This is related to the Fedora 19 "yum groups as objects" feature: it is intended to look at an existing Fedora system, work out which package groups are installed, and write that information out for the use of the "groups as objects" feature.
Testing has indicated that prior to yum-3.4.3-128.fc20 this command was too aggressive in determining which package groups were installed, and marked for instance groups from which only a single package is present on the system as being 'installed', even if that package was actually installed individually or as part of another group. As one of the "groups as objects" features is that not-currently-installed packages from installed groups will be added when running
yum upgrade, the result is that, on running
yum upgrade after
yum groups mark convert, yum will attempt to install many new packages, most of which you likely do not want.
If you ran the command with an affected version of yum and wish to prevent yum trying to install additional packages, there are several possibilities.
The easiest is to run
yum-config-manager --save --setopt=group_command=compat, which will have the effect of disabling the "groups as objects" functionality entirely, reverting yum to its pre-Fedora 19 handling of package groups. Unless you were interested in taking advantage of the "groups as objects" features, you will likely be happy with this behavior.
If you wish to try and maintain the "groups as objects" functionality (despite this bug and the others discussed above), you can run
yum group list installed hidden -v to print the list of groups that yum now believes is installed, and run
yum group mark remove (groupname) to tell yum to consider a group as 'not installed'. Do this for each of the groups you do not want, until yum no longer wishes to install additional packages you do not want.
Missing attributes in objectclasses in 389 Directory Server (and hence FreeIPA)
A bug in the schema parser in the version of the 389 Directory Server included with Fedora 20 could result in objectclasses missing attributes. This bug could have significant and unpredictable negative effects depending on your LDAP configuration; it is at least likely that you will see unexpected errors when attempting to add or modify any entry with one of the broken objectclasses. This bug has already been reported to cause significant issues when running a FreeIPA server on Fedora 20, and if you replicate a broken Fedora 20 deployment of 389 Directory Server / FreeIPA with a working deployment, the issue may spread to the previously-working servers.
Due to other 389 and FreeIPA issues discussed earlier in this page, we still recommend not deploying any kind of production 389 Directory Server or FreeIPA server using the Fedora 20 release at this point. Updates will be issued to resolve the other bugs listed on this page, and it should be safe to deploy a Fedora 20-based 389 / FreeIPA server with those updates installed.
389 Directory Server referential integrity plugin fails to work
If your configuration of the referint (referential integrity) plugin for the 389 Directory Server is missing these two attributes:
nsslapd-pluginEntryScope: dc=example,dc=com nsslapd-pluginContainerScope: dc=example,dc=com
then the plugin would fail to work correctly (attributes would not be adjusted as expected). These attributes were added to the default referint configuration in 389-ds #47621, but it was not intended that the plugin would break if they were not present. If you were affected by this issue, it could be worked around by adjusting your referint plugin configuration to specify these two attributes.
As there are several other significant bugs in this software stack discussed on this page, we strongly recommend you do not deploy FreeIPA or 389 Directory Server on Fedora 20 in production at all until these issues are resolved.
Upgrade to Fedora 20 with fedup 0.7 fails, reboots shortly after booting the System Upgrade option
Upgrading from Fedora 18 or Fedora 19 to Fedora 20 using the FedUp utility will fail if you use version 0.7 or earlier. The symptom is that the first stage of upgrade (before rebooting) works successfully, but when you reboot to complete the upgrade, the second stage begins but almost immediately aborts and reboots back to your previous Fedora system. The failure is not harmful in any way - your existing Fedora install will not be damaged, and you will be able to upgrade to Fedora 20 successfully by following the instructions below.
We apologize for this error - pre-release testing of Fedora 20 indicated that fedup 0.7 would work successfully for most upgrades, but this does not seem to have worked out.
Happily, the resolution is simple: use fedup 0.8 or later for a successful upgrade. If you have not yet upgraded to Fedora 20, simply ensure you have version 0.8 or later of fedup installed (it is available from the updates repository) before running. As long as you use fedup 0.8 or later, your upgrade should run successfully.
If you have already run fedup 0.7 and encountered this issue, you can achieve a successful upgrade with fedup 0.8. Note that the location to which fedup downloads files has changed between 0.7 and 0.8. You can simply run 0.8 and achieve a successful upgrade, but it will re-download files unnecessarily, consuming time, bandwidth and space. To avoid this, before running fedup 0.8, run these commands:
su -c 'mv /var/lib/fedora-upgrade /var/lib/system-upgrade' su -c 'mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade'
This will save you time, bandwidth and disk space.
If you have already run both a failed 0.7 and a successful 0.8 upgrade attempt, you may wish to check if the
/var/tmp/fedora-upgrade directories exist, and if so, remove them: they are no longer needed and are simply occupying disk space.
Upgrade to Fedora 20 with fedup 0.8 fails due to GPG key problems
link to this item - Bugzilla: #1040689 Version 0.8 of the FedUp upgrader adds checking of GPG keys on packages as a feature. This improves the security and verifiability of the upgrade process, but there are a few circumstances in which it may cause problems.
First, it requires that the version of Fedora you are upgrading from have the package signing keys of the version of Fedora you are upgrading to available. This requires that you update to the latest stable version of the
package prior to running fedup. Otherwise, it will fail during the setup phase with the error message Downloading failed: could not verify GPG signature: No public key.
Second, fedup may abort if it cannot find a GPG key for all enabled package repositories. If you have any third party repositories configured, fedup may not be able to find keys for them. If fedup is failing with what looks like a GPG key-related error, and you have any third party repositories enabled, try temporarily disabling them before running fedup. You can re-enable them after the upgrade has completed and then run
yum update to update packages from them.