From Fedora Project Wiki

(Add writeGrub-upgrade-error (568567))
m (add category)
 
(75 intermediate revisions by 17 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
This page documents common bugs in Fedora 13 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.
This page documents common bugs in Fedora 13 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.


Fedora 13 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 13 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).
== Release Notes ==
 
== Release Summary, Announcement and Notes ==


Read the [[F13 Alpha release announcement]] and the [http://fedoraproject.org/wiki/Fedora_13_Alpha_release_notes draft Fedora 13 release notes] for specific information about changes in Fedora 13: known issues, and other general information.
Read the [http://docs.fedoraproject.org/release-notes/f13/ Fedora 13 release notes] for specific information about intentional changes in Fedora 13, and other general information.


== My bug is not listed ==
== My bug is not listed ==
Line 53: Line 53:
== Issues when upgrading from previous releases ==
== Issues when upgrading from previous releases ==


{{Anchor|writeGrub-upgrade-error}}
{{Anchor|preupgrade-default-boot}}
=== Installer fails after upgrade with writeGrub() error ===
=== Preupgrade doesn't work with default-sized /boot partition ===
<small>[[#writeGrub-upgrade-error|link to this item]] - [[rhbug:568567|Bugzilla: #568567]]</small>
<small>[[Common F13 bugs#preupgrade-default-boot|link to this item]]</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 12 (and earlier) who installed their systems using the recommended {{filename|/boot}} partition size of 200 MiB will 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. Its presence is required by several utilities including {{command|grub}}, {{command|kernel}} and {{command|preupgrade}}. 
 
Users that have {{filename|/boot}} partition size of at least 250 MiB should not have problems with using preupgrade. For others it is recommended to simply download Fedora 13 DVD/CD/netinst install medium and do a standard system upgrade. More experienced users that still want to use preupgrade may refer to [[How_to_use_PreUpgrade#Not_enough_space_in_.2Fboot|these additional tips to free up space in /boot]].
 
For Fedora 13 the default {{filename|/boot}} partition size was increased to 500 MiB to avoid these problems in the future.
 
{{anchor|text-upgrade-new-bootloader}}
=== Text-mode upgrade fails when installing ''new'' bootloader ===
<small>[[#text-upgrade-new-bootloader|link to this item]] - [[rhbug:580378|Bugzilla: #580378]]</small>
 
Users upgrading to Fedora 13 using the text-mode installer are advised to not select ''Create a new bootloader configuration''.  Creating a new bootloader configuration is not an intended function for the text-mode installer.  Instead, users are advised to choose the ''upgrade'' or ''skip'' bootloader configuration options during a text-mode upgrade.
 
This issue has been [http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=63fb1731cd77976f99b42dbf2c3598821b7faaff resolved] in future versions of {{package|anaconda}}.
 
{{anchor|fstab-malformed}}
=== Upgrade fails with ''fstab entry is malformed'' exception ===
<small>[[#fstab-malformed|link to this item]] - [[rhbug:577260|Bugzilla: #577260]]</small>
 
Multiple users have reported a failure when trying to upgrade an existing Fedora installation. The installer gives an exception of the format:
<pre>
fstab entry /dev/sda3 is malformed: scanned format (ext3) differs from fstab format (swap)
</pre>
where the entry and both formats may be different. This happens because the installer is quite strict about the formats it will accept in the {{filename|/etc/fstab}} file: entries which are valid for actual mounting purposes are rejected by anaconda in some situations. Common cases where this issue is encountered include entries which specify the formats ''ntfs-3g'' or ''auto''. It is usually possible to work around this issue by changing the format in the problematic {{filename|/etc/fstab}} entry. If the problematic format is ''ntfs-3g'', change it to ''ntfs''. If the problematic format is ''auto'', then change it to the actual format of the affected partition.
 
You may also encounter this issue if mounting an ext3 partition as ext2, or an ext4 partition as ext3 or ext2. In this case, you can work around the issue by adjusting the configuration to mount the partition with its actual native type during the upgrade.


During a system upgrade using the ''Fedora 13 Alpha'' installer, a failure will present after the upgrade process has completed.  A [https://bugzilla.redhat.com/attachment.cgi?id=397346 sample failure is available] for comparison.  The presence of this failure does not impact the upgraded system. In fact, you may reboot the installer and return to your upgraded Fedora 13 system.  This bug has been fixed in {{package|anaconda|anaconda-13.33-1}} and will be available in ''Fedora 13 Beta''.  Until then, should you wish to workaround the bug, a [http://jlaska.fedorapeople.org/updates-568567.img updates.img is available].  For help using an updates.img, see [[Anaconda/Updates]].
One other situation where you may encounter this issue is if the {{filename|/etc/fstab}} file lists devices in the /dev/sdXX format, and the Fedora installer enumerates your devices differently from the installed system (for instance, the F13 installer considers a disk to be /dev/sdc but the installed system considers the same disk to be /dev/sda). In this case, you should adjust {{filename|/etc/fstab}} to refer to devices by their UUIDs or labels.


== Installation issues ==
== Installation issues ==


{{Anchor|failure-to-eject-cdrom}}
{{Anchor|gigabyte-64dvd-fail}}
=== Failure to eject CD-ROM when prompting for next disc ===
=== 64-bit DVD appears unbootable on some systems (especially Gigabyte motherboards) ===
<small>[[#failure-to-eject-cdrom|link to this item]] - [[rhbug:569377|Bugzilla: #569377]]</small>
<small>[[Common F13 bugs#gigabyte-64dvd-fail|link to this item]] -  [[rhbug:597283|Bugzilla: #597283]]</small>
 
Several users have reported that the 64-bit DVD Fedora 13 image cannot be booted on their systems. The system does not see the burned disc as a bootable disc at all, and proceeds to boot from the next listed boot device. The burned disc passes validation and can successfully boot on other systems. This bug appears to affect systems with Gigabyte motherboards in particular; almost all reporters have Gigabyte motherboards.
 
One known workaround is to use a different image for installation. The 64-bit live images and network installation image (netinst.iso) and the 32-bit DVD image are known to boot successfully on most affected systems. Obviously, installing from the 32-bit DVD image will give you a 32-bit Fedora installation.
 
Another workaround reported in the bug by Bob Weaver is to boot with the 32-bit DVD inserted until the first menu screen (where you can choose to Install, or various other options) appears, then eject the 32-bit DVD and insert the 64-bit DVD before selecting Install.
 
We are investigating this issue but have yet to identify the cause or any possible fixes.
 
{{Anchor|pxeboot-e1000e}}
=== Unable to activate some Intel gigabit network devices when booting some systems using PXE ===
<small>[[Common F13 bugs#pxeboot-e1000e|link to this item]] -  [[rhbug:580563|Bugzilla: #580563]]</small>
 
When booting the installer from a network device using PXE, a problem has been identified where the network device does not reset after performing the PXE boot.  The result is that the Fedora 13 installer to fails to activate the network for installation.  Systems affected include those with Intel gigabit network adapters 82577 and 82578. 
 
To confirm whether your system may be impacted by this issue, from a command-prompt, type:
<pre>
# lspci -d 8086:10ea | grep -q Intel \
  && echo "Sorry, your system may be impacted by bug#580563." \
  || echo "Congratulations, you are not affected by bug#580563."
</pre>
 
If your system contains Intel gigabit network adapters affected by {{bz|580563}}, updated {{filename|pxeboot}} installation images are available for download at http://jlaska.fedorapeople.org/updates/580563.  For more information on booting the Fedora 13 installer using PXE, refer to the [http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/sn-booting-from-pxe-x86.html installation guide].
 
{{anchor|vnc-modifier-keys}}
===  ''Space'', ''Enter'', and arrow keys don't work in x86_64 VNC installs ===
<small>[[#vnc-modifier-keys|link to this item]] - [[rhbug:591776|Bugzilla: #591776]]</small>
 
Due to a bug in {{package|tigervnc}}, some keys may not be work as expected when installing Fedora 13 64-bit using {{command|vnc}}.  While some keys may not work as expected, users are still able to complete the install as directed using the mouse and keyboard.  While this issue is resolved in future versions of Fedora, users may work around this problem by using an [http://jlaska.fedorapeople.org/updates-591776.img {{filename|updates.img}}] when installing Fedora 13 64-bit using {{command|vnc}}.  For assistance on using an updates.img, refer to [[Anaconda/Updates]].
 
{{anchor|back-to-repo-failure}}
=== Traceback when going back to modify ''Installation Repo'' ===
<small>[[#text-upgrade-new-bootloader|link to this item]] - [[rhbug:505189|Bugzilla: #505189]]</small>
 
After customizing the install package set using the ''Customize Now'' option, users may encounter a failure when returning to the previous step and attempting to modify the ''Installation Repo''.  An [http://rvykydal.fedorapeople.org/updates.505189.img {{filename|updates.img}}] is available that works around the reported problem.  For assistance on using an updates.img, refer to [[Anaconda/Updates]].
 
{{anchor|attr-error-mapName}}
=== AttributeError: 'Ext4FS' object has no attribute 'mapName' ===
<small>[[#attr-error-mapName|link to this item]] - [[rhbug:494150|Bugzilla: #494150]]</small>
 
While testing Fedora 13, some users encountered problems while partitioning their disks.  The cause of the failure is not yet known.  The exact failure message changes depending on the partition selections.  For example, the following failure messages were observed:
* ''AttributeError: 'Ext3FS' object has no attribute 'mapName' ''
* ''AttributeError: 'Ext4FS' object has no attribute 'mapName' ''
* ''AttributeError: 'BTRFS' object has no attribute 'mapName' ''
 
Users experiencing this problem while installing Fedora 13, are advised to reboot the installer and retry.  The reported problem does not occur on subsequent installs.
 
{{anchor|system-error-22}}
=== SystemError: (22, 'Invalid argument') ===
<small>[[#system-error-22|link to this item]] - [[rhbug:590640|Bugzilla: #590640]]</small>
 
When installing Fedora 13 from a remote NFS share, you may encounter an exception referring to ''SystemError: (22, 'Invalid argument')''.  Investigation into the problem indicates the failure will occur when the Fedora installation boot media does not match the remote installation media available via NFS share.  Users are directed to confirm that Fedora release used to boot the installer matches the Fedora available on remote NFS share.  Users can confirm the boot media and remote installation media match by ensuring the contents of the {{filename|.buildstamp}} match.  The {{filename|.buildstamp}} is available inside the {{filename|images/install.img}} file.  See the example below for guidance on inspecting the {{filename|.buildstamp}} file.
 
<pre>
# mount -o loop /dev/sr0 /media
# mkdir /tmp/squashfs
# mount -o loop /media/images/install.img /tmp/squashfs
# cat /tmp/squashfs/.buildstamp
201005130056.i386
Fedora
13
https://bugzilla.redhat.com</pre>
 
{{anchor|bootfrommdraid}}
=== Booting from an mdraid mirror without a separate /boot fails ===
<small>[[#bootfrommdraid|link to this item]] - [[rhbug:584596|Bugzilla: #584596]]</small>
 
Installing a new system with / on an mdraid mirror without a separate /boot will fail as anaconda creates the / mdraid set with 1.1 metadata which makes it unsuitable to boot from. Workaround: use a separate mdraid mirror for /boot if you want to boot from an mdraid mirror. This issue will be fixed in Fedora 14.
 
{{anchor|cannot-remove-non-leaf}}
=== ValueError: Cannot remove non-leaf device ===
<small>[[#cannot-remove-non-leaf|link to this item]] - [[rhbug:569469|Bugzilla: #569469]]</small>
 
While modifying an existing software RAID1 disk configuration, users may encounter a failure while attempting to re-use the existing software configuration for another software RAID installation.  Installing a new software RAID configuration will not result in failures.  Specifically to [[rhbug:569469|Bugzilla #569469]], a failure occurs while attempting to create a new software RAID5 device using the existing RAID1 disk members where there are insufficient RAID members to needed for the desired RAID installation.  Users can work around this problem by creating a software RAID setup from scratch, or by creating a sufficient number RAID members before reusing an existing RAID device.
 
{{anchor|iscsi-install}}
=== iSCSI install will not boot ===
<small>[[#iscsi-install|link to this item]] - [[rhbug:589250|Bugzilla: #589250]]</small>
 
Users may encounter a boot failure after installing Fedora 13 to a remote iSCSI volume.  The problem is caused by the {{command|iscsistart}} command failing while attempting to find the root device on boot.  An updated {{package|iscsi-initiator-utils|iscsi-initiator-utils-6.2.0.872-4.fc13}} package that resolves the reported problem is available.  Users installing Fedora 13 to a remote iSCSI volume are advised to enable the ''Fedora 13 Updates'' package repository during installation to ensure that the latest {{package|iscsi-initiator-utils}} package is installed.
 
{{anchor|network-clock-jump}}
=== Network goes down due to clock jump during install process, resulting in problems if using network resources ===
<small>[[#network-clock-jump|link to this item]] - [[rhbug:590874|Bugzilla: #590874]]</small>
 
If changing the system clock settings during install results in a sudden large jump in the system clock - which can often happen, usually when selecting a time zone substantially different from the default Eastern time and/or adjusting the ''system clock uses UTC'' setting - any active network connection may go down. Obviously, if you are performing a network-based install, this can lead to it being impossible to complete the installation. To work around this issue, try using the default time zone settings during installation, and adjusting for your time zone after installation.
 
{{anchor|hdinstall-with-mirrorlist-repo}}
=== Hard Drive install fails when improperly specifying remote package repository  ===
<small>[[#hdinstall-with-mirrorlist-repo|link to this item]] - [[rhbug:573492|Bugzilla: #573492]]</small>
 
Users who install Fedora 13 using installation media on an existing hard drive partition (see [http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ch04s07.html installation guide]), may encounter a failure when specifying a remote package repository for additional software updates.  The problem appears to be the result of specifying a ''mirrorlist'' URL for the remote package repository, while failing to select ''URL is a mirror list'' option. 
 
To resolve this issue, users are advised to select the ''URL is a mirror list'' option when adding a remote package repository mirror.  Kickstart users are advised to use the appropriate keyword argument: <pre>repo --name=<name> [--baseurl=<url>|--mirrorlist=<url>] [options] </pre>.  For additional information on the kickstart <code>repo</code> command, see [https://fedoraproject.org/wiki/Anaconda/Kickstart#repo kickstart documentation].
 
{{anchor|installations-fail-with-lvm-create-errors}}
=== Installations fail in anaconda with an error relating to lvm, i.e. lvm create, resulting in the abort of the installation ===
<small>[[#installations-fail-with-lvm-create-errors|link to this item]] - [[rhbug:559290|Bugzilla: #559290]]</small>
 
To resolve the installation abort, allocate at least 512MB memory into a virtual machine, or even a physical machine. The installation should work then. See the bugzilla entry for more information on the cause of the bug. A test xen DomU instance was dropped back to 256MB after installation, result being, the system boots and runs fine in runlevel 3.
 
=== Security: sshd is running during kickstart installs, allowing remote access to the anaconda install system ===
<small>[[#sshd-is-running-during-kickstart-installs|link to this item]] - [[rhbug:600768|Bugzilla: #600768]]</small>
 
sshd is running during kickstart installs and there is no root password by default, allowing unauthorized remote access to the installation system. To avoid running sshd during kickstart installs, add sshd= to anaconda's kernel command line.
 
== Hardware-related issues ==
 
{{Anchor|preupgrade-LCD/CRT-remain-in-standby-after-reboot}}
{{Anchor|misc-gfx}}
=== Miscellaneous graphical problems ===
<small>[[Common F13 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=13 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 13, 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.


During a ''Fedora 13 Alpha'' CD-ROM installation, the installer may fail to properly eject the media when prompting for a subsequent installation disc. Investigation appears to show that performing a media check on the ISO media may trigger this failure later during install.
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.


If you encounter this issue while installing from CD-ROM media, you may work around the problem using the procedure detailed below.
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.
# When prompted to insert the next disc, change to the debug shell on tty2 by pressing ''<Control><Alt>F2''
# Eject the disc by typing: {{command|eject /dev/cdrom}}
# Insert the requested installation disc number
# Prepare the disc by typing: {{command|mount -o ro /dev/cdrom /mnt/source}}
# Return to the installer by pressing ''<Control><Alt>F6''


The above procedure may be repeated for each installation disc needed to complete the install.
To use the ''vesa'' driver during installation from a Fedora live image, press any key at the initial bootloader screen to allow configuration of the kernel parameters, and add the parameters ''xdriver=vesa nomodeset''.


{{Anchor|existing-luks-volumes}}
To use the ''vesa'' driver during upgrade from a previous version of Fedora using preupgrade:
=== Installing on a system with previously encrypted block devices fails - ''LVMError: lvactivate failed for lv_root'' ===
<small>[[#existing-luks-volumes|link to this item]] - [[rhbug:565848|Bugzilla: #565848]]</small>


When installing ''Fedora 13 Alpha'' on a system with an existing encrypted block device, you will encounter a failure if you attempt to reformat the system. Until resolved, whenever installing ''Fedora 13 Alpha'' on a system with encrypted block devices, it is recommended that you do '''not''' provide the passphrase to unlock the existing encrypted block devices.  When prompted for a passphrase, press ''Cancel''.  Alternatively, you may choose to erase any partition information from disks affected by running a command similar to the following.
# 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 13 (Goddard)"'}}, 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


<pre>dd if=/dev/zero bs=512 count=1 of=/dev/sda</pre>
{{Anchor|compiz-i8xx}}
=== Compiz fails to work on older Intel chipsets ===
<small>[[Common F13 bugs#compiz-i8xx|link to this item]] - [[rhbug:586236|Bugzilla: #586236]]</small>


{{admon/caution|Backup your data|Please backup any data before erasing the partition table. It is likely that you will be unable to recover the information on the disk after executing the {{command|dd}} command.}}
Reports indicate that Compiz fails to run on older Intel graphical chipsets, including the i845 chipset and probably other i8xx-generation chipsets. Attempting to enable Compiz will result in a crash which is picked up by abrt (the automated bug reporting tool). We may be able to address this bug with an update, but until that time the only known workaround is not to use Compiz on such hardware.


{{Anchor|lvm-memory-usage}}
{{Anchor|tpm-boot-pause}}
=== Installation using LVM requires a large amount of RAM (over 512MB) ===
=== Boot pauses for a long time, with ''tpm_tis 00:0a: tpm_transmit: tpm_send: error -62'' error displayed on console ===
<small>[[#lvm-memory-usage|link to this item]] - [[rhbug:559290|Bugzilla: #559290]]</small>
<small>[[Common F13 bugs#tpm-boot-pause|link to this item]] - [[rhbug:530393|Bugzilla: #530393]]</small>


Due to a bug in {{package|lvm2}}, installing ''Fedora 13 Alpha'' with any partition layout that involves LVM (including the default configuration) requires a large amount of system memory. 512MB is not enough, while 1GB usually is; extensive testing has not been done at levels between these two. If you are installing ''Fedora 13 Alpha'' on a system with less than 1GB of physical memory, you may need to use a custom partition layout with no use of LVM. If you are installing into a virtual machine, please allocate 1GB or more of memory to the virtual machine for the installation phase. You may be able to reduce the memory allocated to the virtual machine after installation.
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 ==
== Software issues ==


{{Anchor|yum-langpacks}}
{{Anchor|network-doesnt-connect}}
=== PackageKit silently fails to update ===
=== Network doesn't connect ===
<small>[[#yum-langpacks|link to this item]] - [[rhbug:567346|Bugzilla: #567346]] [[rhbug:569352|Bugzilla: #569352]]</small>
<small>[[#network-doesnt-connect|link to this item]] - [[rhbug:498207|Bugzilla: #498207]]</small>
 
After installation from physical media (e.g. CD or DVD), users may notice that programs requiring the network can not connect to the network.  If this is the case, the ''NetworkManager'' icon may show an X indicating that the machine is not currently connected.  While all networking hardware is correctly wired, and device indicators show the network to be properly connected, a change in default install behaviour means that the network does not immediately connect.
 
The required procedure from this point is to click the ''NetworkManager'' icon, and activate the System eth0 or similar connection. If the X disappears from the ''NetworkManager'' icon, then this was the issue that was stopping the connection from being activated.
 
However, the above change is only for the current login. To make this change permanent, right click the ''NetworkManager'' icon, Edit connections, select the System eth0 or similar, click Edit, provide the root password, check the Connect automatically item at the top of the dialog box, Apply and Close.
 
Please also see the [https://fedoraproject.org/wiki/Documentation_Networking_Beat#Ethernet_connections_are_not_started_at_first_boot future release note] describing this, and a [http://fedorasolved.org/Members/khaytsus/go-online-automatically-at-boot graphical description of the steps to take to make this setting].
 
{{Anchor|gnome-panel-crash}}
=== Gnome-panel crashes when opening workspace switcher preferences ===
<small>[[#gnome-panel-crash|gnome-panel-crash]] - [[rhbug:552423|Bugzilla: #552423]]</small>
 
A bug in the GNOME workspace-switcher applet may cause the {{command|gnome-panel}} to crash.  The problem appears to be triggered by right-clicking on the workspace-switcher applet, and selecting ''Preferences''. 
 
An updated [http://admin.fedoraproject.org/updates/gnome-panel-2.30.0-4.fc13 gnome-panel] 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|picasa-upload-broken}}
 
=== Picasa fails to login to google ===
<small>[[#picasa-upload-broken|link to this item]]</small>
 
Google bundles a version of wine with their picasa package (bad google).  This version of wine is linked against a different libssl library and therefore won't work with https addresses which is needed to login to google services.
 
This can be fixed by doing the following:
# Install wine via Yum: <pre>yum install wine</pre>
# Copy the correct library to picasa: <pre>cp /usr/lib/wine/wininet.dll.so /opt/google/picasa/3.0/wine/lib/wine/wininet.dll.so</pre>
 
{{Anchor|gnash-youtube-broken}}
 
=== Gnash fails to play youtube videos ===
<small>[[#gnash-youtube-broken|link to this item]] - [[rhbug:606170|Bugzilla: #606170]]</small>
 
The GNU flash movie player ({{package|gnash}}) fails to play youtube videos (with necessary codecs installed) after the first youtube visit with the message : '''"An error occured, please try again later."''' inside the player.  The problem appears to be due to mishandling of browser cookies.  To workaround the issue, delete youtube cookies, then block cookies from youtube.


After installing ''Fedora 13 Alpha'', some testers experienced a problem where the ''Software Update'' utility (provided by {{package|gnome-packagekit}}) fails to update the system software when requested.  The ''Software Update'' utility will quickly report that the software update has completed without actually downloading and installing any updatesRunning the ''Software Update'' utility again will show that no updates have been applied.
The procedure to remove cookies and block ''youtube.com'' cookies using {{package|firefox}} is listed below.
# Open firefox preferences by selecting ''Edit'' → ''Preferences'' from the firefox menu
# In the preferences window, choose the ''Privacy'' tab
# Under ''History'', set the value of ''Firefox will'' to ''Use custom settings for history''
# Next, remove any youtube cookies by selecting ''Show Cookies''.  Enter <code>youtube</code> in the search box, and click "Remove Cookies"Close the ''Cookies'' dialog when finished.
# Next, add an exception by selecting ''Exceptions'' and add <code>http://www.youtube.com</code> then select ''Block''
# Finally, close the firefox preferences dialog.


It is believed that a yum plugin provided by {{package|yum-langpacks}} may introduce package dependency conflicts, which will cause the update to silently fail.  The problem may affect upgrades using both the ''Software Update'' utility and {{command|yum}}.  Testing also demonstrated that the problem was difficult to reproduce and depends on whether the yum-langpacks plugin is installed, and whether certain conditions exist in the package repositories used during the update.
{{Anchor|no-update-notifications}}


If you are unable to update your system and the problem description above matches your symptoms, you may work around the issue by removing the {{package|yum-langpacks}} package.  To remove the package you may either:
=== Not receiving update notifications ===
# Open a terminal and type: {{command|su -c 'yum remove yum-langpacks'}}
<small>[[#no-update-notifications |link to this item]] - [[rhbug:615099|Bugzilla: #615099]] - [[rhbug:620943|Bugzilla: #620943]]</small>
# Or, from the default Desktop environment
## Select the ''System -> Administration -> Add/Remove Software'' menu item
## Enter the text ''yum-langpacks'' in the text-box
## Deselect the check-box associated with {{package|yum-langpacks}} and select, ''Apply''


{{Anchor|kpackagekit-broken}}
Updates to Fedora introduced two unexpected bugs, either of which results in users no longer seeing notifications of or being able to apply new updates.
=== KDE graphical package management fails to run at all ===
<small>[[#kpackagekit-broken|link to this item]] - [[rhbug:568931|Bugzilla: #568931]]</small>


There is unfortunately a version mismatch in ''Fedora 13 Alpha'' images between {{package|PackageKit}} and {{package|kpackagekit}}, the KDE package management tool. This means that {{package|kpackagekit}} will fail to run at all in KDE after installation of ''Fedora 13 Alpha'', from the KDE live image or the traditional installer. An updated version of {{package|kpackagekit}} is available in the Fedora 13 repositories. To update to this version, open a terminal and run the command {{command|su -c 'yum update kpackagekit'}}. Enter your root password when prompted to do so. If the KDE package management tools still fail to launch even after this, try doing a full system update with yum: {{command|su -c 'yum update'}}. If that encounters dependency problems, try {{command|su -c 'yum update --skip-broken'}}.
During the affected period, updates to the relevant packages were shipped to fix these issues, but users would not receive notifications for them unless they first applied the pending fixed updates using the "yum" tool. Packages fixing these issues were pushed to the Fedora software repositories around July 22, 2010. Users who have done a manual "yum update" since that push may have already received these fixes.


{{Anchor|gnome-keyring-add}}
'''As of this writing, users who are installing Fedora 13 and then immediately updating to the latest packages should not be affected.'''  This note remains mainly for historical purposes.
=== GNOME cannot store new secrets (passwords) ===
<small>[[#gnome-keyring-add|link to this item]] - [[rhbug:558678|Bugzilla: #558678]]</small>


There is a bug in the {{package|gnome-keyring}} packages included with ''Fedora 13 Alpha'' which results in GNOME applications being unable to store new ''secrets'' (usually passwords) in the GNOME keyring. If you upgrade an existing installation, existing secrets will continue to be retrieved from the keyring correctly, but you will not be able to add new ones or change existing ones. For instance, you will not be able to store new wireless network passwords: you will need to enter the password each time you connect to the network.
To fix the issue, please:


{{Anchor|firefox-print-broken}}
1. Open a Terminal (Applications > System Tools > Terminal)
=== Print operations cause Firefox to crash ===
<small>[[#firefox-print-broken|link to this item]] - [[rhbug:553834|Bugzilla: #553834]]</small>


Due to an underlying problem in {{package|libgcrypt}} (see [https://bugzilla.redhat.com/show_bug.cgi?id=553834#c43 this bug comment] for technical details), there is a flaw in the ''Fedora 13 Alpha'' printing stack which causes Firefox to crash immediately if you try to print or do a print preview. An updated {{package|cups}} package, which works around the {{package|libgcrypt}} bug, is available in the ''Fedora 13'' repositories to address this issue. Simply update your ''Fedora 13'' system to get this fix. Of course, ''Fedora 13 Beta'' will include the fix upon its release.
2. Type either of the following commands and enter the password for the root user when prompted.


{{Anchor|gnome-shell-broken}}
a. To choose to apply all pending updates now:
  su -c "yum -y --skip-broken update"
b. To choose to apply updates fixing only the specific issues mentioned above:
  su -c "yum -y --skip-broken update gnome-packagekit selinux-policy"


=== GNOME Shell fails to run at all ===
3. Log out and and then log back in, or reboot your computer.  Note
<small>[[#gnome-shell-broken|link to this item]] - [[rhbug:567116|Bugzilla: #567116]]</small>
that logout/login will complete the fix for the notification issue.
However, if you applied all updates in the previous step, you may need
to reboot for other updates that require it.


''Fedora 13 Alpha'' includes version 1.2 of the [http://clutter-project.org/ Clutter] toolkit, but {{package|gnome-shell}} has not yet been ported to work with this version. As a consequence, in ''Fedora 13 Alpha'', any attempt to use GNOME Shell will fail. Work to port GNOME Shell to Clutter 1.2 is under way, and we hope to include a usable GNOME Shell in ''Fedora 13 Beta''.
[[Category:Bugs]] [[Category:Common bugs]]

Latest revision as of 00:01, 15 March 2018

This page documents common bugs in Fedora 13 and, if available, fixes or workarounds for these problems. If you find your problem in this page, do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.

Release Notes

Read the Fedora 13 release notes for specific information about intentional changes in Fedora 13, 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)


Issues when upgrading from previous releases

Preupgrade doesn't work with default-sized /boot partition

link to this item

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 12 (and earlier) who installed their systems using the recommended /boot partition size of 200 MiB will not be able to upgrade their systems using preupgrade. The /boot filesystem is used to store the kernel and initial ramdisk images that form the core of the Fedora operating system. Its presence is required by several utilities including grub, kernel and preupgrade.

Users that have /boot partition size of at least 250 MiB should not have problems with using preupgrade. For others it is recommended to simply download Fedora 13 DVD/CD/netinst install medium and do a standard system upgrade. More experienced users that still want to use preupgrade may refer to these additional tips to free up space in /boot.

For Fedora 13 the default /boot partition size was increased to 500 MiB to avoid these problems in the future.

Text-mode upgrade fails when installing new bootloader

link to this item - Bugzilla: #580378

Users upgrading to Fedora 13 using the text-mode installer are advised to not select Create a new bootloader configuration. Creating a new bootloader configuration is not an intended function for the text-mode installer. Instead, users are advised to choose the upgrade or skip bootloader configuration options during a text-mode upgrade.

This issue has been resolved in future versions of anaconda.

Upgrade fails with fstab entry is malformed exception

link to this item - Bugzilla: #577260

Multiple users have reported a failure when trying to upgrade an existing Fedora installation. The installer gives an exception of the format:

fstab entry /dev/sda3 is malformed: scanned format (ext3) differs from fstab format (swap)

where the entry and both formats may be different. This happens because the installer is quite strict about the formats it will accept in the /etc/fstab file: entries which are valid for actual mounting purposes are rejected by anaconda in some situations. Common cases where this issue is encountered include entries which specify the formats ntfs-3g or auto. It is usually possible to work around this issue by changing the format in the problematic /etc/fstab entry. If the problematic format is ntfs-3g, change it to ntfs. If the problematic format is auto, then change it to the actual format of the affected partition.

You may also encounter this issue if mounting an ext3 partition as ext2, or an ext4 partition as ext3 or ext2. In this case, you can work around the issue by adjusting the configuration to mount the partition with its actual native type during the upgrade.

One other situation where you may encounter this issue is if the /etc/fstab file lists devices in the /dev/sdXX format, and the Fedora installer enumerates your devices differently from the installed system (for instance, the F13 installer considers a disk to be /dev/sdc but the installed system considers the same disk to be /dev/sda). In this case, you should adjust /etc/fstab to refer to devices by their UUIDs or labels.

Installation issues

64-bit DVD appears unbootable on some systems (especially Gigabyte motherboards)

link to this item - Bugzilla: #597283

Several users have reported that the 64-bit DVD Fedora 13 image cannot be booted on their systems. The system does not see the burned disc as a bootable disc at all, and proceeds to boot from the next listed boot device. The burned disc passes validation and can successfully boot on other systems. This bug appears to affect systems with Gigabyte motherboards in particular; almost all reporters have Gigabyte motherboards.

One known workaround is to use a different image for installation. The 64-bit live images and network installation image (netinst.iso) and the 32-bit DVD image are known to boot successfully on most affected systems. Obviously, installing from the 32-bit DVD image will give you a 32-bit Fedora installation.

Another workaround reported in the bug by Bob Weaver is to boot with the 32-bit DVD inserted until the first menu screen (where you can choose to Install, or various other options) appears, then eject the 32-bit DVD and insert the 64-bit DVD before selecting Install.

We are investigating this issue but have yet to identify the cause or any possible fixes.

Unable to activate some Intel gigabit network devices when booting some systems using PXE

link to this item - Bugzilla: #580563

When booting the installer from a network device using PXE, a problem has been identified where the network device does not reset after performing the PXE boot. The result is that the Fedora 13 installer to fails to activate the network for installation. Systems affected include those with Intel gigabit network adapters 82577 and 82578.

To confirm whether your system may be impacted by this issue, from a command-prompt, type:

# lspci -d 8086:10ea | grep -q Intel \
  && echo "Sorry, your system may be impacted by bug#580563." \
  || echo "Congratulations, you are not affected by bug#580563."

If your system contains Intel gigabit network adapters affected by RHBZ #580563, updated pxeboot installation images are available for download at http://jlaska.fedorapeople.org/updates/580563. For more information on booting the Fedora 13 installer using PXE, refer to the installation guide.

Space, Enter, and arrow keys don't work in x86_64 VNC installs

link to this item - Bugzilla: #591776

Due to a bug in tigervnc, some keys may not be work as expected when installing Fedora 13 64-bit using vnc. While some keys may not work as expected, users are still able to complete the install as directed using the mouse and keyboard. While this issue is resolved in future versions of Fedora, users may work around this problem by using an updates.img when installing Fedora 13 64-bit using vnc. For assistance on using an updates.img, refer to Anaconda/Updates.

Traceback when going back to modify Installation Repo

link to this item - Bugzilla: #505189

After customizing the install package set using the Customize Now option, users may encounter a failure when returning to the previous step and attempting to modify the Installation Repo. An updates.img is available that works around the reported problem. For assistance on using an updates.img, refer to Anaconda/Updates.

AttributeError: 'Ext4FS' object has no attribute 'mapName'

link to this item - Bugzilla: #494150

While testing Fedora 13, some users encountered problems while partitioning their disks. The cause of the failure is not yet known. The exact failure message changes depending on the partition selections. For example, the following failure messages were observed:

  • AttributeError: 'Ext3FS' object has no attribute 'mapName'
  • AttributeError: 'Ext4FS' object has no attribute 'mapName'
  • AttributeError: 'BTRFS' object has no attribute 'mapName'

Users experiencing this problem while installing Fedora 13, are advised to reboot the installer and retry. The reported problem does not occur on subsequent installs.

SystemError: (22, 'Invalid argument')

link to this item - Bugzilla: #590640

When installing Fedora 13 from a remote NFS share, you may encounter an exception referring to SystemError: (22, 'Invalid argument'). Investigation into the problem indicates the failure will occur when the Fedora installation boot media does not match the remote installation media available via NFS share. Users are directed to confirm that Fedora release used to boot the installer matches the Fedora available on remote NFS share. Users can confirm the boot media and remote installation media match by ensuring the contents of the .buildstamp match. The .buildstamp is available inside the images/install.img file. See the example below for guidance on inspecting the .buildstamp file.

# mount -o loop /dev/sr0 /media
# mkdir /tmp/squashfs
# mount -o loop /media/images/install.img /tmp/squashfs
# cat /tmp/squashfs/.buildstamp
201005130056.i386
Fedora
13
https://bugzilla.redhat.com

Booting from an mdraid mirror without a separate /boot fails

link to this item - Bugzilla: #584596

Installing a new system with / on an mdraid mirror without a separate /boot will fail as anaconda creates the / mdraid set with 1.1 metadata which makes it unsuitable to boot from. Workaround: use a separate mdraid mirror for /boot if you want to boot from an mdraid mirror. This issue will be fixed in Fedora 14.

ValueError: Cannot remove non-leaf device

link to this item - Bugzilla: #569469

While modifying an existing software RAID1 disk configuration, users may encounter a failure while attempting to re-use the existing software configuration for another software RAID installation. Installing a new software RAID configuration will not result in failures. Specifically to Bugzilla #569469, a failure occurs while attempting to create a new software RAID5 device using the existing RAID1 disk members where there are insufficient RAID members to needed for the desired RAID installation. Users can work around this problem by creating a software RAID setup from scratch, or by creating a sufficient number RAID members before reusing an existing RAID device.

iSCSI install will not boot

link to this item - Bugzilla: #589250

Users may encounter a boot failure after installing Fedora 13 to a remote iSCSI volume. The problem is caused by the iscsistart command failing while attempting to find the root device on boot. An updated iscsi-initiator-utils-6.2.0.872-4.fc13 package that resolves the reported problem is available. Users installing Fedora 13 to a remote iSCSI volume are advised to enable the Fedora 13 Updates package repository during installation to ensure that the latest iscsi-initiator-utils package is installed.

Network goes down due to clock jump during install process, resulting in problems if using network resources

link to this item - Bugzilla: #590874

If changing the system clock settings during install results in a sudden large jump in the system clock - which can often happen, usually when selecting a time zone substantially different from the default Eastern time and/or adjusting the system clock uses UTC setting - any active network connection may go down. Obviously, if you are performing a network-based install, this can lead to it being impossible to complete the installation. To work around this issue, try using the default time zone settings during installation, and adjusting for your time zone after installation.

Hard Drive install fails when improperly specifying remote package repository

link to this item - Bugzilla: #573492

Users who install Fedora 13 using installation media on an existing hard drive partition (see installation guide), may encounter a failure when specifying a remote package repository for additional software updates. The problem appears to be the result of specifying a mirrorlist URL for the remote package repository, while failing to select URL is a mirror list option.

To resolve this issue, users are advised to select the URL is a mirror list option when adding a remote package repository mirror. Kickstart users are advised to use the appropriate keyword argument:

repo --name=<name> [--baseurl=<url>|--mirrorlist=<url>] [options] 

. For additional information on the kickstart repo command, see kickstart documentation.

Installations fail in anaconda with an error relating to lvm, i.e. lvm create, resulting in the abort of the installation

link to this item - Bugzilla: #559290

To resolve the installation abort, allocate at least 512MB memory into a virtual machine, or even a physical machine. The installation should work then. See the bugzilla entry for more information on the cause of the bug. A test xen DomU instance was dropped back to 256MB after installation, result being, the system boots and runs fine in runlevel 3.

Security: sshd is running during kickstart installs, allowing remote access to the anaconda install system

link to this item - Bugzilla: #600768

sshd is running during kickstart installs and there is no root password by default, allowing unauthorized remote access to the installation system. To avoid running sshd during kickstart installs, add sshd= to anaconda's kernel command line.

Hardware-related issues

Miscellaneous graphical problems

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 13, 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 initial bootloader screen to allow configuration of the kernel parameters, and add the parameters xdriver=vesa nomodeset.

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 13 (Goddard)"', 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

Compiz fails to work on older Intel chipsets

link to this item - Bugzilla: #586236

Reports indicate that Compiz fails to run on older Intel graphical chipsets, including the i845 chipset and probably other i8xx-generation chipsets. Attempting to enable Compiz will result in a crash which is picked up by abrt (the automated bug reporting tool). We may be able to address this bug with an update, but until that time the only known workaround is not to use Compiz on such hardware.

Boot pauses for a long time, with tpm_tis 00:0a: tpm_transmit: tpm_send: error -62 error displayed on console

link to this item - Bugzilla: #530393

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

Network doesn't connect

link to this item - Bugzilla: #498207

After installation from physical media (e.g. CD or DVD), users may notice that programs requiring the network can not connect to the network. If this is the case, the NetworkManager icon may show an X indicating that the machine is not currently connected. While all networking hardware is correctly wired, and device indicators show the network to be properly connected, a change in default install behaviour means that the network does not immediately connect.

The required procedure from this point is to click the NetworkManager icon, and activate the System eth0 or similar connection. If the X disappears from the NetworkManager icon, then this was the issue that was stopping the connection from being activated.

However, the above change is only for the current login. To make this change permanent, right click the NetworkManager icon, Edit connections, select the System eth0 or similar, click Edit, provide the root password, check the Connect automatically item at the top of the dialog box, Apply and Close.

Please also see the future release note describing this, and a graphical description of the steps to take to make this setting.

Gnome-panel crashes when opening workspace switcher preferences

gnome-panel-crash - Bugzilla: #552423

A bug in the GNOME workspace-switcher applet may cause the gnome-panel to crash. The problem appears to be triggered by right-clicking on the workspace-switcher applet, and selecting Preferences.

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


Picasa fails to login to google

link to this item

Google bundles a version of wine with their picasa package (bad google). This version of wine is linked against a different libssl library and therefore won't work with https addresses which is needed to login to google services.

This can be fixed by doing the following:

  1. Install wine via Yum:
    yum install wine
  2. Copy the correct library to picasa:
    cp /usr/lib/wine/wininet.dll.so /opt/google/picasa/3.0/wine/lib/wine/wininet.dll.so

Gnash fails to play youtube videos

link to this item - Bugzilla: #606170

The GNU flash movie player (gnash) fails to play youtube videos (with necessary codecs installed) after the first youtube visit with the message : "An error occured, please try again later." inside the player. The problem appears to be due to mishandling of browser cookies. To workaround the issue, delete youtube cookies, then block cookies from youtube.

The procedure to remove cookies and block youtube.com cookies using firefox is listed below.

  1. Open firefox preferences by selecting EditPreferences from the firefox menu
  2. In the preferences window, choose the Privacy tab
  3. Under History, set the value of Firefox will to Use custom settings for history
  4. Next, remove any youtube cookies by selecting Show Cookies. Enter youtube in the search box, and click "Remove Cookies". Close the Cookies dialog when finished.
  5. Next, add an exception by selecting Exceptions and add http://www.youtube.com then select Block
  6. Finally, close the firefox preferences dialog.

Not receiving update notifications

link to this item - Bugzilla: #615099 - Bugzilla: #620943

Updates to Fedora introduced two unexpected bugs, either of which results in users no longer seeing notifications of or being able to apply new updates.

During the affected period, updates to the relevant packages were shipped to fix these issues, but users would not receive notifications for them unless they first applied the pending fixed updates using the "yum" tool. Packages fixing these issues were pushed to the Fedora software repositories around July 22, 2010. Users who have done a manual "yum update" since that push may have already received these fixes.

As of this writing, users who are installing Fedora 13 and then immediately updating to the latest packages should not be affected. This note remains mainly for historical purposes.

To fix the issue, please:

1. Open a Terminal (Applications > System Tools > Terminal)

2. Type either of the following commands and enter the password for the root user when prompted.

a. To choose to apply all pending updates now:

 su -c "yum -y --skip-broken update"

b. To choose to apply updates fixing only the specific issues mentioned above:

 su -c "yum -y --skip-broken update gnome-packagekit selinux-policy"

3. Log out and and then log back in, or reboot your computer. Note that logout/login will complete the fix for the notification issue. However, if you applied all updates in the previous step, you may need to reboot for other updates that require it.