From Fedora Project Wiki

mNo edit summary
(Issues updated with commonbugs-update)
 
(28 intermediate revisions by 7 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 34 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 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.


{{admon/note|Pre-release version|Fedora 34 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 34 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 ==
Read the [https://fedoramagazine.org/announcing-fedora-34/ F34 release announcement] and the [https://docs.fedoraproject.org/en-US/fedora/f34/release-notes/ Fedora Linux 34 release notes] for specific information about changes in Fedora Linux 34 and other general information.
 
{{Common_bugs_header_shared}}
<!-- == System issues ===
None remaining, therefore commented -->
 
== Installation issues ==
 
{{Common bugs issue|btrfs-rename-compression|Compression not enabled for btrfs subvolumes renamed during install|1952764}}
 
If you use the "custom" partitioning UI during installation of Fedora 34 and change the name of any btrfs subvolume, its line in {{filename|/etc/fstab}} will lack the intended {{code|compress<nowiki>=</nowiki>zstd:1}} mount option. This is benign, affecting only fstab entries, unless the subvolume is mounted as root ({{filename|/}}); 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


== Release Notes ==
# Change the subvolume name during installation.
Read the [https://fedoramagazine.org/announcing-the-release-of-fedora-34-beta/ F34 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 34 and other general information.
# (optionally, to enable compression during installation) Immediately after beginning the installation process proper, switch to a shell (ctrl-alt-f2) and run {{command|mount -o remount,compress<nowiki>=</nowiki>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 {{command|mount <nowiki>|</nowiki> grep btrfs}}.
# Modify {{filename|/etc/fstab}} post-install, either before or after rebooting from the install environment.
 
Workaround B: change the subvolume name change after installation
 
# Proceed with installation without changing the subvolume name.
# After installation, change the name of the root subvolume, and update the {{code|subvol<nowiki>=</nowiki>(NAME)}} setting on the appropriate line of {{filename|/etc/fstab}}.
NOTE: It is safe to rename actively mounted subvolumes.


{{Common bugs header shared}}
{{Common bugs issue|kbd-legacy-media|Some default keyboard layouts (Russian, Finnish...) not installed when they should be|1955162|1955793}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


== KDE issues ==
We have identified a problem with Fedora 34 media which can mean that the expected default console keyboard layout for some languages is not installed. This affects several languages and layouts, including Russian (ru layout) and Finnish (fi layout); it affects any case where the default layout we want to use is in the {{package|kbd-legacy}} package.


{{Common bugs issue|kde-live-update-notification|KDE live image shows update notifications|1939751}}
When installing from a live image, or from the Server DVD image without the additional remote Fedora repository enabled, the installer will configure the system to use the intended layout, but will not be able to install the {{package|kbd-legacy}} package, because due to an oversight it was left off the install media. This will result in the system using the 'us' console keyboard layout, though it may indicate that the 'ru' or 'fi' (etc.) layout is configured.


The Fedora 34 Beta KDE live image will notify you of available updates while running in live mode. Please do ''not'' respond to these notifications and install the updates, it is generally not a good idea to try and update the live system and may cause your session to crash or hang. Please only update installed systems.
If you are able to complete boot and log in using the 'us' layout, please do so, and then install the {{package|kbd-legacy}} package with a graphical package manager or by running {{command|sudo dnf install kbd-legacy}}. If you have encrypted system partitions, you should also run {{command|sudo dracut -f}} to regenerate the initramfs environment, as that is the environment used for partition decryption during boot. This should resolve the issue. If you would like to avoid it at install time, please install from a network install image, or from the Server DVD image but with remote repositories enabled; note that this will still not work for Finnish specifically, as that case suffers from a [https://bugzilla.redhat.com/show_bug.cgi?id=1955793 further bug in the installer].


== Upgrade issues ==
== Upgrade issues ==
Line 27: Line 49:
{{Common bugs issue|pipewire-upgrade-config|Audio may not work after upgrade to Fedora 34 if pipewire was previously installed|1931384}}
{{Common bugs issue|pipewire-upgrade-config|Audio may not work after upgrade to Fedora 34 if pipewire was previously installed|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 {{filename|*.conf}} files out of {{filename|/etc/pipewire}} and reinstalling pipewire with {{command|sudo dnf reinstall pipewire}}. You will then need to re-apply any customizations you had made to the configuration files.
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 {{filename|*.conf}} files out of {{filename|/etc/pipewire}} and reinstalling pipewire with {{command|sudo dnf reinstall pipewire pipewire-pulseaudio}}. You will then need to re-apply any customizations you had made to the configuration files.
 
{{Common bugs issue|iptables-upgrade-best|Upgrade does not install latest version of iptables, or fails on iptables if {{code|--best}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> is used|1953178}}
 
A complex issue involving an attempt to split the iptables package combined with Fedora's package group definitions means that you may encounter problems related to the {{package|iptables}} package when upgrading to Fedora 34, if it is installed and the "Common NetworkManager Submodules" package group is installed.
 
If you use the {{code|--best}} argument when upgrading - which is usually not necessary, and not recommended in the [[Upgrading]] page - the upgrade may fail, complaining it cannot install the "best update candidate". If you do not use {{code|--best}}, the upgrade should not fail, but you may notice it warns about the same thing, and installs an older version of iptables and related packages (1.8.7-3.fc34) rather than the newer versions available from the updates repository.
 
We are currently considering ways to resolve this issue, but it's actually quite difficult. To work around it, we recommend simply not using {{code|--best}}, allowing the upgrade to proceed and install the 1.8.7-3.fc34 package versions, and then updating again, which should install later versions (and remove the {{package|iptables}} package - it is no longer needed, its functionality is retained in other subpackages).
 
Another option is to remove the {{package|iptables}} package before upgrade, and yet a third option is to mark the problematic group as not being installed before upgrading, with {{command|dnf group mark remove networkmanager-submodules}}. If you do either of those, the upgrade should manage to upgrade directly to the latest packages.
 
== Workstation issues ==
 
{{Common bugs issue|gnome-terminal|GNOME Terminal, large selection can cause a crash|1929282}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
When making very large selections in GNOME Terminal, it can crash resulting in the loss of all Terminal instances. Upstream's current workaround is to limit select-all to visible text. Fedora is reverting that workaround, so it's possible very large selections will result in a crash.
 
== KDE issues ==
 
{{Common bugs issue|akonadi-upgrade-fail|Akonadi fails to start after upgrade to Fedora 34, preventing KMail etc. from working correctly|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 {{filename|~/.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.


== ARM and AArch64 issues ==
== ARM and AArch64 issues ==


{{Common bugs issue|console-output-aarch64|Console output not shown on monitor during boot on AArch64|1940163}}
{{Common bugs issue|cma-allocation|Desktop images may require CMA allocation for graphical display|1934576}}
 
Some ARM and AArch64 SBC's (single board computers) may require CMA (Contiguous Memory Allocator) allocation added to the kernel parameters. This can be added with the {{package|arm-image-installer}} by using the {{code|--args}} option or in the grub menu during boot. If required, {{code|1=cma=192M}} is sufficient for most desktops. Workstation uses a little more with {{code|1=cma=256M}} recommended.
 
== Application issues ==
 
== Resolved issues ==
 
{{Common bugs issue|nm-etc-vpn-avc|Constant SELinux alerts if {{filename|/etc/NetworkManager/VPN}} exists|1934725}}
{{Common bugs update released|FEDORA-2021-de55424c01}}
 
If the directory {{filename|/etc/NetworkManager/VPN}} exists on a Fedora 34 system and NetworkManager is enabled, SELinux denials will happen constantly as NetworkManager tries to watch that directory, and SELinux blocks it. The directory is likely to exist if your system began life as Fedora 25 or earlier. In most cases this directory is empty; if so, you can safely remove it, and the denials will stop.


During system boot on AArch64, console output is not shown on the monitor even if one is connected unless {{package|plymouth}} is installed. {{package|plymouth}} is installed by default with graphical desktop package sets, but not with non-graphical package sets like minimal or Fedora Server. Notably, if you have an encrypted system partition, the prompt to decrypt it will be sent to the serial console, not shown on the monitor. To work around this, you can install {{package|plymouth}} - if necessary via a kickstart or before rebooting from the installer - or use the serial console.
{{Common bugs issue|login-authselect-fingerprint-error|GDM login might fail with the error "fingerprint authentication didn't work"|1942443}}
{{Common bugs update released|FEDORA-2021-734b404996}}


{{Common bugs issue|raspi-3-slowboot|Raspberry Pi 3 series systems boot very slowly|1921924}}
After upgrading to Fedora 34, especially on a system that started life as a much older Fedora release (before Fedora 29), or a system where authentication configuration has been locally modified, Workstation users may see a login error message:
{{Common bugs update released|FEDORA-2021-84510c6f65}}
Sorry, fingerprint authentication didn't work. Please try again.
The error will appear even if you don't use fingerprint authentication and want to use a regular password instead.


Due to a bug in uboot, Raspberry Pi 3 series devices may boot Fedora 34 Beta very slowly and report several "failed to come online" errors; the bug is indeed that uboot fails to bring CPU cores beyond the first online, and this causes the slowness as a single core has to handle the entire boot process.
If you upgraded before the fix for this (see above) was released and are stuck, you can switch to a virtual console (e.g. {{key|Ctrl}}+{{key|Alt}}+{{key|F3}}), log in there, and update the system with {{command|sudo dnf --refresh update}}. After this, restart the system, and the bug should be resolved.


An update has been issued that resolves this problem, but it did not quite make the Beta release. To resolve the problem after initial deployment, ensure you have the updated uboot-tools installed, then run {{command|sudo rpi-uboot-update}}.
With the updated {{package|gnome-shell}} package, you still might see the warnings, but they will not prevent logging in from working. In order to fully resolve the issue and make the warnings go away, it is a good idea to reset your authconfig files to the default state, with {{command|sudo authselect select --force sssd with-fingerprint with-silent-lastlog}}.


== IoT Edition ==
{{Common bugs issue|kde-spice-vdagent|Copy/paste between host and Fedora 34 KDE guest using SPICE does not work|1951580}}
{{Common bugs update released|FEDORA-2021-05fdb1456c}}


{{Common bugs issue|iot-grub2|Boot failure after installing grub2-2.06~rc1-1.fc34|1940524}}
It was 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 {{command|spice-vdagent}} - did not work.


After installing the latest {{package|grub2}}, upgrades and package installations may fail to list any IoT ostree deployments in the grub menu, and only list a system firmware option. This is due to a small typo in the grub.cfg. To work around the issue look for the following line in {{filename|/boot/loader/grub.cfg}} :
{{Common bugs issue|libvirt-usb-not-recognized|USB devices forwarded from the host to a guest aren't recognized in a libvirt virtual machine|1950258}}
search --no-floppy --fs-uuid --set=root 5EB5-588D
{{Common bugs update released|FEDORA-2021-3880a7b7f9}}
And change to:
search --no-floppy --fs-uuid --set=boot 5EB5-588D


Note, change "--set=root" to "--set=boot". The UUID (5EB5-588D) may differ on your local system.
If you used a libvirt machine through virt-manager and tried to forward a USB device from the host to a guest (most likely a USB flash drive), the device might not be recognized correctly.

Latest revision as of 00:06, 25 September 2021

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.

Some default keyboard layouts (Russian, Finnish...) not installed when they should be

link to this item - Bugzilla: #1955162 - Bugzilla: #1955793

We have identified a problem with Fedora 34 media which can mean that the expected default console keyboard layout for some languages is not installed. This affects several languages and layouts, including Russian (ru layout) and Finnish (fi layout); it affects any case where the default layout we want to use is in the Package-x-generic-16.pngkbd-legacy package.

When installing from a live image, or from the Server DVD image without the additional remote Fedora repository enabled, the installer will configure the system to use the intended layout, but will not be able to install the Package-x-generic-16.pngkbd-legacy package, because due to an oversight it was left off the install media. This will result in the system using the 'us' console keyboard layout, though it may indicate that the 'ru' or 'fi' (etc.) layout is configured.

If you are able to complete boot and log in using the 'us' layout, please do so, and then install the Package-x-generic-16.pngkbd-legacy package with a graphical package manager or by running sudo dnf install kbd-legacy. If you have encrypted system partitions, you should also run sudo dracut -f to regenerate the initramfs environment, as that is the environment used for partition decryption during boot. This should resolve the issue. If you would like to avoid it at install time, please install from a network install image, or from the Server DVD image but with remote repositories enabled; note that this will still not work for Finnish specifically, as that case suffers from a further bug in the installer.

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 pipewire-pulseaudio. You will then need to re-apply any customizations you had made to the configuration files.

Upgrade does not install latest version of iptables, or fails on iptables if --best is used

link to this item - Bugzilla: #1953178

A complex issue involving an attempt to split the iptables package combined with Fedora's package group definitions means that you may encounter problems related to the Package-x-generic-16.pngiptables package when upgrading to Fedora 34, if it is installed and the "Common NetworkManager Submodules" package group is installed.

If you use the --best argument when upgrading - which is usually not necessary, and not recommended in the Upgrading page - the upgrade may fail, complaining it cannot install the "best update candidate". If you do not use --best, the upgrade should not fail, but you may notice it warns about the same thing, and installs an older version of iptables and related packages (1.8.7-3.fc34) rather than the newer versions available from the updates repository.

We are currently considering ways to resolve this issue, but it's actually quite difficult. To work around it, we recommend simply not using --best, allowing the upgrade to proceed and install the 1.8.7-3.fc34 package versions, and then updating again, which should install later versions (and remove the Package-x-generic-16.pngiptables package - it is no longer needed, its functionality is retained in other subpackages).

Another option is to remove the Package-x-generic-16.pngiptables package before upgrade, and yet a third option is to mark the problematic group as not being installed before upgrading, with dnf group mark remove networkmanager-submodules. If you do either of those, the upgrade should manage to upgrade directly to the latest packages.

Workstation issues

GNOME Terminal, large selection can cause a crash

link to this item - Bugzilla: #1929282

When making very large selections in GNOME Terminal, it can crash resulting in the loss of all Terminal instances. Upstream's current workaround is to limit select-all to visible text. Fedora is reverting that workaround, so it's possible very large selections will result in a crash.

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.

ARM and AArch64 issues

Desktop images may require CMA allocation for graphical display

link to this item - Bugzilla: #1934576

Some ARM and AArch64 SBC's (single board computers) may require CMA (Contiguous Memory Allocator) allocation added to the kernel parameters. This can be added with the Package-x-generic-16.pngarm-image-installer by using the --args option or in the grub menu during boot. If required, cma=192M is sufficient for most desktops. Workstation uses a little more with cma=256M recommended.

Application issues

Resolved issues

Constant SELinux alerts if /etc/NetworkManager/VPN exists

link to this item - Bugzilla: #1934725

Idea.png
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 the directory /etc/NetworkManager/VPN exists on a Fedora 34 system and NetworkManager is enabled, SELinux denials will happen constantly as NetworkManager tries to watch that directory, and SELinux blocks it. The directory is likely to exist if your system began life as Fedora 25 or earlier. In most cases this directory is empty; if so, you can safely remove it, and the denials will stop.

GDM login might fail with the error "fingerprint authentication didn't work"

link to this item - Bugzilla: #1942443

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

After upgrading to Fedora 34, especially on a system that started life as a much older Fedora release (before Fedora 29), or a system where authentication configuration has been locally modified, Workstation users may see a login error message:

Sorry, fingerprint authentication didn't work. Please try again.

The error will appear even if you don't use fingerprint authentication and want to use a regular password instead.

If you upgraded before the fix for this (see above) was released and are stuck, you can switch to a virtual console (e.g. Ctrl+Alt+F3), log in there, and update the system with sudo dnf --refresh update. After this, restart the system, and the bug should be resolved.

With the updated Package-x-generic-16.pnggnome-shell package, you still might see the warnings, but they will not prevent logging in from working. In order to fully resolve the issue and make the warnings go away, it is a good idea to reset your authconfig files to the default state, with sudo authselect select --force sssd with-fingerprint with-silent-lastlog.

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

link to this item - Bugzilla: #1951580

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

It was 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 - did not work.

USB devices forwarded from the host to a guest aren't recognized in a libvirt virtual machine

link to this item - Bugzilla: #1950258

Idea.png
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 used a libvirt machine through virt-manager and tried to forward a USB device from the host to a guest (most likely a USB flash drive), the device might not be recognized correctly.