This page documents common bugs in Fedora 35 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.
For Fedora Linux 35, we are trying a new system: Common Issues at Ask Fedora. If this goes well, we'll use it for F36. Your feedback is welcome!
Release Notes
Read the F35 release announcement and the Fedora Linux 35 release notes for specific information about changes in Fedora Linux 35 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)
Installation issues
When using a secondary keyboard layout in the installer, it frequently switches to the primary one
link to this item - Bugzilla: #2016613
This only affects the Workstation and KDE live images. If you boot one of these, run the installer, configure multiple keyboard layouts (or multiple layouts are automatically configured for the language you chose), and then switch to a secondary layout using the integrated layout switcher, the keyboard layout will switch back to the primary one whenever you press a modifier key (e.g. shift, alt or ctrl).
This isn't usually a problem on Workstation, because there are few places where you are likely to use the secondary layout for typing characters. However, for KDE, it's more likely, because user creation is available, and you might want to use the secondary layout to type the user's real name.
One way to avoid dealing with the problem is just to not use modified characters from the secondary layout during installation; use some other character temporarily, then change it after installation.
If you do want to enter modified characters using the secondary layout during installation, you have two options. One is to select the primary layout, then hold down the modifier key and keep it held down while selecting the secondary layout; you can now type as many modified characters as you like until you release the modifier key (whereupon the primary layout will immediately become active again). Otherwise, you can log out from the live session, and on the login screen, select "Desktop Session: Plasma (X11)" (KDE) or "GNOME on X.org" (Workstation) at the very bottom of the login screen, and then login again as the "Live System User" (no password). With an X.org session, this bug will not occur.
Upgrade issues
No sound after upgrade (wireplumber not running)
link to this item - Bugzilla: #2016253
In some cases, the new WirePlumber service may not be properly configured to start automatically after an upgrade. WirePlumber is a session manager for PipeWire, the modern audio subsystem we made the default starting with Fedora 34. You can read those links for details, but the short version is "this needs to be running for sound to work".
If systemctl --user status wireplumber.service - run as regular user, not root - says "disabled" and "inactive", this is likely your problem. The upgrade process should have taken care of this, and we expect this to be true for almost everyone. However, if your system is one of the unfortunate exceptions, run the following command AS YOUR REGULAR USER from a terminal (not as root or with sudo), and everything should start working:
systemctl --user enable --now wireplumber
No sound after upgrade (pulseaudio still in use)
link to this item - Bugzilla: #2016253
Aside from the above issue, there is another potential cause of sound not working after upgrade to Fedora 35. If wireplumber.service is enabled and running, but you still do not have sound, run the following command (as regular user, not as root):
systemctl --user status session.slice
if it shows all three of pipewire.service, pulseaudio.service and wireplumber.service running, like this:
├─pipewire.service
│ └─4071 /usr/bin/pipewire
├─pulseaudio.service
│ ├─12324 /usr/bin/pulseaudio --daemonize=no --log-target=journal
│ └─12391 /usr/libexec/pulse/gsettings-helper
└─wireplumber.service
└─4072 /usr/bin/wireplumber
then this may be the problem: it appears this configuration does not work, either some or all of the time. This case may result if you manually switched back to pulseaudio from wireplumber in Fedora 34, or possibly may occur on systems which have been upgraded constantly from an older release. In either case, try switching fully to pipewire, with this command:
sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio
If that still does not work, as a last resort, you may try to switch back to pulseaudio, but remove wireplumber and pipewire.
Workstation issues
"Fedora Flathub Selection" third-party repository can't be easily enabled if you don't enable it initially
link to this item - Bugzilla: #2011274
When you install Fedora 35 or upgrade to Fedora 35, if you don't opt-in to Fedora Third-party repositories initially (during the first boot after the installation, or from an info bar in GNOME Software after an upgrade), you are supposed to be able to opt-in through the GNOME Software repositories dialog later. However, the "Fedora Flathub Selection" third-party repository will not be visible there, so cannot be enabled. As a workaround, from the command line, run:
sudo fedora-third-party disable sudo fedora-third-party enable
This will result in all third-party repositories being created and enabled. You can disable any repositories you don't want through the GNOME Software repositories dialog.
Some third-party software might be missing in GNOME Software initially
link to this item - Bugzilla: #2016510
If you enabled third-party repositories during a fresh system install, some software from those repositories might not be shown in GNOME Software initially (there are a couple of rare race conditions - cases where operations happen in just the wrong order - that can cause this to happen occasionally). The best way to force GNOME Software to refresh all repositories and re-populate the search results is to go to its Updates tab and click the refresh arrow in the top left corner. After this is complete, all available applications should show up in the search results.
Disabling camera or microphone access in GNOME Settings does not work
link to this item - Bugzilla: #2018158
If you use GNOME Settings to disable camera and/or microphone access in the Privacy tab, the setting doesn't have the desired effect and applications can still use your camera and microphone. This has been broken for a long time. There is currently no known workaround for this.
Hyperlinks are truncated in GNOME Calendar
link to this item - Bugzilla: #2009451
If you use GNOME Calendar to view your events, and there's a hyperlink in that calendar event, it might be truncated, depending on its length. Such links then obviously lead to invalid URLs. There's no known workaround for this issue.
KDE issues
In Discover, packages can't be installed and immediately removed, or removed and immediately re-installed, without restarting the application
link to this item - Bugzilla: #2015809
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command:
sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2021-f7d19c8901If you install a package in Discover (the KDE package manager), and then try to remove it, the latter operation will fail with a "Package not found" error. The same problem occurs if you remove a package and then try to install it again. The workaround here is to close and reopen Discover after the first operation, and then the second operation will work as expected.
Configured repositories in Discover jump around in the list
link to this item - Bugzilla: #2011774
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command:
sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2021-35e9884fd8If you enable or disable an RPM repository using Discover, the repository you changed and others from the same configuration file will immediately jump to the bottom of the list, which can be quite confusing. So if you perform multiple operations, be careful to check you are clicking on the right item, because the list keeps re-organizing itself after each action.
Audio device not visible or usable in KDE Settings until a profile is assigned
link to this item - Bugzilla: #2011231
We have found in testing that some audio devices - it seems HDMI audio outputs are particularly susceptible to this - may not appear in KDE's notification panel audio applet or main audio device settings screen at all at first, giving the impression they are broken or unsupported. In fact, they will work if assigned a profile. From the audio settings page, click the Configure... button, and you should see the device(s) shown there, with no profile assigned to them. Once you select an appropriate profile, they should then be visible in the main audio settings page and the panel applet.
Server issues
Resolving dnssec-enabled domains may fail after FreeIPA server upgrade to Fedora 35
link to this item - Bugzilla: #1999321
In automated testing of FreeIPA on Fedora 35, we found that upgrading a FreeIPA server with dnssec validation enabled to Fedora 35 may possibly break DNS resolution of hosts in dnssec-enabled domains. This problem occurs in our automated testing environment, but has not yet been successfully replicated outside it, so it may be specific somehow to that environment. However, if after upgrading a FreeIPA server configured to act as a DNS server to Fedora 35 you find that you have problems when resolving hosts in dnssec-enabled domains, you can try disabling dnssec validation on the server:
ipa-dns-install --disable-dnssec-master
Zabbix web interface does not work
link to this item - Bugzilla: #2020292
Zabbix 5.0 is not compatible with PHP 8 shipped in Fedora 35. Workaround is to install PHP 7.4 from another source.
ARM and Aarch64 issues
Raspberry Pi 4 GUI frequently locks up with the Workstation Edition
link to this item - Bugzilla: #2008557
While not officially supported in Fedora, the Raspberry Pi 4 works well for most use cases. Unfortunately the upstream vc4 driver frequently locks up when using Wayland on the Workstation image. This is considerably better when using Xorg, but can still be affected by the bug. To workaround this issue you can blacklist the vc4 driver by running the following command:
echo "blacklist vc4" >> /etc/modprobe.d/blacklist-vc4.conf
Wireless keyboards might not work in GNOME Initial Setup on aarch64
link to this item - Bugzilla: #2017043
If you install Workstation on aarch64, an Initial Setup utility is shown on the first boot, where you configure system basics and create a user. However, it does not seem to not accept input from certain wireless keyboards. The only known workaround currently is to connect a wired keyboard or try another wireless keyboard.
Cloud instances hang occasionally in Openstack on aarch64
link to this item - Bugzilla: #2011928
In testing, we observed that aarch64 cloud instances running in an Openstack instance would hang occasionally, often during disk-intensive operations like software compilation. We observed this on a specific public Openstack cloud (Vexxhost), but cannot be sure whether it is somehow specific to that environment or may also affect others. We did not yet encounter the issue in testing on Amazon EC2.
This issue appears to happen only with btrfs storage, which is the new default in Fedora 35. There is no known workaround at present aside from somehow deploying with a different filesystem (which is beyond the scope of this document), but a fix has been proposed by an upstream developer and is showing promising results in testing so far. We hope to be able to include that fix in updated images in the near future.
Non-GNOME initial setup utility does not require you to create a root password or admin account
link to this item - Bugzilla: #2015490
When you deploy a system from a disk image (i.e. without running the traditional installer), an initial setup utility will run on first boot. For Workstation and Silverblue images this is 
gnome-initial-setup
This application should require you to create a user account with administrator privileges, or set the root password, before proceeding. gnome-initial-setup fulfills this requirement by always creating an admin user. However, initial-setup will allow you to create a regular (non-admin) user and then exit. If you do so, you will have no easy way to administer the installed system.
The best way to avoid this problem is, of course, to create an administrator account or set the root password before exiting initial-setup. If you inadvertently do not do so, you have a couple of options. You could just re-deploy the system and, this time, create an admin user or set the root password. You can also boot with the kernel parameter systemd.debug-shell=1; when you do this, after the system boots, you can hit ctrl-alt-f9 to access a root console. Here you can run passwd to set a password on the root account and reboot.
This bug is not technically specific to ARM architectures, but it is most likely to be encountered there as disk images are most commonly used for deployment on ARM systems.
Virtualization issues
Mouse cursor position is incorrect if you change display resolution in a virtual machine
link to this item - Bugzilla: #2006746
If you run a virtual machine (VM) and change the internal display resolution of the VM, the mouse cursor position might no longer reflect where you actually see the cursor, and instead get some horizontal and vertical offset (meaning your clicks will be passed to a completely different point of the screen). This only seems to happen after the resolution change is performed during a live session, so if you reboot the machine, the issue should disappear (until you decide to change the VM resolution again). Another workaround is to remove the spice-vdagent package, however that will also mean you'll lose some features, like seamless mouse integration into the VM, or clipboard sharing.
link to this item - Bugzilla: #2016563
If you run a virtual machine (VM) with the KDE desktop, your host clipboard will not be shared with VM guest. That means text you copy inside your host can't be pasted into the VM, and text you copy inside the VM can't be pasted into the host. One possible workaround is to log out from the current KDE session, select "Desktop Session: Plasma (X11)" at the very bottom of the login screen, and then login again. With an X11 session, this bug will not occur.