This page documents common bugs in Fedora 31 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.
- 1 Release Notes
- 2 My bug is not listed
- 3 Core system issues
- 4 Installation issues
- 5 Workstation (GNOME) issues
- 6 KDE issues
- 7 Upgrade issues
- 8 Other software issues
Read the F31 Beta release announcement for specific information about changes in Fedora 31 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Core system issues
Encrypted system does not resume from hibernation correctly if you wait more than 90 seconds to input encryption password
If you install Fedora 31 with the system partitions encrypted, and then use the hibernate (suspend-to-disk) feature, you will be prompted to input the encryption password during system resume. If you wait longer than 90 seconds before inputting the password, the system will not resume from hibernation correctly - instead a fresh boot will be performed and your previous state will be lost.
There is currently no known workaround for this problem besides simply making sure you input the password soon enough to avoid it happening.
Custom network configuration passed to the installer via kernel arguments not passed to installed system
When installing Fedora, it is possible to specify custom network configuration via kernel arguments. Indeed, if you need to retrieve a kickstart, updates image or the installer environment itself via a network connection, but that network connection requires manual configuration, this is the only way to do it. Normally, when you do this, the network connection is automatically translated into a NetworkManager configuration file and included with the installed system. However, in Fedora 31 Beta that mechanism is broken, so if you only pass the custom configuration via kernel arguments, the installed system will not have it. It will instead attempt to use DHCP to bring up any physically connected network interfaces, as a typical Fedora installation does.
If you must ensure that the custom network configuration is immediately present on the installed system, then as well as passing it via kernel arguments, you should also specify it either in the kickstart (if installing via kickstart) or interactively in the installer (if performing an interactive installation). This should ensure that the configuration is also written to the installed system.
Workstation (GNOME) issues
GNOME Printers settings app can crash if you enter a typo when searching for a printer
It has been reported that the GNOME Printers settings applet (accessible directly or via the Control Center) may crash if you enter a typo when searching for a printer, e.g.instead of . If you observe this applet crash unexpectedly, this may be the cause, so you may be able to avoid the problem by retrying and typing correctly.
Copy and paste and other agent features do not work with a SPICE-based virtual machine running Workstation
A tool called
spice-vdagent is run automatically in SPICE-based virtual machines (e.g. those run by virt-manager or GNOME Boxes, usually) to enable features like copying and pasting from the host system into the virtual machine, and vice versa. In Fedora 31 Beta, this tool does not run correctly in GNOME, so all features enabled by the agent will not work. The update referenced above fixes this bug, but it was not included in the Beta release, so you will still encounter this bug when booting the Beta Workstation live image in a virtual machine. The bug will be resolved in future nightly live images, and in the Final live images.
Custom keyboard layout switch key combinations do not work in X11
It has been reported that in Fedora 31, if you run GNOME on X11 (not on Wayland) and configure a custom key combination for switching the keyboard layout via GNOME Tweak Tool or direct configuration editing, the custom combination will not work. Custom switcher combos do work in Wayland, and the several pre-defined combos available via the GNOME Control Center do work in both X11 and Wayland. Switching layout via the graphical menu in the top panel also works.
Fedora 31 desktop background not used in KDE
Fedora 31 Beta contains a bug which results in the wrong desktop background being used by default in KDE. It is not a Fedora background at all, in fact, but an upstream background called "Next". The update listed above will fix this bug, but only for users created after the update is installed. If you install using the Fedora 31 Beta KDE live image (or another KDE image from before the bug is resolved) and create a user before updating, the user's background will be set to the 'wrong' one and this will not be changed automatically when updating. You can easily switch to the correct background for affected user accounts in the KDE settings (or, of course, any other background you might prefer). This issue will be resolved for future nightly images and for the Final release.
Podman fails to run containers on upgraded systems (due to use of runc runtime with cgroups v2)
If you upgrade a Fedora system where you have already installed and used podman to Fedora 31, after the upgrade it is likely podman will fail to launch containers any more. This is because on first use of podman in earlier Fedora releases a configuration file is written to the user's home directory which specifies that the
runc runtime should be used to launch containers, but at present,
runc does not work with version 2 of the kernel cgroups feature, as included in Fedora 31.
To resolve this issue, if you have not modified it in any other way, you can simply remove the affected file, with
rm ~/.config/containers/libpod.conf. If you have modified the file in some other way, you can edit it and change the setting from to .
Upgrading Fedora Silverblue or Fedora IoT from an older Fedora release to Fedora 31 might result in duplicate GRUB entries at boot time. However, the default boot entry is still the correct one. Hence, updating and rebooting should still work as usual. This is due to both GRUB2 (via
blscfg) and ostree-grub2 (via
/etc/grub.d/15_ostree) emitting menu entries. However, we cannot yet turn off the latter in favour of pure BLS booting due to a combination of: (1) older systems may have a GRUB2 too old to understand BLS, (2) OSTree systems do not yet have a mechanism for updating bootloader software, and (3) there is no easy way to detect the currently installed GRUB2 version.
We're working on ways to address this. In the meantime, one way to remove the duplicate menu entries is to disable
blscfg support by setting
/etc/default/grub. This will take effect on the next update and reboot.
For more information, see https://github.com/ostreedev/ostree/pull/1929 and https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026.
Other software issues
Dnfdragora shows spurious "DNF is locked by another process" error after successful update
It has been reported that the Dnfdragora package manager used on several desktops in Fedora 31 shows a spurious error message "DNF is locked by another process. dnfdragora will exit." after successfully updating the system. Please rest assured that there are no further consequences and this message can simply be safely ignored.