From Fedora Project Wiki

mNo edit summary
No edit summary
 
(36 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<!--  
<!--
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>.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.
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<|release=XX>}}</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}}
{{autolang|base=yes}}


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.
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.
 
{{admon/note|Pre-release version|Fedora 31 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 31 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).}}


== Release Notes ==
== Release Notes ==
Read the [https://fedoramagazine.org/announcing-the-release-of-fedora-31-beta/ F31 Beta 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 31 and other general information.
Read the [https://fedoramagazine.org/announcing-fedora-31/ Fedora 31 release announcement] and the [https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/ Fedora 31 release notes] for specific information about changes in Fedora 31 and other general information.


{{Common_bugs_header_shared}}
{{Common_bugs_header_shared}}
== Core system issues ==
== Core system issues ==


{{Common bugs issue|encrypted-resume-delay|Encrypted system does not resume from hibernation correctly if you wait more than 90 seconds to input encryption password|1705522}}
== Installation issues ==


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.
{{Common bugs issue|fmw-macos-catalina|Fedora Media Writer does not work on macOS 10.15 (Catalina)}}


There is currently no known workaround for this problem besides simply making sure you input the password soon enough to avoid it happening.
Fedora Media Writer, the official tool for writing Fedora images to USB stick, is reported to [https://github.com/FedoraQt/MediaWriter/issues/217 not work with macOS 10.15 (Catalina)]. It appears to work, but does not actually write anything to the USB stick. There is no known workaround to make FMW work in this scenario at present. Alternative options include running FMW on a Linux or Windows system if you have access to one, [https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/#_using_a_direct_write_method using the command-line {{command|dd}} utility instead], or using a third-party tool. One user in the issue thread recommends [https://www.balena.io/etcher/ a tool called Etcher]: Fedora has not currently officially reviewed this tool and so cannot officially recommend it, but a cursory review of the tool description suggests it at least ought to write Fedora images correctly.


== Installation issues ==
== Workstation (GNOME) issues ==


{{Common bugs issue|installer-cmdline-net-config|Custom network configuration passed to the installer via kernel arguments not passed to installed system|1727904}}
{{Common bugs issue|user-hang-wrong-password|''Users'' settings applet hangs if incorrect existing password is entered when changing user password|1763525}}


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 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.


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.
{{Common bugs issue|qtwebengine-no-fullscreen|QtWebEngine-based apps cannot be made full-screen under Wayland|1759490}}


== Workstation (GNOME) issues ==
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.


{{Common bugs issue|gnome-settings-printer-crash|GNOME Printers settings app can crash if you enter a typo when searching for a printer|1750394}}
{{Common bugs issue|pango-bitmap-fonts|Pango no longer supports bitmap format fonts|1753295}}


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. {{code|socket>}} instead of {{code|socket:}}. 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.
Pango 1.44 no longer supports bitmap fonts in PCF or BDF format.
A workaround is to use the <code>fonttosfnt</code> tool to convert them to OpenType format: see [[BitmapFontConversion]] for more details.


{{Common bugs issue|spice-agent-gnome-fail|Copy and paste and other agent features do not work with a SPICE-based virtual machine running Workstation|1750120}}
{{Common bugs issue|shutdown-no-offline|Workstation shutdown menu does not prompt you to install prepared updates|1805265}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
{{Common bugs update released|FEDORA-2019-0989e01e70}}


A tool called {{command|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.
In Fedora Workstation, the shutdown/reboot menu is intended to alert you if system updates are prepared for installation and offer you the option of installing them before shutting down. This worked as intended in Fedora 28 and earlier. However, in Fedora 29 and later, a change to suspend PackageKit when it is not needed broke this feature: the notification almost never appears in the shutdown/reboot menu (it will only pop up if you happen to try and shut down very shortly after actively using PackageKit somehow).


{{Common bugs issue|x11-custom-switchers|Custom keyboard layout switch key combinations do not work in X11|1743005}}
There is no known practical workaround for this issue at present.


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.
== KDE issues ==


== KDE issues ==
{{Common bugs issue|discover-no-refresh|Discover app may trigger errors if attempting multiple operations on a package in a single run|1762291}}


{{Common bugs issue|kde-wrong-background|Fedora 31 desktop background not used in KDE|1749086}}
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.
{{Common bugs update testing|FEDORA-2019-d7fbbec3ae}}


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.
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 ==
== Upgrade issues ==


{{Common bugs issue|podman-cgroups2-runc|Podman fails to run containers on upgraded systems (due to use of runc runtime with cgroups v2)|1752040}}
{{Common bugs issue|upgrade-reinstall-failure|Upgrade to Fedora 31 may fail if DNF decides packages need to be reinstalled (often related to third-party repositories)|1764169}}
{{Common bugs update released|FEDORA-2019-7cafbe66ba}}
 
In certain cases when upgrading to Fedora 31, DNF complained about "incorrect checksums" and did not perform the upgrade. The error was misleading, the root cause was that DNF due to a bug wanted to reinstall packages which were not downloaded during the download phase. For those missing packages DNF reported "incorrect checksums" errors. This problem was only seen related to some third party repositories, but was most likely a generic issue that can affect even packages from Fedora repositories.


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 {{command|runc}} runtime should be used to launch containers, but at present, {{command|runc}} does not work with version 2 of the kernel ''cgroups'' feature, as included in Fedora 31.
This problem didn't break the upgraded system in any way, it simply didn't start the upgrade process and the system rebooted back into original (un-upgraded) Fedora system.


To resolve this issue, if you have not modified it in any other way, you can simply remove the affected file, with {{command|rm ~/.config/containers/libpod.conf}}. If you ''have'' modified the file in some other way, you can edit it and change the {{code|runtime}} setting from {{code|runc}} to {{code|crun}}.
This problem was fixed, see the colored box with a link to that update. Make sure you have at least that DNF (and related libraries) version before attempting system upgrade.


{{Common bugs issue|silverblue-iot-double-entries|On Fedora Silverblue/IoT, the GRUB menu shows duplicate entries}}
{{Common bugs issue|silverblue-iot-double-entries|On Fedora Silverblue/IoT, the GRUB menu shows duplicate entries}}
Line 67: Line 66:
For more information, see https://github.com/ostreedev/ostree/pull/1929 and https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026.
For more information, see https://github.com/ostreedev/ostree/pull/1929 and https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026.


Update: On newer Fedora releases, users can now also migrate to BLS (as was done in Fedora as part of https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault) by running `grub2-switch-to-blscfg`. Note that this only works on EFI. On BIOS, you can follow the steps in https://github.com/ostreedev/ostree/pull/2044#issuecomment-608316436.
{{Common bugs issue|podman-cgroups2-runc|Podman fails to run containers on upgraded systems (due to use of runc runtime with cgroups v2)|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 {{command|runc}} runtime should be used to launch containers, but at present, {{command|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 {{command|rm ~/.config/containers/libpod.conf}}. If you ''have'' modified the file in some other way, you can edit it and change the {{code|runtime}} setting from {{code|runc}} to {{code|crun}}.
{{Common bugs issue|eclipse-module-reset|Eclipse module has been reset to avoid shadowing non-modular rpms|1780827}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


{{Common bugs issue|docker-moby-engine|Docker package no longer available and will not run by default (due to switch to cgroups v2)|1757078}}
For a brief period, the eclipse module was a "default" module in Fedora 31 (meaning that a `dnf install <package>` command would enable the module and install the modular version of `<package>` if `<package>` is part of the module). Such "shadowing" of non-modular packages is expected with modules, but the eclipse module was shadowing more packages than it should, so the module was made "non-default" again. Nevertheless, users who installed or upgraded affected packages in this window have the module persistently enabled and are not getting the non-modular versions of those rpms, even if those now have a higher version.


Docker package has been removed from the Fedora distribution for Fedora 31.  Docker package has been replaced by the upstream package moby-engine, which includes the Docker CLI as well as the Docker Engine.  Another alternative is to use the Podman package. Podman is compatible with the Docker CLI.  We have also switched the default cgroup for Fedora 31 to V2.  The moby-engine package does not support cgroup V2 yet, although Podman does. If you need to run the moby-engine or run the Docker CE package, then you need to switch the system to using cgroup V1, by changing the kernel boot line.
To resolve this issue, a scriptlet was added to the `fedora-release` package that performs a one time `dnf module reset eclipse` operation. This solves the issue of unexpected shadowing of packages, but at the same time creates a problem for users who have the eclipse module enabled on purpose. They need to once re-enable the module if desired.


You can use the kernel parameter `systemd.unified_cgroup_hierarchy=0`,   
Summary: `fedora-release` performs a one-time disablement of `eclipse` module. Users who wish to have the module enabled should execute `dnf module enable eclipse:latest` once more.


Edit the kernel args by opening  /boot/grub2/grubenv and add `systemd.unified_cgroup_hierarchy=0` to the `kernelopts` line.
== ARM issues ==
== ARM & AArch64 issues ==


{{Common bugs issue|nvidia-jetson-tk1-nouveau|Nvidia Jetson TK1 requires nouveau driver to be blacklisted for graphical output|}}
{{Common bugs issue|nvidia-jetson-tk1-nouveau|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 "/etc/extlinux.conf" file adding 'rd.driver.blacklist=nouveau' to the kernel arguments (line that begins with append).
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 {{filename|/etc/extlinux.conf}}, adding {{code|1=rd.driver.blacklist=nouveau}} to the kernel parameters (line that begins with append).
    
    
{{Common bugs issue|etnaviv-cma|Etnaviv on imx.6 socs require CMA adjustment for graphical output|}}
{{Common bugs issue|etnaviv-cma|Etnaviv on imx.6 requires CMA adjustment for graphical output|1768636}}


To use the Etnaviv driver on imx.6 based boards you will need to make a small adjustment to the kernel arguments to fix CMA memory allocation issues.  To do this before booting the system, mount the installation media and edit the "/etc/extlinux.conf" changing "cma=XXX" to "CMA=256M@2G".
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 {{filename|/etc/extlinux.conf}}, changing {{code|1=cma=256MB}} to {{code|1=cma=256M@2G}}. This was fixed in a recent [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3057ad767542be7bbac44e548cb44017178a163| upstream kernel commit], so the fix should appear in a future Fedora kernel update.


{{Common bugs issue|low-memory-zram-disable|Systems with less than 512M RAM require zram.service to be disabled|}}
{{Common bugs issue|low-memory-systems|Low memory systems|}}


Systems with less than 512M RAM may run out of RAM when running some applications- most notably dnf. To workaround this, stop and disable the zram service "systemctl stop zram; systemctl disable zram; swapoff /dev/zram0". It is then recommended you create a swap file to use in its place.
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.


{{Common bugs issue|aarch64-arm-smmu-errors|Some AArch64 systems may boot with iommu/arm-smmu errors with Device Tree|1724276}}
== AArch64 issues ==


Some Enterprise AArch64 systems may boot with iommu/arm-smmu errors when booting with device tree (the fedora default). It is recommended to boot these systems using ACPI by adding "acpi=force" to the kernel arguments. If you would like to use device tree you can work around this issue by adding "arm-smmu.disable_bypass=n". This should be fixed in firmware by the system vendor.  
{{Common bugs issue|aarch64-arm-smmu-errors|Some AArch64 systems may boot with iommu/arm-smmu errors using Device Tree|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 {{code|1=acpi=force}} to the kernel parameters. If you would like to use device tree you can work around this issue by adding {{code|1=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 ==
== Other software issues ==


{{Common bugs issue|docker-moby-engine|Docker package no longer available and will not run by default (due to switch to cgroups v2)|1757078}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
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 {{package|podman}}, 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 {{code|1=systemd.unified_cgroup_hierarchy=0}}. To do this permanently, run:
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
{{Common bugs issue|firefox-alt-wayland|Trying to scroll with mouse wheel in inactive Firefox window results in back/forward instead|1650051}}
When using the Wayland backend for Firefox, a [https://gitlab.gnome.org/GNOME/gtk/issues/2112 known issue in GTK+] means that the {{key|Alt}} modifier key is still considered active in Firefox after you switch away from the window using the {{key|Alt|Tab}} shortcut. So if you then move the mouse over the inactive Firefox window (but do not click to activate it) and scroll the wheel, Firefox will treat this as holding down the {{key|Alt}} key and scrolling the wheel. By default, in Firefox, this is mapped to going 'back' and 'forward' in the page history, so instead of the page scrolling, you will rapidly move backwards or forwards through your page history.
If you find yourself frequently triggering this unwanted behaviour, you can work around it by navigating to {{code|about:config}} in Firefox and setting the value {{code|mousewheel.with_alt.action}} to 1 instead of 2. 1 sets the action when holding {{key|Alt}} and scrolling the wheel to be the same as when scrolling the wheel normally (it will scroll the page).


[[Category:Common bugs]]
[[Category:Common bugs]]
== Resolved issues ==
{{Common bugs issue|encrypted-resume-delay|Encrypted system does not resume from hibernation correctly if you wait more than 90 seconds to input encryption password|1705522}}
{{Common bugs update released|FEDORA-2020-87abf68a78}}
If you installed Fedora 31 with the system partitions encrypted, and then used the hibernate (suspend-to-disk) feature, you would be prompted to input the encryption password during system resume. If you waited longer than 90 seconds before inputting the password, the system would not resume from hibernation correctly - instead a fresh boot was performed and your previous state was lost.

Latest revision as of 17:07, 5 January 2021

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.

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
    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)

Core system issues

Installation issues

Fedora Media Writer does not work on macOS 10.15 (Catalina)

link to this item

Fedora Media Writer, the official tool for writing Fedora images to USB stick, is reported to not work with macOS 10.15 (Catalina). It appears to work, but does not actually write anything to the USB stick. There is no known workaround to make FMW work in this scenario at present. Alternative options include running FMW on a Linux or Windows system if you have access to one, using the command-line dd utility instead, or using a third-party tool. One user in the issue thread recommends a tool called Etcher: Fedora has not currently officially reviewed this tool and so cannot officially recommend it, but a cursory review of the tool description suggests it at least ought to write Fedora images correctly.

Workstation (GNOME) issues

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.

Workstation shutdown menu does not prompt you to install prepared updates

link to this item - Bugzilla: #1805265

In Fedora Workstation, the shutdown/reboot menu is intended to alert you if system updates are prepared for installation and offer you the option of installing them before shutting down. This worked as intended in Fedora 28 and earlier. However, in Fedora 29 and later, a change to suspend PackageKit when it is not needed broke this feature: the notification almost never appears in the shutdown/reboot menu (it will only pop up if you happen to try and shut down very shortly after actively using PackageKit somehow).

There is no known practical workaround for this issue at present.

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

Upgrade to Fedora 31 may fail if DNF decides packages need to be reinstalled (often related to third-party repositories)

link to this item - Bugzilla: #1764169

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.

In certain cases when upgrading to Fedora 31, DNF complained about "incorrect checksums" and did not perform the upgrade. The error was misleading, the root cause was that DNF due to a bug wanted to reinstall packages which were not downloaded during the download phase. For those missing packages DNF reported "incorrect checksums" errors. This problem was only seen related to some third party repositories, but was most likely a generic issue that can affect even packages from Fedora repositories.

This problem didn't break the upgraded system in any way, it simply didn't start the upgrade process and the system rebooted back into original (un-upgraded) Fedora system.

This problem was fixed, see the colored box with a link to that update. Make sure you have at least that DNF (and related libraries) version before attempting system upgrade.

On Fedora Silverblue/IoT, the GRUB menu shows duplicate entries

link to this item

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.

Update: On newer Fedora releases, users can now also migrate to BLS (as was done in Fedora as part of https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault) by running grub2-switch-to-blscfg. Note that this only works on EFI. On BIOS, you can follow the steps in https://github.com/ostreedev/ostree/pull/2044#issuecomment-608316436.

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.

Eclipse module has been reset to avoid shadowing non-modular rpms

link to this item - Bugzilla: #1780827

For a brief period, the eclipse module was a "default" module in Fedora 31 (meaning that a dnf install <package> command would enable the module and install the modular version of <package> if <package> is part of the module). Such "shadowing" of non-modular packages is expected with modules, but the eclipse module was shadowing more packages than it should, so the module was made "non-default" again. Nevertheless, users who installed or upgraded affected packages in this window have the module persistently enabled and are not getting the non-modular versions of those rpms, even if those now have a higher version.

To resolve this issue, a scriptlet was added to the fedora-release package that performs a one time dnf module reset eclipse operation. This solves the issue of unexpected shadowing of packages, but at the same time creates a problem for users who have the eclipse module enabled on purpose. They need to once re-enable the module if desired.

Summary: fedora-release performs a one-time disablement of eclipse module. Users who wish to have the module enabled should execute dnf module enable eclipse:latest once more.

ARM issues

Nvidia Jetson TK1 requires nouveau driver to be blacklisted for graphical output

link to this item

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).

Etnaviv on imx.6 requires CMA adjustment for graphical output

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

link to this item

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 podman, 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:

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

Trying to scroll with mouse wheel in inactive Firefox window results in back/forward instead

link to this item - Bugzilla: #1650051

When using the Wayland backend for Firefox, a known issue in GTK+ means that the Alt modifier key is still considered active in Firefox after you switch away from the window using the Alt+Tab shortcut. So if you then move the mouse over the inactive Firefox window (but do not click to activate it) and scroll the wheel, Firefox will treat this as holding down the Alt key and scrolling the wheel. By default, in Firefox, this is mapped to going 'back' and 'forward' in the page history, so instead of the page scrolling, you will rapidly move backwards or forwards through your page history.

If you find yourself frequently triggering this unwanted behaviour, you can work around it by navigating to about:config in Firefox and setting the value mousewheel.with_alt.action to 1 instead of 2. 1 sets the action when holding Alt and scrolling the wheel to be the same as when scrolling the wheel normally (it will scroll the page).

Resolved 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

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.

If you installed Fedora 31 with the system partitions encrypted, and then used the hibernate (suspend-to-disk) feature, you would be prompted to input the encryption password during system resume. If you waited longer than 90 seconds before inputting the password, the system would not resume from hibernation correctly - instead a fresh boot was performed and your previous state was lost.