From Fedora Project Wiki

(add 752613 (thinkpads with hybrid graphics failing to boot with discrete adapters))
(25 intermediate revisions by 5 users not shown)
Line 2: Line 2:


This page documents common bugs in Fedora 17 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 17 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|Fedora 17 pre-release|Fedora 17 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 17 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 [[F17 Beta release announcement]] and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora 17 Beta Release Notes] ***[http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/ Official Fedora 17 release notes (Unavailable on 2012-04-19)]*** for specific information about changes in Fedora 17 and other general information.
Read the [[F17 release announcement]] and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora 17 Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/ Fedora 17 release notes]--> for specific information about changes in Fedora 17 and other general information.


== My bug is not listed ==
== My bug is not listed ==
Not every bug is listed in this page, but [http://bugzilla.redhat.com 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.
Not every bug is listed in this page, but [http://bugzilla.redhat.com 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.


Line 53: Line 50:


== Installation issues ==
== Installation issues ==
{{Anchor|chainloading-fail}}
{{Anchor|nfsiso-reboot-hang}}
=== Attempting to chainload after installing Fedora 17 Beta's bootloader to a partition fails ===
=== Post-install reboot fails after NFS installation ===
<small>[[#chainloading-fail|link to this item]] - [[rhbug:804835|Bugzilla: #804835]]</small>
<small>[[#nfsiso-reboot-hang|link to this item]] - [[rhbug:824191|Bugzilla: #824191]]</small>
 
Sometimes, after the completion of a Fedora 17 installation using an NFS repository, the reboot which ends the install process will fail, leaving the system stuck at a black screen or some kernel messages. It is quite safe to reboot manually at this point, the installation has completed successfully and the installed system will work correctly. We recognize that manual rebooting may be more difficult in the case of automated deployment of headless and/or remote systems. The issue occurs when the NFS repository in use is unmounted too quickly, while the installer is still attempting to use resources from it; it appears to be a race-prone issue, as it does not occur in every test, and seems to occur much more frequently on some test systems than in others.
 
There is an [http://rvykydal.fedorapeople.org/updates.reboot.img installer updates image] which should work around the issue. For details on how to use an installer update image, see [https://fedoraproject.org/wiki/Anaconda/Updates this page]. Note that you will need to rename this file to ''updates.img'' for this to work.
 
You can also work around the issue by accessing the remote repository via HTTP or FTP rather than via NFS. HTTP/FTP repositories are not mounted, and so are not subject to the bug.
 
{{Anchor|upgrade-old-kernel}}
 
=== Kernel from previous release may still be used after upgrade, prevents clean shutdown ===
<small>[[#upgrade-old-kernel|link to this item]] - [[rhbug:820351|Bugzilla: #820351]]</small>
 
Starting during the Fedora 17 development cycle, the Fedora kernel team has started keeping the kernel package on all currently-supported releases as closely synchronized as possible. One unfortunate consequence of this policy is that it is now much more likely than previously that, on upgrading from one Fedora release to the next, no kernel from the new release will be installed. This will very likely be the case if you use the Fedora 17 DVD to upgrade from an updated Fedora 16 installation without enabling the ''updates'' online repository during the upgrade.
 
Unfortunately, due to the [[Features/UsrMove|/usr move]] feature of Fedora 17, if you boot a Fedora 17 system using a kernel that was installed while the system was still running Fedora 16, it will be unable to shut down cleanly. You must use a kernel installed after the upgrade to Fedora 17 in order to shut down cleanly.
 
To avoid this problem we recommend enabling the ''updates'' repository when upgrading to Fedora 17 whenever possible. If you do an upgrade to Fedora 17 and find the system will not shut down cleanly, check with {{command|uname -r}} whether the kernel you are using is from a previous release. If so, try to install and use a Fedora 17 kernel from the online repositories.
 
{{Anchor|preupgrade-small-boot}}
=== preupgrade fails with small /boot partition ===
<small>[[#preupgrade-small-boot|link to this item]] - [[rhbug:813973|Bugzilla: #813973]]</small>
 
If you attempt to preupgrade from an earlier Fedora release to Fedora 17 on a system with a small /boot partition - less than 500MB in size - the second phase of the upgrade (when the system reboots to the Fedora installer to complete the upgrade) will fail to boot properly, dropping you to an emergency shell after repeatedly failing to download a file.
 
You can work around this issue by editing the bootloader entry for the upgrade and removing ''/LiveOS/squashfs.img'' from the end of the stage2= parameter, so that it ends with ''/os/''. Doing so should allow the upgrade to proceed as normal.
 
{{Anchor|mac-multi-EFI}}
=== New EFI system partition created every time you install on a Mac ===
<small>[[#mac-multi-EFI|link to this item]] - [[rhbug:821187|Bugzilla: #821187]]</small>
 
Re-installing Fedora 17 on Macs in UEFI mode creates superfluous 200MB HFS+ partitions.
When re-installing Fedora 17 on Macs using UEFI boot, and choosing the "Replace Existing Linux" installation type, the previous 200MB HFS+ partition used as {{filename|/boot/efi}} will not be replaced. Instead a new one will be created. Both old and new boot options will appear in the option-key startup boot menu, and in Mac OS System Preferences > Startup Disk panel. It will not be clear which option is functional. To avoid this ambiguity, delete the 200MB HFS+ partition prior to re-installing Fedora 17, either from within the Anaconda user interface, or a CLI tool capable of editing a GPT. This does not affect first time installs.
 
{{Anchor|ksdevice-case-sensitive}}
=== ''ksdevice'' install parameter values are case-sensitive ===
<small>[[#ksdevice-case-sensitive|link to this item]] - [[rhbug:820366|Bugzilla: #820366]]</small>


If you choose to install the Fedora 17 Beta bootloader to the first sector of a partition (rather than to the MBR) and then try to 'chainload' it from whatever bootloader is installed in the MBR, the system will likely hang at a screen saying only 'GRUB'. This seems to be caused by a bug in grub2 itself.
In Fedora 17, the values for the ''ksdevice='' parameter which can be passed to the installer are case sensitive. That is to say, ''ksdevice=bootif'' and ''ksdevice=link'' are valid, but ''ksdevice=BOOTIF'' or ''ksdevice=Link'' are not. Invalid values can cause the installer to fail to boot. This differs from previous releases, where the values were not case sensitive, so configurations which previously worked may no longer do so.


It has been discovered that this bug can be worked around, at least if the host bootloader is grub or grub2, by using a host bootloader entry which loads the core.img of Fedora 17's grub2 as if it were a kernel, rather than using the 'chainloader' statement. See [https://bugzilla.redhat.com/show_bug.cgi?id=804835#c2 this comment] for an example entry.
{{Anchor|preupgrade-grub}}
=== preupgrade from Fedora 16 does not update bootloader configuration ===
<small>[[#preupgrade-grub|link to this item]] - [[rhbug:815473|Bugzilla: #815473]]</small>


Fixed in grub2-2.0-0.24.beta4.fc17 which has been pushed to f17 stable and used in the latest installer images.
Due to several issues with grub and with the way preupgrade attempts to update the bootloader configuration, when you preupgrade from Fedora 16 to Fedora 17, the first stage of the process - the preupgrade application which runs within Fedora 16 - fails to upgrade the bootloader configuration on completion. This means that, when you reboot in order to complete the upgrade via the Fedora 17 installer, the system will by default boot not to the installer to complete the update process, but back to the existing Fedora 16 installation.


{{Anchor|ntfs-resize-fail}}
There is no danger in this, and the upgrade can still be run successfully, no matter how many times the system is booted to Fedora 16. To complete the upgrade, you only have to access the boot menu before the timeout expires and manually select the 'Upgrade to Fedora 17' entry. This will cause the installer to run and complete the upgrade.


=== Cannot resize NTFS partitions during Fedora 17 Beta installation ===
{{Anchor|anaconda-btrfs-crash}}
<small>[[#ntfs-resize-fail|link to this item]] - [[rhbug:810039|Bugzilla: #810039]]</small>
=== Installer crashes if you edit an existing btrfs partition ===
<small>[[#anaconda-btrfs-crash|link to this item]] - [[rhbug:810141|Bugzilla: #810141]]</small>


Due to a bug in the {{package|lorax}} utility which creates the runtime environment for the Fedora installer - the libraries required by the 'ntfsresize' utility are deleted from the environment - it is not possible to resize NTFS partitions during installation of Fedora 17 Beta from the DVD or network installer images. You will get an error message if you try to do so.
If you use the 'custom partitioning' option in the Fedora 17 installer and attempt to edit an existing btrfs partition in any way, the installer will crash with the error "KeyError: 'fstypeCombo'". If you report the error it will show as a duplicate of [[rhbug:810141|bug #810141]].


The only way to 'work around' this issue is to do any needed NTFS partition resizing in some other environment - such as a live boot - prior to installing Fedora 17 Beta, or to install from a live image (NTFS resizing should work when running the installer from a live image). This issue will be resolved for the final release of Fedora 17.
There is no direct workaround for this bug. Fedora 17 is not capable of interactively creating or modifying btrfs partitions in the installer. If you wish to use btrfs partitions in a Fedora 17 installation, the options available are either to use a [[Anaconda/Kickstart|kickstart]] (scripted installation) or install Fedora 16 and then [[Upgrading|upgrade]].
 
{{Anchor|bootloader-password}}
=== Bootloader password is required on each boot ===
<small>[[#bootloader-password|link to this item]] - [[rhbug:840160|Bugzilla: #840160]]</small>
 
If you set a bootloader password during installation of Fedora 17 (which is only possible when doing a [[Anaconda/Kickstart|kickstart-based]] install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.
 
Lawrence Lowe [https://bugzilla.redhat.com/show_bug.cgi?id=840160#c14 suggests] that the --unrestricted parameter can be added to ''menuentry'' lines in the grub config file to make them available without the password being entered.


== Hardware issues ==
== Hardware issues ==
Line 86: Line 130:
</pre>
</pre>


== Software issues ==
{{Anchor|lenovo-nvidia-hang}}
{{Anchor|missing-translations-langpacks}}
=== Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420) ===
=== Some translations missing after DVD install of Fedora 17 Beta (KDE, LibreOffice, a few others) ===
<small>[[#lenovo-nvidia-hang|link to this item]] - [[rhbug:752613|Bugzilla: #752613]] [https://bugzilla.kernel.org/show_bug.cgi?id=43054 Kernel bugzilla: #43054]</small>
<small>[[#missing-translations-langpacks|link to this item]] - [[rhbug:804216|Bugzilla: #804216]]</small>
 
Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 17 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.


Some packages in Fedora use the 'langpacks' system for translations, where translations are packaged separately from the main package. Due to changes in the package groups definitions, in Fedora 17 Beta, these 'langpacks' translation packages have been inadvertently omitted from the DVD image (in previous releases, they were present on the DVD). This means that if you do a DVD installation without enabling remote repositories, the translation packages will not be installed for any of these packages that are included in the initial installation. Translation packages will be included if you install the packages via yum or PackageKit later - the bug is only an issue at initial install time. System updates will not add the translation packages for any affected packages, however - if you are affected by this bug at installation time, you will have to install the translation packages manually with yum or PackageKit.
Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the [http://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io VT-d advanced virtualization feature], the [https://en.wikipedia.org/wiki/X2APIC X2APIC level APIC], and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.


Packages known to use langpacks include the KDE desktop, LibreOffice, man-pages and hunspell. So if you do a default DVD installation and you use a non-English language, you will find translations are not installed for LibreOffice, hunspell (and so for anything which uses hunspell for spell checking), or man-pages (the man pages for several core commands are included in this compendium package). If you install KDE from the DVD, you will similarly find the translations missing.
So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter ''nox2apic''. In this way, you should be able to determine which of the features you want to use.


To work around this bug at installation time when using the DVD, ensure you enable remote repositories when given the opportunity. If you have already been affected by the bug, you can manually install the appropriate translation packages with yum or PackageKit. For instance, if you use French and you wish to restore the KDE and LibreOffice translations, you would install the {{package|libreoffice-langpack-fr}} and {{package|kde-i18n-French}} packages.
The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.


This issue will be corrected for the final release - the langpacks will be included in the DVD.
== Software issues ==
{{Anchor|hibernate-corruption}}
=== Hibernation may lead to data corruption ===
<small>[[#hibernate-corruption|link to this item]] - [[rhbug:823871|Bugzilla: #823871]] - [[rhbug:822071|Bugzilla: #822071]]</small>


{{Anchor|gsd-date-crash}}
There have been some reports that use of hibernation (suspend to disk, as opposed to suspend to RAM) may result in data corruption, possibly to files in {{filename|/var/tmp}}. After a hibernate/resume cycle, the partition is reported as damaged by fsck. These reports are still being investigated, but as a precaution we highly recommend you avoid use of the hibernation function on systems containing important data. Sleep - suspend to RAM - is usually sufficient for most purposes.
=== GNOME fails to start due to gnome-settings-daemon crash if system date is earlier than 2012-02-01 ===
<small>[[#gsd-date-crash|link to this item]] - [[rhbug:809707|Bugzilla: #809707]]</small>


A bug in ''gnome-settings-daemon'', a core component of the GNOME desktop, causes it to crash if the system date is earlier than the 'starttime' specified in the configuration file for the active desktop background theme. The default Fedora 17 Beta background theme specifies a 'starttime' of 2012-02-01, so if the system date is earlier than this, gnome-settings-daemon will crash and GNOME will fail to start up correctly (it will display the 'Oh no! Something has gone wrong' error screen).
{{Anchor|gdm-layout}}
=== GNOME login screen (GDM) always uses US keyboard layout if available ===
<small>[[#gdm-layout|link to this item]] - [[rhbug:816554|Bugzilla: #816554]]</small>


To work around this issue, correct the system date, or at least set it to something later than 2012-01-31.
In Fedora 17, GDM (the GNOME login manager) is designed to always use the U.S. keyboard layout if it is available. This design is now considered to be flawed, but there was not time to change it for the release of Fedora 17. This means that if you install Fedora 17 using any of the keyboard layouts that are, by default, 'twinned' with the U.S. English layout - including Czech QWERTZ, Russian, several Indian layouts, and several others, all listed in [https://bugzilla.redhat.com/show_bug.cgi?id=816554#c7 this Bugzilla comment], then the chosen layout will be used during user creation in the firstboot utility, but the U.S. English layout will be selected by default in GDM. This is, obviously, confusing, and may lead to your 'correctly typed' password not being accepted, if the keys used to enter it differ between the two layouts. You can change the keyboard layout in GDM simply by clicking on the layout selector at the top-right hand corner of the screen.


An updated [http://admin.fedoraproject.org/updates/FEDORA-2012-6123 gnome-settings-daemon] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [http://admin.fedoraproject.org/updates/FEDORA-2012-6123 report to Bodhi] whether it solves the problem. To test the update, run this command:
Of course, you will also be affected by this issue if you typically use a layout other than U.S. English which does not come 'twinned' with the U.S. English layout by default, but you manually install the U.S. English layout after system installation.
<pre>su -c 'yum --enablerepo=updates-testing update gnome-settings-daemon'</pre> (although it may be better to do a full update, as the update is part of a much bigger GNOME 3.4.1 update).


{{Anchor|dkms-old-fail}}
{{Anchor|dkms-old-fail}}
Line 118: Line 165:
To work around this issue, manually rename {{filename|/usr/sbin/dkms.old}} to {{filename|/usr/sbin/dkms}}. You may have to do this after each update of the {{package|dkms}} package, at least until this bug is fixed.
To work around this issue, manually rename {{filename|/usr/sbin/dkms.old}} to {{filename|/usr/sbin/dkms}}. You may have to do this after each update of the {{package|dkms}} package, at least until this bug is fixed.


We will issue an update to resolve this bug shortly.
We hope to issue an update to resolve this bug shortly.
<!--
{{Anchor|packagekit-yum-lock}}
=== PackageKit sometimes locks yum too frequently and for too long ===
<small>[[#packagekit-yum-lock|link to this item]] - [[rhbug:810530|Bugzilla: #810530]]</small>
 
Some testers have reported that, in Fedora 17 Beta, PackageKit background operations seems to hold the yum lock (preventing any manual use of yum or PackageKit) much more frequently, and for longer periods of time, than was the case in previous releases. There is currently no clear indication of why this is, or any known workaround; we are at the early stages of investigating the problem. It is noted here purely for information.
-->
{{Anchor|deny-ptrace}}
=== SELinux deny_ptrace flag on by default: will prevent gdb etc. from working ===
<small>[[#deny-ptrace|link to this item]]</small>
 
The [[Features/SELinuxDenyPtrace|SELinux deny_ptrace flag]] is enabled in Fedora 17. This will prevent applications that use the kernel ptrace(2) API - like gdb and strace, and other debugging utilities - from working: you will see an SELinux denial when trying to use them. To toggle the flag off (until reboot), so you can use a debugger, run {{command|setsebool deny_ptrace 0}} as root. To make this change permanent even after rebooting, run {{command|setsebool -P deny_ptrace 0}}.


{{Anchor|libvirtd-restart-kill}}
{{Anchor|pam-config-upgrade}}
=== Restarting libvirtd service (including updating libvirt package) kills running virtual machines ===
<small>[[#libvirtd-restart-kill|link to this item]] - [[rhbug:805942|Bugzilla: #805942]]</small>


It has long been the case that you can restart the ''libvirtd'' service without affecting running KVM virtual machines. This is often suggested as part of troubleshooting virtualization issues, and updating the {{package|libvirt}} package usually restarts the service. However, a change in systemd means that, with the versions of {{package|libvirt}} and {{package|systemd}} included in Fedora 17 Beta, restarting the ''libvirtd'' service kills (i.e. uncleanly shuts down) all running virtual machines.
=== Soundcard inaccessible after upgrade from a previous Fedora release ===
<small>[[#pam-config-upgrade|link to this item]] - [[rhbug:815413|Bugzilla: #815413]]</small>


We strongly recommend that, if you are planning to run any virtual machines with Fedora 17 Beta as a host, you configure yum not to automatically update the {{package|libvirt}} package (see the '''exclude''' keyword in {{command|man yum.conf}} for details on doing this), and shut down all running virtual machines manually prior to restarting the ''libvirtd'' service manually, or updating the {{package|libvirt}} package manually. It is, of course, not a good idea to use any pre-release version of Fedora as a host for important virtual machines: pre-release versions of Fedora should never be relied on for any kind of mission critical operation.
A few users reported that after upgrading from Fedora 16 their /etc/pam.d/* configuration files did not reference the pam_systemd.so module. As a result, the user login sessions are not properly tracked by the systemd-logind daemon and the users are not granted access to sound and other devices. It is unclear what the exact conditions for the wrong PAM configuration to occur are. The problem does not seem to be easily reproduced. To fix the problem, run <code>authconfig --updateall</code> which will correct the PAM configuration files.


A systemd update which resolves this issue should be available quite soon.
{{Anchor|chronyd-hotel-california}}
=== Disabling '''chronyd''' service does not stop chronyd from running ===
<small>[[#chronyd-hotel-california|link to this item]] - [[rhbug:821813|Bugzilla: #821813]]</small>


{{Anchor|packagekit-yum-lock}}
Due to the design used to allow the GNOME control center to enable or disable network time configuration, disabling the ''chronyd.service'' service will not in fact prevent chronyd from running if at least one of these conditions is true:
=== PackageKit sometimes locks yum too frequently and for too long ===
* Network time is enabled in the GNOME control center.
<small>[[#packagekit-yum-lock|link to this item]] - [[rhbug:810530|Bugzilla: #810530]]</small>
* ''ntpd.service'' is installed as well and enabled.
 
If you wish to prevent chronyd from starting, you can do <code>systemctl mask chronyd.service</code>. Or, you can remove the {{package|chrony}} package.
 
{{Anchor|virt-gdm-fprint}}
=== GDM fails to run in some virtual machine configurations with fprintd installed ===
<small>[[#virt-gdm-fprint|link to this item]] - [[rhbug:810040|Bugzilla: #810040]]</small>
 
Several users have reported that Fedora 17 installations to various virtual machine configurations, including Xen, VMware, and KVM systems, fail to run the default login manager (GDM). The ''Oh no! An error has occurred'' error screen appears instead. The GDM logs, if examined, show ''<nowiki>JS ERROR: !!!  Exception was: Error: Error invoking Gio.init: Error calling
StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus
.Error.Spawn.ChildExited: Launch helper exited with unknown return code 157</nowiki>''.


Some testers have reported that, in Fedora 17 Beta, PackageKit background operations seems to hold the yum lock (preventing any manual use of yum or PackageKit) much more frequently, and for longer periods of time, than was the case in previous releases. There is currently no clear indication of why this is, or any known workaround; we are at the early stages of investigating the problem. It is noted here purely for information.
This issue can be worked around by removing the {{package|fprintd}} and {{package|fprintd-pam}} packages (from a virtual terminal if necessary). After doing this, GDM should run and work correctly.


=== SELinux deny_ptrace flag on by default: will prevent gdb etc. from working ===
{{Anchor|slow-keys}}
<small>[[#deny-ptrace|link to this item]]</small>
=== Keyboard "dies" (becomes unresponsive) ===
<small>[[#slow-keys|link to this item]] - [[rhbug:816764|Bugzilla: #816764]]</small>


The [[Features/SELinuxDenyPtrace|SELinux deny_ptrace flag]] is enabled in Fedora 17 Beta. This will prevent applications that use the kernel ptrace(2) API - like gdb and strace, and other debugging utilities - from working: you will see an SELinux denial when trying to use them. To toggle the flag off (until reboot), so you can use a debugger, run {{command|setsebool deny_ptrace 0}} as root.
Fedora 17's X server has a feature called "slow keys" which can engage when you hold down the Shift key for more than 10 seconds. On some window managers such as XFCE there is no visual notification when this happens. The bug link gives various possible remedies.

Revision as of 01:06, 20 April 2013

This page documents common bugs in Fedora 17 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 F17 release announcement and the Fedora 17 Beta Release Notes for specific information about changes in Fedora 17 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. Please follow the style and guidelines explained in the comments in the page source.
  • 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

Post-install reboot fails after NFS installation

link to this item - Bugzilla: #824191

Sometimes, after the completion of a Fedora 17 installation using an NFS repository, the reboot which ends the install process will fail, leaving the system stuck at a black screen or some kernel messages. It is quite safe to reboot manually at this point, the installation has completed successfully and the installed system will work correctly. We recognize that manual rebooting may be more difficult in the case of automated deployment of headless and/or remote systems. The issue occurs when the NFS repository in use is unmounted too quickly, while the installer is still attempting to use resources from it; it appears to be a race-prone issue, as it does not occur in every test, and seems to occur much more frequently on some test systems than in others.

There is an installer updates image which should work around the issue. For details on how to use an installer update image, see this page. Note that you will need to rename this file to updates.img for this to work.

You can also work around the issue by accessing the remote repository via HTTP or FTP rather than via NFS. HTTP/FTP repositories are not mounted, and so are not subject to the bug.

Kernel from previous release may still be used after upgrade, prevents clean shutdown

link to this item - Bugzilla: #820351

Starting during the Fedora 17 development cycle, the Fedora kernel team has started keeping the kernel package on all currently-supported releases as closely synchronized as possible. One unfortunate consequence of this policy is that it is now much more likely than previously that, on upgrading from one Fedora release to the next, no kernel from the new release will be installed. This will very likely be the case if you use the Fedora 17 DVD to upgrade from an updated Fedora 16 installation without enabling the updates online repository during the upgrade.

Unfortunately, due to the /usr move feature of Fedora 17, if you boot a Fedora 17 system using a kernel that was installed while the system was still running Fedora 16, it will be unable to shut down cleanly. You must use a kernel installed after the upgrade to Fedora 17 in order to shut down cleanly.

To avoid this problem we recommend enabling the updates repository when upgrading to Fedora 17 whenever possible. If you do an upgrade to Fedora 17 and find the system will not shut down cleanly, check with uname -r whether the kernel you are using is from a previous release. If so, try to install and use a Fedora 17 kernel from the online repositories.

preupgrade fails with small /boot partition

link to this item - Bugzilla: #813973

If you attempt to preupgrade from an earlier Fedora release to Fedora 17 on a system with a small /boot partition - less than 500MB in size - the second phase of the upgrade (when the system reboots to the Fedora installer to complete the upgrade) will fail to boot properly, dropping you to an emergency shell after repeatedly failing to download a file.

You can work around this issue by editing the bootloader entry for the upgrade and removing /LiveOS/squashfs.img from the end of the stage2= parameter, so that it ends with /os/. Doing so should allow the upgrade to proceed as normal.

New EFI system partition created every time you install on a Mac

link to this item - Bugzilla: #821187

Re-installing Fedora 17 on Macs in UEFI mode creates superfluous 200MB HFS+ partitions. When re-installing Fedora 17 on Macs using UEFI boot, and choosing the "Replace Existing Linux" installation type, the previous 200MB HFS+ partition used as /boot/efi will not be replaced. Instead a new one will be created. Both old and new boot options will appear in the option-key startup boot menu, and in Mac OS System Preferences > Startup Disk panel. It will not be clear which option is functional. To avoid this ambiguity, delete the 200MB HFS+ partition prior to re-installing Fedora 17, either from within the Anaconda user interface, or a CLI tool capable of editing a GPT. This does not affect first time installs.

ksdevice install parameter values are case-sensitive

link to this item - Bugzilla: #820366

In Fedora 17, the values for the ksdevice= parameter which can be passed to the installer are case sensitive. That is to say, ksdevice=bootif and ksdevice=link are valid, but ksdevice=BOOTIF or ksdevice=Link are not. Invalid values can cause the installer to fail to boot. This differs from previous releases, where the values were not case sensitive, so configurations which previously worked may no longer do so.

preupgrade from Fedora 16 does not update bootloader configuration

link to this item - Bugzilla: #815473

Due to several issues with grub and with the way preupgrade attempts to update the bootloader configuration, when you preupgrade from Fedora 16 to Fedora 17, the first stage of the process - the preupgrade application which runs within Fedora 16 - fails to upgrade the bootloader configuration on completion. This means that, when you reboot in order to complete the upgrade via the Fedora 17 installer, the system will by default boot not to the installer to complete the update process, but back to the existing Fedora 16 installation.

There is no danger in this, and the upgrade can still be run successfully, no matter how many times the system is booted to Fedora 16. To complete the upgrade, you only have to access the boot menu before the timeout expires and manually select the 'Upgrade to Fedora 17' entry. This will cause the installer to run and complete the upgrade.

Installer crashes if you edit an existing btrfs partition

link to this item - Bugzilla: #810141

If you use the 'custom partitioning' option in the Fedora 17 installer and attempt to edit an existing btrfs partition in any way, the installer will crash with the error "KeyError: 'fstypeCombo'". If you report the error it will show as a duplicate of bug #810141.

There is no direct workaround for this bug. Fedora 17 is not capable of interactively creating or modifying btrfs partitions in the installer. If you wish to use btrfs partitions in a Fedora 17 installation, the options available are either to use a kickstart (scripted installation) or install Fedora 16 and then upgrade.

Bootloader password is required on each boot

link to this item - Bugzilla: #840160

If you set a bootloader password during installation of Fedora 17 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.

Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.

Hardware issues

Systems hangs on X startup with NVIDIA GeForce GTX 580 adapter (affects installation)

link to this item - Bugzilla: #802026

It has been reported that a bug in the nouveau video driver causes systems with an NVIDIA GeForce GTX 580 video adapter to hang as soon as the X graphical environment starts up. This issue also affects installation, so as soon as X is started, installation hangs.

This issue can be worked around by disabling hardware acceleration. To do this, pass the kernel parameter nouveau.noaccel=1. You can append kernel parameters at boot time - of a live image, DVD or network install image, or an installed system - by hitting the Tab key when the system reaches the bootloader menu, and typing in the desired additional parameter.

You can make the workaround 'permanent' on an installed system either by editing it into the /boot/grub2/grub.cfg file, or by creating a file named /etc/modprobe.d/noaccel.conf containing a single line reading:

options nouveau noaccel=1

Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420)

link to this item - Bugzilla: #752613 Kernel bugzilla: #43054

Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 17 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.

Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the VT-d advanced virtualization feature, the X2APIC level APIC, and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.

So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter nox2apic. In this way, you should be able to determine which of the features you want to use.

The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.

Software issues

Hibernation may lead to data corruption

link to this item - Bugzilla: #823871 - Bugzilla: #822071

There have been some reports that use of hibernation (suspend to disk, as opposed to suspend to RAM) may result in data corruption, possibly to files in /var/tmp. After a hibernate/resume cycle, the partition is reported as damaged by fsck. These reports are still being investigated, but as a precaution we highly recommend you avoid use of the hibernation function on systems containing important data. Sleep - suspend to RAM - is usually sufficient for most purposes.

GNOME login screen (GDM) always uses US keyboard layout if available

link to this item - Bugzilla: #816554

In Fedora 17, GDM (the GNOME login manager) is designed to always use the U.S. keyboard layout if it is available. This design is now considered to be flawed, but there was not time to change it for the release of Fedora 17. This means that if you install Fedora 17 using any of the keyboard layouts that are, by default, 'twinned' with the U.S. English layout - including Czech QWERTZ, Russian, several Indian layouts, and several others, all listed in this Bugzilla comment, then the chosen layout will be used during user creation in the firstboot utility, but the U.S. English layout will be selected by default in GDM. This is, obviously, confusing, and may lead to your 'correctly typed' password not being accepted, if the keys used to enter it differ between the two layouts. You can change the keyboard layout in GDM simply by clicking on the layout selector at the top-right hand corner of the screen.

Of course, you will also be affected by this issue if you typically use a layout other than U.S. English which does not come 'twinned' with the U.S. English layout by default, but you manually install the U.S. English layout after system installation.

DKMS broken due to executable being named dkms.old instead of dkms

link to this item - Bugzilla: #790521

The Package-x-generic-16.pngdkms package contains a very old post-install scriptlet which checks for /sbin/dkms and renames it to /sbin/dkms.old. This appears to have been intended to prevent an old copy of dkms in /sbin from overriding the Fedora-provided copy in /usr/sbin. However, with the /usr move feature in Fedora 17, /sbin is a symlink to /usr/sbin, and consequently the Fedora package itself effectively provides a copy of /sbin/dkms - which its own script promptly renames. The upshot is that there is no 'dkms' executable after installation of Fedora 17's Package-x-generic-16.pngdkms package, and so DKMS fails to work at all.

To work around this issue, manually rename /usr/sbin/dkms.old to /usr/sbin/dkms. You may have to do this after each update of the Package-x-generic-16.pngdkms package, at least until this bug is fixed.

We hope to issue an update to resolve this bug shortly.

SELinux deny_ptrace flag on by default: will prevent gdb etc. from working

link to this item

The SELinux deny_ptrace flag is enabled in Fedora 17. This will prevent applications that use the kernel ptrace(2) API - like gdb and strace, and other debugging utilities - from working: you will see an SELinux denial when trying to use them. To toggle the flag off (until reboot), so you can use a debugger, run setsebool deny_ptrace 0 as root. To make this change permanent even after rebooting, run setsebool -P deny_ptrace 0.

Soundcard inaccessible after upgrade from a previous Fedora release

link to this item - Bugzilla: #815413

A few users reported that after upgrading from Fedora 16 their /etc/pam.d/* configuration files did not reference the pam_systemd.so module. As a result, the user login sessions are not properly tracked by the systemd-logind daemon and the users are not granted access to sound and other devices. It is unclear what the exact conditions for the wrong PAM configuration to occur are. The problem does not seem to be easily reproduced. To fix the problem, run authconfig --updateall which will correct the PAM configuration files.

Disabling chronyd service does not stop chronyd from running

link to this item - Bugzilla: #821813

Due to the design used to allow the GNOME control center to enable or disable network time configuration, disabling the chronyd.service service will not in fact prevent chronyd from running if at least one of these conditions is true:

  • Network time is enabled in the GNOME control center.
  • ntpd.service is installed as well and enabled.

If you wish to prevent chronyd from starting, you can do systemctl mask chronyd.service. Or, you can remove the Package-x-generic-16.pngchrony package.

GDM fails to run in some virtual machine configurations with fprintd installed

link to this item - Bugzilla: #810040

Several users have reported that Fedora 17 installations to various virtual machine configurations, including Xen, VMware, and KVM systems, fail to run the default login manager (GDM). The Oh no! An error has occurred error screen appears instead. The GDM logs, if examined, show JS ERROR: !!! Exception was: Error: Error invoking Gio.init: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus .Error.Spawn.ChildExited: Launch helper exited with unknown return code 157.

This issue can be worked around by removing the Package-x-generic-16.pngfprintd and Package-x-generic-16.pngfprintd-pam packages (from a virtual terminal if necessary). After doing this, GDM should run and work correctly.

Keyboard "dies" (becomes unresponsive)

link to this item - Bugzilla: #816764

Fedora 17's X server has a feature called "slow keys" which can engage when you hold down the Shift key for more than 10 seconds. On some window managers such as XFCE there is no visual notification when this happens. The bug link gives various possible remedies.