From Fedora Project Wiki

No edit summary
m (add category)
 
(36 intermediate revisions by 12 users not shown)
Line 6: Line 6:
This page documents common bugs in Fedora 24 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 24 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.


<!--
{{admon/note|Pre-release version|Fedora 24 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 24 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).}}
{{admon/note|Pre-release version|Fedora 24 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 24 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 ==
== Release Notes ==
Read the [[F24_Alpha_release_announcement]] <!--and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/{{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}}/html/Release_Notes/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} release notes]--> for specific information about changes in Fedora 24 and other general information.
Read the [[F24 general release announcement]] <!--and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/{{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}}/html/Release_Notes/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} release notes]--> for specific information about changes in Fedora 24 and other general information.


{{Common_bugs_header_shared}}
{{Common_bugs_header_shared}}


== Installation issues ==
== Installation issues ==
{{Common bugs issue|32bit-no-boot|32-bit Intel images do not boot|1302071}}


For Fedora 24, the 32-bit Intel architecture (i686 / x86_32) is no longer considered 'release blocking'. As it happens, this is very visible with Fedora 24 Alpha, as it seems to be the case that all 32-bit Intel images are unusable. A kernel and/or kernel build environment issue seems to result in any attempt to boot a 32-bit Intel kernel failing with the error {{code|Failed to allocate space for phdrs}}.
{{Common bugs issue|grub-relocation-failed|Dual booting Windows fails with 'relocation failed' error on some UEFI systems|1347291}}


There is no known workaround for this issue. Although support for 32-bit Intel is now no longer guaranteed, there are several people working to fix this issue, and we do hope to provide usable 32-bit Intel Fedora 24 images for Beta and Final. This issue will be updated as soon as usable images are available.
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 <code>error: relocation failed</code>. The problem is still being investigated.


{{Common bugs issue|anaconda-wifi-crash|Installer crashes on wireless network discovery|1262556}}
As a workaround, you can use your UEFI boot menu (the one-time boot menu is usually reachable via some hotkey like {{key press|Esc}}, {{key press|F8}}, {{key press|F11}}, {{key press|F12}}, etc) to boot Windows, which should work fine.


Several testers have reported that the Fedora 24 Alpha installer may crash on wireless network discovery. This crash may occur when entering the '''NETWORK & HOST NAME''' spoke on a system with a wifi adapter and no wired network connection, or may even occur as soon as you reach the hub screen.
Advanced users can download and install [http://koji.fedoraproject.org/koji/buildinfo?buildID=704713 grub2-2.02-0.25.fc23] (<code>grub2</code> from Fedora 23), which should immediately fix the problem. However, when using this solution, the broken version of <code>grub2</code> from Fedora 24 will be offered to you with every new system update, and you'll need to manually exclude it every time.


If you are affected by this issue, the known workaround is to connect to a wired network during installation. Installing from a live image or the Server DVD image rather than a network install image may also help.
{{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|boot-fail|Installed system fails to boot on some hardware|1318067}}
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.


Pre-release Alpha testing has shown that on some hardware, a Fedora 24 Alpha installation will not boot successfully. The boot process hangs at a flashing cursor before the boot menu is displayed. So far, hardware reported to be affected includes Lenovo Thinkpad T450s, Lenovo Thinkpad T400, Lenovo Thinkpad X200, Dell T1500, and Dell T1600. We are still in the process of investigating this issue. So far the only known workaround is to replace the bootloader with an older version. One way to do this is to boot from a Fedora 23 rescue image, allow it to mount the Fedora 24 system (default is {{code|/mnt/sysimage}}) and run {{command|grub2-install --boot-directory{{=}}/mnt/sysimage/boot/ /dev/sda}} (if the system is installed to another disk, adjust the {{code|/dev/sda}} portion of the command).
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 {{key press|Esc}}, {{key press|F8}}, {{key press|F11}}, {{key press|F12}}, etc).


{{Common bugs issue|live-rescue|Live images have no rescue kernel|1317709}}
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.


Due to a change in the image compose process, Fedora 24 Alpha live media contain no 'rescue' kernel. This means a system installed from a Fedora 24 Alpha live image will also have no 'rescue' kernel available for boot. The 'rescue' kernel's purpose is to provide a known-good fallback boot entry which also has a generic initramfs, rather than one tailored to the installed system's hardware (so if you change the system's hardware so much that the regular kernel no longer boots, the rescue kernel still should). If you would like to add a rescue kernel to a Fedora 24 Alpha system after installation from a live image, try this:
{{Common bugs issue|some-raid-fail|Fedora fails to install on some RAID setups|1333131|1259953}}
sudo dnf install dracut-config-rescue
 
sudo /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r)
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 devices 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 devices (this time using free space) as workaround.
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
 
{{Common bugs issue|apple-core-storage-wipe|OS X volumes using Apple Core Storage are not recognized by the installer and shrinking them destroys all data|1033778}}


