Common F26 bugs

In other languages: English (en) español (es) [edit]

This page documents common bugs in Fedora 26 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.

Pre-release version
Fedora 26 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 26 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).

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

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

Disk initialization in installer can take a very long time if large ext filesystems are present

link to this item - Bugzilla: #1170803

When checking existing disks prior to installation, the installer runs an e2fsck (filesystem consistency check) on all ext2/3/4 filesystems. For large (1TB+) filesystems, this can take hours to finish. There is no obvious indicator that this is occurring, but if you know your system has large ext filesystems and the installer pauses for a long time when starting up, this is likely the cause.

Windows entry is missing in grub when systems are installed on firmware RAID on UEFI system

link to this item - Bugzilla: #1347273

When Fedora is installed beside Windows on the firmware RAID and on UEFI it could happen that there will be Windows entry missing in grub menu.

This bug occurs only when UEFI and firmware RAID are used, so BIOS installations and normal disks (or with FW RAID turned off) shouldn't be affected. In most cases, you can use the UEFI boot menu as a workaround. Different systems (different firmwares, in fact) offer access to the UEFI boot menu in different ways, so we cannot provide exact instructions, but often a one-time boot menu is reachable via some hotkey like Esc, F8, F11, F12 at boot time. The UEFI boot menu should offer an option to boot Windows or Fedora.

Fedora fails to install on some RAID setups

link to this item - Bugzilla: #1333131 - Bugzilla: #1259953 - Bugzilla: #1382274

On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash.

• If you try to create a RAID array during setup on a system that has an existing RAID configuration using the drives from that previous RAID array, the newly-created one gets produced incorrectly and is unusable (and of course, the one you deleted is no longer there). User can restart and try again on the same selected drives (this time using free space) as workaround.
• The installer might crash on startup with certain non-intel firmware RAIDs. No further details are known at the moment.

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.

32-bit installer incorrectly calculates space that will be freed when removing devices

link to this item - Bugzilla: #1375732

If you use a 32-bit Fedora 26 image and attempt to free up space for an installation by deleting filesystems or other storage devices, you may find that the installer incorrectly calculates the space that will be freed and refuses to proceed as it does not believe sufficient space will be available.

To work around this, you can remove the devices with some other tool (e.g. gnome-disks or blivet-gui or parted) from a live or rescue environment before running the installer.

Please remember that i686 is no longer a release-blocking architecture for Fedora (since Fedora 24). We recommend the use of x86_64 wherever possible.

GNOME issues

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.

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

GNOME "Oh no!" screen (displayed when a core GNOME component fails) crashes

link to this item - Bugzilla: #1384508

When a core GNOME component (e.g. gnome-session or gnome-shell) fails, GNOME attempts to run something called gnome-session-failed, which displays a screen saying "Oh no! Something has gone wrong". However, in Fedora 26, gnome-session-failed itself can quite often crash. When this happens, you will see a crash report which links back to bug #1384508. This bug actually covers the crash of the "Oh no!" screen: it does not cover whatever failure caused GNOME to attempt to display the "Oh no!" screen in the first place. Many different people following the bug actually appear to have encountered different issues and hit the same "Oh no!" screen crash. One particular case we are aware of is this one, to do with session auto-saving being enabled, but it's clear some reporters are arriving at the "Oh no!" screen crash via a different route.

If you are in this position, if possible, please see if you can ascertain what failure caused GNOME to try and run gnome-session-failed in the first place, as that is likely the problem that really matters to you. Running journalctl -b as the user who encountered the problem may well help, as the GNOME session should log what the critical component failure was. Then see if you can find a bug report for the failure, and if not, please file a new one, with Fedora or GNOME upstream.

We will of course attempt to fix the "Oh no!" screen crash, but fixing that will not resolve whatever problem causes the screen to appear in the first place - it will just mean that you actually see the "Oh no!" screen.

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

link to this item

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.