View source for Common F27 bugs

<!--
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}}</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}}

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 [[F27_release_announcement|Fedora 27 release announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/27/html/Release_Notes/ Fedora 27 release notes] for specific information about changes in Fedora 27 and other general information.

{{Common_bugs_header_shared}}

== Installation issues ==

{{Common bugs issue|anaconda-lang-switch|Switching keyboard layout with key combo does not work in Wayland|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 {{key press|Win|Space}} or {{key press|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).

{{Common bugs issue|grub-macos-broken|macOS can't be booted from grub|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 {{key press|Opt}} (or right {{key press|Alt}}) key when starting the computer, which will show you UEFI boot menu, and select macOS partition to boot from there.

{{Common bugs issue|anaconda-iscsi-live|Installer on several live images does not offer iSCSI support|1395620|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 {{command|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 ==
{{Common bugs issue|gnome-software-f25-f27|gnome-software doesn't show F25->F27 upgrade even though it should|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 [https://fedoraproject.org/wiki/DNF_system_upgrade DNF system upgrade].

{{Common bugs issue|upgrade-fails-with-enablerepo|dnf system-upgrade: dnf.exceptions.MarkingError: no package matched|1490832}}

Upgrading with [https://fedoraproject.org/wiki/DNF_system_upgrade DNF system upgrade] fails when using --enablerepo argument. The workaround is to enable all required repositories before starting the upgrade.

{{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}}

This happens if you have [https://extensions.gnome.org/extension/690/easyscreencast/ 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.

{{Common bugs issue|every-second-login-fails|Every second login attempt fails in certain configurations}}
- [https://bugzilla.gnome.org/show_bug.cgi?id=775463 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 <code>org.gnome.SessionManager auto-save-session</code> gsettings value being <code>true</code> instead of default <code>false</code>. You can see your current value like this:
<pre>$ gsettings get org.gnome.SessionManager auto-save-session</pre>
and change it like this:
<pre>$ gsettings set org.gnome.SessionManager auto-save-session false</pre>

If you encounter this bug, you may see a crash notification that traces back to bug #[[rhbug:1384508|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 #[[rhbug:1384508|1384508]] bug report. See [[#gnome-ohno-crash|the entry for that crash]] for more details. [https://bugzilla.gnome.org/show_bug.cgi?id=775463 GNOME bug #775463] is the bug report for this specific {{code|auto-save-session}} crash case.

{{Common bugs issue|grub-fail-xfs|GRUB update might fail if /boot is on XFS|1227736}}

If you use XFS filesystem on <code>/boot</code> 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 <code>rhgb</code> 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 <code>xfs_repair</code> to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.

== Core system issues ==

== GNOME issues ==

{{Common bugs issue|wayland-issues|Wayland issues}}

[https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 Wayland] is the replacement for the legacy [https://en.wikipedia.org/wiki/X_Window_System 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:
* [[Wayland_features|Wayland features status]]
* '''[[How_to_debug_Wayland_problems#known_issues|Known issues in Wayland]]'''
* [[How_to_debug_Wayland_problems#Looking_for_similar_reports|Bug reports related to Wayland]]

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

[[File:gdm-pick-x11.png|500px]]

{{Common bugs issue|wayland-root-apps|Running graphical apps with root privileges (e.g. gparted) does not work on Wayland|1274451}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->

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, {{command|sudo gedit /etc/someconfigfile.conf}} or {{command|sudo gvim /etc/someconfigfile.conf}} to edit a file which requires root privileges to save. It also stops {{package|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+ [https://wiki.gnome.org/Projects/gvfs ''Gvfs''] file access layer, there is an {{code|admin:///}} resource indicator available. So you can, for example, run {{command|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 ({{command|gnome-disks}} from a console) can do what you wanted to do with {{package|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 {{command|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.

{{Common bugs issue|totem-wayland-vms|Totem fails to play media on Wayland in virtual machines|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.

{{Common bugs issue|vino-crash-wayland|Vino server (remote desktop server) crashes on login under Wayland|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).

{{Common bugs issue|screen-recording-freezes-gnome|Screen recording freezes GNOME in certain conditions|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 [[QA/Sysrq|SysRq]] or ssh in and kill your session). This is related to gstreamer registry cache file ({{filename|~/.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 [https://extensions.gnome.org/extension/690/easyscreencast/ 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 <code>clutter-gst2</code> 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.

{{Common bugs issue|wayland-touchpad-scroll-in-vm|Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland|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.

{{Common bugs issue|gdm-session-add|Workstation login screen (GDM) does not show newly-installed desktops until system is rebooted or shut down|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.

{{Common bugs issue|text-scaling-gedit|Some text views (gedit...) not properly scaled when ''Large Text'' or a text scaling factor set}}

Due to [https://bugzilla.gnome.org/show_bug.cgi?id=774248 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 {{command|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 ==

{{Common bugs issue|kde-live-user-switching|Logging out second user kills first user's session on KDE in a virtual machine (QXL driver)|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 ==

{{Common bugs issue|hibernation-broken|Hibernation doesn't work from a standard install|1206936}}

The systemd-hibernate generator used to handle resume from hibernate functionality expects a <code>resume=/path/to/swap</code> in the kernel args. Anaconda does not add this into {{filename|/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 <code>swapon -s</code> command and add it to the <code>GRUB_CMDLINE_LINUX</code> entry in {{filename|/etc/default/grub}}, then regenerate the {{filename|grub.cfg}} file used:

* Via grub2-mkconfig:
** For BIOS systems: <pre>sudo grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
** For EFI systems: <pre>sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg</pre>
* Via grubby: <pre>sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)</pre>

{{Common bugs issue|grub-efi-other-linux|Booting other UEFI Linux distributions might not work from Fedora bootloader|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 {{bz|1353026}}. The workaround should be to use your UEFI firmware to display a one-time boot menu (often displayed with {{key press|F8}}, {{key press|F10}}, {{key press|F11}}, {{key press|F12}} or {{key press|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 {{key press|e}} to edit the boot menu, and replace <code>linux</code> and <code>initrd</code> keywords with <code>linuxefi</code> and <code>initrdefi</code>, then press {{key press|Ctrl|x}} or {{key press|F10}} to boot it.

{{Common bugs issue|livemedia-metalink|livemedia-creator cannot create images from kickstarts using ''metalink'' repositories (including official kickstarts)|1464843}}

If you try to use the official {{command|livemedia-creator}} tool to create a live image using a kickstart based on one of the official Fedora kickstarts (from the [https://pagure.io/fedora-kickstarts fedora-kickstarts repository], or the {{package|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.