Common F17 bugs
(update for final release, clean out resolved issues)
(add post-nfs-install-reboot-fail issue (824191))
|Line 51:||Line 51:|
== Installation issues ==
== Installation issues ==
== Hardware issues ==
== Hardware issues ==
Revision as of 04:38, 29 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.
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
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Post-install reboot fails after NFS installation
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 in the case where the installer is booted from the full network install or DVD image. For details on how to use an installer update image, see this page. However, this image does not resolve the issue in the case where the installer is booted directly from a kernel/initramfs pair (the difference between the two cases is that the NFS repository is used as the source of the installer itself in the second case, whereas in the first case it is used only as a source of packages; the installer is running from the DVD / network install image).
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.
Systems hangs on X startup with NVIDIA GeForce GTX 580 adapter (affects installation)
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
DKMS broken due to executable being named dkms.old instead of 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
package, and so DKMS fails to work at all.
We hope to issue an update to resolve this bug shortly.
SELinux deny_ptrace flag on by default: will prevent gdb etc. from working
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.
Soundcard inaccessible after upgrade from a previous Fedora release
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.