From Fedora Project Wiki

(document pam config after upgrade issue)
(fix anchors)
Line 136: Line 136:
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.
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 ===
=== SELinux deny_ptrace flag on by default: will prevent gdb etc. from working ===
<small>[[#deny-ptrace|link to this item]]</small>
<small>[[#deny-ptrace|link to this item]]</small>
Line 141: Line 142:
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.
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.


{{Anchor|pam-config-upgrade}}
=== Soundcard inaccessible after upgrade from a previous Fedora release ===
=== Soundcard inaccessible after upgrade from a previous Fedora release ===
<small>[[#pam-config-upgrade|link to this item]]</small>
<small>[[#pam-config-upgrade|link to this item]]</small>


A few users reported ([[rhbug:815413|Bugzilla: #815413]]) 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 few users reported ([[rhbug:815413|Bugzilla: #815413]]) 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.

Revision as of 20:12, 11 May 2012

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.

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

Read the F17 Beta release announcement and the Fedora 17 Beta Release Notes ***Official Fedora 17 release notes (Unavailable on 2012-04-19)*** 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

Attempting to chainload after installing Fedora 17 Beta's bootloader to a partition fails

link to this item - Bugzilla: #804835

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.

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 this comment for an example entry.

Fixed in grub2-2.0-0.24.beta4.fc17 which has been pushed to f17 stable and used in the latest installer images.

Cannot resize NTFS partitions during Fedora 17 Beta installation

link to this item - Bugzilla: #810039

Due to a bug in the 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.

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.

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

Software issues

Some translations missing after DVD install of Fedora 17 Beta (KDE, LibreOffice, a few others)

link to this item - Bugzilla: #804216

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.

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.

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 libreoffice-langpack-fr and kde-i18n-French packages.

This issue will be corrected for the final release - the langpacks will be included in the DVD.

GNOME fails to start due to gnome-settings-daemon crash if system date is earlier than 2012-02-01

link to this item - Bugzilla: #809707

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

To work around this issue, correct the system date, or at least set it to something later than 2012-01-31.

An updated 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 report to Bodhi whether it solves the problem. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update gnome-settings-daemon'

(although it may be better to do a full update, as the update is part of a much bigger GNOME 3.4.1 update).

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

link to this item - Bugzilla: #790521

The dkms 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 dkms 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 dkms package, at least until this bug is fixed.

We will issue an update to resolve this bug shortly.

Restarting libvirtd service (including updating libvirt package) kills running virtual machines

link to this item - Bugzilla: #805942

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 libvirt package usually restarts the service. However, a change in systemd means that, with the versions of libvirt and systemd included in Fedora 17 Beta, restarting the libvirtd service kills (i.e. uncleanly shuts down) all running virtual machines.

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 libvirt package (see the exclude keyword in 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 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 systemd update which resolves this issue should be available quite soon.

PackageKit sometimes locks yum too frequently and for too long

link to this item - Bugzilla: #810530

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.

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 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 setsebool deny_ptrace 0 as root.

Soundcard inaccessible after upgrade from a previous Fedora release

link to this item

A few users reported (Bugzilla: #815413) 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.