From Fedora Project Wiki

m (add category)
 
(104 intermediate revisions by 23 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
{{autolang|base=yes}}
This page documents common bugs in Fedora 14 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 ==
== Release Notes ==


Read the [http://docs.fedoraproject.org/release-notes/{{Template:DocsDict/BeatsVer}}/ Fedora {{Template:DocsDict/BeatsVer}} release notes] for specific information about intentional changes in Fedora {{Template:DocsDict/BeatsVer}}, and other general information.
Read the [[F14 Beta announcement|F14 beta Announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/14/html/Release_Notes/ Fedora 14 release notes] for specific information about changes in Fedora 14: known issues, and other general information.
 


== My bug is not listed ==
== My bug is not listed ==
Line 37: Line 38:


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:
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>
<pre>su -c 'yum --enablerepo=updates-testing update (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):
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):
Line 49: Line 50:
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.
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 ==
{{Anchor|thinkpad-suspend}}
=== Suspend fails on Thinkpad systems ===
<small>[[#thinkpad-suspend|link to this item]] - [[rhbug:644842|Bugzilla: #644842]]</small>
Due to a bug in the TPM (Trusted Platform Module) support in the kernel, suspending will fail with almost all IBM and Lenovo Thinkpad laptops using the Fedora 14 release kernel ([http://koji.fedoraproject.org/koji/buildinfo?buildID=201004 kernel-2.6.35.6-46.fc14]).  Systems affected will be unable to suspend properly, and will emit an error similar to the message below in the {{filename|/var/log/messages}} log.
<pre>tpm_tis 00:0a: tpm_transmit: tpm_send: error -5</pre>
An updated [http://admin.fedoraproject.org/updates/kernel-2.6.35.6-48.fc14 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|xfce_missing_icons}}
=== Missing icons in Xfce desktop ===
<small>[[Common F14 bugs#xfce_missing_icons|link to this item]] - [[rhbug:650504|Bugzilla: #650504]]</small>
Some icons are missing in the Xfce desktop environment. These icons used to be part of the {{package|gnome-icon-theme}} package but were moved to {{package|gnome-icon-theme-legacy}}. To get the missing icons back, install the package {{package|gnome-icon-theme-legacy}} from the graphical package manager or by running the command {{command|su -c 'yum install gnome-icon-theme-legacy'}}.
An updated [https://admin.fedoraproject.org/updates/libxfcegui4-4.6.4-3.fc14 libxfcegui4] 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|python_cheetah}}
=== Cheetah is not compliant with python-2.7 ===
<small>[[#python_cheetah|link to this item]] - [[rhbug:640093|Bugzilla: #640093]]</small>
At the time of the Fedora 14 release, the {{package|python-cheetah}} package had not yet been updated to work with the [[Features/Python_2.7|python-2.7 update]].  However, an updated [https://admin.fedoraproject.org/updates/python-cheetah-2.4.3-1.fc14 python-cheetah] package is now available that resolves the reported issue.  Users experiencing this problem are encouraged to update {{package|python-cheetah}} and report any problems into [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=14&component=python-cheetah bugzilla]. Update your system as usual to receive this update, if you do not yet already have it.
{{anchor|gnome-multihead}}
=== Additional displays turned off by default in GNOME desktop ===
<small>[[#gnome-multihead|link to this item]] - [[rhbug:623824|Bugzilla: #623824]]</small>
Due to a problematic change to the way upstream GNOME handles multiple monitor configurations, on new Fedora 14 installations on laptops with external displays attached, the external displays will often be active during boot but then be deactivated within GNOME by default. The previous Fedora behaviour was to enable such displays by default. You can enable the external display within GNOME by using GNOME's ''Monitor Preferences'' tool, which is available within the system menus.
An updated [https://admin.fedoraproject.org/updates/gnome-settings-daemon-2.32.0-2.fc14 gnome-settings-daemon] 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 the update, the system will return to the Fedora 13 behaviour of allowing X.org to determine how multiple displays are handled, which means the desktop will span across all connected displays by default. If you have manually set up a multi-head configuration, it will not be changed.
{{anchor|ibus_anthy_crash}}
=== ibus-anthy crashes on use of F7 or F8 keys ===
<small>[[Common F14 bugs#ibus_anthy_crash|link to this item]] - [[rhbug:644771|Bugzilla: #644771]]</small>
When you type F7 or F8 key to convert Japanese characters with {{package|ibus-anthy}}, the conversion fails and ibus-anthy will crash.
An updated [https://admin.fedoraproject.org/updates/ibus-anthy-1.2.4-2.fc14 ibus-anthy] 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|openjdk_eclipse_cdt}}
=== Eclipse crashes with OpenJDK when using CDT  ===
<small>[[#openjdk_eclipse_cdt|link to this item]] - [[rhbug:647737|Bugzilla: #647737]]</small>
When Eclipse is loaded with a CDT project, it crashes the Java Virtual Machine (JVM) when rebuilding the index. This issue is caused due to Compressed Ordinary Object Pointers (Compressed Oops) being turned on in the newer HotSpot versions.
An updated [https://admin.fedoraproject.org/updates/eclipse-3.6.1-4.fc14 eclipse] 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. This update works around the issue by disabling compressed Oops.
{{anchor|system-load}}
=== System load is misreported ===
<small>[[Common F14 bugs#system-load|link to this item]] - [[rhbug:650934|Bugzilla: #650934]]</small>
The load statistics being reported by the system were abnormally high. Idle systems could see load greater than 0.50. The readings were in error; there were no consequences in terms of temperature or power consumption.
An updated [http://admin.fedoraproject.org/updates/kernel-2.6.35.10-72.fc14 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.


== Issues when upgrading from previous releases ==
== Issues when upgrading from previous releases ==


{{anchor|f12_preupgrade}}
=== After preupgrading from Fedora 12, unable to login to GDM ===
<small>[[#f12_preupgrade|link to this item]] - [[rhbug:646437|Bugzilla: #646437]]</small>
Users running {{package|preupgrade}} from Fedora 12 may encounter trouble logging into the system after the upgrade - the GDM login screen may not show up or it may keep restarting. To avoid this problem, please be sure to fully update your Fedora 12 installation (and reboot) before using preupgrade tool.
If you did not perform the recommended procedure (or encountered this issue despite that), resolve it by installing a [https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-7.fc14 selinux-policy-3.9.7-7.fc14] update. You can install the update and relabel your system using the following approach:
# Access a root shell - press <code><Ctrl><Alt>F2</code> to change to a different TTY and log in as root.
# Apply the {{package|selinux-policy}} update by typing {{command|yum update selinux-policy}}
# If yum complains about inaccessible repositories, your network devices may have not been started up. Type {{command|dhclient eth0}} to enable your default network card and repeat the previous step.
# Instruct your system to relabel upon the next reboot by typing {{command|touch /.autorelabel}}
# Reboot your system. The boot process will take a bit longer as it relabels your system, that's expected.
After the system reboot completes, you will be able to login to GDM.
== Installation issues ==
{{anchor|modify_ntfs}}
=== Anaconda fails to modify NTFS partition ===
<small>[[#modify_ntfs|link to this item]] - [[rhbug:627153|Bugzilla: #627153]]</small>
Installing Fedora 14 on a system that contains ''NTFS'' formatted partitions may result in a [https://bugzilla.redhat.com/attachment.cgi?id=456119 traceback] when attempting to modify the partitions.  Investigation has identified a problem with the Fedora installer (see [http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1010f3a7db9410c09b41595a3632d7f983a7e5a9 patch]).  To workaround this problem, users are advised to refrain from modifying ''NTFS'' formatted partitions during installation, and instead make necesary changes on a running Fedora 14 system using {{command|palimpsest}}.  If your use case absolutely requires modifying existing ''NTFS'' partitions during installation, an [http://jlaska.fedorapeople.org/updates/627153.img updates.img is available] that resolves the issue.  For instructions for creating and using an updates.img are available on the wiki at [[Anaconda/Updates]].
{{anchor|disc2_plymouth_theme}}
=== Multiple CD-ROM installation may result in incorrect boot progress theme ===
<small>[[#disc2_plymouth_theme|link to this item]] - [[rhbug:645592|Bugzilla: #645592]]</small>
Fedora CD-ROM installation images are constructed with many different packages spread across six ISO images.  Due to an issue with how packages are split into different ISO media, the {{package|plymouth-themes-charge}} package is available on Disc 2.  This will cause CD-ROM installations to use the plymouth text boot progress theme on boot.  When a new {{package|kernel}} update is available and installed on the system, the problem will be resolved. 
Users wishing to manually set the plymouth theme can run the following commands:
# Open a terminal window by selecting ''Applications'' → ''System Tools'' → ''Terminal''
# In the terminal window, change to a root shell by typing: {{command|su - }}
# Reset plymouth to use the default boot theme by typing: {{command|/usr/sbin/plymouth-set-default-theme --reset}}
# Finally, rebuild your initial ramdisk by typing: {{command|/usr/libexec/plymouth/plymouth-generate-initrd}}
{{anchor|livecd_iscsi}}
=== Live install doesn't offer discovery of iSCSI targets ===
<small>[[#livecd_iscsi|link to this item]] - [[rhbug:645523|Bugzilla: #645523]]</small>
When running the Fedora 14 installer from a Live image, the option to add a remote iSCSI target is disabled (see [[:File:Bug645523-before.png|screenshot]]).  The problem is that the <code>iscsi_tcp</code> kernel module hasn't been loaded by the {{command|liveinst}} installer script, and the iSCSI application paths used by the installer are incorrect.  The problem is resolved in future versions of the installer (see anaconda patches [http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=67605ee53bdf4453b469e74ca1759b1797f1ef93 67605ee53bdf4453b469e74ca1759b1797f1ef93] and [http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=19ed4f132069eb06c00fd366ad06d1a3d658ec14 19ed4f132069eb06c00fd366ad06d1a3d658ec14]). 
To install Fedora 14 to iSCSI targets using the Fedora 14 Live image, you must follow the procedure outlined below.
# Open a terminal window by selecting ''Applications'' → ''System Tools'' → ''Terminal''
# In the terminal window, change to a root shell by typing: {{command|su - }}
# Load the {{filename|iscsi_tcp.ko}} kernel module by typing: {{command|modprobe -a iscsi_tcp}}
# Allow anaconda to see the iSCSI application binaries by typing: {{command|cp -vl /sbin/iscsi* /usr/sbin/}}
Now you can use the live image to discover and install Fedora 14 to remote iSCSI targets (see [[:File:Bug645523-after.png|screenshot]]).
== Hardware-related issues ==
{{Anchor|preupgrade-LCD/CRT-remain-in-standby-after-reboot}}
{{Anchor|misc-gfx}}
=== Miscellaneous graphical problems ===
{{admon/note | Creating xorg.conf file | xorg.conf is no longer created by default.  If you require this, follow the instructions at [[How to create xorg.conf]] first. }}
<small>[[Common F14 bugs#misc-gfx|link to this item]]</small>
If you are suffering from problems such as failure of X to start at all (including installer failure when switching to graphical mode), 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.
For AMD/ATI graphics adapters, 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-ati&version=14 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. Please note that for Fedora 14, this workaround is no longer available for NVIDIA or Intel graphics adapters; using the ''nomodeset'' kernel parameter will result either in a non-functional display, or in the fallback ''vesa'' driver being used.
For further instructions on attempting to debug graphics issues, please refer to [[How_to_debug_Xorg_problems]]. That page also explains how to file good bug reports, if you cannot resolve the issue. In such cases, you can use the fallback ''vesa'' driver to get a graphical desktop working, though performance will be slow, 3D acceleration will not be available, it may not be possible to use the native resolution of your display, and more complex graphical operations such as video playback may be problematic. To enable the ''vesa'' driver on an installed system, follow the instructions at [[How_to_create_xorg.conf]] to create a {{filename|/etc/X11/xorg.conf}} file, then edit this file and set the Driver line in the Device section to read:
<pre>
Driver "vesa"
</pre>
You may also need to set the ''nomodeset'' kernel parameter to prevent the native kernel driver for your graphics card interfering with the operation of the vesa driver.
To use the ''vesa'' driver during installation, at the initial screen that appears on booting the installer, select the option labelled "Install system with basic video driver". This will use the ''vesa'' driver for installation and will also configure the installed system to use the ''vesa'' driver.
To use the ''vesa'' driver during installation from a Fedora live image, press any key at the 10 second boot countdown to access the boot menu, and select the option labelled "Boot (Basic Video)".
To use the ''vesa'' driver during upgrade from a previous version of Fedora using preupgrade:
# Boot into the old system (rebooting from a failed or hung preupgrade attempt should do so automatically)
# Login and open a terminal and run {{command|su -c 'preupgrade-cli "Fedora 14 (Laughlin)"'}}, and enter the root password when prompted
# Edit {{filename|/etc/grub.conf}}
# Look for the first entry in the grub configuration, it should state that it is the preupgrade entry
# Find the kernel line and append the options ''xdriver=vesa nomodeset''
# Save the file, and reboot
{{anchor|edp_problems}}
=== Blank screen displayed on many laptops using eDP displays (Dell E4310, E6410, E6500, E6510, Sony Vaio VPCZ1) ===
<small>[[#edp_problems|link to this item]] - [[rhbug:596557|Bugzilla: #596557]] [[rhbug:639146|Bugzilla: #639146]]</small>
New laptops are increasingly using the embedded DisplayPort (eDP) standard for connecting their internal display panels to their graphics adapters. Unfortunately, support for this new standard is incomplete within the current Linux kernel and X.org drivers, and many systems which use eDP may have problems with Fedora 14. In particular, one popular line of Dell Latitude laptops - the Exx1x series - uses the eDP protocol and fails to work correctly with Fedora 14 (though it worked with Fedora 13). This is an area of intense development focus upstream, but it is not straightforward to port specific fixes back to the Fedora kernel, and backporting the changes wholesale runs a significant risk of introducing new regressions. We will attempt to backport safe fixes for these problems to Fedora 14 as and when this is feasible.
Users of affected systems who are comfortable with the process of building and testing kernels may wish to try compiling the drm-intel-next branch of [http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=summary Jesse Barnes' drm-intel tree], which contains the latest work on eDP problems, and resolves the case of the Sony Vaio VPCZ1 in Intel graphics mode (though reports indicate it does not help most of the affected Dell models yet). They may also wish to follow [https://bugs.freedesktop.org/show_bug.cgi?id=29278 Freedesktop.org bug #29278], which is the upstream report for the Dell E6xxx series issue. Aside from this, the only available workaround is to use the vesa driver, as described [[#misc-gfx|above]].
{{anchor|intel_80211n}}
=== Intel wireless adapters stop working when in 802.11n mode ===
<small>[[#intel_80211n|link to this item]] - [[rhbug:648732|Bugzilla: #648732]]</small>
Intel has [http://marc.info/?l=linux-wireless&m=128335670111847&w=2 acknowledged] an issue in the firmware for its wireless chipsets (widely used in laptops from various manufacturers) which can result in the wireless adapter stopping working some time after system boot, if it is operating in 802.11n mode. An error message of the form:
<pre>
BA scd_flow 0 does not match txq_id 10
</pre>
may be found in the system logs. The only reliable way to work around this issue is to disable 802.11n functionality. To do this, create a file named {{filename|/etc/modprobe.d/intel-80211n.conf}}, with the contents:
<pre>
options iwlagn 11n_disable=1
</pre>
and reboot the system. Obviously, this will restrict the connection to 802.11a/g speeds as a maximum, and you must configure your wireless router to enable 802.11a and/or 802.11g support. Intel is working to provide a fix for this issue.
{{anchor|usb_3.0}}
=== USB 3.0 ports not working ===
<small>[[#usb_3.0|link to this item]] - [[rhbug:623573|Bugzilla: #623573]]</small>
Due to USB 3.0 support preventing users from being able to suspend their laptops, it has been disabled by default for the release of Fedora 14. USB 2.0 ports (ehci_hcd) will continue to work as expected. If support for USB 3.0 is more important to you than support for suspend/resume is not necessary, you can pass the kernel parameter ''xhci.enable=1'', which will allow the xHCI support to load. There is also a workaround which will allow you to enable USB 3.0 support and still suspend successfully. After adding the ''xhci.enable=1'' kernel parameter, create a file named {{filename|/etc/pm/config.d/xhci}}, with the contents:
<pre>
SUSPEND_MODULES="xhci"
</pre>
You should now be able to suspend and resume the system successfully.
'''Note:''' If your module is called ''xhci_hcd'' instead of ''xhci'', then the above instructions have to be adjusted accordingly.
{{anchor|nouveau_legacy_wrappedfb}}
=== Slow rendering of older applications with nouveau driver ===
<small>[[#nouveau_legacy_wrappedfb|link to this item]] - [[rhbug:609790|Bugzilla: #609790]]</small>
A change was made to the nouveau driver for NVIDIA graphics cards during the Fedora 14 development cycle which fixes performance and rendering issues in some newer applications at the cost of causing performance issues in some older applications, particularly those which use bitmap fonts. If you notice very slow performance in certain older applications (examples cited in the bug report include emacs and xterm when using bitmap fonts rather than freetype), you may try an X configuration option which restores the old behaviour. Add this line to the Device section of your {{filename|/etc/X11/xorg.conf}} or a new X configuration snippet in {{filename|/etc/X11/xorg.conf.d}}:
<pre>
Option "WrappedFB" "on"
</pre>
This should resolve the issue (though you may possibly notice performance issues or rendering problems in other applications).
{{anchor|Adaptec RAID Cards cause kernel Panic}}
=== Adaptec RAID cards cause Kernel Panic due to lack of support for ASPM (Active-State Power Management) ===
<small>[[#ASPM |link to this item]] - [http://docs.fedoraproject.org/en-US/Fedora/14/html-single/Power_Management_Guide/index.html#ASPM ASPM]</small>
A change to power management was made in Fedora 12 onwards, which causes a kernel panic, if a device does not support ASPM. This prevents the system from booting or even anaconda (installer) to start. In order to address the issue, the following line can be appended to {{filename|/etc/grub.conf}} to facilitate a permanent workaround.
<pre>
pcie_aspm=off
</pre>
For a temporary fix, when the grub screen appears hit any key, hit the ''''e'''' key, then select the kernel line, hit ''''e'''' append the option making sure you prepend a '''<space>'''. For the live usb/cd when the grub screen appears, hit the '''<tab>''' key, select Boot, hit ''''e'''', append the option e.g. ... ''rd_NO_MD pcie_aspm=off''
== Software issues ==
{{anchor|meego_no_worky}}
=== Meego environment does not work ===
<small>[[#meego_no_worky|link to this item]] - [[rhbug:628921|Bugzilla: #628921]]</small>
The Meego 1.0 desktop environment was [[Features/MeeGo_1.0|listed as a feature of Fedora 14]] until release day, and consequently was mentioned in many news stories regarding Fedora 14. Unfortunately, our volunteer Meego developers were unable to complete work on the Meego environment for release, and so although all the Meego-related packages are present, bugs remain which result in the Meego environment currently being entirely unusable (it is not possible to even log in to Meego successfully). We will continue to work on this and try to provide a usable Meego environment for Fedora 14 through official updates. We apologize for any inconvenience or confusion caused by our incorrect messaging regarding this feature.
{{anchor|intel_bios_raid}}
=== Some Intel BIOS RAID arrays not activated correctly when booting live ===
<small>[[#intel_bios_raid|link to this item]] - [[rhbug:645293|Bugzilla: #645293]]</small>
When booting Fedora 14 live images, some Intel BIOS RAID arrays are not correctly activated on boot. No /dev/md* nodes will appear for the partitions that are part of the array, and hence you will not be able to access them. The issue should have no impact when installing because the {{package|anaconda}} installer should correctly activate the array.
{{anchor|su_gnome}}
=== Cannot launch various graphical applications (gedit, nautilus...) as root from a console ===
<small>[[#su_gnome|link to this item]] - [[rhbug:650644|Bugzilla: #650644]]</small>
Trying to run various graphical applications from a console after gaining root privileges by running {{command|su}} will fail, usually with an error message of the form:
<pre>
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)
</pre>
This is most commonly encountered in the case of gedit and nautilus, but affects various other applications too. To avoid this problem, use the command {{command|su -}} instead of {{command|su}}. If you are using the -c parameter to su, use a command like {{command|su -c 'gedit' -}}. The trailing dash tells su to use the whole environment of the target user (root, in this case) rather than simply gaining the target user's privileges. This avoids the problem.
{{anchor|lxde_gmixer_crash}}
=== Crash of gmixer application reported each time LXDE starts ===
<small>[[Common F14 bugs#lxde_gmixer_crash|link to this item]] - [[rhbug:542255|Bugzilla: #542255]]</small>
At each start of the LXDE desktop environment, a crash in the {{package|gmixer}} application occurs (and is reported by the automated crash report tool ABRT). Consequently, no mixer (volume control) applet appears in the LXDE panel. This is a known issue in gmixer; it is not necessary to submit the ABRT report. There is no known workaround for this issue, but it has no consequences beyond the lack of a volume control applet.
{{anchor|lxde_unlock_keyring}}
=== System cannot store keyring password on LXDE installations ===
<small>[[Common F14 bugs#lxde_unlock_keyring|link to this item]] - [[rhbug:643435|Bugzilla: #643435]]</small>
The LXDE environment in Fedora is configured to use {{package|gnome-keyring}} for managing a session keyring (storing mail passwords, ssh passphrases and so on in a common store which you unlock at each login). This tool offers an option labeled ''Automatically unlock this keyring whenever I'm logged in'' when you are first prompted to set up the keyring, which should cause it to be unlocked without you needing to re-enter the password, whenever you log in from the login screen. This option does not work in a default Fedora 14 LXDE environment installation due to the package {{package|gnome-keyring-pam}} not being installed. To make this function work correctly, install the package {{package|gnome-keyring-pam}} from the graphical package manager or by running the command {{command|su -c 'yum install gnome-keyring-pam'}}.
{{anchor|sugar_keyring}}
=== System cannot create keyring on Sugar installations ===
<small>[[Common F14 bugs#sugar_keyring|link to this item]] - [[rhbug:649013|Bugzilla: #649013]]</small>


The Sugar environment in Fedora is configured to use {{package|gnome-keyring}} for managing a session keyring (storing mail passwords, ssh passphrases and so on in a common store which you unlock at each login). When you first start the Sugar environment in Fedora 14, it will prompt to create a password for a default session keyring. If you enter a password as instructed, the same window will pop up again immediately. No matter how many times you enter a password, the window will continue to pop up. The only way to break the cycle is to hit the ''Cancel'' button instead of entering a password.


== Installation Issues ==
The Sugar team will investigate the cause of this problem and issue an update to fix it, if possible.


{{Anchor|radeon-anaconda}}
{{anchor|firefox-gif}}
=== System appears to hang with a black screen when installing on systems with ATI/AMD Radeon graphics cards ===
=== Some animated gifs are not properly displayed in Firefox and Seamonkey ===
<small>[[Common F14 bugs#radeon-anaconda|link to this item]] - [[rhbug:596985|Bugzilla: #596985]]</small>
<small>[[Common F14 bugs#firefox-gif|link to this item]] - [[rhbug:628331|Bugzilla: #628331]]</small>


Due to a bug in X.org, many testers indicated that, when installing Fedora 14 Alpha using the traditional installer (i.e. installing from the DVD or split CD media, not a live image), the system apparently hangs at a black screen when switching from text to graphical mode early in the installation process. The system is not in fact hung, but the display will remain blank until the system is rebooted. The bug that causes this problem could theoretically manifest with any hardware, depending on the contents of memory, but in practice it appears to occur consistently on many systems with ATI/AMD Radeon graphics cards, and - as far as we are aware - not on other systems.
Some animated gifs are just blinking instead of showing animation in {{package|firefox}} and {{package|seamonkey}}. Both will be fixed in regular updates.


To work around this issue, when the installer first boots, select the option labelled ''Install system with basic video driver'' at the initial boot menu. Now proceed with installation as usual. After installation, your system will still use the 'basic video driver' (vesa), which will lead to sub-optimal performance. If you would prefer to switch to the native driver - which most testers indicated works perfectly well once installation is complete - follow this procedure:
{{anchor|gtkvnc-virtmanager-sluggish}}


# Delete or rename the file {{filename|/etc/X11/xorg.conf}}
=== Sluggish interaction and high resource usage when interacting with virtual machines in virt-manager ===
# Remove all occurrences of the word ''nomodeset'' from the file {{filename|/boot/grub/grub.conf}}
<small>[[Common F14 bugs#gtkvnc-virtmanager-sluggish|link to this item]] - [[rhbug:657847|Bugzilla: #657847]]</small>
# Reboot


Some testers with cards in the Radeon 5xxx series encounter a bug with similar initial symptoms, but which actually affects all ability to use X.org with the native driver, not just the traditional Fedora installer. Installing using the ''basic video driver'' option is also a workaround for this case, but you should not revert to the native driver after installation in this case. If you attempt to revert to the native driver and find the system now fails to boot correctly, either reinstall and do not follow the procedure to revert to the native driver after installation, or boot the system with the kernel parameter '3' or in rescue mode, and use the {{command|system-config-display}} tool to select the vesa driver.
Fedora's {{package|virt-manager}} tool for creating and interacting with KVM-based virtual machines uses {{package|gtk-vnc}} to display the console or desktop of a virtual machine directly for you to interact with. Changes in gtk-vnc 0.4.2 cause a significant regression in performance when used in {{package|virt-manager}}; interactive performance, such as typing in a console, moving the cursor, and opening, closing and manipulating application windows will be very sluggish, and the virt-manager process on the host system will consume a large amount of CPU time.


== Hardware-related Issues ==
A possible fix for this issue is currently being investigated. In the mean time, you can work around the bug by downgrading the {{package|gtk-vnc}} packages (gtk-vnc, gtk-vnc-python, and gvnc are installed with virt-manager; others you may have installed are gtk-vnc-devel, gvnc-devel, and gvnc-tools) to version 0.4.1; an update to 0.4.2 is available [https://admin.fedoraproject.org/updates/gtk-vnc-0.4.2-4.fc14 from bodhi].


{{anchor|flash-64-sound}}


=== Strangely distorted sound in Flash-based sites and applications when using Adobe 64-bit Flash plugin ===
<small>[[Common F14 bugs#flash-64-sound|link to this item]] - [[rhbug:638477|Bugzilla: #638477]] - [https://bugs.adobe.com/jira/browse/FP-5739 Adobe bug FP-5739]</small>


== Software Issues ==
The sound in many Flash-based sites and applications, such as Flash video sites like Youtube, is distorted strangely when using the 64-bit version of Adobe's proprietary Flash plugin on Fedora 14. The issue appears to happen with any MP3-encoded audio in a Flash site or application - audio encoded in other formats does not exhibit the bug. On Youtube, videos in 240p quality use MP3 audio and will exhibit the bug; videos in higher quality use other audio codecs and will not exhibit the bug.
=== Network not connected automatically for normal installs ===
<small>[[Common F14 bugs#net-auto-connect|link to this item]] - [[rhbug:620823]]</small>


For network installs, the network link does seem to be not configured to connect automatically.
The cause of this is a bug in Adobe's code which was exposed by a change to the memcpy function in glibc. This issue has been reported to Adobe. This issue will be fixed if Adobe fixes their Flash plugin and issues an updated version. Fedora could work around the bug by temporarily reverting the glibc change; this is under discussion at present.
It can activated and enabled from the NetworkManager applet.


For media installs this is a known issues from earlier releases: see [[rhbug:498207]].
The current advised workaround is to use the 32-bit version of Adobe's Flash plugin, which does not exhibit the bug, instead of the 64-bit version. To run the 32-bit version of the plugin with a 64-bit browser, you will need to use the ''nspluginwrapper'' utility. See [[Multimedia/Flash|the Flash page]] for instructions on how to do this. Running the 32-bit plugin on 64-bit Fedora is advisable for reasons other than this bug; the 32-bit version of the plugin is updated more frequently than the 64-bit version, including to fix security issues, so it is safer to run the 32-bit plugin than the 64-bit plugin.


Live installs seem to be unaffected.
[[Category:Common bugs]]

Latest revision as of 00:00, 15 March 2018

This page documents common bugs in Fedora 14 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 F14 beta Announcement and the Fedora 14 release notes for specific information about changes in Fedora 14: known issues, 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)


Resolved issues

Suspend fails on Thinkpad systems

link to this item - Bugzilla: #644842

Due to a bug in the TPM (Trusted Platform Module) support in the kernel, suspending will fail with almost all IBM and Lenovo Thinkpad laptops using the Fedora 14 release kernel (kernel-2.6.35.6-46.fc14). Systems affected will be unable to suspend properly, and will emit an error similar to the message below in the /var/log/messages log.

tpm_tis 00:0a: tpm_transmit: tpm_send: error -5

An updated 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.

Missing icons in Xfce desktop

link to this item - Bugzilla: #650504

Some icons are missing in the Xfce desktop environment. These icons used to be part of the gnome-icon-theme package but were moved to gnome-icon-theme-legacy. To get the missing icons back, install the package gnome-icon-theme-legacy from the graphical package manager or by running the command su -c 'yum install gnome-icon-theme-legacy'.

An updated libxfcegui4 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.

Cheetah is not compliant with python-2.7

link to this item - Bugzilla: #640093

At the time of the Fedora 14 release, the python-cheetah package had not yet been updated to work with the python-2.7 update. However, an updated python-cheetah package is now available that resolves the reported issue. Users experiencing this problem are encouraged to update python-cheetah and report any problems into bugzilla. Update your system as usual to receive this update, if you do not yet already have it.

Additional displays turned off by default in GNOME desktop

link to this item - Bugzilla: #623824

Due to a problematic change to the way upstream GNOME handles multiple monitor configurations, on new Fedora 14 installations on laptops with external displays attached, the external displays will often be active during boot but then be deactivated within GNOME by default. The previous Fedora behaviour was to enable such displays by default. You can enable the external display within GNOME by using GNOME's Monitor Preferences tool, which is available within the system menus.

An updated gnome-settings-daemon 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 the update, the system will return to the Fedora 13 behaviour of allowing X.org to determine how multiple displays are handled, which means the desktop will span across all connected displays by default. If you have manually set up a multi-head configuration, it will not be changed.

ibus-anthy crashes on use of F7 or F8 keys

link to this item - Bugzilla: #644771

When you type F7 or F8 key to convert Japanese characters with ibus-anthy, the conversion fails and ibus-anthy will crash.

An updated ibus-anthy 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.

Eclipse crashes with OpenJDK when using CDT

link to this item - Bugzilla: #647737

When Eclipse is loaded with a CDT project, it crashes the Java Virtual Machine (JVM) when rebuilding the index. This issue is caused due to Compressed Ordinary Object Pointers (Compressed Oops) being turned on in the newer HotSpot versions.

An updated eclipse 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. This update works around the issue by disabling compressed Oops.

System load is misreported

link to this item - Bugzilla: #650934

The load statistics being reported by the system were abnormally high. Idle systems could see load greater than 0.50. The readings were in error; there were no consequences in terms of temperature or power consumption.

An updated 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.

Issues when upgrading from previous releases

After preupgrading from Fedora 12, unable to login to GDM

link to this item - Bugzilla: #646437

Users running preupgrade from Fedora 12 may encounter trouble logging into the system after the upgrade - the GDM login screen may not show up or it may keep restarting. To avoid this problem, please be sure to fully update your Fedora 12 installation (and reboot) before using preupgrade tool.

If you did not perform the recommended procedure (or encountered this issue despite that), resolve it by installing a selinux-policy-3.9.7-7.fc14 update. You can install the update and relabel your system using the following approach:

  1. Access a root shell - press <Ctrl><Alt>F2 to change to a different TTY and log in as root.
  2. Apply the selinux-policy update by typing yum update selinux-policy
  3. If yum complains about inaccessible repositories, your network devices may have not been started up. Type dhclient eth0 to enable your default network card and repeat the previous step.
  4. Instruct your system to relabel upon the next reboot by typing touch /.autorelabel
  5. Reboot your system. The boot process will take a bit longer as it relabels your system, that's expected.

After the system reboot completes, you will be able to login to GDM.

Installation issues

Anaconda fails to modify NTFS partition

link to this item - Bugzilla: #627153

Installing Fedora 14 on a system that contains NTFS formatted partitions may result in a traceback when attempting to modify the partitions. Investigation has identified a problem with the Fedora installer (see patch). To workaround this problem, users are advised to refrain from modifying NTFS formatted partitions during installation, and instead make necesary changes on a running Fedora 14 system using palimpsest. If your use case absolutely requires modifying existing NTFS partitions during installation, an updates.img is available that resolves the issue. For instructions for creating and using an updates.img are available on the wiki at Anaconda/Updates.

Multiple CD-ROM installation may result in incorrect boot progress theme

link to this item - Bugzilla: #645592

Fedora CD-ROM installation images are constructed with many different packages spread across six ISO images. Due to an issue with how packages are split into different ISO media, the plymouth-themes-charge package is available on Disc 2. This will cause CD-ROM installations to use the plymouth text boot progress theme on boot. When a new kernel update is available and installed on the system, the problem will be resolved.

Users wishing to manually set the plymouth theme can run the following commands:

  1. Open a terminal window by selecting ApplicationsSystem ToolsTerminal
  2. In the terminal window, change to a root shell by typing: su -
  3. Reset plymouth to use the default boot theme by typing: /usr/sbin/plymouth-set-default-theme --reset
  4. Finally, rebuild your initial ramdisk by typing: /usr/libexec/plymouth/plymouth-generate-initrd

Live install doesn't offer discovery of iSCSI targets

link to this item - Bugzilla: #645523

When running the Fedora 14 installer from a Live image, the option to add a remote iSCSI target is disabled (see screenshot). The problem is that the iscsi_tcp kernel module hasn't been loaded by the liveinst installer script, and the iSCSI application paths used by the installer are incorrect. The problem is resolved in future versions of the installer (see anaconda patches 67605ee53bdf4453b469e74ca1759b1797f1ef93 and 19ed4f132069eb06c00fd366ad06d1a3d658ec14).

To install Fedora 14 to iSCSI targets using the Fedora 14 Live image, you must follow the procedure outlined below.

  1. Open a terminal window by selecting ApplicationsSystem ToolsTerminal
  2. In the terminal window, change to a root shell by typing: su -
  3. Load the iscsi_tcp.ko kernel module by typing: modprobe -a iscsi_tcp
  4. Allow anaconda to see the iSCSI application binaries by typing: cp -vl /sbin/iscsi* /usr/sbin/

Now you can use the live image to discover and install Fedora 14 to remote iSCSI targets (see screenshot).

Hardware-related issues

Miscellaneous graphical problems

Creating xorg.conf file
xorg.conf is no longer created by default. If you require this, follow the instructions at How to create xorg.conf first.

link to this item

If you are suffering from problems such as failure of X to start at all (including installer failure when switching to graphical mode), 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.

For AMD/ATI graphics adapters, 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-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. Please note that for Fedora 14, this workaround is no longer available for NVIDIA or Intel graphics adapters; using the nomodeset kernel parameter will result either in a non-functional display, or in the fallback vesa driver being used.

For further instructions on attempting to debug graphics issues, please refer to How_to_debug_Xorg_problems. That page also explains how to file good bug reports, if you cannot resolve the issue. In such cases, you can use the fallback vesa driver to get a graphical desktop working, though performance will be slow, 3D acceleration will not be available, it may not be possible to use the native resolution of your display, and more complex graphical operations such as video playback may be problematic. To enable the vesa driver on an installed system, follow the instructions at How_to_create_xorg.conf to create a /etc/X11/xorg.conf file, then edit this file and set the Driver line in the Device section to read:

Driver "vesa"

You may also need to set the nomodeset kernel parameter to prevent the native kernel driver for your graphics card interfering with the operation of the vesa driver.

To use the vesa driver during installation, at the initial screen that appears on booting the installer, select the option labelled "Install system with basic video driver". This will use the vesa driver for installation and will also configure the installed system to use the vesa driver.

To use the vesa driver during installation from a Fedora live image, press any key at the 10 second boot countdown to access the boot menu, and select the option labelled "Boot (Basic Video)".

To use the vesa driver during upgrade from a previous version of Fedora using preupgrade:

  1. Boot into the old system (rebooting from a failed or hung preupgrade attempt should do so automatically)
  2. Login and open a terminal and run su -c 'preupgrade-cli "Fedora 14 (Laughlin)"', and enter the root password when prompted
  3. Edit /etc/grub.conf
  4. Look for the first entry in the grub configuration, it should state that it is the preupgrade entry
  5. Find the kernel line and append the options xdriver=vesa nomodeset
  6. Save the file, and reboot

Blank screen displayed on many laptops using eDP displays (Dell E4310, E6410, E6500, E6510, Sony Vaio VPCZ1)

link to this item - Bugzilla: #596557 Bugzilla: #639146

New laptops are increasingly using the embedded DisplayPort (eDP) standard for connecting their internal display panels to their graphics adapters. Unfortunately, support for this new standard is incomplete within the current Linux kernel and X.org drivers, and many systems which use eDP may have problems with Fedora 14. In particular, one popular line of Dell Latitude laptops - the Exx1x series - uses the eDP protocol and fails to work correctly with Fedora 14 (though it worked with Fedora 13). This is an area of intense development focus upstream, but it is not straightforward to port specific fixes back to the Fedora kernel, and backporting the changes wholesale runs a significant risk of introducing new regressions. We will attempt to backport safe fixes for these problems to Fedora 14 as and when this is feasible.

Users of affected systems who are comfortable with the process of building and testing kernels may wish to try compiling the drm-intel-next branch of Jesse Barnes' drm-intel tree, which contains the latest work on eDP problems, and resolves the case of the Sony Vaio VPCZ1 in Intel graphics mode (though reports indicate it does not help most of the affected Dell models yet). They may also wish to follow Freedesktop.org bug #29278, which is the upstream report for the Dell E6xxx series issue. Aside from this, the only available workaround is to use the vesa driver, as described above.

Intel wireless adapters stop working when in 802.11n mode

link to this item - Bugzilla: #648732

Intel has acknowledged an issue in the firmware for its wireless chipsets (widely used in laptops from various manufacturers) which can result in the wireless adapter stopping working some time after system boot, if it is operating in 802.11n mode. An error message of the form:

BA scd_flow 0 does not match txq_id 10

may be found in the system logs. The only reliable way to work around this issue is to disable 802.11n functionality. To do this, create a file named /etc/modprobe.d/intel-80211n.conf, with the contents:

options iwlagn 11n_disable=1

and reboot the system. Obviously, this will restrict the connection to 802.11a/g speeds as a maximum, and you must configure your wireless router to enable 802.11a and/or 802.11g support. Intel is working to provide a fix for this issue.

USB 3.0 ports not working

link to this item - Bugzilla: #623573

Due to USB 3.0 support preventing users from being able to suspend their laptops, it has been disabled by default for the release of Fedora 14. USB 2.0 ports (ehci_hcd) will continue to work as expected. If support for USB 3.0 is more important to you than support for suspend/resume is not necessary, you can pass the kernel parameter xhci.enable=1, which will allow the xHCI support to load. There is also a workaround which will allow you to enable USB 3.0 support and still suspend successfully. After adding the xhci.enable=1 kernel parameter, create a file named /etc/pm/config.d/xhci, with the contents:

SUSPEND_MODULES="xhci"

You should now be able to suspend and resume the system successfully.

Note: If your module is called xhci_hcd instead of xhci, then the above instructions have to be adjusted accordingly.

Slow rendering of older applications with nouveau driver

link to this item - Bugzilla: #609790

A change was made to the nouveau driver for NVIDIA graphics cards during the Fedora 14 development cycle which fixes performance and rendering issues in some newer applications at the cost of causing performance issues in some older applications, particularly those which use bitmap fonts. If you notice very slow performance in certain older applications (examples cited in the bug report include emacs and xterm when using bitmap fonts rather than freetype), you may try an X configuration option which restores the old behaviour. Add this line to the Device section of your /etc/X11/xorg.conf or a new X configuration snippet in /etc/X11/xorg.conf.d:

Option "WrappedFB" "on"

This should resolve the issue (though you may possibly notice performance issues or rendering problems in other applications).

Adaptec RAID cards cause Kernel Panic due to lack of support for ASPM (Active-State Power Management)

link to this item - ASPM

A change to power management was made in Fedora 12 onwards, which causes a kernel panic, if a device does not support ASPM. This prevents the system from booting or even anaconda (installer) to start. In order to address the issue, the following line can be appended to /etc/grub.conf to facilitate a permanent workaround.

pcie_aspm=off

For a temporary fix, when the grub screen appears hit any key, hit the 'e' key, then select the kernel line, hit 'e' append the option making sure you prepend a <space>. For the live usb/cd when the grub screen appears, hit the <tab> key, select Boot, hit 'e', append the option e.g. ... rd_NO_MD pcie_aspm=off

Software issues

Meego environment does not work

link to this item - Bugzilla: #628921

The Meego 1.0 desktop environment was listed as a feature of Fedora 14 until release day, and consequently was mentioned in many news stories regarding Fedora 14. Unfortunately, our volunteer Meego developers were unable to complete work on the Meego environment for release, and so although all the Meego-related packages are present, bugs remain which result in the Meego environment currently being entirely unusable (it is not possible to even log in to Meego successfully). We will continue to work on this and try to provide a usable Meego environment for Fedora 14 through official updates. We apologize for any inconvenience or confusion caused by our incorrect messaging regarding this feature.

Some Intel BIOS RAID arrays not activated correctly when booting live

link to this item - Bugzilla: #645293

When booting Fedora 14 live images, some Intel BIOS RAID arrays are not correctly activated on boot. No /dev/md* nodes will appear for the partitions that are part of the array, and hence you will not be able to access them. The issue should have no impact when installing because the anaconda installer should correctly activate the array.

Cannot launch various graphical applications (gedit, nautilus...) as root from a console

link to this item - Bugzilla: #650644

Trying to run various graphical applications from a console after gaining root privileges by running su will fail, usually with an error message of the form:

GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)

This is most commonly encountered in the case of gedit and nautilus, but affects various other applications too. To avoid this problem, use the command su - instead of su. If you are using the -c parameter to su, use a command like su -c 'gedit' -. The trailing dash tells su to use the whole environment of the target user (root, in this case) rather than simply gaining the target user's privileges. This avoids the problem.

Crash of gmixer application reported each time LXDE starts

link to this item - Bugzilla: #542255

At each start of the LXDE desktop environment, a crash in the gmixer application occurs (and is reported by the automated crash report tool ABRT). Consequently, no mixer (volume control) applet appears in the LXDE panel. This is a known issue in gmixer; it is not necessary to submit the ABRT report. There is no known workaround for this issue, but it has no consequences beyond the lack of a volume control applet.

System cannot store keyring password on LXDE installations

link to this item - Bugzilla: #643435

The LXDE environment in Fedora is configured to use gnome-keyring for managing a session keyring (storing mail passwords, ssh passphrases and so on in a common store which you unlock at each login). This tool offers an option labeled Automatically unlock this keyring whenever I'm logged in when you are first prompted to set up the keyring, which should cause it to be unlocked without you needing to re-enter the password, whenever you log in from the login screen. This option does not work in a default Fedora 14 LXDE environment installation due to the package gnome-keyring-pam not being installed. To make this function work correctly, install the package gnome-keyring-pam from the graphical package manager or by running the command su -c 'yum install gnome-keyring-pam'.

System cannot create keyring on Sugar installations

link to this item - Bugzilla: #649013

The Sugar environment in Fedora is configured to use gnome-keyring for managing a session keyring (storing mail passwords, ssh passphrases and so on in a common store which you unlock at each login). When you first start the Sugar environment in Fedora 14, it will prompt to create a password for a default session keyring. If you enter a password as instructed, the same window will pop up again immediately. No matter how many times you enter a password, the window will continue to pop up. The only way to break the cycle is to hit the Cancel button instead of entering a password.

The Sugar team will investigate the cause of this problem and issue an update to fix it, if possible.

Some animated gifs are not properly displayed in Firefox and Seamonkey

link to this item - Bugzilla: #628331

Some animated gifs are just blinking instead of showing animation in firefox and seamonkey. Both will be fixed in regular updates.

Sluggish interaction and high resource usage when interacting with virtual machines in virt-manager

link to this item - Bugzilla: #657847

Fedora's virt-manager tool for creating and interacting with KVM-based virtual machines uses gtk-vnc to display the console or desktop of a virtual machine directly for you to interact with. Changes in gtk-vnc 0.4.2 cause a significant regression in performance when used in virt-manager; interactive performance, such as typing in a console, moving the cursor, and opening, closing and manipulating application windows will be very sluggish, and the virt-manager process on the host system will consume a large amount of CPU time.

A possible fix for this issue is currently being investigated. In the mean time, you can work around the bug by downgrading the gtk-vnc packages (gtk-vnc, gtk-vnc-python, and gvnc are installed with virt-manager; others you may have installed are gtk-vnc-devel, gvnc-devel, and gvnc-tools) to version 0.4.1; an update to 0.4.2 is available from bodhi.

Strangely distorted sound in Flash-based sites and applications when using Adobe 64-bit Flash plugin

link to this item - Bugzilla: #638477 - Adobe bug FP-5739

The sound in many Flash-based sites and applications, such as Flash video sites like Youtube, is distorted strangely when using the 64-bit version of Adobe's proprietary Flash plugin on Fedora 14. The issue appears to happen with any MP3-encoded audio in a Flash site or application - audio encoded in other formats does not exhibit the bug. On Youtube, videos in 240p quality use MP3 audio and will exhibit the bug; videos in higher quality use other audio codecs and will not exhibit the bug.

The cause of this is a bug in Adobe's code which was exposed by a change to the memcpy function in glibc. This issue has been reported to Adobe. This issue will be fixed if Adobe fixes their Flash plugin and issues an updated version. Fedora could work around the bug by temporarily reverting the glibc change; this is under discussion at present.

The current advised workaround is to use the 32-bit version of Adobe's Flash plugin, which does not exhibit the bug, instead of the 64-bit version. To run the 32-bit version of the plugin with a 64-bit browser, you will need to use the nspluginwrapper utility. See the Flash page for instructions on how to do this. Running the 32-bit plugin on 64-bit Fedora is advisable for reasons other than this bug; the 32-bit version of the plugin is updated more frequently than the 64-bit version, including to fix security issues, so it is safer to run the 32-bit plugin than the 64-bit plugin.