(update the 524808/533952 note - update kernel is in updates-testing) |
(Add fuse mount bug, please edit the language if needed) |
||
| Line 294: | Line 294: | ||
{{BlameVendor|Mozilla|http://www.mozilla.org}} | {{BlameVendor|Mozilla|http://www.mozilla.org}} | ||
There is a conflict between binary software downloaded from Mozilla and software included in Fedora which may lead to a crash, often seen when using [[Flash]]. See [https://fedoraproject.org/wiki/Mozilla_NSS_Conflict this page] for details and workarounds. | There is a conflict between binary software downloaded from Mozilla and software included in Fedora which may lead to a crash, often seen when using [[Flash]]. See [https://fedoraproject.org/wiki/Mozilla_NSS_Conflict this page] for details and workarounds. | ||
{{Anchor|fuse-mount-xattr}} | |||
=== FUSE mounts may hang === | |||
<small>[[Common F12 bugs#fuse-mount-xattr|link to this item]] - [[rhbug:493565|Bugzilla: #493565]]</small> | |||
When audit is enabled and FUSE file systems are being mounted, a deadlock may happen which causes the mount to block indefinitely. A common symptom of this bug is that the user's Home folder appears to be empty when opened with Nautilus. Running the <pre>ls -la</pre> command in the user's home directory will also hang. Some users have reported that a reboot will fix the problem, others have reported that they need to do a file system check. To have the system check its file systems during the next boot, create an empty file named <tt>forcefsck</tt> in the / directory: <pre>su -c 'touch /forcefsck'</pre> This will only be a temporary fix and the problem will most likely appear again. The developers are working on fixing this issue in the Linux kernel. | |||
Revision as of 10:44, 25 November 2009
This page documents common bugs in Fedora 12 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 Fedora 12 release notes for specific information about intentional changes in Fedora 12, 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. Remember to try and follow the style and guidelines explained in the comments in the page source.
- Add the CommonBugs keyword to the bug report, and contact the Fedora QA team with the Bugzilla report number explaining why you believe that particular report qualifies as a common issue. You can contact Fedora QA through any of the methods listed here.
Issues when upgrading from previous releases
As usual, the supported methods for upgrading from previous Fedora releases are to do an 'upgrade install' from the regular installation media, or to use preupgrade (see How_to_use_PreUpgrade). If you intend to upgrade using preupgrade, it is highly recommended that you install the latest preupgrade package for your current Fedora release from the updates-testing repository before proceeding, due to several issues which are documented below. Upgrading by using yum directly is not supported, but may in practice work. For known issues when upgrading via yum, see the page on this upgrade method. For additional guidance on supported upgrade methods, see section 17.2. Upgrading Your System in the installation guide.
Preupgrade free space check on /boot not thorough
link to this item - Bugzilla: #530541
Preupgrade is intended to provide a hassle-free method for upgrading a system to the current release of Fedora. Testing identified that users of Fedora 11 (and earlier) who installed their systems using the recommended /boot partition size of 200MB may not be able to upgrade their systems using preupgrade. The /boot filesystem is used to store the kernel and initial ramdisk images that form the core of the Fedora operating system. required by several utilities including grub, kernel and preupgrade.
The preupgrade utility was not properly detecting the amount of available space on the /boot filesystem prior to beginning the system update process. As a result, preupgrade would successfully complete pre-upgrade operations, and reboot the system into the installer to continue with the upgrade. After reboot, the installer would then fail indicating that insufficient disk space was available to perform the update. A screenshot of the failure message is available.
A preupgrade update is available that will properly detect the amount of disk space available in /boot. Users are advised to update to the following 
preupgrade
- Fedora 12 - https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536
- Fedora 11 - https://admin.fedoraproject.org/updates/F11/FEDORA-2009-11547
- Fedora 10 - https://admin.fedoraproject.org/updates/F10/FEDORA-2009-11530
After installing the updated preupgrade package, if you are still unable to proceed with an update, please refer to these additional tips to free up space in /boot.
Preupgrade does not correctly detect and handle /boot on RAID in all cases
link to this item - Bugzilla: #533545
The preupgrade tool is intended to detect when the /boot partition is on a RAID array, warn that this is a potentially troublesome configuration to upgrade, and offer a workaround. In some cases, preupgrade may fail to detect this scenario, including when the RAID array in question is handled with dmraid rather than mdraid. If this happens it will continue operation without using the necessary workaround, which will result in a failed upgrade.
A preupgrade update is available that will properly detect the /boot on RAID situation in more cases. Users are advised to update to the following
- Fedora 12 - https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536
- Fedora 11 - https://admin.fedoraproject.org/updates/F11/FEDORA-2009-11547
- Fedora 10 - https://admin.fedoraproject.org/updates/F10/FEDORA-2009-11530
Upgrade on PPC architecture does not offer boot loader configuration screen
link to this item - Bugzilla: #536705
When manually upgrading a PPC Fedora system using Fedora 12 installation media, the installer will not offer a choice to modify your boot loader configuration. Instead, the installer will default to Update boot loader configuration and proceed with the upgrade. No workaround has yet been identified for this issue.
Installation issues
/boot must be a minimum of 300 MB
link to this item - Bugzilla: #510970
If you use a separate /boot partition, it is highly recommended that it be at least 300MB in size.
Windows recovery partition available as boot option instead of Windows partition
link to this item - Bugzilla: #534066
When installing Fedora alongside Windows on a system whose manufacturer provides a special 'recovery partition' to allow the re-installation of a clean copy of Windows, the Fedora installer may incorrectly configure the system boot to the recovery partition - rather than the main Windows partition - when the Other boot menu choice is selected. To resolve this issue, edit the file /boot/grub/menu.lst - you will need root privileges to edit this file - and adjust the Other entry accordingly. In most cases, the recovery partition will be the first partition on the first hard disk, and the real Windows partition the second partition on the first hard disk. In this case, the incorrect entry will look like this:
title Other rootnoverify (hd0,0) chainloader +1
It should be corrected to look like this:
title Other rootnoverify (hd0,1) chainloader +1
If you are not sure about your partition layout, the output of the command fdisk -l can help. The restore partition and the real Windows partition should be shown with different types. The output of this command uses /dev/sda to denote the first hard disk, /dev/sdb the second, and so on; and appends the partition numbers starting at 1, rather than 0. So /dev/sda1 in the fdisk output is equivalent to (hd0,0) in grub's format, while /dev/sda2 would be equivalent to (hd0,1) and /dev/sdc5 would be equivalent to (hd2,4).
RAID /boot partition not marked bootable when bootloader is installed on it
link to this item - Bugzilla: #533533
If you install Fedora 12 with /boot on a RAID array - either as its own partition or as part of a root partition that is on a RAID array - and also install the bootloader to that partition rather than to the system MBR, the partition will not be marked as bootable, as it should be. This renders the installed Fedora unbootable. To work around this issue, you must manually mark the appropriate partition as bootable with a tool such as fdisk.
Boot fails if system partition is on NFS or iSCSI on PPC architecture when installing from DVD or 6-CD media sets
link to this item - Bugzilla: #533392
The
Miscellaneous problems with Intel graphics adapters
If you are suffering from problems with an Intel graphics adapter such as failure of X to start at all, hangs or freezes or crashes in the graphical environment, display corruption, failure of 3D accelerated applications to work properly or similar problems, and your issue is not specifically covered elsewhere on this page, the following general advice may be of use.
Several such issues may be worked around by disabling kernel mode setting. To do this, add
nomodeset
as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, file a new bug report on the xorg-x11-drv-intel component, explaining your symptoms, and providing all the usual information required for X.org bug reports. In future kernel mode setting will be the only available method, and so we wish to ensure all problems caused by kernel mode setting are fixed.
If this does not resolve your issue, one other potential workaround is to change to a different acceleration method. To do this, add a line:
Option "AccelMethod" "EXA"
or:
Option "AccelMethod" "XAA"
to the Device section of /etc/X11/xorg.conf. If that file does not exist, see How_to_create_xorg.conf for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please file a new bug report on the xorg-x11-drv-intel component, explaining your symptoms, and providing all the usual information required for X.org bug reports. These legacy acceleration methods will be removed in future, so any bugs in the new acceleration method (UXA) need to be fixed.
Miscellaneous problems with ATI / AMD graphics adapters
link to this item - Bugzilla: #498457
If you are experiencing failure to start the graphical desktop, hanging or freezing, corruption, or slow performance with an ATI / AMD graphics adapter, you may try the following.
Some issues may be worked around by disabling kernel mode setting. To do this, add
nomodeset
as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, file a new bug report on the xorg-x11-drv-ati component, explaining your symptoms, and providing all the usual information required for X.org bug reports. In future kernel mode setting will be the only available method, and so we wish to ensure all problems caused by kernel mode setting are fixed.
If this does not resolve your issue, one other potential workaround is to change to a different acceleration method. To do this, add a line:
Option "AccelMethod" "XAA"
to the Device section of /etc/X11/xorg.conf. If that file does not exist, see How_to_create_xorg.conf for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please file a new bug report on the xorg-x11-drv-ati component, explaining your symptoms, and providing all the usual information required for X.org bug reports. These legacy acceleration methods will be removed in future, so any bugs in the new acceleration method (EXA) need to be fixed.
If this does not resolve your issue, there is another configuration option to try. Add a line:
Option "AccelDFS" "off"
to the Device section of /etc/X11/xorg.conf. If that file does not exist, see How_to_create_xorg.conf for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please file a new bug report on the xorg-x11-drv-ati component, explaining your symptoms, and providing all the usual information required for X.org bug reports.
Finally, if this still does not resolve your issue, try adding this line:
Option "DRI" "off"
to the Device section of /etc/X11/xorg.conf. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please file a new bug report on the xorg-x11-drv-ati component, explaining your symptoms, and providing all the usual information required for X.org bug reports.
Display cannot be reactivated if it enters sleep mode with laptop lid closed
link to this item - Bugzilla: #489907 - X.org bug #21230
Due to a known bug, on some laptops with Intel video adapters, if the display goes into sleep mode with the laptop lid closed, it will not be reactivated when the laptop lid is opened. The display will stay blank unless you reboot or use the following workaround. To workaround this problem, create a file with the following contents:
#!/bin/bash xrandr --output LVDS1 --off xrandr --output LVDS1 --auto
and save it as ~/screenfix.sh. Make it executable, and assign it to a keyboard shortcut (the method for doing this depends on your desktop environment). Executing this script via the keyboard shortcut should bring the display back to life. Note that the output parameter may vary; you can see the appropriate value for your system by running xrandr at a console and examining the output. A fix for this issue has been committed to the upstream kernel and may be made available in a future Fedora 12 kernel update.
Poor performance (mainly 3D) with some AMD / ATI Radeon adapters
link to this item - Bugzilla: #526967
Some aspects of graphics performance - mainly 3D performance, but also some 2D cases such as OpenOffice.org Impress effects - are known to be very poor on some ATI / AMD Radeon graphics chipsets with kernel modesetting enabled. If you are experiencing poor performance on an AMD / ATI graphics adapter, you can attempt to work around this issue by disabling kernel mode setting, using the nomodeset kernel parameter as documented above. This issue is known and is being worked on for future Fedora releases and potentially for Fedora 12 updates.
Software issues
Systems fail to boot, USB is not functional, network adapter fails to work (or possibly other symptoms) due to imperfect handling of BIOSes with broken IOMMU handling
link to this item - Bugzilla: #524808 and Bugzilla: #533952
Some manufacturers ship systems with a BIOS whose handling of IOMMU hardware is incorrect. The BIOS is supposed to tell the operating system where in memory to find the IOMMU hardware, but some BIOSes do not do so correctly, providing a garbage location or a location which is valid but is not actually where the device is located. The kernel attempts to handle these cases, but some are still not fully handled in the Fedora 12 kernel. If you have a system affected by this problem, the most common symptom is that the USB subsystem will fail to work (no USB peripherals will work), but other symptoms have included systems that completely fail to boot, and non-functional network adapters.
The list of systems currently known to be potentially affected by this issue is available here. For all of those except the HP xw4600 Workstation and the Dell Precision M6400, all of the following conditions must be true before you hit the bug:
- You must be using the 32-bit edition of Fedora 12
- You must have no memory beyond the 4GB address area (practically speaking, this means you must have around 2.5GB of physical RAM or less)
- Virtualization features (VT-d) must be disabled in the BIOS
If any of the above is not the case, you should not encounter this issue. If you think you may be suffering from this issue, look for a kernel log message including something similar to:
Your BIOS is broken; DMAR reported at address fed10000 returns all ones!
or:
Your BIOS is broken; DMAR reported at address zero!
Please note that if you are using a system with such a broken BIOS, the kernel message will always appear, even if the kernel in fact handles your case correctly, or you have successfully worked around the issue. So don't worry that you still see the message once you have worked around the problem.
There are several ways to work around this issue, if you hit it. In most cases (see above), installing the 64-bit edition of Fedora 12 would be enough. If your BIOS has an option for it, enabling virtualization features in the BIOS should also work around this problem. Finally, you can work around it by appending the kernel parameter iommu=soft to your boot configuration.
An updated kernel package has been submitted to the updates-testing repository for testing, that should resolve this issue for most affected users. 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 kernel'
Future kernel builds should bring a more permanent fix that should catch all BIOSes that are broken regarding IOMMU location.
LXDE live images are unusable
Due to a severe bug which was not noticed during the LXDE group's testing, the initial LXDE live images for Fedora 12 are completely unusable. lxde-session will crash on startup and get stuck in an infinite restart loop, rendering the desktop useless. For more details, see this blog post from the Fedora LXDE group leader. The original images have been removed and fixed images will be forthcoming. If you downloaded one of the original LXDE live images, please discard it and wait for an updated image. You can also install Fedora 12 from the DVD or any of the other live spins and install LXDE by installing the LXDE package group. That method works without problems.
Live USB sticks created with unetbootin do not work
link to this item - upstream report
The root cause of this problem is not Fedora, but rather software provided by UNetbootin. If you are interested in a fix for this issue, you must contact that vendor through their web site.
Multiple reports have been received that trying to create a Fedora 12 live USB stick from the live CD images using the popular UNetbootin utility results in a non-bootable stick. Attempting to boot the stick fails completely at an early stage. No known workaround is available to make a UNetbootin-created stick work. However, you can create the stick using the console livecd-iso-to-disk or graphical liveusb-creator tools. On existing Fedora systems, livecd-iso-to-disk is available in the liveusb-creator is available in the liveusb-creator following the official instructions.
This issue has been reported to the UNetbootin developers, so they may be able to release an updated UNetbootin which works with Fedora 12 images in the future.
Encrypted disks can't be unencrypted for non-graphical boot
link to this item - Bugzilla: #530896
Due to an unidentified bug early in the boot cycle, some users are unable to access encrypted disks or partitions at boot up when using a non-graphical boot splash. This issue can be worked around by booting with:
rhgb vga=0x318
on the kernel command line (specified at grub time).
If you are installing Fedora 12 and intend to use encrypted partitions, or are upgrading a system with encrypted partitions to Fedora 12 from an earlier release, it is recommended that you use the traditional installer - not a live image - to install, and make sure to enable the Fedora 12 - Updates repository during installation. This will ensure you are not affected by this issue.
An updated plymouth package has been released to address this issue. Update your system as usual to receive this update, if you do not yet already have it. You may need to rebuild your initial ramdisk after applying the update on an installed Fedora 12 system by running the following command: /usr/libexec/plymouth/plymouth-update-initrd as root. Make sure that you are booted into the latest installed kernel before rebuilding the initial ramdisk.
Missing printer drivers
link to this item - Bugzilla: #536831
The yum install foomatic.
CD tray problems or slow boot after installation from live CD
link to this item - Bugzilla: #527781
When installing from a live CD, the anaconda package is installed on the system. It includes some custom udev rules in the file /lib/udev/rules.d/70-anaconda.rules. These rules have been reported to cause various problems, ranging from CD trays closing again right after ejecting a CD or boot hanging in udev for a long time.
If your system shows these symptoms, you can simply remove the
Intel BIOS RAID arrays created after installation not detected
link to this item - Bugzilla: #537329
Due to incomplete handling in the initialization scripts, Fedora 12 will not correctly recognize Intel BIOS-managed RAID sets created after Fedora has been installed. This type of RAID set will, however, be correctly handled if it exists at install time. This issue can be worked around by adding the parameter iswnomd to the kernel command line, which can be achieved by editing /boot/grub/menu.lst. You may also wish to consider creating the array as a Linux software RAID array rather than a BIOS-managed array; this will make it portable between different Linux systems, and avoid this issue.
An update may be made available to address this issue, however it is not a straightforward issue to fix so this may not be possible or may take some time.
Problems when using the proprietary NVIDIA graphics driver (especially with KDE)
link to this item - Bugzilla: #533620
The root cause of this problem is not Fedora, but rather software provided by NVIDIA. If you are interested in a fix for this issue, you must contact that vendor through their web site.
We encourage Fedora users to use the free nouveau driver, rather than the proprietary nvidia driver, whenever possible.
Due to a bad interaction between the proprietary NVIDIA driver and a fix in Fedora 12's X.org server package for an unrelated problem, current versions of the said driver have several problems in Fedora 12. In particular, they render KDE almost unusable, as discussed in the bug report cited above. Fedora does not provide or support these proprietary drivers and cannot fix this issue. However, users who wish to use the proprietary driver with Fedora 12 can find an unsupported alternative build of the X.org server packages in a comment on the bug report, which several users have reported to work around this issue.
Adobe Reader fails to run
The root cause of this problem is not Fedora, but rather software provided by Adobe. If you are interested in a fix for this issue, you must contact that vendor through their web site.
We encourage Fedora users to use a free alternative to Adobe reader, such as Evince or Okular, whenever possible.
The latest release of Adobe Reader (AdobeReader_enu-9.2-1.i486) works in Fedora 12. Previous releases of Adobe Reader do not run by default on Fedora 12. To work around this problem, launch Adobe Reader with the following command: GDK_NATIVE_WINDOWS=1 acroread.
Non-Fedora Mozilla/Firefox binaries may crash
The root cause of this problem is not Fedora, but rather software provided by Mozilla. If you are interested in a fix for this issue, you must contact that vendor through their web site.
There is a conflict between binary software downloaded from Mozilla and software included in Fedora which may lead to a crash, often seen when using Flash. See this page for details and workarounds.
FUSE mounts may hang
link to this item - Bugzilla: #493565
When audit is enabled and FUSE file systems are being mounted, a deadlock may happen which causes the mount to block indefinitely. A common symptom of this bug is that the user's Home folder appears to be empty when opened with Nautilus. Running the
ls -la
command in the user's home directory will also hang. Some users have reported that a reboot will fix the problem, others have reported that they need to do a file system check. To have the system check its file systems during the next boot, create an empty file named forcefsck in the / directory:
su -c 'touch /forcefsck'
This will only be a temporary fix and the problem will most likely appear again. The developers are working on fixing this issue in the Linux kernel.