This page documents common bugs in Fedora 27 and, if available, fixes or workarounds for these problems. If you find your problem on 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 Fedora 27 release announcement and the Fedora 27 release notes for specific information about changes in Fedora 27 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
Switching keyboard layout with key combo does not work in Wayland
link to this item - Bugzilla: #1389959
If you're running Workstation Live install media and configure multiple languages in the installer, you won't be able to switch between them using the standard system shortcut (typically ⊞ Win+Space or Alt+⇧ Shift). However, you can still click on the language indicator in the installer with the mouse and that will switch the languages.
This does not affect other install media (KDE Live, DVD and netinst images).
macOS can't be booted from grub
link to this item - Bugzilla: #893179
If you install Fedora into dual-boot on a Mac, Fedora creates several "Mac OS X" menu items in grub that should allow you to boot macOS. These menu items are broken, however, and macOS can't be booted from grub. The available workaround is to press and hold down the ⌥ Opt (or right Alt) key when starting the computer, which will show you UEFI boot menu, and select macOS partition to boot from there.
Installer on several live images does not offer iSCSI support
link to this item - Bugzilla: #1395620 - Bugzilla: #1429132
On many or all of the Fedora 26 Alpha live images, the installer will not offer iSCSI functionality (the "Add iSCSI target" button will not appear in the 'Specialized & Network Disks' screen). You can avoid the problem by running sudo dnf install storaged-iscsi
from a console before starting the install process, or by installing from a dedicated installer image rather than a live image.
Upgrade issues
gnome-software doesn't show F25->F27 upgrade even though it should
link to this item - Bugzilla: #1494061
GNOME Software doesn't offer the upgrade from Fedora 25 to Fedora 27. Possible workarounds are either to upgrade from Fedora 25 to Fedora 26 and then to Fedora 27 or to upgrade with DNF system upgrade.
dnf system-upgrade: dnf.exceptions.MarkingError: no package matched
link to this item - Bugzilla: #1490832
Upgrading with DNF system upgrade fails when using --enablerepo argument. The workaround is to enable all required repositories before starting the upgrade.
Frozen gray screen during logging in after upgrade
link to this item - Bugzilla: #1394755
This happens if you have EasyScreenCast extension installed and upgrade. It is the same bug as #screen-recording-freezes-gnome, see that entry for a full description and a workaround.
Every second login attempt fails in certain configurations
link to this item - GNOME bug #775463
If you've upgraded your system, you might see an issue where every second login attempt fails and you're returned to the login screen (without any visible error). This happens for Wayland sessions, but not for X11 sessions. Currently it seems this might be caused by org.gnome.SessionManager auto-save-session
gsettings value being true
instead of default false
. You can see your current value like this:
$ gsettings get org.gnome.SessionManager auto-save-session
and change it like this:
$ gsettings set org.gnome.SessionManager auto-save-session false
If you encounter this bug, you may see a crash notification that traces back to bug #1384508. This crash, and the bug report, actually cover a crash in the "Oh no!" screen which GNOME attempts to show when a core component crashes: the report doesn't actually cover the initial crash of the gnome-session component. This has caused some confusion, because the same "Oh no!" screen crash can be encountered in several other ways, and so several people with quite different bugs are all following the #1384508 bug report. See the entry for that crash for more details. GNOME bug #775463 is the bug report for this specific auto-save-session crash case.
Core system issues
GNOME issues
Wayland issues
Wayland is the replacement for the legacy X11 display stack. Although development has been rapid and Wayland is usable in most situations, some bugs remain. Please see the following link to learn the details:
Please check the list for your issue before you file a new bug, although if you're not sure, filing a new bug is the right thing to do.
Wayland is currently enabled by default only in GNOME. If you want to disable it, select GNOME on Xorg as session type when logging in (you only see this screen if your user has a password defined):
Running graphical apps with root privileges (e.g. gparted) does not work on Wayland
link to this item - Bugzilla: #1274451
Running graphical applications with root privileges does not work on Wayland. This is not exactly a bug, but an intentional design, at least at present: it is part of a general plan to make Wayland safer than X (which is very vulnerable to exploitation by malicious applications). It is generally intended that apps which need root privileges to perform some operations should be designed such that the application itself does not need root privileges, but uses a mechanism like PolicyKit to have privileges granted to a restricted subset of itself which only handles the operations that actually need elevated privileges.
This means you cannot run, for example, sudo gedit /etc/someconfigfile.conf
or sudo gvim /etc/someconfigfile.conf
to edit a file which requires root privileges to save. It also stops gparted
working by default at all, as it is designed to run with root privileges by default. There are various ways to work around different elements of this problem.
For applications which use the GTK+ Gvfs file access layer, there is an admin:/// resource indicator available. So you can, for example, run gedit admin:///etc/someconfigfile.conf
to edit a file requiring root privileges to save. In future, this mechanism will be better integrated into applications so you do not have to manually invoke it. This will not work for applications which do not use Gvfs, though, like gvim.
In other cases, you may be able to use an alternative application. For instance, you may find the Disks application (gnome-disks
from a console) can do what you wanted to do with gparted
.
There is a workaround you can use to allow non-Wayland-native apps to run as root if you absolutely must: from a console as the regular user, run xhost +si:localuser:root
. This will not work for Wayland-native applications, however, only apps which run via XWayland.
Finally, if none of these options is workable for you, you can switch back to using X.org instead of Wayland, as documented above.
Totem fails to play media on Wayland in virtual machines
link to this item - Bugzilla: #1467368
Totem (Videos) will fail to play media when using a Wayland session in virtual machines (applies to default libvirt VMs, but not VirtualBox). The audio will play, but neither video nor a totem window will appear. If you need to play media in this environment, please either use X11 session, or a different media player.
Vino server (remote desktop server) crashes on login under Wayland
link to this item - Bugzilla: #1394599
If you have configured a remote desktop server using vino-server (available e.g. in GNOME settings), you'll see a crash each time you log in into a Wayland session. Remote desktop functionality is not yet supported under Wayland. Either disable the remote desktop server (Settings -> Sharing -> Screen sharing) to avoid seeing the crash notifications or use Xorg session instead (if you require remote desktop functionality).
Screen recording freezes GNOME in certain conditions
link to this item - Bugzilla: #1394755
If you start screen recording in GNOME (Ctrl+Alt+Shift+R) your session might freeze hard (you can only get out of it using SysRq or ssh in and kill your session). This is related to gstreamer registry cache file (~/.cache/gstreamer-1.0/registry.x86_64.bin
) - when it is changed (might happen during a plugin update, or if you remove the file), this bug occurs. It is not only triggered by the integrated GNOME recorder, but also by extensions/tools like EasyScreenCast - in that case, the freeze occurs immediately during login.
The existing workaround is to select Xorg session in the session picker (see #Wayland issues) and log in at least once. That fixes the cache file and then it should be possible to log in even to Wayland session. It also helps to remove EasyScreenCast extension (if you have it installed), and remove clutter-gst2
package (but some of your apps might depend on it). If none of that helps for you, please continue using the Xorg session instead of the default Wayland session, until this bug is fixed.
Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland
link to this item - Bugzilla: #1386602
Under Wayland, sending scroll events into a virtual machine works well when using the mouse, but doesn't work when using touchpad or trackpoint. As a workaround, switch to Xorg session on your host.
Workstation login screen (GDM) does not show newly-installed desktops until system is rebooted or shut down
link to this item - Bugzilla: #1398770
If you install an additional desktop environment after installing Fedora Workstation, it will not appear on the session chooser in the login screen (GDM) if you simply log out from a user session and log in again. This is because gdm keeps running after logging you into your user session, and there is no signal to tell it that a new desktop has been installed; it will not notice until it is restarted. It is possible to restart GDM without restarting the system, but in practice rebooting or shutting down and starting up again is usually the easiest thing to do.
Some text views (gedit...) not properly scaled when Large Text or a text scaling factor set
Due to an issue with some specific text view widgets, when a 'text scaling factor' is set in GNOME, this scaling is not properly applied in a few specific cases. This makes text appear tiny. Setting the Large Text option in Universal Access sets a text scaling factor; it is also possible to set one manually in the gnome-tweak-tool
application, so if you have set either of those options, you will likely see this bug.
This issue is known to affect gedit (the text in the document being edited, not the user interface), anjuta, and latexila.
To work around this issue in gedit you can just set a custom font in Preferences and make its point size larger than normal. A similar workaround may be available for other affected apps.
Plasma (KDE) issues
Logging out second user kills first user's session on KDE in a virtual machine (QXL driver)
link to this item - Bugzilla: #1382001
When you live switch users, logging out the second user kills the first user's session. This only happens with QXL driver which is used in virtual machines by default (GNOME Boxes, virt-manager).
Network issues
Hardware issues
Application issues
ARM issues
Fedora Server issues
Fedora Cloud issues
Fedora Atomic issues
Other issues
Hibernation doesn't work from a standard install
link to this item - Bugzilla: #1206936
The systemd-hibernate generator used to handle resume from hibernate functionality expects a resume=/path/to/swap
in the kernel args. Anaconda does not add this into /etc/default/grub
and the dracut cmdline generator doesn't act in a way the systemd hibernate generator can locate the swap with the resume image.
To work around this, check the devmapper path to the swap via swapon -s
command and add it to the GRUB_CMDLINE_LINUX
entry in /etc/default/grub
, then regenerate the grub.cfg
file used:
- Via grub2-mkconfig:
- For BIOS systems:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
- For EFI systems:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
- For BIOS systems:
- Via grubby:
sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)
Booting other UEFI Linux distributions might not work from Fedora bootloader
link to this item - Bugzilla: #1353026
Certain people who have multiple Linux distributions installed (in UEFI mode on GPT disks) report they're not able to boot non-Fedora systems from Fedora bootloader. If this happens to you, please tell us in RHBZ #1353026. The workaround should be to use your UEFI firmware to display a one-time boot menu (often displayed with F8, F10, F11, F12 or Esc) and pick the system you want to boot. That will boot the system directly, without going through Fedora bootloader. If this is not available for you, you can try to select the OS you want to boot in the Fedora bootloader, hit e to edit the boot menu, and replace linux
and initrd
keywords with linuxefi
and initrdefi
, then press Ctrl+x or F10 to boot it.
livemedia-creator cannot create images from kickstarts using metalink repositories (including official kickstarts)
link to this item - Bugzilla: #1464843
If you try to use the official livemedia-creator
tool to create a live image using a kickstart based on one of the official Fedora kickstarts (from the fedora-kickstarts repository, or the fedora-kickstarts
package), you may find that it fails due to anaconda being unable to correctly set up the software source.
This is because the livemedia-creator+anaconda combination does not currently correctly handle kickstarts that specify repositories using metalink URLs. If you're wondering "in that case, how were the official images built?", the answer is that the repository definitions from the kickstart files are actually modified on-the-fly by the Fedora compose system before the images are built (in order to use a local disk repository that's produced as part of the compose process).
To work around this problem for now, modify the repository definition in your flattened kickstart to use a direct URL or a mirrorlist URL before starting your compose.