From Fedora Project Wiki

(add 1394862 to upgrade-libdb entry)
(add 1572944)
 
(25 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<!--  
<!--
This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_prerelease]] at the time of page creation: <nowiki>{{subst:Common_bugs_header_prerelease}}</nowiki>. Please do this rather than copy/pasting. At the time a release goes stable, replace this entire header with a '''SUBSTITUTION''' of [[Template:Common_bugs_header_stable_release]]: <nowiki>{{subst:Common_bugs_header_stable_release}}</nowiki>.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.
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}}
{{autolang|base=yes}}


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


{{admon/note|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).}}
== Release Notes ==
Read the [[F26_release_announcement|Fedora 26 release announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/26/html/Release_Notes/ Fedora 26 release notes] for specific information about changes in Fedora 26 and other general information.


{{Common_bugs_header_shared}}
{{Common_bugs_header_shared}}
Line 21: Line 22:


When checking existing disks prior to installation, the installer runs an {{code|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.
When checking existing disks prior to installation, the installer runs an {{code|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.
There's a updates.img provided that should hopefully fix or improve this issue in [https://bugzilla.redhat.com/show_bug.cgi?id=1170803#c92 comment 92]. If you're affected, feel free to try it out and provide a feedback, thanks.


{{Common bugs issue|grub-windows-missing|Windows entry is missing in grub when systems are installed on firmware RAID on UEFI system|1347273}}
{{Common bugs issue|grub-windows-missing|Windows entry is missing in grub when systems are installed on firmware RAID on UEFI system|1347273}}
Line 42: Line 45:


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.
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.
{{Common bugs issue|anaconda-realmd-clock|System time incorrect after kickstart install with FreeIPA domain enrolment (can break domain user authentication)|1433560}}
Fedora 26 testing indicates that, if you use the ability to enrol a system into a FreeIPA domain during a kickstart (scripted) install, the system clock may well be set incorrectly after the install completes. As accurate time is critical to Kerberos, this can prevent authentication as a domain user from working until the system clock is corrected.
You can run something like {{command|ntpdate 0.fedora.pool.ntp.org}}, as root, to correct the system clock. After this, domain operations should work as normal.


{{Common bugs issue|anaconda-32-shrink|32-bit installer incorrectly calculates space that will be freed when removing devices|1375732}}
{{Common bugs issue|anaconda-32-shrink|32-bit installer incorrectly calculates space that will be freed when removing devices|1375732}}
Line 75: Line 72:


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.
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.
{{Common bugs issue|upgrade-libdb|Upgrade may hang unless performed with {{code|libdb-5.3.28-21}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> or {{code|libdb-5.3.28-23}}+|1397087|1394862}}
Early testing of upgrades to Fedora 26 found that certain package scriptlets (scripts that run at various points during RPM transactions) can cause RPM to hang if the transaction also updates glibc or libpthread in such a way as to affect RPM's database (note that this is a rough summary of a rather complex issue: please read the relevant bug reports for more technical information).
Changes to address this problem were sent out to Fedora 24, 25 and 26 in the {{code|libdb-5.3.28-21}} build, which was pushed to stable for all three releases. However, subsequent reports indicated that updating to the -21 build could result in (recoverable) RPM database issues in some cases: see [[#libdb-rebuilddb|this other entry on this page]] for more information. We then created a -22 build with the upgrade issue fix reverted and sent it to updates-testing for all three releases; however, for various reasons we ultimately decided to stick with the -21 build and withdrew the -22 build from updates-testing. A -23 build will appear soon which includes the fixes again, plus an additional fix for a further upgrade-related issue.
All this is to say that, if you are upgrading to Fedora 26, please ensure you have ''either'' {{code|libdb-5.3.28-21}} ''or'' {{code|libdb-5.3.28-23}} or higher installed on the system prior to running the upgrade, and that the upgrade will install {{code|libdb-5.3.28-21.fc26}} or {{code|libdb-5.3.28-23.fc26}} or higher. We do not recommend attempting an upgrade that involves {{code|libdb-5.3.28-20}} or lower, or {{code|libdb-5.3.28-22}}, on either end. Due to the potential for error and confusion, we strongly recommend not upgrading any important systems to Fedora 26 at this time, at least until the {{code|libdb-5.3.28-23}} builds have been sent out and gone stable for all releases. This entry may be updated from time to time with newer information, so do keep an eye on it.
To ensure the correct version of libdb is installed prior to upgrading, try running {{command|1=dnf --disablerepo=updates-testing distro-sync}}. Ensuring the ''updates-testing'' repository is disabled during the upgrade process should also ensure an appropriate version is included in the upgrade transaction. If at any time you encounter RPM database errors, running {{command|rpm --rebuilddb}} should resolve them. Note that rebuilding the RPM database manually may result in its files having the wrong [[SELinux]] label: to fix this, run {{command|restorecon -RFv /var/lib/rpm}} as root after rebuilding the database.
{{Common bugs issue|upgrade-rich-deps|Upgrade from Fedora 26 to 27+ fails if upgraded version of any installed package has `with` rich dependencies|1551543}}
{{Common bugs update testing|FEDORA-2018-d4cacdf9bc}}
Between Fedora 26 and Fedora 27, upstream RPM added support for a `with` statement in rich dependencies. As the RPM version in Fedora 26 did not understand these dependencies, if you try to upgrade from Fedora 26, and for any package you have installed the upgraded version uses a `with` dependency, the upgrade will fail. The easiest way to work around this is just to use the updated RPM package that is currently in testing - see instructions above. With that update, the upgrade should work smoothly.


{{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}}
{{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}}
Line 90: Line 102:
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.
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|upgrade-libdb|Upgrade may hang unless performed with {{code|libdb-5.3.28-21}} or {{code|libdb-5.3.28-23}}+|1397087|1394862}}
{{Common bugs issue|stock-backgrounds-vanish|Stock GNOME backgrounds may vanish during upgrade}}
 
The collection of additional stock GNOME backgrounds was split out into ''gnome-backgrounds-extras''. If a user has one of these stock backgrounds installed, then after they upgrade and login, it's likely they'll see a blank background. The solution for this issue is easy: reinstall the stock backgrounds with the command {{code|dnf install gnome-backgrounds-extras}}.


Early testing of upgrades to Fedora 26 found that certain package scriptlets (scripts that run at various points during RPM transactions) can cause RPM to hang if the transaction also updates glibc or libpthread in such a way as to affect RPM's database (note that this is a rough summary of a rather complex issue: please read the relevant bug reports for more technical information).
== Core system issues ==
 
{{Common bugs issue|libdb-rebuilddb|RPM database errors after updating libdb|1460303|1394862}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->
 
The changes made to {{package|libdb}} to address the [[#upgrade-libdb|upgrade issue discussed above]] have been reported to sometimes cause issues in the RPM database when updating libdb itself. When this happens, any subsequent package-related operation will likely fail, with some kind of message indicating that there are problems with the RPM database. This can potentially happen on update from any earlier libdb version to {{code|libdb-5.3.28-21}} or {{code|libdb-5.3.28-23}} or later, on update from {{code|libdb-5.3.28-21}} to {{code|libdb-5.3.28-22}}, and on update from {{code|libdb-5.3.28-22}} to {{code|libdb-5.3.28-23}} or later.
 
Happily, the developers report that all such issues so far encountered should be easily, fully and safely recoverable. Usually simply running {{command|sudo rpm --rebuilddb}} should suffice; if not, try running {{command|sudo rm -rf /var/lib/rpm/__db*}} and then {{command|sudo rpm --rebuilddb}} again. Note that rebuilding the RPM database manually may result in its files having the wrong [[SELinux]] label: to fix this, run {{command|restorecon -RFv /var/lib/rpm}} as root after rebuilding the database.
 
{{Common bugs issue|vmware-guest-fail|Workstation fails to boot as a VMware guest|1468321}}


Changes to address this problem were sent out to Fedora 24, 25 and 26 in the {{code|libdb-5.3.28-21}} build, which was pushed to stable for all three releases. However, subsequent reports indicated that updating to the -21 build could result in (recoverable) RPM database issues in some cases: see [[#libdb-rebuilddb|this other entry on this page]] for more information. We then created a -22 build with the upgrade issue fix reverted and sent it to updates-testing for all three releases; however, for various reasons we ultimately decided to stick with the -21 build and withdrew the -22 build from updates-testing. A -23 build will appear soon which includes the fixes again, plus an additional fix for a further upgrade-related issue.
Pre-release testing indicates that Fedora 26 Workstation may frequently fail to reach the desktop when booted as a guest in the VMware virtualization system. Multiple testers reported failed attempts to boot Fedora 26 Workstation guests under VMware 12, where Fedora 25 booted successfully. We do not yet know whether the issue lies more on the Fedora side or the VMware side. We will continue to investigate this issue and work with VMware to resolve it.


All this is to say that, if you are upgrading to Fedora 26, please ensure you have ''either'' {{code|libdb-5.3.28-21}} ''or'' {{code|libdb-5.3.28-23}} or higher installed on the system prior to running the upgrade, and that the upgrade will install {{code|libdb-5.3.28-21.fc26}} or {{code|libdb-5.3.28-23.fc26}} or higher. We do not recommend attempting an upgrade that involves {{code|libdb-5.3.28-20}} or lower, or {{code|libdb-5.3.28-22}}, on either end. Due to the potential for error and confusion, we strongly recommend not upgrading any important systems to Fedora 26 at this time, at least until the {{code|libdb-5.3.28-23}} builds have been sent out and gone stable for all releases. This entry may be updated from time to time with newer information, so do keep an eye on it.
{{Common bugs issue|boot-random-block|Boot process is very slow or appears to hang with kernel 4.16.4 onwards|1572944}}


To ensure the correct version of libdb is installed prior to upgrading, try running {{command|1=dnf --disablerepo=updates-testing distro-sync}}. Ensuring the ''updates-testing'' repository is disabled during the upgrade process should also ensure an appropriate version is included in the upgrade transaction. If at any time you encounter RPM database errors, running {{command|rpm --rebuilddb}} should resolve them.
From version 4.16.4, the kernel (upstream: this issue is not Fedora-specific) [https://lkml.org/lkml/2018/4/12/711 is stricter] in determining when the kernel is "ready" to supply random numbers. Previously it indicated it was "ready" when the RNG was able to provide only a limited degree of randomness; now it indicates it is "ready" only when the RNG is able to provide randomness sufficient for cryptographic purposes. This was considered a [https://access.redhat.com/security/cve/cve-2018-1108 security issue].


== Core system issues ==
If any part of a system's boot process happens to involve blocking on this "readiness", the boot process will be delayed until the kernel indicates it is "ready", and of course with this change, that becomes more likely to happen. This is particularly likely to affect systems without access to a hardware random number generator and with only limited internal sources of entropy; in practice this means it commonly affects virtual machines and cloud instances. In particularly serious cases, the delay can be such that timeouts kick in and the system fails to boot fully.


{{Common bugs issue|libdb-rebuilddb|RPM database errors after updating libdb|1460303|1394862}}
If your system seems to boot fine with kernel 4.16.3 or earlier, but is slow to boot or appears to hang during boot with 4.16.4 and later, you may well be affected by this issue. You can try simply hitting random keys on the keyboard when the boot process appears to hang: this acts as a source of entropy and allows the kernel to seed its RNG. If you can get the boot process to continue after several seconds of keyboard mashing, this indicates you are suffering from this issue. It can also be a viable workaround in some cases, though of course not all.


The changes made to {{package|libdb}} to address the [[#upgrade-libdb|upgrade issue discussed above]] have been reported to sometimes cause issues in the RPM database when updating libdb itself. When this happens, any subsequent package-related operation will likely fail, with some kind of message indicating that there are problems with the RPM database. This can potentially happen on update from any earlier libdb version to {{code|libdb-5.3.28-21}} or {{code|libdb-5.3.28-23}} or later, on update from {{code|libdb-5.3.28-21}} to {{code|libdb-5.3.28-22}}, and on update from {{code|libdb-5.3.28-22}} to {{code|libdb-5.3.28-23}} or later.
For virtual machines and cloud instances, allowing the host to provide entropy to the VM/instance can help significantly, particularly if the host has a hardware RNG and this is configured as the source. The details of how to do this vary between virtualization systems and clouds. [https://wiki.openstack.org/wiki/LibvirtVirtioRng#Random_number_generator_device This page] documents how to do it in OpenStack. [[QA:Testcase_Virtualization_VirtioRNG|This test case]] includes some information on how to do it in libvirt. [https://wiki.qemu.org/Features/VirtIORNG This page] explains how to do it directly in qemu. Other virtualization systems may also support virtio-rng.


Happily, the developers report that all such issues so far encountered should be easily, fully and safely recoverable. Usually simply running {{command|sudo rpm --rebuilddb}} should suffice; if not, try running {{command|sudo rm -rf /var/lib/rpm/__db*}} and then {{command|sudo rpm --rebuilddb}} again.
A particularly severe form of this issue manifests itself if you boot with an initramfs generated while {{package|dracut-fips}} is installed. In this case the boot process will hang extremely early (at the time systemd starts up, so if any systemd activity has happened at all, you are already past this case), and the use of virtio-rng will not help (for VMs/cloud instances) as it is not yet loaded at this point. If you find yourself in this situation, it's probably best to remove {{package|dracut-fips}} and run {{command|sudo dracut -f}} to re-generate the initramfs for the current kernel. This form of the issue may potentially affect Fedora images generated with kernel 4.16.4 or later, but so far as we know, no official or semi-official images affected by this issue have yet been released.


== GNOME issues ==
== GNOME issues ==
Line 123: Line 145:
[[File:gdm-pick-x11.png|500px]]
[[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}}
{{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.
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.
Line 136: Line 158:


Finally, if none of these options is workable for you, you can switch back to using X.org instead of Wayland, as documented above.
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}}
{{Common bugs issue|vino-crash-wayland|Vino server (remote desktop server) crashes on login under Wayland|1394599}}
Line 146: Line 172:


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.
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|gnome-ohno-crash|GNOME "Oh no!" screen (displayed when a core GNOME component fails) crashes|1384508}}
When a core GNOME component (e.g. gnome-session or gnome-shell) fails, GNOME attempts to run something called {{code|gnome-session-failed}}, which displays a screen saying "Oh no! Something has gone wrong". However, in Fedora 26, {{code|gnome-session-failed}} itself can quite often crash. When this happens, you will see a crash report which links back to bug #[[rhbug:1384508|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 [[#every-second-login-fails|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 {{code|gnome-session-failed}} in the first place, as that is likely the problem that really matters to you. Running {{command|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.


{{Common bugs issue|wayland-touchpad-scroll-in-vm|Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland|1386602}}
{{Common bugs issue|wayland-touchpad-scroll-in-vm|Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland|1386602}}
Line 170: Line 188:


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.
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.
{{Common bugs issue|gdm-vesa-intel|Login screen locks up with VESA driver on Intel graphics cards|1467278}}
If you boot GNOME with Intel graphics card using the VESA driver (''basic graphics mode''), you might see just a gray screen instead of login screen (GDM). If possible, use a proper accelerated mode instead (it should work well with Intel graphics). If that is not possible, you have following options:
* If possible on your hardware, change from BIOS mode to UEFI mode. The UEFI fallback driver doesn't seem to cause these issues.
* Boot into runlevel 3 instead, edit <code>/etc/gdm/custom.conf</code> and uncomment <code>#WaylandEnable=false</code> (i.e. disable wayland support). That should avoid this issue.


== Plasma (KDE) issues ==
== Plasma (KDE) issues ==
{{Common bugs issue|sddm-xauth-hostname|System installed from KDE Live fails to boot to graphics on later reboots in certain networking setups (e.g. libvirt networking)|1370222}}
In certain networking setups (most notably with default libvirt NAT-style networking, e.g. when using virt-manager or gnome-boxes), a system install from KDE Live will boot the first time after installation, but later reboots will end up with a black screen and no graphical login screen. This is caused by dhcp server providing a network hostname to the machine and sddm (KDE login screen) crashing due to hostname changing during boot.
If you want to avoid this issue, you can:
* Set up a static hostname (something else than ''localhost'') in the installer before starting the installation.
* Install from Everything netinst image rather than KDE Live image.
If you're already affected by this issue, you can:
* Switch to TTY2, and set a new static hostname (something else than ''localhost'') using <pre>$ sudo hostnamectl set-hostname HOSTNAME</pre>
* Change the MAC address for your network controller, or remove and re-add the network card in case of VM (that will change its MAC address).
* Remove the old hostnames remember by libvirt, which are stored somewhere in ''/var/lib/libvirt/dnsmasq/''.


{{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}}
{{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}}
Line 181: Line 218:
== Hardware issues ==
== Hardware issues ==


== Application issues ==
{{Common bugs issue|nouveau-readfault-wayland|Wayland sessions crash on start on some NVIDIA graphics cards, logs show {{code|fifo: read fault}} error|1457626}}
 
Multiple users with NVIDIA graphics cards have reported an issue in Fedora 26 where the GNOME Wayland session (the default on the Workstation edition) crashes shortly after login. If you check the journal from the time of the crash, an error message containing the text {{code|fifo: read fault}} can be seen around the time of the crash.
 
The problem can be worked around by disabling Wayland, which you can do by editing the file {{filename|/etc/gdm/custom.conf}} and removing the leading {{code|#}} from the line {{code|1=#WaylandEnable=false}}. This is the only known way to avoid the problem at present.


Hardware reported to be affected so far includes:


{{Common bugs issue|glibc-unity3d|Games using the Unity engine freeze with black screen|1440287}}
* GeForce GTX 960 (GM206)
* Quadro K4200 (GK104GL)
* GeForce GTX 650 (GK107)
* GeForce GTX 760 (GK104)
* Quadro 4000 (GF100GL)
* Quadro 5000 (GF100GL)
* GeForce GTX 770 (GK104)


Trying to run a proprietary game from Steam or elsewhere, and it just gives you a blank black screen. You've hit this issue. A workaround is to install the {{package|jemalloc}} package (<code>sudo dnf install jemalloc</code>) and to add the line <code>export LD_PRELOAD=${LD_PRELOAD}:/usr/lib64/libjemalloc.so.2</code> to the startup script for the game (or to the startup script for Steam).
== Application issues ==


== ARM issues ==
== ARM issues ==
Line 212: Line 260:


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.
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.
== Resolved issues ==
{{Common bugs issue|gst-transcode-conflict|Upgrade may fail due to a conflict in gstreamer components|1467136}}
{{Common bugs update released|FEDORA-2017-366dfb242c}}
Due to a file naming conflict, the {{package|gstreamer1-plugins-entrans}} and {{package|gst-transcoder}} packages in the Fedora 26 distribution could not be installed together for a time. Attempting to install them simultaneously would result in dnf failing with a message similar to:
<pre>Error: Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgsttranscode.so from install of gst-transcoder-1.12.0-1.fc26.x86_64
  conflicts with file from package gstreamer1-plugins-entrans-1.0.3-2.fc26.x86_64</pre>
You would have encountered this error during the {{command|dnf system-upgrade download}} process, if the Fedora 25 system contained both {{code|gstreamer1-plugins-entrans}} (with or without its {{code|gst-entrans}} parent package) and {{code|gst-transcoder}} (which may also be pulled in automatically by other packages, including the {{package|pitivi}} video-editing software). If this was the case, {{command|dnf system-upgrade download}} would fail with the above conflict message before the process completed, even if {{command|--allowerasing}} was used. The issue could have been dealt with by removing one or other package temporarily, but since the update was released, this should no longer be necessary.
{{Common bugs issue|gnome-ohno-crash|GNOME "Oh no!" screen (displayed when a core GNOME component fails) crashes|1384508}}
{{Common bugs update released|FEDORA-2017-782a98300e}}
When a core GNOME component (e.g. gnome-session or gnome-shell) fails, GNOME attempts to run something called {{code|gnome-session-failed}}, which displays a screen saying "Oh no! Something has gone wrong". However, in Fedora 26, {{code|gnome-session-failed}} itself could quite often crash. When this happened, you would see a crash report which linked back to bug #[[rhbug:1384508|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 [[#every-second-login-fails|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 were in this position, if possible, please see if you can ascertain what failure caused GNOME to try and run {{code|gnome-session-failed}} in the first place, as that is likely the problem that really matters to you. Running {{command|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.
{{Common bugs issue|discover-crash-flatpak|Discover app crashes on start|1468239}}
{{Common bugs update released|FEDORA-2017-4adf59bd1c}}
The version of the ''Discover'' software management application included in the KDE spin by default is known to crash on startup. The update mentioned above fixes this crash, but of course the app will still crash if you attempt to launch it from the un-updated live image. There are a few ways to work around this problem: perhaps the easiest is to install the {{package|flatpak}} package, with {{command|sudo dnf install flatpak}}. You can also use the ''dnfdragora'' package management application instead, which is also included by default.
{{Common bugs issue|glibc-unity3d|Games using the Unity engine freeze with black screen|1440287}}
{{Common bugs update released|FEDORA-2017-ab2085210e}}
Trying to run a proprietary game from Steam or elsewhere could result in a blank screen on launch. If you are trying to run games from an original release live image and thus cannot update glibc, a workaround for the issue is documented in the bug report.
[[Category:Common bugs]]

Latest revision as of 22:58, 1 May 2018

This page documents common bugs in Fedora 26 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 26 release announcement and the Fedora 26 release notes for specific information about changes in Fedora 26 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
    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.

There's a updates.img provided that should hopefully fix or improve this issue in comment 92. If you're affected, feel free to try it out and provide a feedback, thanks.

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.

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.

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.

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 from Fedora 24 to Fedora 26.

Fedora 25 and 26 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 (and didn't follow these instructions when upgrading to Fedora 25), you're strongly advised to fix your "user installed" database before you try to upgrade to Fedora 26:

  1. 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.
  2. 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.

Upgrade may hang unless performed with libdb-5.3.28-21 or libdb-5.3.28-23+

link to this item - Bugzilla: #1397087 - Bugzilla: #1394862

Early testing of upgrades to Fedora 26 found that certain package scriptlets (scripts that run at various points during RPM transactions) can cause RPM to hang if the transaction also updates glibc or libpthread in such a way as to affect RPM's database (note that this is a rough summary of a rather complex issue: please read the relevant bug reports for more technical information).

Changes to address this problem were sent out to Fedora 24, 25 and 26 in the libdb-5.3.28-21 build, which was pushed to stable for all three releases. However, subsequent reports indicated that updating to the -21 build could result in (recoverable) RPM database issues in some cases: see this other entry on this page for more information. We then created a -22 build with the upgrade issue fix reverted and sent it to updates-testing for all three releases; however, for various reasons we ultimately decided to stick with the -21 build and withdrew the -22 build from updates-testing. A -23 build will appear soon which includes the fixes again, plus an additional fix for a further upgrade-related issue.

All this is to say that, if you are upgrading to Fedora 26, please ensure you have either libdb-5.3.28-21 or libdb-5.3.28-23 or higher installed on the system prior to running the upgrade, and that the upgrade will install libdb-5.3.28-21.fc26 or libdb-5.3.28-23.fc26 or higher. We do not recommend attempting an upgrade that involves libdb-5.3.28-20 or lower, or libdb-5.3.28-22, on either end. Due to the potential for error and confusion, we strongly recommend not upgrading any important systems to Fedora 26 at this time, at least until the libdb-5.3.28-23 builds have been sent out and gone stable for all releases. This entry may be updated from time to time with newer information, so do keep an eye on it.

To ensure the correct version of libdb is installed prior to upgrading, try running dnf --disablerepo=updates-testing distro-sync. Ensuring the updates-testing repository is disabled during the upgrade process should also ensure an appropriate version is included in the upgrade transaction. If at any time you encounter RPM database errors, running rpm --rebuilddb should resolve them. Note that rebuilding the RPM database manually may result in its files having the wrong SELinux label: to fix this, run restorecon -RFv /var/lib/rpm as root after rebuilding the database.

Upgrade from Fedora 26 to 27+ fails if upgraded version of any installed package has with rich dependencies

link to this item - Bugzilla: #1551543

Update available for testing
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command: sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2018-d4cacdf9bc

Between Fedora 26 and Fedora 27, upstream RPM added support for a with statement in rich dependencies. As the RPM version in Fedora 26 did not understand these dependencies, if you try to upgrade from Fedora 26, and for any package you have installed the upgraded version uses a with dependency, the upgrade will fail. The easiest way to work around this is just to use the updated RPM package that is currently in testing - see instructions above. With that update, the upgrade should work smoothly.

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.

Stock GNOME backgrounds may vanish during upgrade

link to this item

The collection of additional stock GNOME backgrounds was split out into gnome-backgrounds-extras. If a user has one of these stock backgrounds installed, then after they upgrade and login, it's likely they'll see a blank background. The solution for this issue is easy: reinstall the stock backgrounds with the command dnf install gnome-backgrounds-extras.

Core system issues

RPM database errors after updating libdb

link to this item - Bugzilla: #1460303 - Bugzilla: #1394862

The changes made to libdb to address the upgrade issue discussed above have been reported to sometimes cause issues in the RPM database when updating libdb itself. When this happens, any subsequent package-related operation will likely fail, with some kind of message indicating that there are problems with the RPM database. This can potentially happen on update from any earlier libdb version to libdb-5.3.28-21 or libdb-5.3.28-23 or later, on update from libdb-5.3.28-21 to libdb-5.3.28-22, and on update from libdb-5.3.28-22 to libdb-5.3.28-23 or later.

Happily, the developers report that all such issues so far encountered should be easily, fully and safely recoverable. Usually simply running sudo rpm --rebuilddb should suffice; if not, try running sudo rm -rf /var/lib/rpm/__db* and then sudo rpm --rebuilddb again. Note that rebuilding the RPM database manually may result in its files having the wrong SELinux label: to fix this, run restorecon -RFv /var/lib/rpm as root after rebuilding the database.

Workstation fails to boot as a VMware guest

link to this item - Bugzilla: #1468321

Pre-release testing indicates that Fedora 26 Workstation may frequently fail to reach the desktop when booted as a guest in the VMware virtualization system. Multiple testers reported failed attempts to boot Fedora 26 Workstation guests under VMware 12, where Fedora 25 booted successfully. We do not yet know whether the issue lies more on the Fedora side or the VMware side. We will continue to investigate this issue and work with VMware to resolve it.

Boot process is very slow or appears to hang with kernel 4.16.4 onwards

link to this item - Bugzilla: #1572944

From version 4.16.4, the kernel (upstream: this issue is not Fedora-specific) is stricter in determining when the kernel is "ready" to supply random numbers. Previously it indicated it was "ready" when the RNG was able to provide only a limited degree of randomness; now it indicates it is "ready" only when the RNG is able to provide randomness sufficient for cryptographic purposes. This was considered a security issue.

If any part of a system's boot process happens to involve blocking on this "readiness", the boot process will be delayed until the kernel indicates it is "ready", and of course with this change, that becomes more likely to happen. This is particularly likely to affect systems without access to a hardware random number generator and with only limited internal sources of entropy; in practice this means it commonly affects virtual machines and cloud instances. In particularly serious cases, the delay can be such that timeouts kick in and the system fails to boot fully.

If your system seems to boot fine with kernel 4.16.3 or earlier, but is slow to boot or appears to hang during boot with 4.16.4 and later, you may well be affected by this issue. You can try simply hitting random keys on the keyboard when the boot process appears to hang: this acts as a source of entropy and allows the kernel to seed its RNG. If you can get the boot process to continue after several seconds of keyboard mashing, this indicates you are suffering from this issue. It can also be a viable workaround in some cases, though of course not all.

For virtual machines and cloud instances, allowing the host to provide entropy to the VM/instance can help significantly, particularly if the host has a hardware RNG and this is configured as the source. The details of how to do this vary between virtualization systems and clouds. This page documents how to do it in OpenStack. This test case includes some information on how to do it in libvirt. This page explains how to do it directly in qemu. Other virtualization systems may also support virtio-rng.

A particularly severe form of this issue manifests itself if you boot with an initramfs generated while dracut-fips is installed. In this case the boot process will hang extremely early (at the time systemd starts up, so if any systemd activity has happened at all, you are already past this case), and the use of virtio-rng will not help (for VMs/cloud instances) as it is not yet loaded at this point. If you find yourself in this situation, it's probably best to remove dracut-fips and run sudo dracut -f to re-generate the initramfs for the current kernel. This form of the issue may potentially affect Fedora images generated with kernel 4.16.4 or later, but so far as we know, no official or semi-official images affected by this issue have yet been released.

GNOME issues

Wayland issues

link to this item

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

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.

Login screen locks up with VESA driver on Intel graphics cards

link to this item - Bugzilla: #1467278

If you boot GNOME with Intel graphics card using the VESA driver (basic graphics mode), you might see just a gray screen instead of login screen (GDM). If possible, use a proper accelerated mode instead (it should work well with Intel graphics). If that is not possible, you have following options:

  • If possible on your hardware, change from BIOS mode to UEFI mode. The UEFI fallback driver doesn't seem to cause these issues.
  • Boot into runlevel 3 instead, edit /etc/gdm/custom.conf and uncomment #WaylandEnable=false (i.e. disable wayland support). That should avoid this issue.

Plasma (KDE) issues

System installed from KDE Live fails to boot to graphics on later reboots in certain networking setups (e.g. libvirt networking)

link to this item - Bugzilla: #1370222

In certain networking setups (most notably with default libvirt NAT-style networking, e.g. when using virt-manager or gnome-boxes), a system install from KDE Live will boot the first time after installation, but later reboots will end up with a black screen and no graphical login screen. This is caused by dhcp server providing a network hostname to the machine and sddm (KDE login screen) crashing due to hostname changing during boot.

If you want to avoid this issue, you can:

  • Set up a static hostname (something else than localhost) in the installer before starting the installation.
  • Install from Everything netinst image rather than KDE Live image.

If you're already affected by this issue, you can:

  • Switch to TTY2, and set a new static hostname (something else than localhost) using
    $ sudo hostnamectl set-hostname HOSTNAME
  • Change the MAC address for your network controller, or remove and re-add the network card in case of VM (that will change its MAC address).
  • Remove the old hostnames remember by libvirt, which are stored somewhere in /var/lib/libvirt/dnsmasq/.

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

Wayland sessions crash on start on some NVIDIA graphics cards, logs show fifo: read fault error

link to this item - Bugzilla: #1457626

Multiple users with NVIDIA graphics cards have reported an issue in Fedora 26 where the GNOME Wayland session (the default on the Workstation edition) crashes shortly after login. If you check the journal from the time of the crash, an error message containing the text fifo: read fault can be seen around the time of the crash.

The problem can be worked around by disabling Wayland, which you can do by editing the file /etc/gdm/custom.conf and removing the leading # from the line #WaylandEnable=false. This is the only known way to avoid the problem at present.

Hardware reported to be affected so far includes:

  • GeForce GTX 960 (GM206)
  • Quadro K4200 (GK104GL)
  • GeForce GTX 650 (GK107)
  • GeForce GTX 760 (GK104)
  • Quadro 4000 (GF100GL)
  • Quadro 5000 (GF100GL)
  • GeForce GTX 770 (GK104)

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

Resolved issues

Upgrade may fail due to a conflict in gstreamer components

link to this item - Bugzilla: #1467136

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

Due to a file naming conflict, the gstreamer1-plugins-entrans and gst-transcoder packages in the Fedora 26 distribution could not be installed together for a time. Attempting to install them simultaneously would result in dnf failing with a message similar to:

Error: Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgsttranscode.so from install of gst-transcoder-1.12.0-1.fc26.x86_64
  conflicts with file from package gstreamer1-plugins-entrans-1.0.3-2.fc26.x86_64

You would have encountered this error during the dnf system-upgrade download process, if the Fedora 25 system contained both gstreamer1-plugins-entrans (with or without its gst-entrans parent package) and gst-transcoder (which may also be pulled in automatically by other packages, including the pitivi video-editing software). If this was the case, dnf system-upgrade download would fail with the above conflict message before the process completed, even if --allowerasing was used. The issue could have been dealt with by removing one or other package temporarily, but since the update was released, this should no longer be necessary.

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

link to this item - Bugzilla: #1384508

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

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 could quite often crash. When this happened, you would see a crash report which linked 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 were 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.

Discover app crashes on start

link to this item - Bugzilla: #1468239

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

The version of the Discover software management application included in the KDE spin by default is known to crash on startup. The update mentioned above fixes this crash, but of course the app will still crash if you attempt to launch it from the un-updated live image. There are a few ways to work around this problem: perhaps the easiest is to install the flatpak package, with sudo dnf install flatpak. You can also use the dnfdragora package management application instead, which is also included by default.

Games using the Unity engine freeze with black screen

link to this item - Bugzilla: #1440287

Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

Trying to run a proprietary game from Steam or elsewhere could result in a blank screen on launch. If you are trying to run games from an original release live image and thus cannot update glibc, a workaround for the issue is documented in the bug report.