This page documents common bugs in Fedora 25 and, if available, fixes or workarounds for these problems. If you find your problem in 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 25 release announcement and the Fedora 25 release notes for specific information about changes in Fedora 25 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).
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.
In most cases this check is not necessary. If you are not planning to make any changes to the existing filesystems as part of your installation, or you already know they are clean, you can use an updates image which disables the check. To use it, boot the install media normally, but at the bootloader screen, edit the boot parameters and add inst.updates=https://www.happyassassin.net/updates/1170803.0.img.
Dual booting Windows fails with 'relocation failed' error on some UEFI systems
link to this item - Bugzilla: #1347291
On some hardware, it's not possible to start Windows (possibly even some other OSes) from GRUB boot menu when booting over UEFI (it does not happen in BIOS mode). The message says error: relocation failed. The problem is still being investigated.
As a workaround, you can use your UEFI boot menu (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc) to boot Windows, which should work fine.
Advanced users can download and install grub2-2.02-0.25.fc23 (grub2 from Fedora 23), which should immediately fix the problem. However, when using this solution, the broken version of grub2 from Fedora 25 will be offered to you with every new system update, and you'll need to manually exclude it every time. There is also a Fedora 25 scratch build with a patch which should address this issue. However, this is not signed for Secure Boot use, so you cannot use it if you have Secure Boot enabled.
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 happens only with UEFI. User can use UEFI boot menu as a workaround (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc).
This bug appears just when UEFI and firmware RAID is used. So BIOS installations and normal disks (or with FW RAID turned off) shouldn't be affected.
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.
OS X volumes using Apple Core Storage are not recognized by the installer and shrinking them destroys all data
link to this item - Bugzilla: #1033778
The installer appears to support volume shrink for OS X volumes (Apple Core Storage) by offering a Shrink button and sizing slider in Automatic partitioning; and likewise allow numeric resizing in Manual partitioning. However, setting the installer to resize these volumes and proceeding with installation will result in complete data loss of the volume. Resize the volume in OS X's Disk Utility to create free space before proceeding with the installation of Fedora.
Live installer crashes on attempt to add iSCSI target
link to this item - Bugzilla: #1395620
If you attempt to add an iSCSI target as a storage device for an install when running the installer from the Fedora Workstation 25 live image (or probably any other live image), the installer will likely crash with the error TypeError: Argument 1 does not allow None as a value. This error is caused by a missing dependency. 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
DNF upgrade might remove essential system packages if you used PackageKit (GNOME Software, KDE Apper) in the past
link to this item - Bugzilla: #1259865
There was an unfortunate situation in the past few Fedora releases where PackageKit and DNF didn't work well together. If you installed something via PackageKit (used by GNOME Software or KDE Apper), it didn't mark such packages as "user installed" in the DNF database (which is used to differentiate user-requested packages from other packages installed purely as a dependency, but not explicitly requested by the user). Similarly, if you updated your system using PackageKit (GNOME offline updates, Apper), it erased such "user installed" flags from all updated packages. DNF then tries to remove any unnecessary packages during its next transaction (or when specifically asked using sudo dnf autoremove). This might lead to removing core system packages because DNF no longer sees them as "user installed" and considers them a no-longer-needed dependency. It is also possible that this might happen to you when performing a system upgrade to Fedora 25.
Fedora 25 hasn't been affected by this bug at all, and it was fixed in Fedora 23 and 24 since libhif-0.2.2-3. Current use of PackageKit (GNOME Software, Apper) should be safe. However, if you have ever used these tools in the past, you're strongly advised to fix your "user installed" database before you try to upgrade to Fedora 25:
- First, make sure your libhif package version is the same as described above or newer:
rpm -q libhif
If not, update it, and check again:
sudo dnf --refresh update libhif
Reboot after update. - Then, mark all your current packages as "user installed" using this command:
rpm -qa --qf '%{NAME}\n' | xargs sudo dnf mark install
Please note that this solution is slightly excessive, because you're going to end up with all your packages considered either system essential or user requested, and none of them is ever going to be removed as a no-longer-needed dependency. However, this is the only way how to be absolutely sure that you're not going to be affected by this issue, at a relatively small cost (some packages might stay on your disk unnecessarily). Power users can tweak this solution according to their needs.
Frozen gray screen during logging in after upgrade
link to this item - Bugzilla: #1394755
In certain configurations, you might not be able to log in after upgrade from Fedora 24. Once you provide your password and confirm, the screen will stay gray and the mouse pointer will get stuck, and nothing else will happen. If this happens to you and you're moderately technically skilled, we would welcome your feedback in bug 1394755 and test mailing list (see the instructions).
The existing workaround is to select Xorg session in the session picker (see #Wayland issues) and log in at least once. Then it should be possible to log in even to Wayland session.
Core system 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):
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).
Most Qt 5 apps crash under Wayland when displaying a file dialog if you don't have qgnomeplatform installed
link to this item - Bugzilla: #1392605
If you've upgraded your system from Fedora 23 or older, you might not have qgnomeplatform package installed. As a consequence, Qt 5 apps crash when trying to display a file dialog under Wayland. The workaround is to install qgnomeplatform package:
$ sudo dnf install qgnomeplatform
GNOME freezes frequently with 3 monitors on Wayland
There are frequent freezes of GNOME when using 3 monitors at the same time. This is confirmed at least on several ThinkPad series laptops with Intel graphics. See gnome bug 774557 for more details.
Current workaround is to use 2 monitors at maximum, or use X11 session instead of Wayland.
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
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
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.
GNOME Wayland session does not start a login shell, so does not process .bash_profile or .bashrc etc.
Unlike GNOME-on-Xorg, the GNOME-on-Wayland session is not run through a login shell. This means that some configuration shell scripts which are sourced for login shells, like /etc/profile, /etc/profile.d/*, ~/.bash_profile and ~/.bashrc are not sourced for the GNOME session, and most applications run from the GNOME session will not have those settings applied. By default, GNOME Terminal sessions will source ~/.bashrc, which sources /etc/bashrc, which sources /etc/profile.d/*. However, they will not source ~/.bash_profile or /etc/profile.
There is no exact convenient 'workaround' for this to simply have login shell settings applied to a GNOME-on-Wayland session.
- You can set environment variables in
/etc/environment(simple ENVVAR=value format): these settings are respected. - There are various alternatives to setting things using these shell scripts, e.g. running things on session startup by using desktop files in
~/.config/autostartor/etc/xdg/autostart.
There is much more detailed discussion of the consequences of this change and possible workarounds in the upstream bug report.
Fedora Workstation issues
Running processes are killed when logging out of GNOME
link to this item - Bugzilla: #1394937
If you log out from GNOME, all your apps and processes will be immediately killed (receiving a SIGKILL signal) without getting chance to save their state (receiving a SIGTERM first). A systemd update is being prepared. Be sure to save your work and ideally even close your apps in a standard way before logging out until then.
First login attempt, and every second attempt after that, fails
link to this item - Bugzilla: #1384508
Testing of Fedora Workstation 25 so far suggests that if a certain GNOME configuration setting is set, the first attempt to log in as a given user after each boot will fail, and every second attempt after that will fail. The symptom is that you enter a user name and password, the system works for a while, then returns you to the login screen; a second attempt to log in succeeds. If you see this problem, try running gsettings set org.gnome.SessionManager auto-save-session false as your regular user after logging in. We believe it should resolve the problem. This is most likely to occur on systems which have been upgraded across several releases.
Certain Qt 5 apps (VLC, Calibre) are scaled up or down when they should not be
link to this item - Bugzilla: #1381828
Certain Qt 5 apps like VLC or Calibre are configured to use window scaling for high DPI monitors. However, the implementation scales the applications even on some standard (Full HD) monitors. It also further adjust the scaling if you have several monitors attached. In the end you might see a very huge or a very tiny widgets/fonts.
There is no known workaround at the moment.
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, Evolution) 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) and the Evolution mail composer (again, in the mail text itself, not the rest of the user interface). Text in these widgets will appear the size it would be with a scaling factor of 1, rather than the factor the user configured.
To work around this issue in gedit you can just set a custom font in Preferences and make its point size larger than normal. There is no known workaround for the Evolution composer at this point in time.
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
External displays are not disconnected after undocking
link to this item - Bugzilla: #1392885
If you use a docking station with an external display attached and undock your laptop, the system will think the external display is still connected and will not automatically make the screen disappear (but you won't be able to see its contents). You can manually disable the screen using your desktop's configuration tools.
This is only a problem for Live environment and clean installs (with kernel-4.8.6-300.fc25). It has been fixed in kernel-4.8.7-300.fc25, which is available as an update.
Application issues
ARM issues
Fedora Server issues
PHP web applications cause many SELinux 'execmem' denials
link to this item - Bugzilla: #1398474
If you run PHP webapps on a Fedora Server 25 server, unless you change the httpd_execmem SELinux boolean from 0 (the default) to 1, you will likely see a large number of SELinux denials for the execmem action for your HTTP server. This appears to be caused by a new feature in PHP 7, just-in-time compilation of PCREs (perl-compatible regular expressions).
There are two known workarounds at present. As mentioned, you can allow HTTP servers the execmem action, by running setsebool -P httpd_execmem 1. This will allow PHP applications to work without any changes and without any SELinux denials, but it does slightly reduce safety. Alternatively, you can disable the PCRE JIT compilation feature, by placing the line pcre.jit=0 in a config file under /etc/php.d.
As well as the Fedora bug report, there is an upstream pcre report tracking this issue.
SELinux prevents SpamAssassin (spamd) accessing /var/spool/mail
link to this item - Bugzilla: #1398437
This issue may commonly be encountered by mail servers running Fedora Server 25. If you have a mail server using SpamAssassin in a typical configuration, you may find that SELinux prevents spamd and its child processes (which may be identified by a long alphanumerical string like 7370616D64206368696C64 in the logs) from accessing /var/spool/mail. If you monitor your system and audit logs you may see several AVCs denying various processes with the context system_u:system_r:spamd_t:s0 from accessing paths with the context system_u:object_r:mail_spool_t:s0: these are all cases of this same problem.
This will likely prevent various SpamAssassin features from working as intended, though we haven't exhaustively investigated the precise effects of the issue. It certainly prevents the Razor plugin from working correctly.
To work around this without setting SELinux to permissive mode, you can generate a custom policy with audit2allow. A .te file like this should work:
module 1398437-workaround 1.0;
require {
type mail_spool_t;
type spamd_t;
class dir { add_name create getattr open read remove_name search write };
class file { append create getattr ioctl open read unlink write };
}
#============= spamd_t ==============
allow spamd_t mail_spool_t:dir { add_name create getattr open read remove_name search write };
allow spamd_t mail_spool_t:file { append create getattr ioctl open read unlink write };
Fedora Cloud 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.
Resolved issues
Fedora Media Writer shows Fedora 24 instead of Fedora 25 by default
link to this item - Bugzilla: #1397461
This issue is fixed in Fedora Media Writer 4.0.7 and later. This version is now a released update for all supported Fedora releases and it (or a later version) are offered for download for Windows and macOS from getfedora.org, so new Fedora 25 users should no longer encounter this bug.
Fedora Media Writer is the new tool for creating installation media (usually, USB flash drives). In version 4.0.4, as was available at getfedora.org on release day, if you immediately select Fedora Workstation, the default release was Fedora 24, rather than Fedora 25. You can click on "Version 24" to change this. In all other Editions and Spins (Fedora Server, KDE Plasma Desktop, etc.), Fedora 25 was correctly selected by default, and, if you chose one of these and then return to Workstation, F25 would now be the default there too.