Common F18 bugs

In other languages: English (en) [edit]

This page documents common bugs in Fedora 18 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 18 pre-release
Fedora 18 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 18 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

Read the F18 Alpha release announcement and the Fedora 18 Alpha Release Notes for specific information about changes in Fedora 18 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)

Installation issues

Installer crashes with FormatDestroyError: error wiping old signatures when installing over encrypted LVM or LVM-on-RAID

link to this item - Bugzilla: #876789

The Fedora 18 Beta installer may crash during partitioning (first stage of actual installation process) with the error FormatDestroyError: error wiping old signatures from (device). So far, two scenarios have been identified which lead to this crash: an LVM-based (default) install over an existing Fedora 18 installation which contains an encrypted LV, and an LVM-based (default) install over an existing Fedora 17 installation which contains LVs on a firmware RAID array. However, there may well be other configurations which will trigger this problem.

The bug appears to occur when the installer believes a newly-created partition may still contain stale LVM or RAID metadata and so runs the wipefs command to delete it. If the partition is set to become part of an LV, though, it may become busy immediately after creation, and this causes the wipefs command to fail.

Developers are currently examining the various factors which contribute to this problem, and it will be resolved for Fedora 18 Final.

Installer crashes with degraded/incomplete RAID, LVM or btrfs devices present

link to this item - Bugzilla: #873224 Bugzilla: #876441

The installer in Fedora 18 Beta cannot reliably handle degraded or incomplete RAID, LVM or redundant/striped btrfs devices. When running the installer with such devices present, a crash (the linked bug, or another) may well occur during initial startup or partitioning.

This will be fixed for the Final release (in the sense that the installer will detect such devices and refuse to use them; it is intended that the installer will not deal with such devices, but it is not intended that it crashes in the case that they are present).

Cannot install from NFS repository

link to this item - Bugzilla: #879187

A bug in Fedora 18 Beta makes installation using an NFS repository difficult. Attempting to select such a repository interactively - from the Installation Source screen, after booting the installer - will fail, resulting either in the option reverting to 'Closest mirror', or in a crash. Attempting to specify an NFS repository as the package source by passing the inst.repo=nfs:... parameter documented here to a boot of the network install image, with no other change, will also fail, resulting in the use of 'Closest mirror'.

Two methods have been identified which do seem to result in success. If you boot the installer kernel and initramfs pair directly - as is typical when booting via PXE, and can be done in other cases - you can successfully pass inst.repo=nfs:.... Otherwise, when booting from the full network install image (or DVD), when editing the kernel parameters, you must also remove the inst.stage2=... parameter which is present by default. If you entirely remove this parameter as well as add the inst.repo=nfs:... parameter, you should meet with success.

This issue will be resolved for Fedora 18 final.

MATE installation is broken from the DVD media

link to this item - Bugzilla: #878985

If you choose to install the MATE desktop in Fedora 18 Beta from DVD installation media, you will receive a very incomplete and non-working environment, as the DVD does not in fact contain most of the MATE packages. MATE was not intended to be listed as available for installation from the DVD, but by mistake, it is.

The available workarounds are to use the netinst image instead of the DVD image, set the installation source to network repositories instead of the internal DVD package repository, or install MATE after system installation.

Installer boot options documentation is outdated

link to this item - Bugzilla: #864468

There are currently two pages documenting the boot options of the installer of Fedora 18 Beta: Anaconda Boot Options and http://wwoods.fedorapeople.org/doc/boot-options.html. Both of them are at least partly outdated. We are hoping to update these pages soon, but in the mean time you can try to look at both and take a guess which of the boot options are current and which are obsolete, if you need to use them. Of course, if you are able to follow the source code, you can check out the anaconda source and derive the currently-valid options from that.

Some old anaconda options - notably, several of the network configuration options - have been replaced by Dracut options, which are documented at Dracut/Options.

Installer freezes briefly in remote repository setup

link to this item - Bugzilla: #874287

If you use a remote package repository for the installation (netinst image or inst.repo boot argument), you might experience a brief freeze in the installer interface, usually lasting several seconds. It is assumed this is related to setting up the repository source and downloading metadata in the background. There is no loss of functionality, just wait a short while if you see the interface not responding immediately.

Invalid installation source breaks many configuration screens

link to this item - Bugzilla: #875003

