Common F17 bugs

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(add 820351 (problems when 16 kernel still used after 17 upgrade))
(add 816554 (US english keyboard layout used in gdm if available))
Line 104: Line 104:
  
 
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.
 
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.
 +
 +
{{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>
 +
 +
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.
 +
 +
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.
  
 
{{Anchor|dkms-old-fail}}
 
{{Anchor|dkms-old-fail}}

Revision as of 06:00, 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.

Contents

Release Notes

Read the F17 Beta 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.

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.

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.

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

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.

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, on a system using the GNOME desktop, disabling the chronyd.service service will not in fact prevent chronyd from running, as long as network time is enabled in the GNOME control center.

If you wish to disable chronyd, several suggestions are listed in the bug report. You can directly disable the target used by the GNOME control center, which is systemd-timedated-ntp.target. You can disable network time in the GNOME control center. Or, you can remove the Package-x-generic-16.pngchrony package.