From Fedora Project Wiki

(Issues updated with commonbugs-update)
(link to experimental new system)
 
(29 intermediate revisions by 5 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 Linux 35 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 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.
  
{{admon/note|Pre-release version|Fedora Linux 35 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 35 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).}}
+
{{admon/tip|New Common Issues experiment underway...}}
 +
 
 +
For Fedora Linux 35, we are trying a new system: [https://ask.fedoraproject.org/c/common-issues/141/none/l/latest?order=votes Common Issues at Ask Fedora]. If this goes well, we'll use it for F36. [https://ask.fedoraproject.org/t/we-are-testing-a-new-common-issues-category-and-process/18916 Your feedback] is welcome!
  
 
== Release Notes ==
 
== Release Notes ==
Read the [https://fedoramagazine.org/announcing-fedora-35-beta/ F35 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 Linux 35 and other general information.
+
Read the [https://fedoramagazine.org/announcing-fedora-35/ F35 release announcement] and the [https://docs.fedoraproject.org/en-US/fedora/f35/release-notes/ Fedora Linux 35 release notes] for specific information about changes in Fedora Linux 35 and other general information.
 +
 
 +
{{Common_bugs_header_shared}}
 +
 
 +
== Installation issues ==
 +
{{Common bugs issue|anaconda-secondary-keymap-switch|When using a secondary keyboard layout in the installer, it frequently switches to the primary one|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 ==
 +
 
 +
{{Common bugs issue|no-sound-on-upgrade|No sound after upgrade (wireplumber not running)|2016253}}
 +
 
 +
In some cases, the new [[Changes/WirePlumber|WirePlumber]] service may not be properly configured to start automatically after an upgrade. WirePlumber is a session manager for [https://pipewire.org/ PipeWire], the modern audio subsystem we made the [[Changes/DefaultPipeWire|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".
  
{{Common bugs header shared}}
+
If {{command|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
 +
 
 +
{{Common bugs issue|no-sound-on-upgrade-pulseaudio|No sound after upgrade (pulseaudio still in use)|2016253}}
 +
 
 +
Aside from the above issue, there is another potential cause of sound not working after upgrade to Fedora 35. If {{code|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 {{code|pipewire.service}}, {{code|pulseaudio.service}} and {{code|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 ==
 
== Workstation issues ==
{{Common bugs issue|gnome-xorg-fail|Trying to log into GNOME on Xorg still gives Wayland|2007742}}
 
{{Common bugs update testing|FEDORA-2021-bfcc9cd095}}
 
  
Some users have reported that trying to log into the "GNOME on Xorg" session that is available from the login manager still results in a Wayland session. This seems to happen if the Xorg session is pre-selected (because it was used in the previous session), and not if you explicitly select it from the menu.
+
{{Common bugs issue|flathub-filtered-enablement|"Fedora Flathub Selection" third-party repository can't be easily enabled if you don't enable it initially|2011274}}
{{Common bugs issue|gis-third-party|Enabling third-party repositories during GNOME initial setup does not work|2001837}}
+
 
 +
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.
 +
 
 +
{{Common bugs issue|third-party-apps-missing|Some third-party software might be missing in GNOME Software initially|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.
 +
 +
{{Common bugs issue|disabling-camera-microphone-doesnt-work|Disabling camera or microphone access in GNOME Settings does not work|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.
 +
 
 +
{{Common bugs issue|calendar-links-truncated|Hyperlinks are truncated in GNOME Calendar|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 ==
 +
 
 +
{{Common bugs issue|discover-cant-reinstall|In Discover, packages can't be installed and immediately removed, or removed and immediately re-installed, without restarting the application|2015809}}
 +
{{Common bugs update testing|FEDORA-2021-f7d19c8901}}
 +
 
 +
If 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.
 +
 
 +
{{Common bugs issue|discover-repo-jump|Configured repositories in Discover jump around in the list|2011774}}
 +
{{Common bugs update testing|FEDORA-2021-35e9884fd8}}
 +
 
 +
If 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.
  
The initial setup tool that runs on first boot after a fresh install of Fedora Workstation offers an option to enable third-party software repositories. However, if SELinux is in enforcing mode (the default), this will not work.
+
{{Common bugs issue|hdmi-audio-profile|Audio device not visible or usable in KDE Settings until a profile is assigned|2011231}}
  
To resolve this issue, you can simply run GNOME Software and enable third-party repositories there (it should offer you the option on first run). This will work correctly. We intend to resolve this issue for the Final release.
+
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 ==
 
== Server issues ==
Line 28: Line 101:
  
 
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:
 
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
 
  
{{Common bugs issue|cockpit-ad-join|Joining Active Directory domain from Cockpit as non-root user fails with error "Not authorized to perform this action"|2006028}}
+
ipa-dns-install --disable-dnssec-master
{{Common bugs update testing|FEDORA-2021-55aee7fb50}}
+
 
 +
{{Common bugs issue|zabbix|Zabbix web interface does not work|2020292}}
  
If you attempt to enrol a system in an Active Directory domain using Cockpit, it may fail with the error "Not authorized to perform this action", even after gaining administrative privileges. To work around this problem, you can refresh the page after gaining administrative privileges, or log in to Cockpit directly as root.
+
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 ==
 
== ARM and Aarch64 issues ==
{{Common bugs issue|jetson-mesa|GNOME (and likely other graphical environments) fail to start on Jetson Nano|1989726}}
 
  
Due to a known issue in the 3D graphics stack, GNOME - and likely other graphical environments and applications - do not run on the Jetson Nano board in Fedora 35 Beta. This means you cannot boot Workstation or other graphical images on the device. We regret that it was not possible to resolve this issue in a reasonable time frame for the Beta release. We are hoping to find a way to fix it before the Final release.
+
{{Common bugs issue|f35-rpi-vc4|Raspberry Pi 4 GUI frequently locks up with the Workstation Edition|2008557}}
  
{{Common bugs issue|f35-rpi|Raspberry Pi Boards will not start without being connected to a monitor|1894241}}
+
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:
  
An HDMI monitor must be connected to Raspberry Pi boards to boot successfully. To boot headless after completing initial-setup, add {{code|1=hdmi_force_hotplug=1}} to {{filename|/boot/efi/config.txt}}. This is due to an [https://www.spinics.net/lists/arm-kernel/msg922521.html upstream regression ] and will be fixed in a kernel update.  
+
echo "blacklist vc4" >> /etc/modprobe.d/blacklist-vc4.conf
  
{{Common bugs issue|f35-rpi-vc4|Raspberry Pi 4 GUI frequently locks up with the Workstation Edition|2008557}}
+
{{Common bugs issue|gis-wireless-keyboard|Wireless keyboards might not work in GNOME Initial Setup on aarch64|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.
 +
 
 +
{{Common bugs issue|aarch64-openstack-hang|Cloud instances hang occasionally in Openstack on aarch64|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.
 +
 
 +
{{Common bugs issue|initial-setup-skip|Non-GNOME initial setup utility does not require you to create a root password or admin account|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 {{package|gnome-initial-setup}}; in all other cases it is the separate {{package|initial-setup}} application.
 +
 
 +
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 {{code|1=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 {{command|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 ==
 +
 
 +
{{Common bugs issue|libvirt-cursor-offset-resolution-change|Mouse cursor position is incorrect if you change display resolution in a virtual machine|2006746}}
  
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 '{{code|1=echo "blacklist vc4" >> /etc/modprobe.d/blacklist-vc4.conf}}'.
+
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.
  
== Software issues ==
+
{{Common bugs issue|kde-no-shared-clipboard|Clipboard is not shared with KDE virtual machines|2016563}}
{{Common bugs issue|older-toolboxes|Cannot run Fedora 33 or 34 toolbox containers in Fedora 35|1995439}}
 
  
It has been reported that trying to run a Fedora 33- or Fedora 34-based toolbox container on Fedora 35 - commonly used on OSTree-based systems like Silverblue and Kinoite - fails with an "invalid entry point PID" error. A fix for this is being worked on [https://github.com/containers/toolbox/pull/829 upstream], but until that is done, there is no known workaround for the problem. You can only use a Fedora 35-based toolbox container on Fedora 35 for now.
+
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.

Latest revision as of 00:01, 15 December 2021

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.

Idea.png
New Common Issues experiment underway...

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

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

Idea.png
Update available for testing
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-f7d19c8901

If 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

Idea.png
Update available for testing
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-35e9884fd8

If 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 Package-x-generic-16.pnggnome-initial-setup; in all other cases it is the separate Package-x-generic-16.pnginitial-setup application.

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.

Clipboard is not shared with KDE virtual machines

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.