From Fedora Project Wiki

(Three monitors with an Intel GPU results in instability and display issues)
m (add category)
 
(31 intermediate revisions by 6 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 23 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 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.
 
{{admon/note|Pre-release version|Fedora 23 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 23 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 [[F23_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 23 and other general information.
Read the [[F23_release_announcement|Fedora 23 release announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/23/html/Release_Notes/ Fedora 23 release notes] for specific information about changes in Fedora 23 and other general information.


{{Common_bugs_header_shared}}
{{Common_bugs_header_shared}}
== Installation issues ==
== Installation issues ==


{{Common bugs issue|luc-litd-23|USB sticks written from Fedora 23 with liveusb-creator (dd mode) and livecd-iso-to-disk do not work|1264012|1263988}}
{{Common bugs issue|kickstart-named-repo|Kickstarts listing default repos by name only are not properly handled|1277638}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


When run from Fedora 23 (or Rawhide), {{command|liveusb-creator}} (in dd mode) and {{command|livecd-iso-to-disk}} fail to create bootable USB sticks (they may boot in UEFI mode). Run from Fedora 22 or earlier (and Windows, for liveusb-creator) they work correctly.
When doing a [[Anaconda/Kickstart|kickstart]] install, you are supposed to be able to enable repositories that are present in {{filename|/etc/anaconda.repos.d}} but not enabled by default - e.g. {{code|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.


If you need to write a USB stick from Fedora 23 or Rawhide for now, we recommend using the {{command|dd}} method or "Linux (GNOME) quick start (direct write)" documented at [[How_to_create_and_use_Live_USB]].
We have provided an [[Anaconda/Updates|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 {{code|1=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.


{{Common bugs issue|media-check-error|Media consistency check fails with an error on DVD/netinst|1250414}}
{{Common bugs issue|anaconda-deleting-esp|Installer deletes EFI System Partition even in dual boot scenarios|1183880}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


If you choose to verify media consistency using appropriate boot menu item when using the DVD or netinst media, you'll shortly see [https://bugzilla.redhat.com/attachment.cgi?id=1059408 an error] and then the boot will continue. You'll not be able to verify whether the image was burned/created correctly.
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.


We recommend at least verifying the downloaded ISO image sha256 checksum to avoid download errors, or using the Live media if you need to be sure that the image was burned correctly.
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.


{{Common bugs issue|media-check-timeout|Media consistency check times out when using optical media|1250440}}
{{Common bugs issue|anaconda-minimal-partition-size|Installer does not always correctly compute the minimal required partition size|1224048}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


If you choose to verify media consistency using appropriate boot menu item when booting from a optical medium (CD/DVD instead of USB stick), the check is very likely to take more than 90 seconds, after which the boot process times out and you're put into an emergency shell. The consistency check still continues and can you wait for it to finish to make sure the medium is burned correctly. But then you'll need to reboot the machine and boot the installer again, this time avoiding "Test this media" boot options.  
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.


{{Common bugs issue|anaconda-deleting-esp|Installer deletes EFI System Partition even in dual boot scenarios|1183880}}
To be safe from this issue, please don't try to set an extremely small root partition (or any other system-critical partition, like {{code|/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).


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.
{{Common bugs issue|decryption-with-cyrillic-and-arabic-passphrases|Filesystems encrypted with passphrases using Cyrillic, Arabic or other switched keyboard layout characters cannot be decrypted at boot time|681250}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


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


{{Common bugs issue|anaconda-minimal-partition-size-netinst|Installer does not correctly compute the minimal required partition size when using network installation|1224048}}
{{Common bugs issue|old-kernel-by-default|System boots into an older kernel instead of the latest one|1261569}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts -->


If you use the network install image (netinst), the installer will not always correctly warn you when your root partition is too small to contain the installed system. If the disk space runs out during package installation, anaconda reboots the machine without a warning, and the partial Fedora installation is broken and unusable. If this happens, please repeat the installation, but assign more space to the root partiton. For example, the ''absolute minimum'' for a Workstation package set is 6 GiB.
''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.''


In the vast majority of cases, this issue does not affect Live or DVD (offline) installations. There is a very slight chance that if you set the partition to be almost exactly the same size as is the installed package set, the filesystem metadata will occupy enough space so that the installed system does not fit into the free space.
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 {{code|/etc/sysconfig/kernel}} from:
  DEFAULTKERNEL=b'kernel-core'
to
  DEFAULTKERNEL=kernel-core


To be safe from this issue, please don't try to set an extremely small root partition.
{{Common bugs issue|mdraid-unknown|Software RAID (mdraid) from existing Fedora installations not recognized by Workstation/Live installs|1225184}}


{{Common bugs issue|decryption-with-cyrillic-and-arabic-passphrases|Filesystems encrypted with passphrases using Cyrillic, Arabic or other switched keyboard layout characters cannot be decrypted at boot time|681250}}
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.


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


{{Common bugs issue|crash-report-dialog|Installer crash reporting does not work if dialog is showing|1250942}}
== Upgrade issues ==


The Fedora 23 Beta installer contains a bug which means that, if it crashes while some sort of dialog (e.g. the 'Reclaim Space' dialog) is showing on top of the main installer UI, the crash report tool will not respond to clicks.
{{Common bugs issue|upgrade-dependency-missing|Upgrade from Fedora 23 fails if {{package|dnf-plugin-system-upgrade}} is not installed|1395686}}


This makes it difficult to report the crash, unless you can copy the crash report directory to another system and run the report from there. We will aim to fix this issue in time for the final release.
When upgrading from Fedora 23, 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.


== Upgrade issues ==
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.


{{Common bugs issue|plymouth-theme-upgrade|Certain plymouth themes are problematic during system upgrade|1267949}}
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.


Certain plymouth (boot screen) themes are buggy when being inside the system upgrade environment. The known issues are with <code>script</code> and <code>spinner</code> themes - for the first one, the progress information scrolls off the screen soon, for the second one the screen stays black during the whole upgrade. The upgrade itself will execute just fine, but you won'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).
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.


There is [https://bodhi.fedoraproject.org/updates/FEDORA-2015-d771412e5b a fixed version of plymouth] to resolve this issue. Even if you have it installed, you still need to execute <code>sudo dracut -f</code> manually to regenerate the ramdisk for your current kernel (or install a new kernel, which will do that automatically for you).
{{Common bugs issue|vagrant-upgradepath|Upgrade path for Vagrant broken (rubygem-celluloid retired)|1275030}}


Alternatively, you can revert to the default theme before performing the upgrade:
The package {{package|rubygem-celluloid}} was retired between Fedora 22 and Fedora 23, but no package was set to obsolete it. If you have the package installed when you try to upgrade to Fedora 23, and you do not use the {{code|--allowerasing}} option, the upgrade will fail to resolve dependencies. We recommend using {{code|--allowerasing}} to enable DNF to remove the rubygem-celluloid package and allow the upgrade to proceed, but please check the list of packages to be removed carefully and make sure the upgrade will not remove anything vital to you.
<pre>
sudo plymouth-set-default-theme charge
sudo dracut -f
</pre>


== Core software issues ==
== Core software issues ==
{{Common bugs issue|text-initial-setup|Initial setup sometimes starts in text mode instead of in graphics mode|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 ==
{{Common bugs issue|initial-setup-logout|Initial user creation hands off to login screen (not desktop) and first attempt to log out fails|1273112|1272706}}
GNOME includes its own 'first boot' utility, {{package|gnome-initial-setup}}. If you install Workstation and do not create a user during the installation process, it will appear the first time you boot the installed system and require you to create a user account. When you complete the utility, it is intended to transfer you directly to the desktop logged in as the newly created user. However, sometimes, this does not work as intended and instead you see the GNOME login screen after creating the user account. When this happens, and you log in as the user you just created, your first attempt to log out will not work correctly, but instead will return you to a fresh logged in desktop session.
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 ==
{{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}}
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 {{command|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 ==
== ARM 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 issue|dnf-resize-crash|dnf crashes during install if terminal resized too small|1256531}}
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.


The version of the [[Dnf]] tool included in Fedora 23 Beta contains a bug which may cause it to crash during some operations if it is running in a terminal window and that window is resized to a smaller size. This is a fairly unusual case, but as it can cause dnf to crash during a package operation, it can cause severe consequences (the system being left in an inconsistent state). This bug will be fixed as soon as possible, but until then we strongly recommend you ensure any terminal windows in which you run dnf are of a reasonable size (80x24 characters is known to be safe) and do not resize them while it is running.
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.


{{Common bugs update testing|FEDORA-2015-16428}}
An [https://bodhi.fedoraproject.org/updates/FEDORA-2016-188c172b10 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.


{{Common bugs issue|systemd-shutdown-kill|All user session processes killed on system shutdown|1170765}}
If you already hit this bug during upgrade, just 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 connect to {{code|<nowiki>https://(serverhostname):8443/ca/admin/ca/getStatus</nowiki>}} for some time, failing each time, then eventually time out.


systemd, as included in Fedora 23 Beta, contains an issue with scope management (which includes user sessions). On system shutdown (or reboot), processes running in scopes are killed (with SIGKILL) almost immediately. The practical effect of this is that if you shut down the system directly from a user session (e.g. a logged-in desktop), rather than logging out first, applications running within that session will be killed, rather than shutting down cleanly.
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-188c172b10}}. 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.


The effects of this depend heavily on the application. Some known effects are:
== Fedora Cloud issues ==


* Firefox will often display its recovery screen the next time you run it.
== Other issues ==
* If any bash shells were running in the session, their history may not be properly appended (so you will not find commands run in that shell in the {{command|history}} output on subsequent boots), and if a particularly unfortunate timing is encountered, the bash history may be entirely destroyed.


Other applications may display other effects; basically, applications cannot be relied upon to quit in an orderly fashion, so anything they would normally do when called upon to quit may not happen correctly.
== Resolved issues ==


Logging out of the user session before shutting down the system should avoid this issue.
{{Common bugs issue|freeipa-upgrade-fail|FreeIPA fails to upgrade properly|1274905}}
{{Common bugs update released|FEDORA-2015-4d94884a7e}}
{{Common bugs update released|FEDORA-2015-f12c332a2f}}


This issue will be addressed before the final release of Fedora 23.
If you upgrade a system running [http://www.freeipa.org/page/Main_Page FreeIPA] to Fedora 23, FreeIPA will not start on the upgraded system. The logs will instruct you to run FreeIPA's upgrade process: {{code|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.


== GNOME issues ==
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.
{{Common bugs issue|autologin-logout-fail|Logging out does not work when autologin enabled|1245953}}


If you enable autologin in GNOME in Fedora 22, trying to log out will fail to work correctly; instead of returning to the login screen, you will get stuck at a black screen. We are working to fix this issue and an update should be available soon. Until then, we advise not using the autologin function of GNOME.
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:


== Plasma (KDE) issues ==
* Edit {{filename|/etc/dirsrv/slapd-(DOMAIN)/schema/99user.ldif}}
* Find the entry (split across three lines) that starts {{code|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 {{command|pki-server migrate --tomcat 8}}
* Run {{command|systemctl start pki-tomcatd@pki-tomcat.service}}
* Re-run the upgrade script: {{command|ipa-server-upgrade}}


{{Common bugs issue|text-initial-setup|Initial setup sometimes starts in text mode instead of in graphics mode|1185447}}
However, results may vary.


Sometimes happens that initial setup starts in text mode instead of graphical mode. Furthermode, it seems that text mode does not display properly. You can either reboot a few times, or log into a console and disable initial-setup-text.service by running command {{command|sudo systemctl disable initial-setup-text.service}} and restart. The graphical initial setup should be provided then.
{{Common bugs issue|plymouth-theme-upgrade|Certain plymouth themes are problematic during system upgrade|1267949}}
{{Common bugs update released|FEDORA-2015-08ea674d2c}}


== Network issues ==
Certain plymouth (boot screen) themes were buggy inside the system upgrade environment. The known issues are with {{code|script}} and {{code|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).


{{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}}
After installing the update, you can execute {{code|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.


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


If you don't need libvirt to work in the VM, you can remove libvirt networking there by running {{command|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.
{{Common bugs issue|selinux-abrt-sigchld|SELinux denial appears on application crash|1276305}}
{{Common bugs update released|FEDORA-2015-6b85d80ba8}}


== Hardware issues ==
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 {{code|SELinux is preventing abrt-hook-ccpp from using the 'sigchld' accesses on a process}}.


{{Common bugs issue|spurious-reboot|The system reboots instead of shutting down|1257131}}
{{Common bugs issue|spurious-reboot|The system reboots instead of shutting down|1257131}}
{{Common bugs update released|FEDORA-2015-115c302856}}
On some specific Intel boards the system would reboot after a few seconds instead of shutting down.


On some specific Intel boards the system reboots after a few seconds instead of shutting down. This is related to the XHCI controller and will likely be fixed with newer kernel releases, but for now there is a workaround listed in the bug report to fix this issue.
{{Common bugs issue|system-upgrade-locale|System-upgrade does not work under Chinese and Japanese (and probably some other) locales|1278031}}
{{Common bugs update released|FEDORA-2015-fe6e8b885b}}
{{Common bugs update released|FEDORA-2015-45efbec1fe}}


{{Common bugs issue|amd-64-32|Some 64-bit AMD processors cannot boot 32-bit Fedora 23 Beta images|1263762}}
Before this issue was fixed, system upgrade would fail with some languages, at least Chinese and Japanese. A workaround was to switch to English locale solely to run the upgrade, but as the bugs have now been fixed, this should no longer be necessary.


Fedora 23 Beta testing identified an issue where some 64-bit AMD processors cannot boot 32-bit Fedora 23 Beta kernels. 32-bit AMD CPUs do boot these kernels successfully. This may also affect you if you upgrade a 32-bit install on a 64-bit AMD system to Fedora 23 Beta.
{{Common bugs issue|python-requests-httpd|FreeIPA web UI (and potentially other webapps) does not work, SELinux denies 'execmem' access|1277224}}
{{Common bugs update released|FEDORA-2016-49b6510089}}


If you are affected by this issue, you can work around it by passing the kernel parameter {{code|1=maxcpus=0}} or {{code|1=maxcpus=1}}. If you upgraded from Fedora 22, the Fedora 22 kernel should also still be bootable.
There was a complex bug in Fedora 23 which was known to affect the FreeIPA web UI and may have affected 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 original {{package|python-cryptography}} module version in Fedora 23 commonly triggered such 'execmem' accesses. Notably, using the widely used {{package|python-requests}} module loads the python-cryptography module if the {{package|python-ndg_httpsclient}} package is installed. This package was a dependency of {{package|python-urllib3}} in Fedora 21, so it is fairly common to have it installed.
 
The result of this was that, if you have {{package|python-ndg_httpsclient}} installed, any Python webapp that uses the requests module was likely to crash. In the system logs you saw an SELinux denial of the 'execmem' access, and in the web server logs you likely saw a note that the affected process crashed. This was known to affect at least the FreeIPA web UI - the web server would continually try to launch child processes, and each one would crash - and may possibly have affected other webapps.
 
This issue was resolved with updates to the {{package|python-cffi}} and {{package|python-cryptography}} packages. As long as you have installed the latest versions of those packages, the issue should no longer affect you.
 
{{Common bugs issue|atomic-bad-tmp-permissions|Atomic images have incorrect permissions on the /tmp directory|1276775}}
{{Common bugs update released|FEDORA-2015-dd4760d0fc}}
{{Common bugs update released|FEDORA-2015-5f8e9e7d20}}


{{Common bugs issue|intel-three-monitors|Three monitors with an Intel GPU results in instability and display issues|1275770}}
The permissions of the {{filename|/tmp}} dir on early Fedora 23 Atomic host images were 755 when they should have been 777. This broke things that wanted to write to {{filename|/tmp}} but didn't have permissions to. This issue was resolved with an update to the {{package|ostree}} package which both ensured later Fedora 23 Atomic images were correct out of the box, and fixes the permissions on existing Fedora 23 Atomic deployments when they are updated.


Since kernel 4.2, people with Intel graphics cards experience issues when they have 3 (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.
{{Common bugs issue|upgrade-clean-cache|Packages downloaded for system upgrade are removed if you perform a package transaction before starting the upgrade|1276886}}
{{Common bugs update released|FEDORA-2015-12577}}


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.
If you want to [[DNF system upgrade|upgrade your system]], you first need to download all necessary packages, and then trigger the upgrade process. However, with DNF versions before 1.0.2, 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 {{code|Error: system is not ready for upgrade}} error message. You'll need to download all the packages again (using <code>dnf system-upgrade download ...</code> command).


== ARM issues ==
This issue was resolved in DNF 1.0.2, which was in Fedora 23 at release time, and was released for Fedora 22 as an update. Therefore, when upgrading from Fedora 22 to Fedora 23 you should not encounter this issue so long as Fedora 22 is updated first, and you should never encounter this issue when upgrading from Fedora 23 to a later release.
== Fedora Server issues ==
== Fedora Cloud issues ==


{{Common bugs issue|atomic-bad-tmp-permissions|Atomic images have incorrect permissions on the /tmp directory|1276775}}
If you still need to work around this issue, use <code>--setopt=keepcache=True</code> DNF option for transactions you perform between the upgrade download and the reboot. That will make sure your package cache is not cleaned and you will not need to re-download everything again.


The permissions of the /tmp dir on F23 atomic host RC10 are 755 when they should be 777. This breaks things that want to write to tmp but dont't have permissions to. To get around this: {{code|chmod 1777 /sysroot/tmp}}
{{Common bugs issue|intel-three-monitors|Three monitors with an Intel GPU results in instability and display issues|1275770}}
{{Common bugs update released|FEDORA-2016-f2f8b12e17}}


{{Common bugs issue|docker-privileged-containers|docker 1.7.0 can't bind mount root dir into container|1276776}}
Since kernel 4.2, some people with Intel graphics cards had 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.


Many super privileged containers need a bind mount of the root of the filesystem into the container. We can't do this with docker docker-1.7.0-22.gitdcff4e1.fc23.x86_64. Simply update docker to 1.8.0. You can wait until this hits the stable repos (it should be showing up soon) or build from source.
The initial reporter of this bug reported on 2016-05-09 that "The issue I originally reported is now fixed as of at least: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". We have not received further reports since.


== Other issues ==
[[Category:Common bugs]]

Latest revision as of 23:58, 14 March 2018

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

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

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

link to this item - Bugzilla: #1395686

When upgrading from Fedora 23, 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.

Upgrade path for Vagrant broken (rubygem-celluloid retired)

link to this item - Bugzilla: #1275030

The package rubygem-celluloid was retired between Fedora 22 and Fedora 23, but no package was set to obsolete it. If you have the package installed when you try to upgrade to Fedora 23, and you do not use the --allowerasing option, the upgrade will fail to resolve dependencies. We recommend using --allowerasing to enable DNF to remove the rubygem-celluloid package and allow the upgrade to proceed, but please check the list of packages to be removed carefully and make sure the upgrade will not remove anything vital to you.

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, gnome-initial-setup. If you install Workstation and do not create a user during the installation process, it will appear the first time you boot the installed system and require you to create a user account. When you complete the utility, it is intended to transfer you directly to the desktop logged in as the newly created user. However, sometimes, this does not work as intended and instead you see the GNOME login screen after creating the user account. When this happens, and you log in as the user you just created, your first attempt to log out will not work correctly, but instead will return you to a fresh logged in desktop session.

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

ARM issues

Fedora Server issues

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

Other issues

Resolved issues

FreeIPA fails to upgrade properly

link to this item - Bugzilla: #1274905

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

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.

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

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.

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

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.

On some specific Intel boards the system would reboot after a few seconds instead of shutting down.

System-upgrade does not work under Chinese and Japanese (and probably some other) locales

link to this item - Bugzilla: #1278031

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.

Before this issue was fixed, system upgrade would fail with some languages, at least Chinese and Japanese. A workaround was to switch to English locale solely to run the upgrade, but as the bugs have now been fixed, this should no longer be necessary.

FreeIPA web UI (and potentially other webapps) does not work, SELinux denies 'execmem' access

link to this item - Bugzilla: #1277224

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.

There was a complex bug in Fedora 23 which was known to affect the FreeIPA web UI and may have affected 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 original python-cryptography module version in Fedora 23 commonly triggered such 'execmem' accesses. Notably, using the widely used python-requests module loads the python-cryptography module if the python-ndg_httpsclient package is installed. This package was a dependency of python-urllib3 in Fedora 21, so it is fairly common to have it installed.

The result of this was that, if you have python-ndg_httpsclient installed, any Python webapp that uses the requests module was likely to crash. In the system logs you saw an SELinux denial of the 'execmem' access, and in the web server logs you likely saw a note that the affected process crashed. This was known to affect at least the FreeIPA web UI - the web server would continually try to launch child processes, and each one would crash - and may possibly have affected other webapps.

This issue was resolved with updates to the python-cffi and python-cryptography packages. As long as you have installed the latest versions of those packages, the issue should no longer affect you.

Atomic images have incorrect permissions on the /tmp directory

link to this item - Bugzilla: #1276775

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.

The permissions of the /tmp dir on early Fedora 23 Atomic host images were 755 when they should have been 777. This broke things that wanted to write to /tmp but didn't have permissions to. This issue was resolved with an update to the ostree package which both ensured later Fedora 23 Atomic images were correct out of the box, and fixes the permissions on existing Fedora 23 Atomic deployments when they are updated.

Packages downloaded for system upgrade are removed if you perform a package transaction before starting the upgrade

link to this item - Bugzilla: #1276886

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 want to upgrade your system, you first need to download all necessary packages, and then trigger the upgrade process. However, with DNF versions before 1.0.2, 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).

This issue was resolved in DNF 1.0.2, which was in Fedora 23 at release time, and was released for Fedora 22 as an update. Therefore, when upgrading from Fedora 22 to Fedora 23 you should not encounter this issue so long as Fedora 22 is updated first, and you should never encounter this issue when upgrading from Fedora 23 to a later release.

If you still need to work around this issue, use --setopt=keepcache=True DNF option for transactions you perform between the upgrade download and the reboot. That will make sure your package cache is not cleaned and you will not need to re-download everything again.

Three monitors with an Intel GPU results in instability and display issues

link to this item - Bugzilla: #1275770

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.

Since kernel 4.2, some people with Intel graphics cards had 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.

The initial reporter of this bug reported on 2016-05-09 that "The issue I originally reported is now fixed as of at least: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". We have not received further reports since.

Retrieved from "https://fedoraproject.org/w/index.php?title=Common_F23_bugs&oldid=512866"