For UEFI, the final command should be {{command|sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg}}. Thanks to Andre Robatino for working out this procedure.
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.


{{Common bugs issue|initial-setup-corner|Initial setup utility displays in a small corner of the screen|1160891}}
{{Common bugs issue|lvm-on-luks-reuse-broken|LVM setup on encrypted PVs unrecognized after decryption|1348688}}


Fedora has a {{code|initial-setup}} tool which is run on first system boot in some cases. It does ''not'' run on minimal installations or GNOME (Workstation) installations (GNOME has its own separate tool called {{code|gnome-initial-setup}}), but does run on installs of most other desktops.
Due to the issues with the new LVM DBus API, the installation fails to analyze an existing LVM setup on top of encrypted (LUKS) PVs after unlocking the LUKS device(s).
{{Common bugs update anaconda|http://vpodzime.fedorapeople.org/1348688_updates.img}}
This bug doesn't seem to occur with Live images (at least with Workstation Live), only netinst/Server images.


If you encounter this tool in graphical mode in Fedora 24 Alpha, you may notice it appears strangely - it initially appears very small and occupies only a corner of the screen, and the main interactions (setting a root password and creating a user account) are not immediately visible. You can find them by scrolling the window down. When you enter any spoke, the utility will become somewhat bigger, though still will not occupy the full screen.
{{Common bugs issue|mdraid-unknown|Software RAID (mdraid) from existing Fedora installations not recognized by Workstation/Live edition|1225184}}


This bug is purely cosmetic and the tool will work correctly as long as you manage to navigate it. We are working to resolve this issue for Fedora 24 Beta and Final.
Installation from Workstation/Live image does not properly recognize existing Software RAID (mdraid) devices (e.g. from an existing Fedora installation). Those devices are listed as "Unknown" (0 bytes size) and cannot be used in the device selection dialogue which makes it effectively impossible to install Fedora 24 or keep existing data.


{{Common bugs issue|luc-no-progress-f22|Fedora Media Writer shows no writing progress on Fedora 22|1328462}}
This bug exists since Fedora 22 (several Bugzilla reports have been filed for this issue but none has been processed yet).
 
The Server image does not have this problem and it can be used as a workaround to setup a minimal Server, and then install the "Workstation" package group from network remotely (using dnf). The result is not exactly the same and requires some minor additional manual work afterwards. (If anybody knows easier workarounds, please add to this section.)
 
== Upgrade issues ==
 
{{Common bugs issue|rpmfusion-unsigned|Rpmfusion packages block Fedora upgrade|}}
 
At the time of release, rpmfusion packages were blocking Fedora upgrades with a message similar to:
<pre>Error: Package a52dec-0.7.4-19.fc24.x86_64.rpm is not signed</pre>
 
This is a third-party repository issue outside of Fedora control. You can read more about possible solutions in [https://kparal.wordpress.com/2016/06/22/package-xxx-is-not-signed-error-during-upgrade-to-fedora-24/ this blog post]. The repository maintainers are supposedly working on signing their repo, so that the issue disappears in the future. As of recently (mid-July) this has been fixed and RPMFusion packages are signed.
 
{{Common bugs issue|upgrade-dependency-missing|Upgrade from Fedora 24 fails if {{package|dnf-plugin-system-upgrade}} is not installed|1395686}}
 
When upgrading from Fedora 24, it is possible to be in a situation where upgrade preparation - the {{command|dnf system-upgrade download}} step - works, but the actual upgrade - the {{command|dnf system-upgrade reboot}} step - does not. This occurs if you have the {{package|python3-dnf-plugin-system-upgrade}} package installed, but not the {{package|dnf-plugin-system-upgrade}} package.
 
If you encounter this issue, when you try the upgrade step, the system will start booting, but then appear to stall. If you hit {{key press|Esc}}, you may see a message {{code|Reached target System Update}}. No progress information on the upgrade will appear.
 
To be absolutely sure this is the issue you are encountering, please leave the system for a long time - say, two or three hours - to ensure it is not just upgrading silently, as rebooting in the middle of an upgrade can cause the system to be entirely unusable.
 
But if there definitely appears to be no activity after several hours, shut the system down. Now either boot up and add {{code|rd.break}} to the boot parameters, boot the 'Rescue mode' from a Fedora install image, or boot from a live image. From the installed system root, remove the file {{filename|/system-update}}. Now you should be able to boot the system normally again. Now install the package {{package|dnf-plugin-system-upgrade}} and retry the upgrade process.
 
== Core system issues ==
 
{{Common bugs issue|packagekit-userinstalled|DNF might remove essential system packages if you used PackageKit (GNOME Software, KDE Apper) in the past|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 <code>sudo dnf autoremove</code>). 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 24.
 
This is now fixed in Fedora 24 (since <code>libhif-0.2.2-3.fc24</code>) and Fedora 23 (since <code>libhif-0.2.2-3.fc23</code>). Future 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 start using DNF:
<ol>
<li>First, make sure your libhif package version is the same as described above or newer:
<pre>rpm -q libhif</pre>
If not, update it, and check again:
<pre>sudo dnf --refresh update libhif</pre>
Reboot after update.</li>
<li>Then, mark all your current packages as "user installed" using this command:
<pre>rpm -qa --qf '%{NAME}\n' | xargs sudo dnf mark install</pre></li>
</ol>
 
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 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|xorg-udev-hybrid-crash|X crashes when systemd-udev package updated on systems with multiple graphics adapters (hybrid graphics)|1341327|1378974}}
{{Common bugs update released|FEDORA-2016-faf2598d0c|noupdate}}
 
If your system has multiple graphics adapters - the most common case being laptop 'hybrid graphics' (NVIDIA Optimus or AMD 'Dynamic Switchable Graphics') - and you update the {{code|systemd-udev}} package while X is running, it is highly likely that X will crash.
 
This may be a severe problem if you were running the update process inside of X (e.g. from a terminal app within your desktop). The X crash will kill the update process before the update has properly completed. This may leave you with inconsistencies in the package database, which can be difficult to recover from, and cause various other consequences (these will vary depending on which parts of the update process were not completed before the crash).
 
The crash is triggered when the {{code|systemd-udev-trigger.service}} service is restarted, so any other action which results in that happening may also cause X to crash on affected systems.
 
We strongly advise against running updates from a terminal window inside a graphical desktop. We advise against this in any case, but obviously there is a specific and severe reason to avoid it in this case. The safest way to apply updates on Fedora is using the 'offline updates' system, which applies updates by rebooting to a minimal environment, installing the updates, then rebooting to the usual environment.
 
If you update from the GNOME Software application on Fedora Workstation (GNOME), or by clicking on the 'reboot to install updates' notifications which are shown automatically from time to time on Workstation, you are using the 'offline updates' system and will not be affected by this bug.


If you use [[How to create and use Live USB#fmw|Fedora Media Writer]] (formerly liveusb-creator) on Fedora 22 to create a new bootable USB drive, no progress is displayed during the writing process. You need to wait until the dialog says "Finished".
On other desktops or non-graphical installs, you can use the offline updates system as follows:


{{Common bugs issue|some-raid-fail|Fedora fails to install on some RAID setups|1333131|1259953}}
sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger && \
sudo systemctl reboot


On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash. The crash itself messes the disks a little and renders the RAID unusable. User can restart and try again (this time using free space) as workaround.
If you do not want to use the offline update system, we strongly advise you at least update from a VT, instead of from a terminal app in a graphical desktop. That is, press ctrl-alt-f3 to get a console login prompt, log in, and run the update from the console. If you leave X running while the update runs on an affected system, it will still crash when the {{code|systemd-udev}} package is updated, but the update process will not crash (as it is not running in X) and will complete properly.


{{Common bugs issue|uefi-chainloading-error|Chainloading bootmgr.efi on UEFI results in error|1320273}}
An update to resolve this particular issue was released, but due to the technical details of exactly how the bug is triggered, the update process that applies the fix will still be vulnerable to the bug. The fix can only prevent '''subsequent''' updates involving the {{code|systemd-udev}} package from triggering the bug. You must still take care when performing updates at least until after {{code|systemd-229-16.fc24}} is installed, but it is really the best idea to always follow the guidelines explained here when updating the system.
Some testers have reporter an error on UEFI systems with dual-boot. Chainloading results in out of memory error. Grub2 team is aware of this issue and working to resolve it. There has been reported a workaround, see [https://bugzilla.redhat.com/show_bug.cgi?id=1320273#c23 RHBZ1320273#c23]


{{Common bugs issue|libdb-rebuilddb|RPM database errors after updating libdb|1460303|1394862}}


== Upgrade issues ==
The changes made to {{package|libdb}} to address [[Common_F26_bugs#upgrade-libdb|an issue with upgrading to Fedora 26+]] 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.
== GNOME issues ==
{{Common bugs issue|gsd-crash|GNOME Settings Daemon crash on startup|1288850}}


On some systems, the GNOME configuration manager, {{code|gnome-settings-daemon}}, crashes during system startup. This may prevent expected settings from being applied to the session (this can manifest in many ways, like fonts not appearing as expected). A crash notification will usually appear. If you are affected by this, you should be able to launch the daemon manually from a console with {{command|/usr/libexec/gnome-settings-daemon &}}. This issue is likely resolved in GNOME 3.20, which arrived too late for inclusion in Fedora 24 Alpha, and so should be addressed after install and update of the Alpha, and in the Beta release.
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.


{{Common bugs issue|gnome-session-crash|Crash on shutdown or restart|1316311}}
== GNOME issues ==


Several Fedora 24 Alpha testers have reported a GNOME crash on session end (usually shutdown or restart). This crash may be somewhat hardware-specific. The issue is resolved in an upstream release that arrived too late for inclusion in Fedora 24 Alpha, so the crash should no longer occur on installed systems after an update. The crash does not have any known serious consequences and can be ignored.
{{Common bugs issue|packagekit-chrome|Offline updates in GNOME stop working after Google Chrome is installed|1344643}}


{{Common bugs issue|webkit-crash|Webkit crash when entering online account credentials or browsing GNOME Shell extensions|1314658}}
If you install Google Chrome, it tries but fails to install a GPG key for its repository. This will break "offline update" functionality in GNOME Software (in this mode the updates are installed during a system reboot). Once a new google-chrome update is released, all future updates using GNOME Software will fail (including system updates unrelated to google-chrome, it's enough that the new google-chrome package is in the update set). This is not a problem for DNF, which will ask you to confirm the GPG key during the next google-chrome update.


Several Fedora 24 Alpha testers have reported crashes in the Webkit HTML rendering engine while using various GNOME desktop features that use it. Specific cases known to be affected include configuring online accounts (one reporter suggests a crash occurs when enabling caps lock while entering Facebook account credentials) and browsing GNOME Shell extensions.
In order to work around this, you need to confirm the GPG key for the google-chrome repo. You can do it using DNF, once a new google-chrome update is available. Simply update chrome using DNF and confirm the gpg key question:
<pre>$ sudo dnf update 'google-chrome*'</pre>


At least some of the bugs have been resolved upstream, but the fixes have not yet worked their way downstream into Fedora yet.
Alternatively, you can download the key and import it into RPM database (in this case you don't need to wait until new google-chrome update is available):
<pre>$ curl -O 'https://dl.google.com/linux/linux_signing_key.pub'
$ sudo rpmkeys --import ./linux_signing_key.pub</pre>


{{Common bugs issue|nm-unusable-dialogs|Network Manager IPv4 and IPv6 dialogs incorrectly displayed, unusable with mouse |1326047}}
After this, offline updates using GNOME Software should start working again.


The network properties dialog of network manager in Gnome display has issue with controls on IPv4 and IPv6 configuration screens. The controls are not placed properly and the dialog is not sized correctly. It is not possible to click on the buttons with mouse, although it works with TAB key on keyboard. The problem occurs for all types of connections.
{{Common bugs issue|nm-apply|Network configuration changes not always applies in GNOME control center|1344788}}


This bug is fixed in {{code|gtk3-3.20.3}}, just update the package by running command {{command|dnf update gtk3}}.
In GNOME settings (control-center), network changes may not take effect for a connection using the {{key press|Apply}} button - the configuration is not reloaded. Turn the connection off then back on again to reload the settings.


One of the affected options is "Use this connection only for resources on its network". This can be used for example when someone wants to make wireless connection default and still connect via wired connection for local resources.


== Plasma (KDE) issues ==
== Plasma (KDE) issues ==
{{Common bugs issue|kde-background|Fedora 24 background not used in Plasma|1320666}}


The intended Fedora 24 background is not used in the Fedora 24 Alpha Plasma spin. Instead an upstream default background is used. The Fedora KDE / Plasma team is aware of this issue and working to resolve it with an update and for Fedora 24 Beta.
{{Common bugs issue|plasma-qxl|Plasma crashes when switching users in VMs using QXL driver|1293167}}
 
If you try to switch between different user accounts in Plasma while running in a virtual machine using the QXL driver, Plasma is likely to crash. This doesn't seem to happen when using a different video driver. It also doesn't affect bare metal machines (because those don't use QXL). The workaround is to use a different video driver in your VM.


== Network issues ==
== Network issues ==
{{Common bugs issue|libvirt-no-network-in-guest-from-Live|No network connection in VM when both host and guest installed from a Live image|1146232|1146284}}


If you install Fedora from a Live image, and then create a virtual machine on it and install another Fedora from a Live image as a guest, your networking in guest will probably not work. The is reason is that libvirt virtual network address ranges are the same both in the host and the guest and clash. This does not happen if you install the libvirt packages in guest manually at some point later (it is detected during package installation), just when you install from a LiveCD.
== Hardware issues ==


If you don't need libvirt to work in the VM, you can remove libvirt networking there by running <code>sudo virsh net-destroy default && sudo virsh net-undefine default</code>, and then renewing the network connection in NetworkManager. If you need libvirt to work in VM, you need to edit its configuration files and assign a different IP range to it.
== Application issues ==


== Hardware issues ==
== Application issues ==
{{Common bugs issue|firefox-ffmpeg|Firefox no longer plays H264 content using gstreamer, uses ffmpeg now|1331496}}
{{Common bugs issue|firefox-ffmpeg|Firefox no longer plays H264 content using gstreamer, uses ffmpeg now|1331496}}


Since Firefox 46, it no longer uses gstreamer to play non-free multimedia content (most often represented by H264 video codec), but uses ffmpeg instead. Instead of having <code>gstreamer1-libav</code>,  now you need to have <code>ffmpeg-libs</code> installed if you want to be able to play such content in Firefox. Please note that ffmpeg is not distributed by Fedora and you need to obtain it yourself, if you wish to use it.
Since Firefox 46, it no longer uses gstreamer to play non-free multimedia content (most often represented by H264 video codec), but uses ffmpeg instead. Instead of having <code>gstreamer1-libav</code>,  now you need to have <code>ffmpeg-libs</code> installed if you want to be able to play such content in Firefox. Please note that ffmpeg is not distributed by Fedora and you need to obtain it yourself, if you wish to use it.


{{Common bugs issue|docker-fail|Docker fails to run anything|1322909}}
{{Common bugs issue|docker-fail|Docker fails to run anything if docker-1.10.3-3 was ever used|1322909}}


There has been reporten an issue with {{code|docker-1.10.3-3}}, which results in unusable {{code|docker}}. This issue persists even if {{code|docker}} is updated. Sufficient workaround should be to stop {{code|docker}}, remove directory {{command|/var/lib/docker}} and install newer {{code|docker}}. Users with lvm thin pool must recreate the pool since the removal of {{command|/var/lib/docker}} breaks it. For more, see [https://bugzilla.redhat.com/show_bug.cgi?id=1322909#c21 RHBZ1322909#c21].
There has been reported an issue with {{code|docker-1.10.3-3}}, which results in unusable {{code|docker}}. This issue persists even if {{code|docker}} is updated. Sufficient workaround should be to stop {{code|docker}}, remove directory {{command|/var/lib/docker}} and install newer {{code|docker}}. Users with lvm thin pool must recreate the pool since the removal of {{command|/var/lib/docker}} breaks it. For more, see [https://bugzilla.redhat.com/show_bug.cgi?id=1322909#c21 RHBZ 1322909#c21].


== ARM issues ==
== ARM issues ==
{{Common bugs issue|Bananapi-pxe|bananapi: unable to pxe boot|1329613}}
{{Common bugs issue|Bananapi-pxe|bananapi: unable to pxe boot|1329613}}


Line 110: Line 171:


== Fedora Server issues ==
== Fedora Server issues ==
{{Common bugs issue|freeipa-upgrade-profiles|FreeIPA fails to start after upgrade if initially installed with Fedora 21 or earlier|1323400}}
{{Common bugs update released|FEDORA-2016-4d226a5f7e}}
Between Fedora 21 and Fedora 22, FreeIPA was changed from using a file-based store for certificate profiles to a database store. Any FreeIPA server initially deployed under Fedora 21 or earlier would have had the file store, and would need to be migrated to the database store on upgrade to Fedora 22 or later.
Testing indicates that this migration was often not correctly performed on upgrade. With versions of {{package|pki-core}} after 10.2.6-12.fc22 (Fedora 22), 10.2.6-16.fc23 (Fedora 23), or 10.3.0.a1-2 (Fedora 24+), this prevents FreeIPA from starting successfully. With earlier versions, FreeIPA would start successfully, but some certificate operations would fail.
An [https://bodhi.fedoraproject.org/updates/FEDORA-2016-4d226a5f7e update that fixes the upgrade migration process] was released. If you have a server which was initially deployed with Fedora 21 or earlier and you waited until this update was released before upgrading, this bug should not affect you.
If you already hit this bug during upgrade, updating the package will not fix it. The symptom of this bug is that the {{code|pki-tomcatd@pki-tomcat.service}} service fails to start during FreeIPA initialization. If you run {{command|ipactl -d}}, you will see it repeatedly attempt to connection to {{code|https://(serverhostname):8443/ca/admin/ca/getStatus}} for some time, failing each time, then eventually time out.
If you are affected by the bug, first apply the update: run {{command|sudo dnf install yum}}, then {{command|1=sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-4d226a5f7e}}. Then, edit the file {{filename|/etc/pki/pki-tomcat/ca/CS.cfg}} and replace the text {{code|1=subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem}} with {{code|1=subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem}}. Finally, run {{command|sudo ipa-server-upgrade}}. This should correctly perform the migration, and FreeIPA should subsequently start correctly.
== Fedora Cloud issues ==
== Fedora Cloud issues ==
== LXDE issues ==
{{Common bugs issue|lxde-midori|Default LXDE browser (Midori) is broken|1319516|1306144}}


The default browser on the Fedora 24 Alpha LXDE spin, Midori, does not launch (it will crash) when run normally. It can be launched from a console with {{command|midori --plain}}. You may also choose to install Firefox or another browser into the live environment, with {{command|sudo dnf install firefox}}; this will use some extra RAM.
== Other issues ==


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


The systemd-hibernate generator used to handle resume from hibernate functionality expects a resume=/path/to/swap in the kernel args. Anaconda does not add this in /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.
The systemd-hibernate generator used to handle resume from hibernate functionality expects a <code>resume=/path/to/swap</code> in the kernel args. Anaconda does not add this into {{filename|/etc/default/grub}} and the dracut cmdline generator doesn't act in a way the systemd hibernate generator can locate the swap with the resume image.
 
To work around this, check the devmapper path to the swap via <code>swapon -s</code> command and add it to the <code>GRUB_CMDLINE_LINUX</code> entry in {{filename|/etc/default/grub}}, then regenerate the {{filename|grub.cfg}} file used:
 
* Via grub2-mkconfig:
** For BIOS systems: <pre>sudo grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
** For EFI systems: <pre>sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg</pre>
* Via grubby: <pre>sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)</pre>


To work around this check the devmapper path to the swap via <code>swapon -s</code> and add this to the GRUB_CMDLINE_LINUX entry in /etc/default/grub then regenerate the grub.cfg file used:
== Resolved issues ==
<pre>
 
Via grub2-mkconfig:
{{Common bugs issue|luc-no-progress-f22|Fedora Media Writer shows no writing progress on Fedora 22|1328462}}
  For BIOS systems:
{{Common bugs update released|FEDORA-2016-ff4136b90c}}
  grub2-mkconfig -o /boot/grub/grub.cfg
{{Common bugs update released|FEDORA-2016-77e613d54d}}


  For EFI systems:
If you used an older version of [[How to create and use Live USB#fmw|Fedora Media Writer]] (formerly liveusb-creator) on Fedora 22 to create a new bootable USB drive, no progress was displayed during the writing process. You had to wait until the dialog says "Finished". This issue was resolved in version 3.93.2; 3.93.3 was released for Fedora 22 on 2016-04-26, and 3.95.2 on 2016-06-23.
  grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg


Via grubby:
{{Common bugs issue|kde-bonus-cinnamon|Non-live install with KDE, or installing KDE post-install, also installs Cinnamon|1349743}}
  grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)
{{Common bugs update released|FEDORA-2016-87de75ef6b}}
</pre>
{{Common bugs update released|FEDORA-2016-3ddc57115a}}


Due to some unfortunate interactions between the Fedora package group definitions and the {{package|libsolv}} dependency solver, if you installed the KDE package set from a traditional installer image (rather than the KDE live image), or tried to install KDE after initial system install by running {{command|sudo dnf groupinstall kde-desktop-environment}} or something similar, you got KDE...and also Cinnamon.


{{Common bugs issue|ostree-status-error|Error and timeout on command rpm-ostree status|1330318}}
This should be resolved for new network installs of KDE, and {{code|kde-desktop-environment}} installs to already-deployed systems, since around 2016-09. If you were already affected by the issue, you will still have to remove the unwanted packages manually.


Several testers have reported that command {{command|rpm-ostree status}} fails after 30 seconds hang. Updating to {{code|selinux-policy-3.13.1-185}} fixes this issue.
[[Category:Common bugs]]

Latest revision as of 23:58, 14 March 2018

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


Release Notes

Read the F24 general release announcement for specific information about changes in Fedora 24 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

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 24 will be offered to you with every new system update, and you'll need to manually exclude it every time.

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

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 devices 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 devices (this time using free space) as workaround.

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.

LVM setup on encrypted PVs unrecognized after decryption

link to this item - Bugzilla: #1348688

Due to the issues with the new LVM DBus API, the installation fails to analyze an existing LVM setup on top of encrypted (LUKS) PVs after unlocking the LUKS device(s).

Updates image available
An installer update image has been made available which resolves this issue. To use it, hit e or Tab on the installer boot menu to edit the boot options, and add the following: inst.updates=http://vpodzime.fedorapeople.org/1348688_updates.img

This bug doesn't seem to occur with Live images (at least with Workstation Live), only netinst/Server images.

Software RAID (mdraid) from existing Fedora installations not recognized by Workstation/Live edition

link to this item - Bugzilla: #1225184

Installation from Workstation/Live image does not properly recognize existing Software RAID (mdraid) devices (e.g. from an existing Fedora installation). Those devices are listed as "Unknown" (0 bytes size) and cannot be used in the device selection dialogue which makes it effectively impossible to install Fedora 24 or keep existing data.

This bug exists since Fedora 22 (several Bugzilla reports have been filed for this issue but none has been processed yet).

The Server image does not have this problem and it can be used as a workaround to setup a minimal Server, and then install the "Workstation" package group from network remotely (using dnf). The result is not exactly the same and requires some minor additional manual work afterwards. (If anybody knows easier workarounds, please add to this section.)

Upgrade issues

Rpmfusion packages block Fedora upgrade

link to this item

At the time of release, rpmfusion packages were blocking Fedora upgrades with a message similar to:

Error: Package a52dec-0.7.4-19.fc24.x86_64.rpm is not signed

This is a third-party repository issue outside of Fedora control. You can read more about possible solutions in this blog post. The repository maintainers are supposedly working on signing their repo, so that the issue disappears in the future. As of recently (mid-July) this has been fixed and RPMFusion packages are signed.

Upgrade from Fedora 24 fails if dnf-plugin-system-upgrade is not installed

link to this item - Bugzilla: #1395686

When upgrading from Fedora 24, it is possible to be in a situation where upgrade preparation - the dnf system-upgrade download step - works, but the actual upgrade - the dnf system-upgrade reboot step - does not. This occurs if you have the python3-dnf-plugin-system-upgrade package installed, but not the dnf-plugin-system-upgrade package.

If you encounter this issue, when you try the upgrade step, the system will start booting, but then appear to stall. If you hit Esc, you may see a message Reached target System Update. No progress information on the upgrade will appear.

To be absolutely sure this is the issue you are encountering, please leave the system for a long time - say, two or three hours - to ensure it is not just upgrading silently, as rebooting in the middle of an upgrade can cause the system to be entirely unusable.

But if there definitely appears to be no activity after several hours, shut the system down. Now either boot up and add rd.break to the boot parameters, boot the 'Rescue mode' from a Fedora install image, or boot from a live image. From the installed system root, remove the file /system-update. Now you should be able to boot the system normally again. Now install the package dnf-plugin-system-upgrade and retry the upgrade process.

Core system issues

DNF 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 24.

This is now fixed in Fedora 24 (since libhif-0.2.2-3.fc24) and Fedora 23 (since libhif-0.2.2-3.fc23). Future 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 start using DNF:

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

X crashes when systemd-udev package updated on systems with multiple graphics adapters (hybrid graphics)

link to this item - Bugzilla: #1341327 - Bugzilla: #1378974

Fix released
An update has been released to address this problem. However, as this issue manifests before the system can be updated, you may still have to work around it as described here.

If your system has multiple graphics adapters - the most common case being laptop 'hybrid graphics' (NVIDIA Optimus or AMD 'Dynamic Switchable Graphics') - and you update the systemd-udev package while X is running, it is highly likely that X will crash.

This may be a severe problem if you were running the update process inside of X (e.g. from a terminal app within your desktop). The X crash will kill the update process before the update has properly completed. This may leave you with inconsistencies in the package database, which can be difficult to recover from, and cause various other consequences (these will vary depending on which parts of the update process were not completed before the crash).

The crash is triggered when the systemd-udev-trigger.service service is restarted, so any other action which results in that happening may also cause X to crash on affected systems.

We strongly advise against running updates from a terminal window inside a graphical desktop. We advise against this in any case, but obviously there is a specific and severe reason to avoid it in this case. The safest way to apply updates on Fedora is using the 'offline updates' system, which applies updates by rebooting to a minimal environment, installing the updates, then rebooting to the usual environment.

If you update from the GNOME Software application on Fedora Workstation (GNOME), or by clicking on the 'reboot to install updates' notifications which are shown automatically from time to time on Workstation, you are using the 'offline updates' system and will not be affected by this bug.

On other desktops or non-graphical installs, you can use the offline updates system as follows:

sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger && \
sudo systemctl reboot

If you do not want to use the offline update system, we strongly advise you at least update from a VT, instead of from a terminal app in a graphical desktop. That is, press ctrl-alt-f3 to get a console login prompt, log in, and run the update from the console. If you leave X running while the update runs on an affected system, it will still crash when the systemd-udev package is updated, but the update process will not crash (as it is not running in X) and will complete properly.

An update to resolve this particular issue was released, but due to the technical details of exactly how the bug is triggered, the update process that applies the fix will still be vulnerable to the bug. The fix can only prevent subsequent updates involving the systemd-udev package from triggering the bug. You must still take care when performing updates at least until after systemd-229-16.fc24 is installed, but it is really the best idea to always follow the guidelines explained here when updating the system.

RPM database errors after updating libdb

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

The changes made to libdb to address an issue with upgrading to Fedora 26+ 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.

GNOME issues

Offline updates in GNOME stop working after Google Chrome is installed

link to this item - Bugzilla: #1344643

If you install Google Chrome, it tries but fails to install a GPG key for its repository. This will break "offline update" functionality in GNOME Software (in this mode the updates are installed during a system reboot). Once a new google-chrome update is released, all future updates using GNOME Software will fail (including system updates unrelated to google-chrome, it's enough that the new google-chrome package is in the update set). This is not a problem for DNF, which will ask you to confirm the GPG key during the next google-chrome update.

In order to work around this, you need to confirm the GPG key for the google-chrome repo. You can do it using DNF, once a new google-chrome update is available. Simply update chrome using DNF and confirm the gpg key question:

$ sudo dnf update 'google-chrome*'

Alternatively, you can download the key and import it into RPM database (in this case you don't need to wait until new google-chrome update is available):

$ curl -O 'https://dl.google.com/linux/linux_signing_key.pub'
$ sudo rpmkeys --import ./linux_signing_key.pub

After this, offline updates using GNOME Software should start working again.

Network configuration changes not always applies in GNOME control center

link to this item - Bugzilla: #1344788

In GNOME settings (control-center), network changes may not take effect for a connection using the Apply button - the configuration is not reloaded. Turn the connection off then back on again to reload the settings.

One of the affected options is "Use this connection only for resources on its network". This can be used for example when someone wants to make wireless connection default and still connect via wired connection for local resources.

Plasma (KDE) issues

Plasma crashes when switching users in VMs using QXL driver

link to this item - Bugzilla: #1293167

If you try to switch between different user accounts in Plasma while running in a virtual machine using the QXL driver, Plasma is likely to crash. This doesn't seem to happen when using a different video driver. It also doesn't affect bare metal machines (because those don't use QXL). The workaround is to use a different video driver in your VM.

Network issues

Hardware issues

Application issues

Firefox no longer plays H264 content using gstreamer, uses ffmpeg now

link to this item - Bugzilla: #1331496

Since Firefox 46, it no longer uses gstreamer to play non-free multimedia content (most often represented by H264 video codec), but uses ffmpeg instead. Instead of having gstreamer1-libav, now you need to have ffmpeg-libs installed if you want to be able to play such content in Firefox. Please note that ffmpeg is not distributed by Fedora and you need to obtain it yourself, if you wish to use it.

Docker fails to run anything if docker-1.10.3-3 was ever used

link to this item - Bugzilla: #1322909

There has been reported an issue with docker-1.10.3-3, which results in unusable docker. This issue persists even if docker is updated. Sufficient workaround should be to stop docker, remove directory /var/lib/docker and install newer docker. Users with lvm thin pool must recreate the pool since the removal of /var/lib/docker breaks it. For more, see RHBZ 1322909#c21.

ARM issues

bananapi: unable to pxe boot

link to this item - Bugzilla: #1329613

Some people are experiencing a problem with graphical PXE installation on Banana Pi. They are probably running into memory issues when 1G of RAM is not enough. The workaround is to append inst.text to kernel cmdline and proceed with text installation or install the system via VNC.

Fedora Server issues

FreeIPA fails to start after upgrade if initially installed with Fedora 21 or earlier

link to this item - Bugzilla: #1323400

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.

Between Fedora 21 and Fedora 22, FreeIPA was changed from using a file-based store for certificate profiles to a database store. Any FreeIPA server initially deployed under Fedora 21 or earlier would have had the file store, and would need to be migrated to the database store on upgrade to Fedora 22 or later.

Testing indicates that this migration was often not correctly performed on upgrade. With versions of pki-core after 10.2.6-12.fc22 (Fedora 22), 10.2.6-16.fc23 (Fedora 23), or 10.3.0.a1-2 (Fedora 24+), this prevents FreeIPA from starting successfully. With earlier versions, FreeIPA would start successfully, but some certificate operations would fail.

An update that fixes the upgrade migration process was released. If you have a server which was initially deployed with Fedora 21 or earlier and you waited until this update was released before upgrading, this bug should not affect you.

If you already hit this bug during upgrade, updating the package will not fix it. The symptom of this bug is that the pki-tomcatd@pki-tomcat.service service fails to start during FreeIPA initialization. If you run ipactl -d, you will see it repeatedly attempt to connection to https://(serverhostname):8443/ca/admin/ca/getStatus for some time, failing each time, then eventually time out.

If you are affected by the bug, first apply the update: run sudo dnf install yum, then sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-4d226a5f7e. Then, edit the file /etc/pki/pki-tomcat/ca/CS.cfg and replace the text subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem with subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem. Finally, run sudo ipa-server-upgrade. This should correctly perform the migration, and FreeIPA should subsequently start correctly.

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
  • Via grubby:
    sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)

Resolved issues

Fedora Media Writer shows no writing progress on Fedora 22

link to this item - Bugzilla: #1328462

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

If you used an older version of Fedora Media Writer (formerly liveusb-creator) on Fedora 22 to create a new bootable USB drive, no progress was displayed during the writing process. You had to wait until the dialog says "Finished". This issue was resolved in version 3.93.2; 3.93.3 was released for Fedora 22 on 2016-04-26, and 3.95.2 on 2016-06-23.

Non-live install with KDE, or installing KDE post-install, also installs Cinnamon

link to this item - Bugzilla: #1349743

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.
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 some unfortunate interactions between the Fedora package group definitions and the libsolv dependency solver, if you installed the KDE package set from a traditional installer image (rather than the KDE live image), or tried to install KDE after initial system install by running sudo dnf groupinstall kde-desktop-environment or something similar, you got KDE...and also Cinnamon.

This should be resolved for new network installs of KDE, and kde-desktop-environment installs to already-deployed systems, since around 2016-09. If you were already affected by the issue, you will still have to remove the unwanted packages manually.