From Fedora Project Wiki

Revision as of 22:01, 26 April 2021 by Adamwill (talk | contribs) (fix shortlink for last issue)

This page documents common bugs in Fedora 34 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 F34 release announcement and the Fedora Linux 34 release notes for specific information about changes in Fedora Linux 34 and other general information.


My bug is not listed

Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.

To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.

If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:

  • Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
  • Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
    1. a summary of the problem
    2. any known workarounds
    3. an assessment on the impact to Fedora users

For reference, you can query Bugzilla for bugs tagged CommonBugs:

  • CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
  • CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)

Installation issues

Compression not enabled for btrfs subvolumes renamed during install

link to this item - Bugzilla: #1952764

If you use the "custom" partitioning UI during installation of Fedora 34 and change the name of any btrfs subvolume, its line in /etc/fstab will lack the intended compress=zstd:1 mount option. This is benign, affecting only fstab entries, unless the subvolume is mounted as root (/); in this case, the entire installation will lack compression.

If you need to change the root subvolume name, e.g. to "@root", there are two possible workarounds:

Workaround A: change the subvolume name during installation, and then fix /etc/fstab after installation

  1. Change the subvolume name during installation.
  2. (optionally, to enable compression during installation) Immediately after beginning the installation process proper, switch to a shell (ctrl-alt-f2) and run mount -o remount,compress=zstd:1 /mnt/sysimage. If you get an error, you were too fast, the installer hasn't yet mounted the filesystem - simply reissue the command until it returns without error. You can confirm it's enabled with mount | grep btrfs.
  3. Modify /etc/fstab post-install, either before or after rebooting from the install environment.

Workaround B: change the subvolume name change after installation

  1. Proceed with installation without changing the subvolume name.
  2. After installation, change the name of the root subvolume, and update the subvol=(NAME) setting on the appropriate line of /etc/fstab.

NOTE: It is safe to rename actively mounted subvolumes.

KDE issues

Akonadi fails to start after upgrade to Fedora 34, preventing KMail etc. from working correctly

link to this item - Bugzilla: #1953675

It has been reported that after upgrading a KDE system to Fedora 34, the akonadi PIM server may fail to start correctly. This can prevent KMail and other apps that use Akonadi from working.

We are currently investigating this issue, but in the meantime, it has been reported that renaming ~/.config/share/akonadi will allow Akonadi to start up correctly. Of course, this will remove any local configuration that might be set there; you may be able to reapply it from the backup location after Akonadi has started successfully.

Copy/paste between host and Fedora 34 guest using SPICE does not work

link to this item - Bugzilla: #1951580

It has been reported that when running Fedora 34 KDE in a VM using the SPICE protocol (default for libvirt, virt-manager and Boxes virtualization), copy/paste between the host and the guest - and possibly other features relying on spice-vdagent - does not work. We are still investigating this issue and hope to have a resolution soon.

Upgrade issues

Upgrade to Fedora 34 may fail if i686 rdma-core package installed

link to this item - Bugzilla: #1919864

If you try to upgrade to Fedora 34 with the Package-x-generic-16.pngrdma-core i686 package installed, the upgrade may fail with errors relating to that package. The i686 version of the package needs to be removed on upgrade to Fedora 34, but due to limitations in RPM we cannot make this happen automatically in all cases. If you encounter this issue, you can try using the --allowerasing argument for the upgrade; it should cause the upgrade to remove the package. Please do check it does not result in any other desired package being selected for removal.

Audio may not work after upgrade to Fedora 34 if pipewire was previously installed

link to this item - Bugzilla: #1931384

Some users have reported that pipewire (the default audio framework in Fedora 34) may not work properly on update from older versions due to a configuration file format incompatibility. If you had pipewire installed in Fedora 32 or 33, it may stop working on upgrade to Fedora 34. If this happens to you, we recommend moving all *.conf files out of /etc/pipewire and reinstalling pipewire with sudo dnf reinstall pipewire. You will then need to re-apply any customizations you had made to the configuration files.

ARM and AArch64 issues

Raspberry Pi 4 will not start without being connected to a monitor

link to this item - Bugzilla: #1894241

An HDMI monitor must be connected to the Raspberry Pi 4 to boot successfully. To boot headless after completing initial-setup, add hdmi_force_hotplug=1 to /boot/efi/config.txt.