This page documents common bugs in Fedora 23 and, if available, fixes or workarounds for these problems. If you find your problem in this page, please do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
Release Notes
Read the Fedora 23 release announcement and the Fedora 23 release notes for specific information about changes in Fedora 23 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Installation issues
Kickstarts listing default repos by name only are not properly handled
link to this item - Bugzilla: #1277638
When doing a kickstart install, you are supposed to be able to enable repositories that are present in /etc/anaconda.repos.d but not enabled by default - e.g. updates-testing - by including a line which simply specifies the repo by name:
repo --name=updates-testing
Unfortunately, this feature was inadvertently broken by an over-enthusiastic check in Fedora 23. If the installer is run in graphical mode, such a kickstart will cause it to stop at the hub screen, showing an error condition for the INSTALLATION SOURCE spoke; if the installer is run in text mode, such a kickstart will cause a crash.
We have provided an installer update image including the fix for this. If you need to use such a kickstart line, you can use the updates image by adding the kernel parameter inst.updates=https://fedorapeople.org/groups/qa/updates/1277638.img when booting the installer. Of course, you can also download the updates image and use any of the other available updates image delivery mechanisms.
Installer deletes EFI System Partition even in dual boot scenarios
link to this item - Bugzilla: #1183880
If you have several operating systems installed using UEFI boot (booting from EFI System Partition - ESP) and then go into the manual partitioning screen in the installer and select one of the operating systems to be deleted, the ESP will be deleted as well, even though it is required by the other operating systems.
If you need to perform such installation, don't delete the full partition tree under the to-be-deleted operating system, but delete all of its non-ESP partitions individually and leave ESP intact.
Installer does not always correctly compute the minimal required partition size
link to this item - Bugzilla: #1224048
The installer uses a set of heuristics to determine the minimal partition size to fit your installation in. Sometimes if you get very unlucky or you intentionally try to get the install partitions as small as possible, the installer might approve the partition size, but the installation fails at the beginning of the installation transaction (after your partitions have been created and formatted) due to insufficient disk size.
To be safe from this issue, please don't try to set an extremely small root partition (or any other system-critical partition, like /usr partition, if you decide to define one). Always plan for at least 500+MB of free disk space on such partitions (of course, in majority of cases you want much much more free space to have your system usable and useful).
Filesystems encrypted with passphrases using Cyrillic, Arabic or other switched keyboard layout characters cannot be decrypted at boot time
link to this item - Bugzilla: #681250
If the console keyboard layout for your language is 'switched' (you use a key combination to switch between typing Latin characters, and characters from your language), you will not be able to switch when entering encryption passphrases. Therefore, you will only be able to enter passphrases using whichever layout is the default. Usually, the Latin layout is the default. Therefore, if you are doing an encrypted installation using a language with a switched keyboard layout, we recommend you use only Latin characters in the passphrase.
System boots into an older kernel instead of the latest one
link to this item - Bugzilla: #1261569
This bug only affects systems installed from a pre-release version of Fedora 23 (before Fedora 23 RC2). If you have used the final release for installation (or upgraded from a previous Fedora), you're not affected.
The affected systems do not boot with an updated kernel, but to the old kernel version. This can be fixed by manually changing a line in /etc/sysconfig/kernel from:
DEFAULTKERNEL=b'kernel-core'
to
DEFAULTKERNEL=kernel-core
Software RAID (mdraid) from existing Fedora installations not recognized by Workstation/Live installs
link to this item - Bugzilla: #1225184
Installation from Workstation/Live image does not properly recognize software RAID (mdraid) devices from existing (e.g. previous) Fedora installations. Those devices are listed as "Unknown" (0 bytes size) and cannot be used in the device selection dialog which makes it basically impossible to install Fedora 23 or keep existing data.
This bug exists since Fedora 22 (several Bugzilla reports has been filed for this issue). The Server image does not have this problem and can be used as a workaround to install the Workstation spin from network remotely. Fedora Workstation may no longer be the proper distribution for systems with Software RAID devices.
Upgrade issues
System-upgrade does not work under Chinese and Japanese (and probably some other) locales
link to this item - Bugzilla: #1278031
System upgrade cannot be performed on system using certain languages - we currently know about Chinese and Japanese, but it's likely that further languages are affected as well. Until that bug is resolved, the simplest workaround is to switch your system temporarily to English, perform the upgrade, and then switch back to your language. First, see what language (locale) you are currently using:
$ locale
It should list something like LANG=zh_CN.UTF-8 (for Chinese). Mark this down. Then switch the system to English:
$ sudo localectl set-locale LANG=en_US.UTF-8
Reboot. If you run locale, you should see LANG=en_US.UTF-8 output (unless your session uses a different language from the default one in system, in that case you need to change language in your session as well, for example in gnome control center). Now perform the upgrade according to instructions. Once it is done and you're running Fedora 23, change the system locale back to your original one:
$ sudo localectl set-locale LANG=YOUR_PREVIOUS_LOCALE
and reboot.
Packages downloaded for system upgrade are removed if you perform a package transaction before starting the upgrade
link to this item - Bugzilla: #1276886
If you want to upgrade your system, you first need to download all necessary packages, and then trigger the upgrade process. However, if you do any package transaction between these two actions, e.g. because there is some dependency issue between your currently installed packages and the downloaded packages, or because you decide to install/remove something before starting the upgrade process, the whole package cache (including all of your downloaded packages) are cleaned. If you try to start the upgrade process, you'll receive unhelpful Error: system is not ready for upgrade error message. You'll need to download all the packages again (using dnf system-upgrade download ... command).
If you download all the packages for upgrade, and then want or need to perform some other transaction before starting the upgrade, use --setopt=keepcache=True DNF option. That will make sure your package cache is not cleaned and you will not need to re-download everything again.
Upgrade path for Vagrant broken (rubygem-celluloid retired)
link to this item - Bugzilla: #1275030
The package 
rubygem-celluloid
Core software issues
Initial setup sometimes starts in text mode instead of in graphics mode
link to this item - Bugzilla: #1185447
Sometimes, the initial setup utility that runs on first boot when a user account is not created in the installer starts in text mode instead of graphical mode. This looks a little surprising, but the text mode utility will work correctly and allow you to create a user account if desired, and the login screen should be shown correctly after it is complete.
GNOME issues
Initial user creation hands off to login screen (not desktop) and first attempt to log out fails
link to this item - Bugzilla: #1273112 - Bugzilla: #1272706
GNOME includes its own 'first boot' utility,
It appears that there is a timing problem, where gnome-initial-setup creates the logged in desktop session but does not successfully hand off to it, and when you then log in normally and log out, you are sent to the session created by gnome-initial-session.
This problem is a one-time issue and has no further effects. Once you log out a second time, everything will work normally from then on.
Plasma (KDE) issues
Network issues
No network connection in VM when both host and guest installed from a live image
link to this item - Bugzilla: #1146232
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 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 the guest manually at some point later (it is detected during package installation), only when you install from a live image.
If you don't need libvirt to work in the VM, you can remove libvirt networking there by running sudo virsh net-destroy default && sudo virsh net-undefine default, 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.
Hardware issues
Three monitors with an Intel GPU results in instability and display issues
link to this item - Bugzilla: #1275770
Since kernel 4.2, some people with Intel graphics cards have reported issues when they have three (or possibly more) monitors attached. The issues can range from desktop environment crashing, to monitor layout being reset from time to time, or certain monitors not waking up from sleep/locked desktop mode.
If you're affected, you can install and boot an older kernel 4.1 to work around this, or please wait until the issues are fixed in some future kernel update.
ARM issues
Fedora Server issues
FreeIPA web UI (and potentially other webapps) does not work, SELinux denies 'execmem' access
link to this item - Bugzilla: #1277224
There is a complex bug in Fedora 23 which is known to affect the FreeIPA web UI and may affect other webapps written in Python. In Fedora, SELinux is configured by default to prevent web server processes from executing writeable memory - referred to as 'execmem' access. We have determined that use of the
The result of this is that, if you have
The actual problematic code is likely in the
One possible workaround for this problem is to remove the setsebool -P httpd_execmem 1 with root privileges.
FreeIPA fails to start after upgrade if initially installed with Fedora 21 or earlier
link to this item - Bugzilla: #1323400
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
An update that fixes the upgrade migration process is available. If you have a server which was initially deployed with Fedora 21 or earlier and you have not yet upgraded to Fedora 22 or later, please either wait for the update to be released, or ensure it is included in the upgrade by enabling the updates-testing repository during upgrade or in some other way, to ensure the migration works correctly.
If you already hit this bug during upgrade, just 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 connect 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-188c172b10. 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
Atomic images have incorrect permissions on the /tmp directory
link to this item - Bugzilla: #1276775
The permissions of the /tmp dir on Fedora 23 Atomic host images are 755 when they should be 777. This breaks things that want to write to tmp but don't have permissions to. To get around this: chmod 1777 /sysroot/tmp. Updated Atomic host images are expected to be provided regularly for Fedora 23, and this issue should be resolved in those.
Other issues
Resolved issues
FreeIPA fails to upgrade properly
link to this item - Bugzilla: #1274905
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.
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 upgrade a system running FreeIPA to Fedora 23, FreeIPA will not start on the upgraded system. The logs will instruct you to run FreeIPA's upgrade process: Upgrade required: please run ipa-server-upgrade command. However, if you ran the upgrade script with the original FreeIPA packages released with Fedora 23, it would fail, and FreeIPA would still not work.
We strongly advise you ensure the updates repository is enabled when upgrading FreeIPA servers to Fedora 23 and ensure the updates listed above are included.
If you ran the upgrade script before the updates were released and encountered the bugs, you may be able to recover and get FreeIPA working by doing the following:
- Edit
/etc/dirsrv/slapd-(DOMAIN)/schema/99user.ldif - Find the entry (split across three lines) that starts attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey'
- Replace it with:
attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' DESC ' IPA vault public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.1 21.1.40 X-ORIGIN ( 'IPA v4.2' 'user defined' ) )
- Run
pki-server migrate --tomcat 8 - Run
systemctl start pki-tomcatd@pki-tomcat.service - Re-run the upgrade script:
ipa-server-upgrade
However, results may vary.
Certain plymouth themes are problematic during system upgrade
link to this item - Bugzilla: #1267949
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.
Certain plymouth (boot screen) themes were buggy inside the system upgrade environment. The known issues are with script and spinner themes - for the first one, the progress information scrolled off the screen soon, for the second one the screen stayed black during the whole upgrade. The upgrade itself would execute just fine, but you wouldn't see the progress properly (if this happened to you, do not force-reboot the computer in the middle of the operation, wait for it to finish, it will automatically reboot once the upgrade is done).
After installing the update, you can execute sudo dracut -f manually to regenerate the ramdisk for your current kernel. Otherwise the fix will only kick in with the first kernel update after the plymouth update.
Alternatively, you can revert to the default theme before performing the upgrade:
sudo dnf install plymouth-theme-charge sudo plymouth-set-default-theme charge sudo dracut -f
SELinux denial appears on application crash
link to this item - Bugzilla: #1276305
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.
There was a known issue in Fedora 23's SELinux policy which caused a denial to occur often when an application crashed. SELinux was forbidding the ABRT crash reporting tool from doing something it wants to do to analyze the crash. The denial was SELinux is preventing abrt-hook-ccpp from using the 'sigchld' accesses on a process.
The system reboots instead of shutting down
link to this item - Bugzilla: #1257131
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.
On some specific Intel boards the system would reboot after a few seconds instead of shutting down.