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, please do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
Contents
- 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
- 7.1 Upgrade to Fedora 31 may fail if DNF decides packages need to be reinstalled (often related to RPM Fusion third-party repository)
- 7.2 On Fedora Silverblue/IoT, the GRUB menu shows duplicate entries
- 7.3 Podman fails to run containers on upgraded systems (due to use of runc runtime with cgroups v2)
- 8 ARM issues
- 9 AArch64 issues
- 10 Other software issues
Release Notes
Read the Fedora 31 release announcement and the Fedora 31 release notes 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
link to this item - Bugzilla: #1705522
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.
Installation issues
Workstation (GNOME) issues
Custom keyboard layout switch key combinations do not work in X11
link to this item - Bugzilla: #1743005
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.
Users settings applet hangs if incorrect existing password is entered when changing user password
link to this item - Bugzilla: #1763525
If you enter a user's existing password wrong when attempting to change their password from the Users settings applet in Fedora 31 Workstation, the applet may hang. It should be possible to exit the applet with alt-F4 and try again. If you enter the existing password correctly, things should work fine.
QtWebEngine-based apps cannot be made full-screen under Wayland
link to this item - Bugzilla: #1759490
It has been reported that QtWebEngine-based applications - including Falkon and Qutebrowser - cannot be made full-screen under Wayland (so this is an issue that mainly affects Fedora Workstation, as Wayland is the default compositor there). Under X11 this works fine. We are still working to determine the cause and solution for this issue; if it is a major problem for you, you can run GNOME on X11 instead of Wayland, it is a choice available at the login screen.
Pango no longer supports bitmap format fonts
link to this item - Bugzilla: #1753295
Pango 1.44 no longer supports bitmap fonts in PCF or BDF format.
A workaround is to use the fonttosfnt
tool to convert them to OpenType format: see BitmapFontConversion for more details.
KDE issues
Discover app may trigger errors if attempting multiple operations on a package in a single run
link to this item - Bugzilla: #1762291
The Discover package management application in KDE appears not to refresh its internal accounting of package states after performing an install or remove operation. So, for instance, if you run it and install a package, the install will work fine, but on some level that instance of Discover still doesn't 'know' the package is installed. If you then attempt to uninstall it, you may get a "Package not found" error.
It seems some actions within Discover do trigger a refresh of this state, so this issue is somewhat unpredictable. But if you encounter unexpected errors when doing something like this, we recommend you exit the application and run it again. This should avoid such issues.
Upgrade issues
link to this item - Bugzilla: #1764169
It has been reported that an upgrade to Fedora 31 may fail in a certain specific circumstance. There is a known design limitation to the Fedora upgrade process: it involves running two DNF transactions, the first (the download transaction, run in the normal system environment) deciding which packages will ultimately need to be upgraded and downloading them, and the second (the upgrade transaction, run in a special limited environment after the system is rebooted) actually applying those upgrades using the previously-downloaded packages. The second transaction is not recalculated in exactly the same way as the first; instead, the lists of packages to be 'installed' and 'removed' in the first transaction are recorded and used to create the second transaction, which runs without a constraint that applies to the first but expects that duplicating the lists of packages to be 'installed' and 'removed' will result in an identical transaction.
It seems that in some cases, when calculating the second transaction, DNF can decide that some packages should be 'reinstalled', when it did not do so when calculating the first transaction; in this situation, the relevant packages will not have been downloaded as part of the first transaction, and so will not be available to DNF when attempting to perform the second transaction, and so it will fail. The failure manifests as the 'upgrade' step taking an unusually short time, and the system remaining at Fedora 30 when it reboots; no changes are actually made to the system, so this is not a damaging failure, it just means the upgrade does not work. If you examine the system journal and/or /var/log/dnf*.log
log files from the time of the upgrade attempt, you will see an error indicating that a package has an incorrect checksum - this is slightly misleading, what it really means is that the package file was not present *at all* when DNF went to calculate its checksum.
We have not yet worked out precisely the conditions that cause this failure, but it seems at least most often to happen when packages related to the third party 'RPM Fusion' repository are installed. Temporarily removing packages related to that repository, then re-installing them after the upgrade is complete, may help to work around the bug.
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 GRUB_ENABLE_BLSCFG=false
in /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.
Podman fails to run containers on upgraded systems (due to use of runc runtime with cgroups v2)
link to this item - Bugzilla: #1752040
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 runtime setting from runc to crun.
ARM issues
Nvidia Jetson TK1 requires nouveau driver to be blacklisted for graphical output
Due to an issue with Nouveau on the Nvidia Jetson TK1 you will need to blacklist the driver. To do this before booting the system, mount the installation media and edit the file /etc/extlinux.conf
, adding rd.driver.blacklist=nouveau to the kernel parameters (line that begins with append).
link to this item - Bugzilla: #1768636
To use the Etnaviv driver on imx.6 based boards you will need to make a small adjustment to the kernel parameters to fix CMA memory allocation issues. To do this before booting the system, mount the installation media and edit the file /etc/extlinux.conf
, changing cma=256MB to cma=256M@2G. This was fixed in a recent upstream kernel commit, so the fix should appear in a future Fedora kernel update.
Low memory systems
Systems with low memory (less than 512MB) may run out of memory when running some applications- most notably dnf. To workaround this, stop and disable the zram service:
sudo systemctl disable --now zram-swap
It is recommended you then create a swap file to use in its place.
AArch64 issues
Some AArch64 systems may boot with iommu/arm-smmu errors using Device Tree
link to this item - Bugzilla: #1724276
Some Enterprise AArch64 systems may boot with iommu/arm-smmu errors when booting using device tree (the fedora default). It is recommended to boot these systems using ACPI by adding acpi=force to the kernel parameters. If you would like to use device tree you can work around this issue by adding arm-smmu.disable_bypass=n. To do one of these permanently, you can use one of the following:
sudo grubby --update-kernel=ALL --args="acpi=force" sudo grubby --update-kernel=ALL --args="arm-smmu.disable_bypass=n"
This should be fixed in a system firmware update.
Other software issues
Docker package no longer available and will not run by default (due to switch to cgroups v2)
link to this item - Bugzilla: #1757078
The Docker package has been removed from Fedora 31. It has been replaced by the upstream package moby-engine, which includes the Docker CLI as well as the Docker Engine. However, we recommend instead that you use
, which is a Cgroups v2-compatible container engine whose CLI is compatible with Docker's. Fedora 31 uses Cgroups v2 by default. The moby-engine package does not support Cgroups v2 yet, so if you need to run the moby-engine or run the Docker CE package, then you need to switch the system to using Cgroups v1, by passing the kernel parameter systemd.unified_cgroup_hierarchy=0. To do this permanently, run:
podman
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"