From Fedora Project Wiki

(add 2011928 (aarch64 openstack hang))
(add 2015490 (initial-setup lets you out without admin privileges))
Line 93: Line 93:


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

Revision as of 23:16, 1 November 2021

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.

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

Release Notes

Read the F35 Beta release announcement 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

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". The upgrade process should take 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 from a terminal (not as root or with sudo), and everything should start working:

systemctl --user enable --now wireplumber                                                                                   


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

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


ARM and Aarch64 issues

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

link to this item - Bugzilla: #1894241

An HDMI monitor must be connected to Raspberry Pi boards to boot successfully. To boot headless after completing initial-setup, add hdmi_force_hotplug=1 to /boot/efi/config.txt. This is due to an upstream regression and will be fixed in a kernel update.

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.

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