If you happen to provide an invalid installation source (in the Installation Source screen) in the Fedora 18 Beta installer, some installer screens might become corrupted even when you provide a correct installation repository (like Closest mirror) afterwards. Most often the package selection screen gets corrupted, but other screens like partitioning or keyboard selection screen might be affected too. The only safe workaround is to reboot and start the installer again.

UEFI boot doesn't work with liveusb-creator

link to this item - Bugzilla: #810112

liveusb-creator is one of the recommended tools for converting optical media ISO images into a bootable USB images. However, this tool still hasn't implemented support for UEFI boot. If you want to install Fedora in native UEFI mode from a USB media, use either dd or livecd-iso-to-disk to create it. The full instructions are at How to create and use Live USB.

Fedora 16 cannot be directly upgraded to Fedora 18

link to this item - Bugzilla: #873375

Beginning with Fedora 18 Beta, a new upgrade tool fedup has been introduced, replacing the older PreUpgrade. FedUp currently only supports Fedora 17 -> Fedora 18 upgrades. If you want to upgrade Fedora 16, you need to go through Fedora 17 as an intermediary step. More information about the process should appear on the page Upgrading soon.

'Language packs' (localized data for certain packages) not installed when installing from DVD

link to this item - Bugzilla: #879030

Translations and other localized data for a few Fedora components are kept in so-called 'langpacks' - sub-packages for each available translation, which are intended to be installed alongside the main package when appropriate. For instance, when installing libreoffice-core with the system locale set to French, you should also get the libreoffice-langpack-fr package, which contains French translations.

Due to a bug in the package metadata aggregation that takes place during the creation of the DVD image, this mechanism does not work during DVD installations of Fedora 18 Beta. When installing in a language other than U.S. English from the Fedora 18 Beta DVD, you will not get the appropriate langpacks for libreoffice, Firefox, hunspell, KDE and any other component you install which uses the langpack system.

This bug does not affect installations from remote repositories, so doing a remote repository-based installation is a workaround for the bug. Otherwise, you can manually install the missing packages after system installation is complete.

This issue will be resolved in Fedora 18 final.

Installer crashes instead of presenting an error dialog when disk is too small (or other errors)

link to this item - Bugzilla: #854856

If you try to install Fedora 18 Beta to a very small disk, the installer may crash with an error PartitioningError: not enough free space on disks, or another error. In general, there are several cases where there is code in the installer to catch errors, but no 'error handling' code to present a dialog to the user with appropriate options when one of these errors occurs.

There is no workaround for this kind of problem, but in any case where this happens, it indicates some kind of problem in your installation attempt. You may be able to tell from the error message and traceback what the error is, and correct it in another attempt to install. For this specific error, the problem is that the target disk is too small.

Software issues

Possible data loss when dual-booting with Windows 8 and using "fast restart"

link to this item - Bugzilla: #859373

Using the "fast restart" feature of Windows 8 and rebooting into Fedora may lead to data loss. Files written to the Windows partition by Fedora may be deleted when rebooting into Windows 8. This may be avoided by disabling the "fast restart" feature in Windows 8.

Graphical bootloader broken after upgrade on an UEFI machine

link to this item - Bugzilla: #857523 Bugzilla: #873455

If you have installed Fedora 17 in an UEFI mode (you have grub-efi installed) and upgrade to Fedora 18, your graphical bootloader will fail to load with error grub_open("hd(0,1)/grub/splash.xpm.gz") failed or similar. The system is still able to boot the default kernel automatically and you can access a text mode menu after pressing a key, so this situation is not fatal, just not pretty.

A manual fix is described at FedUp#Updating GRUB (UEFI systems).

No visible progress during upgrade with FedUp

link to this item - Bugzilla: #879295, Bugzilla: #873144

This is a combination of multiple bugs. During upgrade with FedUp, the incorrect plymouth boot screen is shown and the graphical progress bar that should be displayed isn't due to a quirk in the build process. A patch has been submitted to fix the issue and it should be fixed for final.

The other issue is that the text output which is supposed to be displayed behind the plymouth splash doesn't show up due to another plymouth issue.

To see the upgrade progress properly, you have to manually adjust the boot arguments. The workaround is described at FedUp#Executing the Upgrade.

If you don't enable the progress monitoring, be patient with the upgrade and wait for the system to reboot. It can take up to an hour or more for the upgrade process to complete, depending on your system. Rebooting your system mid-upgrade could cause serious problems, data loss or require a complete re-install.