From Fedora Project Wiki

Revision as of 21:03, 31 May 2010 by Adamwill (talk | contribs) (fix 'link to this issue' for tpm-boot-pause (was pointing to f12))

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.

After preupgrade has run and the system is rebooted, LCD/CRTs remain in standby

link to this item

After running preupgrade users see output confirming boot is commencing, but as soon as the GUI switch happens and device probing occurs, the screens remain black and show the standby LEDs flashing.

If this happens, do the following:

#Reboot the system, by either pressing ctrl-alt-del (wait 1 minute), if the system does not reboot,
# hit the reset button.
#The system will now reboot into the old system. Log-in and open a terminal and type the following:
su -                                    # to become root
preupgrade-cli "Fedora 13 (Goddard)"    # run preupgrade again
# Edit grub.conf
vim /etc/grub.conf                      # Using vim edit grub.conf
# Look for the first title in grub, it should state that it is the preupgrade addition
# Find the kernel line and append the following two options
xdriver=vesa nomodeset
# Save the file by hitting the ESC key, and type :wq! and hit the enter/return key.
reboot

Now your system should boot into Preupgrade and do it's job. Please be very patient, it might run for 3-5 hours, depending on how many packages you have installed and what kind of CPU you have. It will reboot when it is finished.

P.s: Your already downloaded packages for the upgrade will remain for the new run of preupgrade, so you will not have to download all packages again!

NOTE: Lines starting with a # are comments! So are additions appended with a #!

Installation issues

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.

Hardware-related issues

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

PackageKit silently fails to update

should be already fixed now

link to this item - Bugzilla: #567346 Bugzilla: #569352

After installing Fedora 13 Alpha, some testers experienced a problem where the Software Update utility (provided by 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 updates. Running the Software Update utility again will show that no updates have been applied.

It is believed that a yum plugin provided by 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 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.

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 yum-langpacks package. To remove the package you may either:

  1. Open a terminal and type: su -c 'yum remove yum-langpacks'
  2. Or, from the default Desktop environment
    1. Select the System -> Administration -> Add/Remove Software menu item
    2. Enter the text yum-langpacks in the text-box
    3. Deselect the check-box associated with yum-langpacks and select, Apply

GNOME Shell fails to run at all

link to this item - Bugzilla: #567116

Fedora 13 Beta includes version 1.2 of the Clutter toolkit, but gnome-shell has not yet been ported to work with this version. As a consequence, in Fedora 13 Beta, 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.

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