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.
- 1 Release Notes
- 2 My bug is not listed
- 3 Installation issues
- 4 Upgrade issues
- 5 Core system issues
- 6 GNOME issues
- 6.1 Wayland issues
- 6.2 Running graphical apps with root privileges (e.g. gparted) does not work on Wayland
- 6.3 Totem fails to play media on Wayland in virtual machines
- 6.4 Vino server (remote desktop server) crashes on login under Wayland
- 6.5 Screen recording freezes GNOME in certain conditions
- 6.6 Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland
- 6.7 Workstation login screen (GDM) does not show newly-installed desktops until system is rebooted or shut down
- 6.8 Some text views (gedit...) not properly scaled when Large Text or a text scaling factor set
- 7 Plasma (KDE) issues
- 8 Network issues
- 9 Hardware issues
- 10 Application issues
- 11 ARM issues
- 12 Fedora Server issues
- 13 Fedora Cloud issues
- 14 Fedora Atomic issues
- 15 Other issues
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)
Switching keyboard layout with key combo does not work in Wayland
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+ or + ). 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
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(or right ) 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
On many or all Fedora 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.
Frozen gray screen during logging in after upgrade
Every second login attempt fails in certain configurations
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 crash case.
GRUB update might fail if /boot is on XFS
If you use XFS filesystem on
/boot and upgrade your system, you might end up in a GRUB minimal prompt (just a command prompt, no kernel to choose from interactively) after the upgrade is complete. The problem is in the system rebooting while XFS is in dirty state and not all changes being saved to the filesystem yet.
In order to prevent this issue, you might try to disable plymouth (by removing
rhgb kernel boot option) during the upgrade or uninstall it prior the upgrade (these workarounds were not tested).
If this already occurred to you, you should be able to fix the problem by booting a Live or rescue image, mounting the filesystem in question (which should replay the journal), perhaps running
xfs_repair to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.
Core system 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
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
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 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.
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
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
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
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
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
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)
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).
Kerberos might be broken in certain cases
Kerberos doesn't work in certain configurations on Fedora 27, probably on some upgraded systems and when
is installed. You'll see errors like
Internal credentials cache error while getting default ccache. If you're affected, removing
/var/lib/sss/secrets/secrets.ldb file and rebooting seems to help.
Network configuration file from image creation on AArch64 disk images
A network configuration file from the disk image creation process is still present on the aarch64 disk images and can be safely removed to prevent any conflicts.
Unable to log in on the KDE disk image after completing Initial-Setup
After completing the Initial-Setup utility on the armhfp KDE disk image you will need to install additional packages in order to log in to the desktop. Connect to tty2 and log in as root or ssh to the system from another computer and install 'KDE plasma desktop'.
dnf install plasma-desktop
Root password listed as 'set' in Initial-Setup TUI on AArch64 disk images
For security, the root account is 'locked' during the aarch64 disk image creation. As a result, the initial-setup configuration utility incorrectly lists the password for the root account as 'set'. Users should take care to either set the root password or to create a user account with Administrator privileges.
There is no network on the Pine 64 with AArch64 disk images
When booting the AArch64 disk images on the Pine 64 you will not have a network connection. To correct this issue create a symlink named 'dtb' pointing to the installed kernel dtb directory (dtb-4.13.9-300.fc27.aarch64) and reboot the system.
cd /boot; ln -sf dtb-4.13.9-300.fc27.aarch64 dtb
Fedora Server issues
Fedora Cloud issues
Fedora Atomic issues
Hibernation doesn't work from a standard install
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
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 , , , or ) 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 to edit the boot menu, and replace
initrd keywords with
initrdefi, then press + or to boot it.
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
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.