From Fedora Project Wiki

(add #855849 (uefi boot broken for dvd/netinst on optical media or dd))
(33 intermediate revisions by 4 users not shown)
Line 52: Line 52:


== Installation issues ==
== Installation issues ==
{{Anchor|this-installer-kills-disks}}
{{Anchor|old-signatures-crash}}
=== Installer reformats target disks without warning ===
=== Installer crashes with ''FormatDestroyError: error wiping old signatures'' when installing over encrypted LVM or LVM-on-RAID ===
<small>[[#this-installer-kills-disks|link to this item]] - [[rhbug:855976|Bugzilla: #855976]]</small>
<small>[[#old-signatures-crash|link to this item]] - [[rhbug:876789|Bugzilla: #876789]]</small>


<span style="color:red">'''The Anaconda installer for Fedora 18 will format the entire disk unless custom partitioning is selected.'''</span>
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.


In Fedora 18 Alpha, if you select a disk or disks to which to install Fedora in the ''Installation destination'' screen and hit 'Continue' at the 'INSTALLATION OPTIONS' dialog without checking ''Let me review & customize the partitioning of the disks anyway'', then complete the installation, the installer will '''reformat all disks selected without any further warning'''. There is no option presented to use free space on the disks or resize existing partitions, '''all existing data on the disks will be lost'''.
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.


Checking the ''Let me review & customize the partitioning of the disks anyway'' box allows you to enter the custom partitioning screen, where you may be able to create a viable layout without destroying existing data. Be aware, however, that the custom partitioning screen is far from complete and known to be buggy. We strongly advise you to install Fedora 18 Alpha only on systems or virtual machines which contain no data of value to you.
Developers are currently examining the various factors which contribute to this problem, and it will be resolved for Fedora 18 Final.


This is not the final design of the partitioning process for Fedora 18, and it will be improved for the Beta and Final releases.
{{Anchor|incomplete-array-crash}}
=== Installer crashes with degraded/incomplete RAID, LVM or btrfs devices present ===
<small>[[#incomplete-array-crash|link to this item]] - [[rhbug:873224|Bugzilla: #873224]] [[rhbug:876441|Bugzilla: #876441]]</small>


{{Anchor|upgrade-not-available}}
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.
=== No upgrade function available from Fedora 17 to Fedora 18 Alpha ===
<small>[[#upgrade-not-available|link to this item]]</small>


There is no upgrade function available in the Fedora 18 Alpha installer, nor is preupgrade yet capable of upgrading from Fedora 17 to Fedora 18. The upgrade code for the new version of the installer was not completed in time for the Alpha release.
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).


If you are intent upon upgrading an installed Fedora 17 system to Fedora 18 Alpha you may attempt to upgrade using yum, following [[Upgrading_Fedora_using_yum|these instructions]] - make sure to read the section specific to the Fedora 18 upgrade. Please be aware that yum upgrades can have problems and you should not attempt this on any system containing data of any value to you.
{{Anchor|nfs-install-broken}}
=== Cannot install from NFS repository ===
<small>[[#nfs-install-broken|link to this item]] - [[rhbug:879187|Bugzilla: #879187]]</small>


This issue will be addressed for Fedora 18 Beta. Upgrade code will be in place at the time of the Beta release.
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 [http://wwoods.fedorapeople.org/doc/boot-options.html#_inst_repo here] to a boot of the network install image, with no other change, will also fail, resulting in the use of 'Closest mirror'.


{{Anchor|anaconda-error-handling}}
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.
=== Installer crashes instead of presenting an error dialog when disk is too small (or other errors) ===
<small>[[#anaconda-error-handling|link to this item]] - [[rhbug:854856|Bugzilla: #854856]]</small>


If you try to install Fedora 18 Alpha to a very small disk, the installer will likely crash with an error ''PartitioningError: not enough free space on disks''. 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.
This issue will be resolved for Fedora 18 final.


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.
{{Anchor|mate-dvd-broken}}
=== MATE installation is broken from the DVD media ===
<small>[[#mate-dvd-broken|link to this item]] - [[rhbug:878985|Bugzilla: #878985]]</small>


Error handling code will be implemented in the installer for Fedora 18 Beta.
If you choose to install the [[Features/MATE-Desktop|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.


{{Anchor|anaconda-autopart-crash}}
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 crashes when using automatic partitioning option with no free space available ===
<small>[[#anaconda-autopart-crash|link to this item]] - [[rhbug:849112|Bugzilla: #849112]]</small>


If you enter the custom partitioning screen of the Fedora 18 Alpha installer (by checking ''Let me review & customize the partitioning of the disks anyway'') and attempt to use the ''Click here to create them automatically'' option if there is no unpartitioned space available, the installer will crash with the error ''NoDisksError''. Another reporter has reported that this can also be triggered by entering the 'Installation destination' screen and immediately clicking ''Back'' without making any selection.
{{Anchor|installer-docs-old}}
=== Installer boot options documentation is outdated ===
<small>[[#installer-docs-old|link to this item]] - [[rhbug:864468|Bugzilla: #864468]]</small>


This bug is an instance of the lack of error handling described [[#anaconda-error-handling|above]]. It can be worked around by ensuring there is unpartitioned space available before attempting to use the automatic partitioning option (if your target disk is fully partitioned, delete one or more existing partitions before attempting to use the automatic partitioning option). As explained above, proper error handling will be implemented for the Fedora 18 Beta release.
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 [http://git.fedorahosted.org/cgit/anaconda.git/log/?h=f18-beta2-branch the anaconda source] and derive the currently-valid options from that.


{{Anchor|uefi-dvd-fail}}
Some old anaconda options - notably, several of the network configuration options - have been replaced by Dracut options, which are documented at [[Dracut/Options]].
=== UEFI boot of DVD/network install media fails ===
<small>[[#uefi-dvd-fail|link to this item]] - [[rhbug:855849|Bugzilla: #855849]]</small>


Native UEFI booting of the Fedora 18 Alpha DVD / network install images is known to be broken in certain cases. If you write the DVD or network install image to an optical disc, or to a USB stick using the {{command|dd}} (direct copy) method, the resulting medium will not succeed in starting the installer if booted via UEFI. You will be dropped to a rescue shell with the error message ''dracut-initqueue: Warning: /dev/root does not exist''.
{{Anchor|installer-short-freeze}}
=== Installer freezes briefly in remote repository setup ===
<small>[[#installer-short-freeze|link to this item]] - [[rhbug:874287|Bugzilla: #874287]]</small>


To avoid this issue, use one of the other methods of producing UEFI-bootable install media. Live images written to optical discs, with {{command|dd}}, or with {{command|livecd-iso-to-disk --efi}} should all boot successfully. If you wish to use the DVD or network install images, the {{command|livecd-iso-to-disk --efi}} method should result in a USB medium that will boot successfully.
If you use a remote package repository for the installation (netinst image or {{code|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.


See [[How_to_create_and_use_Live_USB]] for detailed instructions on the various methods of writing USB media.
{{Anchor|invalid-install-source}}
=== Invalid installation source breaks many configuration screens ===
<small>[[#invalid-install-source|link to this item]] - [[rhbug:875003|Bugzilla: #875003]]</small>


{{Anchor|reboot-after-live}}
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.
=== Reboot fails after live installation ===
<small>[[#reboot-after-live|link to this item]] - [[rhbug:857076|Bugzilla: #857076]]</small>


Multiple testers reported that, after completing a live installation of Fedora 18 Alpha, rebooting fails. If you hit Esc to see the console messages, you will see 'Dependency failed for Reboot.' and, at the end, 'Reached target Shutdown.'
{{Anchor|luc-no-uefi}}
=== UEFI boot doesn't work with liveusb-creator ===
<small>[[#luc-no-uefi|link to this item]] - [[rhbug:810112|Bugzilla: #810112]]</small>


Once the system has reached this point it is quite safe to hit the physical reset button or turn the power off. There is no known workaround for the issue besides simply rebooting or powering off manually.
[https://fedorahosted.org/liveusb-creator/ 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 {{command|dd}} or {{command|livecd-iso-to-disk}} to create it. The full instructions are at [[How to create and use Live USB]].


== Hardware issues ==
{{Anchor|F16-no-fedup}}
{{Anchor|nvidia-render-problems}}
=== Fedora 16 cannot be directly upgraded to Fedora 18 ===
=== Problems with start or display of login manager or desktop on NVIDIA graphics adapters ===
<small>[[#F16-no-fedup|link to this item]] - [[rhbug:873375|Bugzilla: #873375]]</small>
<small>[[#nvidia-render-problems|link to this item]] - [[rhbug:857300|Bugzilla: #857300]]</small>


There is a problem in the nouveau kernel module in Fedora 18 Alpha which can cause various symptoms that ultimately prevent you from reaching a usable desktop, when booting the live image or an installed system. The login manager and/or desktop may fail to appear at all (though ps and systemctl will show that they are running), or they may appear but with the cursor missing and/or visual corruption issues.
Beginning with Fedora 18 Beta, a new upgrade tool {{package|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.


To work around this issue for live system boot or first boot of an installed system, edit the kernel parameters at boot time and remove 'rhgb'. This should result in a fully working boot.
{{Anchor|dvd-langpacks-fail}}
=== 'Language packs' (localized data for certain packages) not installed when installing from DVD ===
<small>[[#dvd-langpacks-fail|link to this item]] - [[rhbug:879030|Bugzilla: #879030]]</small>


An updated [http://admin.fedoraproject.org/updates/kernel-3.6.0-0.rc6.git0.2.fc18 kernel] 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/kernel-3.6.0-0.rc6.git0.2.fc18 report to Bodhi] whether it solves the problem. To test the update, run this command:
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 {{package|libreoffice-core}} with the system locale set to French, you should also get the {{package|libreoffice-langpack-fr}} package, which contains French translations.
<pre>su -c 'yum --enablerepo=updates-testing update kernel'</pre>


== Software issues ==
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.
{{Anchor|qxl-unlock-crash}}
=== GNOME crashes when unlocking screen (usually in a KVM) ===
<small>[[#qxl-unlock-crash|link to this item]] - [[rhbug:856256|Bugzilla: #856256]]</small>


When running Fedora 18 Alpha in a KVM virtual machine using the 'qxl' video adapter and 'xorg-x11-drv-qxl' video driver, using the GNOME desktop, if the screen is locked either by the user or after an inactivity timeout, GNOME will crash back to the login screen a few seconds after the screen is unlocked.
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.


Note that a few reporters have reported similar behaviour with other video adapters and drivers (on real machines, not virtual ones), but these issues likely have different causes and should be reported separately.
This issue will be resolved in Fedora 18 final.


To workaround this issue you can disable screen locking, or - if you require screen locking - use a different video adapter and/or driver in the virtual machine, which will allow you to use screen locking but give you poorer video performance. The combination of the 'cirrus' adapter and the 'xorg-x11-drv-modesetting' driver also has problems, so if you are going to use an alternative combination, we recommend the 'vga' adapter.
{{Anchor|anaconda-error-handling}}
=== Installer crashes instead of presenting an error dialog when disk is too small (or other errors) ===
<small>[[#anaconda-error-handling|link to this item]] - [[rhbug:854856|Bugzilla: #854856]]</small>


Some testing suggests that updating to the latest GNOME packages from the updates-testing repository may resolve this issue.
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.


{{Anchor|packagekit-import-gpg}}
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.
=== PackageKit-based package management tools cannot import Fedora GPG key ===
<small>[[#packagekit-import-gpg|link to this item]] - [[rhbug:856225|Bugzilla: #856225]]</small>


After installing Fedora from the traditional installer, the Fedora GPG key is not included in the RPM keyring: the first time you perform any package operation, the tool you are using should prompt you to import the Fedora GPG key. (When installing from a live image, the key is already imported and this problem does not occur).
== Hardware issues ==


In Fedora 18 Alpha, PackageKit-based tools, such as the GNOME and KDE package installer and update applications, are not able to import the key. They will prompt you, but will not actually manage to import the key. This will mean you cannot complete any package management operation, such as installing a package or updating the system, with these tools.


The workaround for this is simply to perform any package install or update with the {{command|yum}} tool. This will prompt you to import the Fedora GPG key, and via yum, the import will be successful. After this, you can use PackageKit-based tools successfully.
== Software issues ==
{{Anchor|win8-fast-restart}}
=== Possible data loss when dual-booting with Windows 8 and using "fast restart" ===
<small>[[#win8-fast-restart|link to this item]] - [[rhbug:859373|Bugzilla: #859373]]</small>


A fix for this issue has been identified, but not yet incorporated into a Fedora package. This should be done soon.
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.


{{Anchor|virt-cursor-jump}}
=== Cursor frequently jumps to the edges of the screen, triggering overview in GNOME, especially in virtual machines ===
<small>[[#virt-cursor-jump|link to this item]] - [[rhbug:852841|Bugzilla: #852841]]</small>


Multiple testers reported an issue in Fedora 18 Alpha where the overview mode of GNOME Shell is triggered inadvertently. This issue especially affects virtual machines, both KVM and VirtualBox, though it can also affect real hardware.
{{Anchor|grub-upgrade-uefi}}
=== Graphical bootloader broken after upgrade on an UEFI machine ===
<small>[[#grub-upgrade-uefi|link to this item]] - [[rhbug:857523|Bugzilla: #857523]] [[rhbug:873455|Bugzilla: #873455]]</small>


The cause of this issue is a bug in the X server which causes the cursor to jump to the edges of the screen when a so-called 'absolute input device' is connected to the system. As moving to the top-left edge of the screen triggers the overview in GNOME, the bug can cause that to happen. The bug particularly affects virtual machines because they use virtual tablet devices to represent mouse input from the host (this has certain benefits over using a virtual mouse). It therefore also affects real hardware configurations that involve an absolute input device, like a tablet.
If you have installed Fedora 17 in an UEFI mode (you have {{package|grub-efi}} installed) and upgrade to Fedora 18, your graphical bootloader will fail to load with error <code>grub_open("hd(0,1)/grub/splash.xpm.gz") failed</code> 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.


The issue can be worked around by removing the absolute input device from the system (whether virtual or real). No other workaround has yet been discovered. Work on fixing the issue is ongoing.
A manual fix is described at [[FedUp#Updating GRUB (UEFI systems)]].


{{Anchor|grub-edit-font}}
{{Anchor|fedup-upgrade-no-visable-progress}}
=== Font in grub console (when editing boot options) is large and not monospaced, cannot be seen at all at 640x480 (in virtual machines) ===
<small>[[#grub-edit-font|link to this item]] - [[rhbug:850783|Bugzilla: #850783]]</small>


In Fedora 18 Alpha, the font used for the grub (bootloader) console - what you see when you hit 'e' at the bootloader menu, which allows you to edit the boot configuration - is poorly chosen. It is not a monospace font, and it is too large. This makes it difficult to read the screen, leads to bugs in cursor placement, and when grub renders at 640x480 resolution - which is the case in many virtual machine configurations - makes the screen completely unusable, no text is visible.
=== No visible progress during upgrade with FedUp ===
<small>[[#fedup-upgrade-no-visable-progress|link to this item]] - [[rhbug:879295|Bugzilla: #879295]], [[rhbug:873144|Bugzilla: #873144]]</small>


A fix for this issue has been identified, and will be a part of the next grub2 package released for Fedora 18.
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.


{{Anchor|startx-weirdness}}
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.
=== Various issues in desktop sessions started via startx ===
<small>[[#startx-weirdness|link to this item]] - [[rhbug:806491|Bugzilla: #806491]]</small>


If you start a graphical session in Fedora 18 Alpha by logging into a virtual terminal and running the {{command|startx}} command, you may find that at first all appears to be fine, but various small issues appear. Some effects that have been noted are issues with the GNOME lock screen, issues running virtual machines, the Suspend option not appearing in the User menu when holding the alt key, and several other issues related to session handling.
To see the upgrade progress properly, you have to manually adjust the boot arguments. The workaround is described at [[FedUp#Executing the Upgrade]].


The root issue here is that session handling is not done correctly for desktop sessions started via startx. Using the command {{command|startx -- vt01}} instead of plain {{command|startx}} will resolve several of the issues, though possibly not all of them.
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.

Revision as of 09:52, 29 November 2012

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.

Note.png
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 Package-x-generic-16.pngfedup 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 Package-x-generic-16.pnglibreoffice-core with the system locale set to French, you should also get the Package-x-generic-16.pnglibreoffice-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.

Hardware issues

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 Package-x-generic-16.pnggrub-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.

Retrieved from "https://fedoraproject.org/w/index.php?title=Common_F18_bugs&oldid=312836"