View source for Common F12 bugs

This page documents common bugs in Fedora 12 and, if available, provides 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 [http://docs.fedoraproject.org/release-notes/f12/ 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 on 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.

To see if your bug has already been reported, you can [https://bugzilla.redhat.com/query.cgi 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 a previously 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 [[QA#Communicate|here]].
<!-- 
When adding issues to this page, ensure to add the CommonBugs keyword to the bug report, and place the anchor link to the entry on this page in the Whiteboard field on the bug report if it is not being used for anything else.
-->
<!-- *** FOLLOW THIS FORMAT FOR ALL ENTRIES PLEASE. ***
{{Anchor|Issue-Foo}}
=== Issue Foo (example) ===
<small>[[{{subst:PAGENAME}}#Issue-Foo|link to this item]] - [[rhbug:XXXXXX|Bugzilla: #XXXXXXX]]</small>

Words words words. Blah blah blah. Include a good explanation of the problem, and any available workarounds.

If a build which may fix the problem is made available via updates-testing, add this boilerplate paragraph (appropriately customized for the issue):

An updated [http://admin.fedoraproject.org/updates/(name)-(EVR) (name)] 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/(name)-EVR report to Bodhi] whether it solves the problem. To test the update, run this command:
<pre>su -c 'yum --enablerepo=updates-testing (name)'</pre>

If a scratch build which may fix the problem is made available via Koji (rather than in updates-testing), add this boilerplate paragraph (appropriately customized for the issue):

A test build that should resolve this problem is available from Koji: [http://koji.fedoraproject.org/koji/taskinfo?taskID=XXXXXXX packagename-EVR]. If you are affected by this issue, please test this update and report your results to the [[rhbug:XXXXXX|bug report]].

If the page is in pre-release state and a documented problem has been fixed in Rawhide but no newer pre-release has yet come out, add this boilerplate paragraph (appropriately customized for the issue):

This issue was fixed in the updated ''(name)-(EVR)'' package. To solve the issue, update your (pre-release name, e.g. "Fedora 12 Beta") installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|(name)}}.

When the page is in pre-release state and a new pre-release becomes available, simply remove any issues that are now fixed from the page entirely.
-->

== Resolved issues ==
===Problems updating===
<small>[[Common F12 bugs#pk-installed|link to this item]] - [[rhbug:541645|Bugzilla: #541645]]</small>

If you are updating using a graphical user interface to PackageKit (the default for desktop users) and you receive this error:

<pre>Error Type: <class 'yum.Errors.RepoError'>
Error Value: Error getting repository data for installed, repository not found
</pre>

Run <code>yum update PackageKit yum rpm</code> as root.  After rebooting, the update system should perform normally again.  You may wish to instead run <code>yum update</code> to get all available updates all at once (so if any other updates require it, you will only need to reboot once).

This update cannot happen automatically because there is a transient problem in PackageKit itself.  Fortunately, "yum" is available as an alternative updater interface.  This should not happen again for Fedora 13 or new upgrades to Fedora 12, but Fedora 12 users who upgraded during a certain window of time will need to apply the manual workaround.

{{Anchor|intel-gma4500-crash}}

=== Kernel crashes when booting on systems with Intel GMA 4500 graphics adapters ===
<small>[[Common F12 bugs#intel-gma4500-crash|link to this item]] - [[rhbug:540218|Bugzilla: #540218]]</small>

Several users reported kernel crashes when booting Fedora 12 on systems with Intel GMA 4500 graphics adapters. The full crash message can be found in the bug report; the crash occurred in the intel_tv_mode_set function. This issue can be worked around by disabling kernel mode setting with the ''nomodeset'' kernel parameter, as described [[Common F12 bugs#intel-misc-gfx|below]].

An updated [http://admin.fedoraproject.org/updates/kernel-2.6.31.6-162.fc12 kernel] 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.

{{Anchor|iommu-problems}}
=== 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 ===
<small>[[Common F12 bugs#iommu-problems|link to this item]] - [[rhbug:524808|Bugzilla: #524808]] and [[rhbug:533952|Bugzilla: #533952]]</small>

Some manufacturers ship systems with a BIOS whose handling of [http://en.wikipedia.org/wiki/IOMMU 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 were still not fully handled in the Fedora 12 release 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.

There are some systems currently known to be potentially affected by this issue. 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:
<pre>
Your BIOS is broken; DMAR reported at address fed10000 returns all ones!
</pre>
or:
<pre>
Your BIOS is broken; DMAR reported at address zero!
</pre>
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. 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 this issue by appending the kernel parameter ''iommu=soft'' to your boot configuration.

An updated [http://admin.fedoraproject.org/updates/kernel-2.6.31.6-145.fc12 kernel] 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. Obviously, if you are affected by the problem, you will need to use one of the above workarounds to first bring your system to a state from which you can install a fixed kernel.

{{Anchor|lxde-live-fail}}

=== LXDE live images are unusable ===
<small>[[Common F12 bugs#lxde-live-fail|link to this item]]</small>

Due to a severe bug which was not noticed during the LXDE group's testing, the initial LXDE live images for Fedora 12 were completely unusable. lxde-settings-daemon would crash on startup and get stuck in an infinite restart loop, rendering the desktop useless. For more details, see [http://www.christoph-wickert.de/blog/2009/11/18/fedora-12-lxde-spin-images-are-broken/ this blog post] from the Fedora LXDE group leader. The original images have been removed and [http://spins.fedoraproject.org/lxde/ updated images are now available]. If you downloaded one of the original LXDE live images, please discard it and download 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.

{{Anchor|NVIDIA-xorg-broken}}

=== Problems when using KDE with the proprietary NVIDIA graphics driver, some Radeon dual-head configurations, or nouveau with KMS disabled ===
<small>[[Common F12 bugs#NVIDIA-xorg-broken|link to this item]] - [[rhbug:533620|Bugzilla: #533620]] and [https://bugs.freedesktop.org/show_bug.cgi?id=25136 X.org bug #25136]</small>

We encourage Fedora users to use the free ''nouveau'' driver, rather than the proprietary ''nvidia'' driver, whenever possible.

A patch added to Fedora 12's X.org server package to fix another bug results in severe performance regressions in certain configurations when using KDE. Known affected configurations include any use of the NVIDIA proprietary driver, some configurations using the ''nouveau'' NVIDIA driver with kernel mode setting disabled, and some configurations using the ''radeon'' driver with dual monitors. The cause of this issue was identified by NVIDIA developers.

An updated [http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.4-1.fc12 xorg-x11-server] set of packages has been released to address this issue. Update your system as usual to receive this update, if you do not yet already have it.

{{Anchor|yumex-kernel-update}}
=== New kernels installed with yumex do not function correctly ===
<small>[[Common F12 bugs#yumex-kernel-update|link to this item]] - [[rhbug:527528|Bugzilla: #527528]]</small>

Due to an SELinux problem, installing updated Fedora 12 kernels using the {{package|yumex}} utility does not work correctly if SELinux is active. The installed kernel will be unable to load any modules at boot time, which will cause many hardware components not to work, if the system is able to boot at all. To avoid this issue, use {{package|yum}} or {{package|PackageKit}} to install new kernels, rather than {{package|yumex}}. If you have already installed a kernel using {{package|yumex}}, boot to an older kernel, remove the newer kernel package (and any related packages), and then re-install it using {{package|yum}} or {{package|PackageKit}}.

An updated [http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-55.fc12 selinux-policy] 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.

{{Anchor|encrypted-password-for-text-boot}}
=== Encrypted disks can't be unencrypted for non-graphical boot ===
<small>[[Common F12 bugs#encrypted-password-for-text-boot|link to this item]] - [[rhbug:530896|Bugzilla: #530896]]</small>

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:
<pre>
rhgb vga=0x318
</pre>
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 [http://admin.fedoraproject.org/updates/plymouth-0.8.0-0.2009.29.09.19.fc12 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 {{command|/usr/libexec/plymouth/plymouth-update-initrd}} as root. Make sure you are booted into the latest installed kernel before rebuilding the initial ramdisk.

{{Anchor|foomatic-not-installed}}

=== Missing printer drivers ===
<small>[[Common F12 bugs#foomatic-not-installed|link to this item]] - [[rhbug:536831|Bugzilla: #536831]]</small>

The {{package|foomatic}} package is not installed by default in a standard Fedora 12 installation. If you have a PostScript printer, or your printer requires an older driver such as one of the ghostscript built-in drivers, you may need to install this package before a driver for your printer will be available from the Fedora printer configuration tool.  To install it, select System->Administration->Add/Remove Software from the main menu and search for "foomatic", or run this command from the command line as root: {{command|yum install foomatic}}.

If you apply system updates, system-config-printer-1.1.13-10.fc12 or greater should automatically suggest installation of the appropriate drivers.

{{Anchor|aspire-one-ssb-hang}}

=== System hangs when booting on some Broadcom wireless systems: Acer Aspire One, HP Mini 311 ===
<small>[[Common F12 bugs#aspire-one-ssb-hang|link to this item]] - [[rhbug:533746|Bugzilla: #533746]]</small>

Several Acer Aspire One users (models known to be affected include some AO751h and some D250 models) and users of the HP Mini 311 have reported that Fedora 12 hangs when booting on their systems. The live images hang when attempting to start udev, and the traditional installer images hang when detecting hardware. To work around this issue, add this kernel parameter to the bootloader configuration:
<pre>
ssb.blacklist=1
</pre>
For the traditional installer, you can also use:
<pre>
noprobe
</pre>
Once the installation has completed, create a file {{filename|/etc/modprobe.d/blacklist-ssb.conf}} with the contents:
<pre>
blacklist ssb
</pre>
Note that this will prevent the wireless network adapter from working. On some systems, it may also prevent the wired ethernet adapter from working.

An updated [http://admin.fedoraproject.org/updates/kernel-2.6.32.10-94.fc12 kernel] 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. After updating, you can remove the workaround {{filename|/etc/modprobe.d/blacklist-ssb.conf}} file.

{{Anchor|adobe-reader-fail}}
=== Adobe Reader fails to run ===
<small>[[Common F12 bugs#adobe-reader-fail|link to this item]]</small>
{{BlameVendor|Adobe|http://www.adobe.com}}

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: {{command|GDK_NATIVE_WINDOWS<nowiki>=</nowiki>1 acroread}}.

{{Anchor|non-responsive-flash-objects}}
=== Non-responsive Flash objects ===
<small>[[Common F12 bugs#non-responsive-flash-objects|link to this item]] - [[rhbug:542424|Bugzilla:#542424]]</small>

When {{package|compiz}} is enabled, some flash objects in web pages may be unresponsive to mouse clicks.

An updated [http://admin.fedoraproject.org/updates/nspluginwrapper-1.3.0-10.fc12 nspluginwrapper] 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.

{{Anchor|unetbootin-broken}}

=== Live USB sticks created with unetbootin do not work ===
<small>[[Common F12 bugs#unetbootin-broken|link to this item]] - [http://bugs.launchpad.net/unetbootin/+bug/515008 upstream report]</small>
{{BlameVendor|UNetbootin|http://unetbootin.sourceforge.net/}}

All versions of [http://unetbootin.sourceforge.net/ UNetbootin] since version 393 are fully compatible with making Fedora 12 Live USB drives.

Multiple reports have been received that trying to create a Fedora 12 live USB stick from the live CD images using the popular [http://unetbootin.sourceforge.net/ 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 on a Linux system using simply dd or on Fedora systems using the console {{command|livecd-iso-to-disk}} or graphical cross platform {{command|liveusb-creator}} tools. On existing Fedora systems, {{command|livecd-iso-to-disk}} is available in the {{package|livecd-tools}} package and {{command|liveusb-creator}} is available in the {{package|liveusb-creator}} package. On other Linux systems or on Windows, you can install {{command|liveusb-creator}} following the [https://fedorahosted.org/liveusb-creator/ official instructions].

This issue has been [http://bugs.launchpad.net/unetbootin/+bug/515008 reported] to the UNetbootin developers, so they may be able to release an updated UNetbootin which works with Fedora 12 images in the future.

This issue should no longer occur with recent (newer than version 393) versions of UNetbootin.

== 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 [[Upgrading_Fedora_using_yum#11-12|the page on this upgrade method]].  For additional guidance on supported upgrade methods, see section [http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch17s02.html 17.2. Upgrading Your System] in the installation guide.

{{Anchor|preupgrade-boot}}
==== Preupgrade free space check on /boot not thorough ====
<small>[[Common F12 bugs#preupgrade-boot|link to this item]] - [[rhbug:530541|Bugzilla: #530541]]</small>

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 {{filename|/boot}} partition size of 200MB may not be able to upgrade their systems using preupgrade.  The {{filename|/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 {{command|grub}}, {{command|kernel}} and {{command|preupgrade}}.  

The {{command|preupgrade}} utility was not properly detecting the amount of available space on the {{filename|/boot}} filesystem prior to beginning the system update process.  As a result, {{command|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 [https://bugzilla.redhat.com/attachment.cgi?id=368370 screenshot of the failure message] is available.

A {{command|preupgrade}} update is available that will properly detect the amount of disk space available in {{filename|/boot}}.  Users are advised to update to the following {{package|preupgrade}} package for their release before using preupgrade to upgrade to Fedora 12.
* {{FedoraVersion|long|12}} - https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536
* {{FedoraVersion|long|11}} - https://admin.fedoraproject.org/updates/F11/FEDORA-2009-11547
* {{FedoraVersion|long|10}} - https://admin.fedoraproject.org/updates/F10/FEDORA-2009-11530

{{Anchor|preupgrade-free-space}}
After installing the updated preupgrade package, if you are still unable to proceed with an update, please refer to [[How_to_use_PreUpgrade#Not_enough_space_in_.2Fboot|these additional tips to free up space in /boot]].

{{Anchor|preupgrade-raid}}
==== Preupgrade does not correctly detect and handle /boot on RAID in all cases ====
<small>[[Common F12 bugs#preupgrade-raid|link to this item]] - [[rhbug:533545|Bugzilla: #533545]]</small>

The {{command|preupgrade}} tool is intended to detect when the {{filename|/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 {{command|preupgrade}} update is available that will properly detect the {{filename|/boot}} on RAID situation in more cases.  Users are advised to update to the following {{package|preupgrade}} package for their release before using preupgrade to upgrade to Fedora 12.
* {{FedoraVersion|long|12}} - https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536
* {{FedoraVersion|long|11}} - https://admin.fedoraproject.org/updates/F11/FEDORA-2009-11547
* {{FedoraVersion|long|10}} - https://admin.fedoraproject.org/updates/F10/FEDORA-2009-11530

{{Anchor|upgrade-bootloader}}
=== Upgrade on PPC architecture does not offer boot loader configuration screen ===
<small>[[Common F12 bugs#upgrade-bootloader|link to this item]] - [[rhbug:536705|Bugzilla: #536705]]</small>

When manually upgrading a PPC Fedora system using {{FedoraVersion|long|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 ==

{{Anchor|boot-500mb}}
=== /boot must be a minimum of 300 MB ===
<small>[[Common F12 bugs#boot-300mb|link to this item]] - [[rhbug:510970|Bugzilla: #510970]]</small>

If you use a separate <code>/boot</code> partition, it is highly recommended that it be at least 300MB in size.

{{Anchor|recovery-partition-boot}}
=== Windows recovery partition available as boot option instead of Windows partition ===
<small>[[Common F12 bugs#recovery-partition-boot|link to this item]] - [[rhbug:534066|Bugzilla: #534066]]</small>

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 {{filename|/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:
<pre>
title Other
	rootnoverify (hd0,0)
	chainloader +1
</pre>
It should be corrected to look like this:
<pre>
title Other
	rootnoverify (hd0,1)
	chainloader +1
</pre>
If you are not sure about your partition layout, the output of the command {{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).

{{Anchor|boot-on-raid-not-bootable}}
=== RAID /boot partition not marked bootable when bootloader is installed on it ===
<small>[[Common F12 bugs#boot-on-raid-not-bootable|link to this item]] - [[rhbug:533533|Bugzilla: #533533]]</small>

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 {{command|fdisk}}.

This bug should be fixed for Fedora 13 releases (anaconda-13.8-1 or greater).

{{Anchor|imsm-upgrade}}
=== Upgrading from F11 with / on an Intel BIOS RAID array results in an unbootable system ===
<small>[[Common F12 bugs#imsm-upgrade|link to this item]] - [[rhbug:540191|Bugzilla: #540191]] (CLOSED/WONTFIX - please use one of the workarounds below.)</small>

If a system running Fedora-11 has its <code>/</code> partition on an Intel BIOS RAID array, then after upgrading to
Fedora 12, the system will fail to boot because it can not find <code>/</code>. This is caused by F12 switching from
dmraid to mdraid for Intel BIOS RAID arrays, see [https://fedoraproject.org/wiki/Anaconda/Features/MDRaid|F12 MDRaid Feature].

The new mdraid Intel BIOS RAID support needs /etc/mdadm.conf with info on the RAID sets to be present to find them, on a
fresh F12 install this gets written by anaconda. But on an upgrade anaconda does not write configuration files (to leave
the existing ones intact), causing this issue.

There are 2 possible workarounds for this:
# Do a fresh Fedora 12 install (recommended)
# During boot press a key to get the grub menu, then press A to append to the kernel commandline, and then add " noiswmd", this will make the system use dmraid for Intel BIOS RAID again. You can edit /etc/grub.conf to make this permanent.

{{Anchor|ppc-dracut-network}}
=== Boot fails if system partition is on NFS or iSCSI on PPC architecture when installing from DVD or 6-CD media sets ===
<small>[[Common F12 bugs#ppc-dracut-network|link to this item]] - [[rhbug:533392|Bugzilla: #533392]]</small>

The {{package|dracut-network}} package was mistakenly omitted from the DVD and 6-CD media sets for the PowerPC architecture. This causes boot to fail on the installed system if a crucial system partition (root or /usr for example) is accessed via NFS or iSCSI. To avoid this issue, either enable the supplementary internet repositories when doing such an installation from the DVD or 6-CD media set on the PPC architecture, or do a network install from a full tree (or at least a tree in which the {{package|dracut-network}} package is available).

This problem should be fixed in Fedora 13 releases.

{{Anchor|localtime-install-crash}}
=== Live installation crashes with a 'same file' error message ===
<small>[[Common F12 bugs#localtime-install-crash|link to this item]] - [[rhbug:533240|Bugzilla: #533240]]</small>

The Fedora 12 live installation process can crash with the following error message:
<pre>
Error: `/usr/share/zoneinfo/America/New_York` and `/etc/localtime` are the same file
</pre>
under certain circumstances. This is believed to happen when an operation run between the time of booting the live image and the time of running the installer turns the file /etc/localtime into a symlink to another file. It may be triggered by manually setting the system clock, and/or enabling NTP, after booting the live image but before attempting to install it.

This issue will be resolved for Fedora 13 and later releases. To work around it, either change the time zone during the installation process, or reboot and proceed straight to installation as soon as the live image boots.

== Hardware-related issues ==

{{Anchor|intel-misc-gfx}}
=== Miscellaneous problems with Intel graphics adapters ===
<small>[[Common F12 bugs#intel-misc-gfx|link to this item]]</small>

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.

First, make sure you have applied all system updates, in case the problem has already been fixed.

Several such issues may be worked around by disabling kernel mode setting. To do this, add
<pre>
nomodeset
</pre>
as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-intel&version=11 file a new bug report] on the ''xorg-x11-drv-intel'' component, explaining your symptoms, and providing [[BugsAndFeatureRequests#Xorg|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.

{{Anchor|radeon-misc-gfx}}

=== Miscellaneous problems with ATI / AMD graphics adapters ===
<small>[[Common F12 bugs#radeon-misc-gfx|link to this item]]</small>

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.

First, make sure you have applied all system updates; some known bugs have been fixed.

Some issues may be worked around by disabling kernel mode setting. To do this, add
<pre>
nomodeset
</pre>
as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati&version=11 file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing [[BugsAndFeatureRequests#Xorg|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:
<pre>
Option "AccelMethod" "XAA"
</pre>
to the Device section of {{filename|/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 [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati&version=11 file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing [[BugsAndFeatureRequests#Xorg|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:
<pre>
Option "AccelDFS" "off"
</pre>
to the Device section of {{filename|/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 [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati&version=11 file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing [[BugsAndFeatureRequests#Xorg|all the usual information required for X.org bug reports]].

Finally, if this still does not resolve your issue, try adding this line:
<pre>
Option "DRI" "off"
</pre>
to the Device section of {{filename|/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 [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati&version=11 file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing [[BugsAndFeatureRequests#Xorg|all the usual information required for X.org bug reports]].

{{Anchor|intel-lid-dpms}}
=== Display cannot be reactivated if it enters sleep mode with laptop lid closed ===
<small>[[Common F12 bugs#intel-lid-dpms|link to this item]] - [[rhbug:489907|Bugzilla: #489907]] - [http://bugs.freedesktop.org/show_bug.cgi?id=21230 X.org bug #21230]</small>

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 workaround below.

A fix for this issue has been committed to the upstream kernel and may be made available in a future Fedora 12 kernel update.  Some users report this problem is fixed in kernel-2.6.31.12-174.2.3.fc12 or greater, but this may be hardware dependent.  

To workaround this problem, create a file with the following contents:
<pre>
#!/bin/bash
xrandr --output LVDS1 --off
xrandr --output LVDS1 --auto
</pre>
and save it as {{filename|~/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 {{command|xrandr}} at a console and examining the output.

Another approach for more advanced users is to use acpid to get the display reset automatically. This works at least on a Thinkpad X41. You need to install acpid for it and get it running.
{{admon/important|Single user system only|The acpid workaround works as is only if there is a single user with uid 500 that is logged in in X. In other cases this may fail. Use this workaround only if you are pretty sure to know what the commands do.}}

* install acpid: <pre>su -c 'yum install acpid'</pre>
* create the file {{filename|/etc/acpi/actions/reset-display.sh}} with the following contents:
<pre>
#!/bin/bash
# workaround for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=489907
PATH="/bin:/usr/bin:/sbin:/usr/sbin"
export DISPLAY=:0.0
if grep open /proc/acpi/button/lid/LID/state
then
su "$(getent passwd 500 | cut -d: -f1)" -c "xrandr --output LVDS1 --off"
su "$(getent passwd 500 | cut -d: -f1)" -c "xrandr --output LVDS1 --auto"
fi
</pre>
* create the file <code>/etc/acpi/events/reset-display.conf</code> with the following contents:
<pre>
# workaround for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=489907
event=button/lid LID 00000080.*
action=/etc/acpi/actions/reset-display.sh
</pre>
* stop hald: <pre>su -c 'service haldaemon stop'</pre>
* start acpid: <pre>su -c 'service acpid start'</pre>
* start hald: <pre>su -c 'service haldaemon start'</pre>
* enable acpid on startup: <pre>su -c 'chkconfig acpid on'</pre>

{{Anchor|ati-kms-slow}}

=== Poor performance (mainly 3D) with some AMD / ATI Radeon adapters ===
<small>[[Common F12 bugs#ati-kms-slow|link to this item]] - [[rhbug:526967|Bugzilla: #526967]]</small>

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 [[Common F12 bugs#radeon-misc-gfx|above]]. This issue is known and is being worked on for future Fedora releases and potentially for Fedora 12 updates.

{{Anchor|hda-clicks}}
=== Click noise problems with audio adapters ===
<small>[[Common F12 bugs#hda-clicks|link to this item]] -  [[rhbug:527286|Bugzilla: #527286]]</small>

If you are suffering from problems with an audio adapter such as frequent click noises or crackles, the following advice may be of use.

Fedora 12 enabled a power save feature for HDA audio devices, and set the default power save timeout to 5 seconds. Each time the device goes into power save state, or wakes up from power save state when playing sound, it may produce a click sound.

This problem should be fixed in kernel versions 2.6.32.3 and greater, which should be available as an official update soon (currently available for testing).  If you are still experiencing crackles after upgrading your kernel, please file a new bug.  In the meantime, you can also try the following workaround to diagnose and solve this problem.

On systems using the snd_hda_intel kernel module (Intel HD Audio adapters) this can be disabled by executing the following command as root:
<pre>
echo 0 > /sys/module/snd_hda_intel/parameters/power_save
</pre>

If it fixes your problem, you may permanently configure this parameter by appending 
<pre>
snd_hda_intel.power_save=0
</pre>
as a kernel parameter.

{{Anchor|tpm-boot-pause}}
=== Boot pauses for a long time, with ''tpm_tis 00:0a: tpm_transmit: tpm_send: error -62'' error displayed on console ===
<small>[[Common F12 bugs#tpm-boot-pause|link to this item]] -  [[rhbug:530393|Bugzilla: #530393]]</small>

Users of several systems, including Acer Travelmate 6465, 6592 and 6492 models, Zepto 6625WD and 6024W models, and Sony Vaio SZ7 series models (including, but likely not limited to, SZ71VN/X, SZ75MZ, SZ750N), have reported that their systems pause for several minutes during boot. If the boot process is set up so the console is visible at that point, the error message ''tpm_tis 00:0a: tpm_transmit: tpm_send: error -62'' is shown on the console. Boot does eventually proceed, and the system works without side effects. There is no solution for this problem at present, but a workaround is available. Adding ''tpm_tis.interrupts=0'' as a kernel parameter should avoid the problem in most cases.

== Software issues ==

{{Anchor|liveinst-udev-trouble}}

=== CD tray problems or slow boot after installation from live CD ===
<small>[[Common F12 bugs#liveinst-udev-trouble|link to this item]] - [[rhbug:527781|Bugzilla: #527781]]</small>

When installing from a live CD, the anaconda package is installed on the system. It includes some custom udev rules in the file {{filename|/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 {{package|anaconda}} package. It is not needed once you have completed installation of the system.

This problem is fixed in Fedora 13 (anaconda-13.5-1 or greater).

{{Anchor|intel-bios-raid-postinstall}}
=== Intel BIOS RAID arrays created after installation not detected ===
<small>[[Common F12 bugs#intel-bios-raid-postinstall|link to this item]] - [[rhbug:537329|Bugzilla: #537329]]</small>

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 {{filename|/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.

{{Anchor|firefox-upstream-binary}}

=== Non-Fedora Mozilla/Firefox binaries may crash ===
<small>[[Common F12 bugs#firefox-upstream-binary|link to this item]]</small>
{{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.

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

{{Anchor|ccsm-compiz-no-changes}}
=== Changes in CCSM do not affect Compiz ===
<small>[[Common F12 bugs#ccsm-compiz-no-changes|link to this item]] - [[rhbug:532229|Bugzilla:#532229]]</small>

In GNOME, changes in {{package|ccsm}} (CompizConfig Settings Manager) do not affect Compiz behavior. To work around this issue, install the {{package|compizconfig-backend-gconf}} package. Then, in CCSM, go to Preferences, and choose "GConf Configuration Backend" in the Backend section.

=== ABRT alert icon states that ABRT service did not start ===
<small>[[Common F12 bugs#abrt-alert-icon|link to this item]] - [[rhbug:552869|Bugzilla:#552869]]</small>

After installing new or upgrading,  the ABRT alert icon shows up on the desktop.  The alert icon states that the ABRT service did not start.  This issue is caused by ABRT's default configuration file trying to utilize ABRT plugins that are not installed by default.  There are two workarounds to resolve this issue:
* Install all ABRT plugins:
<pre>yum install abrt-desktop</pre>
* Edit /etc/abrt/abrt.conf and remove references to ABRT plugins that are not installed.
{{admon/important|You will need to restart the ABRT service after you complete the chosen workaround in order for the changes to take effect.  Also, right click on the ABRT alert icon and click on quit.  Or simply restart the system.}}

{{Anchor|32bit-virt-host}}
=== Fedora 12 32-bit installations cannot successfully host KVM virtual machines ===
<small>[[Common F12 bugs#32bit-virt-host|link to this item]] - [[rhbug:572215|Bugzilla:#572215]]</small>

Testing has indicated that trying to host KVM virtual machines (such as created through the {{package|virt-manager}} GUI) on a 32-bit Fedora 12 installation is unsuccessful. This bug affects only 32-bit installations; 64-bit installations have no problem hosting virtual machines.

An updated [https://admin.fedoraproject.org/updates/qemu-0.12.3-2.fc12 qemu] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [https://admin.fedoraproject.org/updates/qemu-0.12.3-2.fc12 report to Bodhi] whether it solves the problem. To test the update, run this command:
<pre>su -c 'yum --enablerepo=updates-testing qemu'</pre>

[[Category:Bugs]]