From Fedora Project Wiki

(create a special title for issues fixed in Beta, more readable this way)
m (add category)
 
(89 intermediate revisions by 11 users not shown)
Line 2: Line 2:


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.
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.
{{admon/note|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 ==
== Release Notes ==
Read the [[F18 Alpha release announcement]] and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora 18 Alpha Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/ Fedora 18 release notes]--> for specific information about changes in Fedora 18 and other general information.
Read the [[F18_release_announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/index.html Fedora 18 release notes] for specific information about changes in Fedora 18 and other general information.


== My bug is not listed ==
== My bug is not listed ==
Not every bug is listed in this page, but [http://bugzilla.redhat.com 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.
Not every bug is listed in this page, but [https://bugzilla.redhat.com 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 [http://bugzilla.redhat.com 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.
To see if your bug has already been reported, you can [https://bugzilla.redhat.com 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:
If you believe an already-reported bug report should be added to ''this'' page because it is commonly encountered, you can:
Line 50: Line 48:
When the page is in pre-release state and a new pre-release becomes available, simply remove any issues that are now fixed from the page entirely.
When the page is in pre-release state and a new pre-release becomes available, simply remove any issues that are now fixed from the page entirely.
-->
-->
== Resolved issues ==
{{Anchor|packagekit-unsigned}}
=== PackageKit could not install unsigned packages ===
<small>[[#packagekit-unsigned|link to this item]] - [[rhbug:890616|Bugzilla: #890616]]</small>
Due to a bug, Fedora 18's PackageKit-based package management tools (which includes the default graphical tools for both GNOME and KDE desktops) initially could not install packages that are not signed. PackageKit should allow you to install such packages after providing additional authentication. You may particularly have noticed this when attempting to install popular third-party packages or enable commonly-used third-party repositories, but it should never affect installation of official Fedora packages, as these should always be signed with a trusted key.
This issue was fixed in the updated [https://admin.fedoraproject.org/updates/FEDORA-2013-0957/PackageKit-0.8.7-1.fc18 PackageKit-0.8.7-1.fc18] package. To solve the issue, update your Fedora 18 installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|PackageKit}}.
{{Anchor|ypserv-maps}}
=== Internal map files in ypserv could become unreadable after upgrade ===
<small>[[#ypserv-maps|link to this item]] - [[rhbug:896612|Bugzilla: #896612]]</small>
Package ypserv started using Tokyo Cabinet to store map files instead of GDBM, which could no longer be used because of license issues. Rebuilding of maps during upgrade doesn't have to be successful every time, because there is not enough information to do so.
This issue is believed to have been fixed in the updated [https://admin.fedoraproject.org/updates/FEDORA-2013-1404/ypserv-2.29-8.fc18 ypserv-2.29-8.fc18] package. To solve the issue, update your Fedora 18 installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|ypserv}}.


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


{{Anchor|invalid-source-breaks-anaconda}}
{{Anchor|mediacheck-unhelpful}}
=== Invalid installation source breaks many configuration screens ===
=== Media consistency check can't be skipped, its output is unhelpful ===
<small>[[#invalid-source-breaks-anaconda|link to this item]] - [[rhbug:875003|Bugzilla: #875003]]</small>
<small>[[#mediacheck-unhelpful|link to this item]] - [[rhbug:891548|Bugzilla: #891548]] [[rhbug:891551|Bugzilla: #891551]]</small>
 
The installation medium is checked for errors during boot be default. The consistency check says ''Press [Esc] to abort check.'', but if you try to skip it, lots of errors are printed and you end up in an emergency mode. Use <code>reboot</code> command or hard-reset the machine. It is recommended to let the consistency check finish, but if you really want to skip it, boot the installer using ''Install Fedora'' menu item instead of ''Test this media & install Fedora''.
 
If your media is corrupted, you will also receive lots of cryptic messages and end up in an emergency mode. The output will contain ''It is not recommended to use this media'' somewhere in the middle (see [https://bugzilla.redhat.com/attachment.cgi?id=667316 screenshot]). The flood of error messages might be confusing, but the main message is clear - your media was either corrupted in the download process (check its checksum) or in the burning process (try to burn it again).
 
{{Anchor|live-autologin}}
=== Automatic login does not work on Desktop Live image ===
<small>[[#live-autologin|link to this item]] - [[rhbug:854722|Bugzilla: #854722]]</small>
 
When you boot the Fedora 18 Desktop Live image, you will not be automatically logged in to the desktop, as was the case in previous releases and as is intended. The login screen will appear with 'Live System User' as the only available user account: clicking this user will log you into the live system, which will then work as usual. There are no further consequences of this bug beyond the minor inconvenience.
 
{{Anchor|posix-locale}}
=== Text installation sets POSIX locale ===
<small>[[#posix-locale|link to this item]] - [[rhbug:891379|Bugzilla: #891379]]</small>
 
If you perform the installation in the text mode, the system will have a POSIX locale enabled by default. That can break some programs that expect unicode-enabled environment. You can change the default locale after installation by editing {{filename|/etc/locale.conf}} and setting <code>LANG="en_US.UTF-8"</code> (or other locale).
 
{{Anchor|malay-crash}}
=== Installer crashes after selecting "Malay (Malaysia)" language ===
<small>[[#malay-crash|link to this item]] - [[rhbug:893026|Bugzilla: #893026]]</small>
 
If you boot the installer and select ''Malay (Malaysia)'' at the language selection screen, the installer crashes immediately after clicking the ''Continue'' button. The work-around is to start the installer in English and add Malaysian keymap manually (if you need it). In the installed system you can then change the default language using graphical configuration tools in your desktop environment or by editing {{filename|/etc/locale.conf}}. The Malaysian translation of the Fedora 18 installer is in any case very very incomplete, so in practice you would need to be able to read English to install anyway. We apologize to Malaysian-speaking users for this error.
 
{{Anchor|multi-layouts-manual}}
=== Installer does not automatically set up multiple keyboard layouts and switch command ===
<small>[[#multi-layouts-manual|link to this item]] - [[rhbug:892110|Bugzilla: #892110]]</small>
 
Keyboard layout configuration has changed substantially between Fedora 17 and Fedora 18. This may catch speakers of some languages off guard.
 
In Fedora 17 and earlier versions, Fedora had sophisticated handling of a fairly small range of languages and keyboard layouts. The installer, and Fedora's keyboard configuration tool, were aware of the 'correct' configurations for a given range of keyboard types. In particular, the installer was aware of several types of keyboard for which it should configure both a 'native' layout and the U.S. English layout, and a command to switch between them. This applies to keyboards such as Russian (and many other Cyrillic keyboards) where the 'native' layout does not provide the ability to input Roman characters (and other commonly-used ASCII characters). Users of such layouts are used to switching between their native layout and the U.S. English layout to input Roman characters.
 
Maintaining this sophisticated handling was a development burden, though, and it made it hard to offer the full range of available keyboard layouts, and it did not offer the ability to configure more 'unusual' combinations of layouts. So in Fedora 18, the 'sophisticated' handling has been removed, and the installer now simply offers a fairly generic interface that offers all available keyboard layouts and lets you enable as many of them as you like.
 
On the very first screen of the installation process, where you select your language, there is a checkbox marked "Set keyboard to default layout for selected language". It is natural to assume that this checkbox does something similar to the previous 'sophisticated' behaviour: however, it does not, exactly. It just uses a fairly simple algorithm to try and pick the single keyboard layout whose name most closely matches the name of the language you selected. It will never configure more than one layout. So picking the Russian language and checking this box will only configure the Russian layout, it will not also configure a U.S. layout. This applies to all layouts where it is 'normal' to also configure the U.S. layout: just checking that box and not performing any further keyboard configuration is likely to give you a result you do not want.
 
If you do ''not'' check the box, the behaviour may also not be exactly what you would expect. The installer will still attempt to guess what keyboard layout most closely matches the name of the language you selected. It will then add both that layout and the U.S. layout, with the U.S. layout as default, and alt-shift as the key combination to switch between them.
 
If you need more than one layout, whether you check the box or not, be sure to visit the ''Keyboard'' screen in the installer and add any additional layouts you need. Also make sure you configure a command to switch between layouts: you may well need to use it during the user creation stage of installation. Previous Fedora releases automatically configured 'both shift keys' as the keyboard command to switch layouts, but in Fedora 18 you can choose between several commands in the ''Keyboard'' screen.
 
If you become stuck at the user creation stage without access to the U.S. layout, you can try and workaround the problem from a text mode boot, but it may be simplest to restart installation and make sure you add the U.S. layout and a layout switch command.
 
{{Anchor|keyboard-layout-testing}}
 
=== Keyboard layout testing and selection during installation does not work as expected ===
<small>[[#keyboard-layout-testing|link to this item]] - [[rhbug:854557|Bugzilla: #854557]]</small>
 
On the Keyboard screen during Fedora 18 installation there is a text entry box labelled 'Test the selected layout below:'. This label is confusing. The box does not let you test the layout currently highlighted in the list on the left hand side of the screen, but the layout that is active. There is no indicator for the active layout, so it is not easy to know which layout is active. The layout that was in the list when you first entered the screen will stay active until you do one of two things: remove it, or configure a layout switch key combination and use it. So if the English (U.S.) layout was in the list when you first entered the screen, if you add the French (French) layout, it will not be active. If you highlight it in the list, it will not be active. If you move it to the top of the list, it will still not be active. But if you remove the English (U.S.) layout, French (French) will become the active layout. Alternatively, if you add French (French), then click the 'Options' button, pick one or more keyboard layout switch combination(s), click 'OK', and then press a layout switch combination you just configured, French (French) will become active: press it again, and English (U.S.) will be active again. This should be reflected in the test box.
 
As there is no indication of the current active layout throughout installation, if you are configuring multiple layouts, we recommend you ensure the layout you wish to use for the rest of the install process is active using the test box before leaving the Keyboard screen, and then do not switch layouts until installation is complete.
 
{{Anchor|dvd-no-libreoffice}}
=== DVD install does not include LibreOffice by default ===
<small>[[#dvd-no-libreoffice|link to this item]] - [[rhbug:880653|Bugzilla: #880653]]</small>
 
Though it has historically been part of the default Fedora package set, the LibreOffice office suite is not included in a default DVD or network installation of Fedora 18 (it is included in the Desktop live image installation, though, where it was not before). This is partly an oversight and partly due to technical limitations which prevented it being included by default but de-selectable for those users who do not want it.
 
If you wish to have LibreOffice installed as part of your DVD or network installation, make sure to enter the Software Selection screen and check the LibreOffice option on the right-hand side.
 
{{Anchor|non-ascii-disk-encryption}}
=== Disk encryption with national keyboard layout sometimes doesn't work ===
<small>[[#non-ascii-disk-encryption|link to this item]] - [[rhbug:743281|Bugzilla: #743281]]</small>
 
The installer offers the possibility to encrypt your disk partitions. If you chose a non-US keyboard layout earlier in the installation process, there is a possibility that if you encrypt your disk with some language-specific characters you might not be able to decrypt the disk during system boot. This concerns only some languages and only some keyboard layouts, but the full list of affected layouts is unknown.
 
The recommended approach is to use ASCII-only characters in your disk encryption password, or (this is the safest approach) select the default US keyboard layout in the installation process, and set your custom keyboard layout only inside the desktop session.
 
{{Anchor|oom-error}}
 
=== Insufficient system memory during installation might appear as a packaging error (or some other error) ===
<small>[[#oom-error|link to this item]] - [[rhbug:893987|Bugzilla: #893987]]</small>
 
The required amount of system memory (RAM) for installation might vary depending on the installation options you choose. If you receive an error message during installation saying ''There was an error installing the xyz package. This is a fatal error and installation will be aborted.'' ([https://bugzilla.redhat.com/attachment.cgi?id=675375 screenshot]) - or any other error which seems difficult to trace back to a definite source - there is some chance that this error occurred due to insufficient system memory. Either increase the system memory, or set up a larger ''swap'' partition and repeat the installation.
 
{{Anchor|uefi-win8-nogrub}}
 
=== Windows 8 installed in UEFI mode are not present in the Fedora bootloader menu ===
<small>[[#uefi-win8-nogrub|link to this item]] - [[rhbug:873207|Bugzilla: #873207]]</small>
 
If you install Windows 8 in the [http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface UEFI] mode and then install Fedora 18 into dual-boot, Windows will not be present in the bootloader menu (GRUB) that appears right after your computer starts. This is not a bug per se, UEFI systems handle operating system selection in a different way. Your computer should support a hotkey that triggers an OS selection dialog before GRUB even loads. In this dialog you should see the Windows system. Your OS preference should also be configurable in BIOS.
 
{{Anchor|mac-uefi-dvd}}
=== UEFI boot of Fedora 18 CD or DVD disc on Mac hardware falls to a prompt ===
<small>[[#mac-uefi-dvd|link to this item]] - [[rhbug:893839|Bugzilla: #893839]]</small>
 
If you boot a Fedora 18 CD or DVD disc - an actual silver disc - via UEFI on an Apple Mac system, instead of reaching the normal boot menu and hence the Fedora installer, it will drop to a bootloader prompt.


If you happen to provide 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.
This bug does not affect boot of Fedora 18 CD or DVD images written to a USB stick using one of the supported methods, so the easiest way to avoid this bug on Mac hardware is simply to boot the install from a USB stick rather than an actual optical disc. If you must use an optical disc for some reason, you can cause the installation to proceed from the prompt by entering this command: {{command|configfile (cd0,apple3)/EFI/BOOT/grub.cfg}}.


{{Anchor|solaris-zfs-freespace}}
=== Partitions on Solaris 10-formatted disks may appear as free space to installer ===
<small>[[#solaris-zfs-freespace|link to this item]] - [[rhbug:869482|Bugzilla: #869482]]</small>


{{Anchor|liveusb-creator-no-uefi}}
It has been reported that the Fedora 18 installer may not correctly recognize disks formatted by the Solaris 10 installer: it may see partitions on these disks as free (unformatted) space. This may be due to the Solaris 10 installer using an unusual GPT format. If you have disks formatted by the Solaris installer that contain data of value to you, exercise caution in installing Fedora 18. See the bug report for more details.
=== UEFI boot doesn't work with liveusb-creator ===
<small>[[#liveusb-creator-no-uefi|link to this item]] - [[rhbug:810112|Bugzilla: #810112]]</small>


[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 the support for UEFI boot. If you want to install Fedora in the UEFI mode from a USB media, use either {{command|dd}} or {{command|livecd-iso-to-disk}} to create it. The full guide is described in [[How to create and use Live USB]].
{{Anchor|lvm-free-space}}
=== Difficult to install to free space within an existing LVM volume group (VG) ===
<small>[[#lvm-free-space|link to this item]] - [[rhbug:892269|Bugzilla: #892269]]</small>


It can difficult to install to free space within an LVM volume group (VG) using the custom partitioning mode of Fedora 18.


{{Anchor|broken-lvm-raid-btrfs}}
This applies whether you begin the partitioning process with free space within an existing volume group, or you plan to remove or shrink existing LVs (but not to remove the entire volume group) as part of your partitioning approach.
=== Installer crashes with degraded/incomplete RAID, LVM or Btrfs ===
<small>[[#broken-lvm-raid-btrfs|link to this item]] - [[rhbug:873224|Bugzilla: #873224]] [[rhbug:876441|Bugzilla: #876441]]</small>


The installer in Fedora 18 Beta cannot successfully use degraded or incomplete RAID or LVM setups. The installer might crash in this case. This might affect also certain configurations or Btrfs.
When you come to create the new mount points, after having scheduled removal or shrink of existing LVs if necessary, you will find that the installer's free space counter does not account for the free space within the existing VG - it will show zero, or a very small number representing the available space outside the VG. If you then create a new volume and leave its size unspecified, the installer will create a new LV within the existing VG, but only of the size it believed was available as 'free space' (so, uselessly tiny). You will not be able to make the new LV any larger, even though there really is space available within the VG.


This will be fixed for the Final release.
It is possible to make this work, however. What you have to do is specify the correct intended size for each new volume as you create it. The installer will allow this. So if you have 100GB of free space within your existing VG, you could, say, create a / mount point and specify its size as 30GB, then create a /home mount point and specify its size as 70GB. The installer will allow this and will create these as LVs within the existing VG. Note that you will not be able to increase the size of an LV after you 'create' it, within the installer - even if there really is space available within the VG. However, you get as many tries as you like, when dealing with this bug - if you get it wrong, you can just remove the LVs and try again, as in the new installer, no operations are actually performed until you complete the partitioning step and start the installation. All the 'creations' and 'removals' are just planned operations. So don't be afraid to fiddle around until you nail it.


{{Anchor|identical-vg-crash}}
=== Crash when installing to disks containing identically-named LVM volume groups (VGs) ===
<small>[[#identical-lv-crash|link to this item]] - [[rhbug:887539|Bugzilla: #887539]]</small>


{{Anchor|no-fedup-for-F16}}
Testing indicates that the Fedora 18 installer may crash if you attempt an install to a system containing two or more identically named LVM volume groups (VGs) - even if you choose to delete one or both as part of the installation process.


=== Fedora 16 can't be directly upgraded to Fedora 18 ===
If you are affected by this problem, there are several possible workarounds. Most simply, if you only need to install to one of the disks containing identically-named VGs, you can leave the other disk(s) out of the installation target disk set (selected on the first page of the Installation Destination spoke), or temporarily remove the other disk(s) from the system. If you need to keep the offending disks connected and use them as installation targets, you will need to remove or rename one of the VGs using another tool before beginning the Fedora installation.
<small>[[#no-fedup-for-F16|link to this item]] - [[rhbug:873375|Bugzilla: #873375]]</small>


Beginning with Fedora 18 Beta, a new upgrade tool {{package|fedup}} has been introduced, replacing 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 page [[Upgrading]].
{{Anchor|btrfs-freespace-problems}}
=== Install to small btrfs volume may fail or crash ===
<small>[[#btrfs-freespace-problems|link to this item]] - [[rhbug:893331|Bugzilla: #893331]], [[rhbug:893758|Bugzilla: #893758]]</small>


Two related bugs have been discovered in Fedora 18 installation when installing to a small btrfs volume. The Fedora installer attempts to check whether your planned disk layout will be big enough to accommodate your chosen package set, but this calculation is not strict enough for btrfs installations: it will allow installation to proceed in some cases even if there is actually not quite enough space available for the installation to succeed. This affects only quite a narrow 'band' of cases - for instance, in the reported test system, the installer would refuse to install to a 7GB disk due to lack of space, and install to a 9GB disk would succeed. An 8GB disk would trigger the bug.


{{Anchor|anaconda-error-handling}}
To ensure you do not run into this problem, if installing to a btrfs volume, try and ensure there will be sufficient space for the installation to succeed. You are unlikely to have trouble unless you are installing to a fairly small disk.
=== 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.
If you do encounter this bug, you will find the failure case can be quite unpredictable - this is a result of the other related bug, which is that btrfs' behaviour on running out of space can vary, and result in different effects in the Fedora installer. It is very likely that it will crash in some way, but the precise nature of the crash may vary.


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|installer-docs-old}}
=== Installer boot options documentation is outdated ===
<small>[[#installer-docs-old|link to this item]] - [[rhbug:864468|Bugzilla: #864468]]</small>


This has not been fixed in Fedora 18 Beta, although the symptoms might be a bit different now.
There are currently two pages documenting the boot options of the installer of Fedora 18: [[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.


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


== Hardware issues ==
{{Anchor|install-source-nothing}}
=== Installation source shows 'Nothing selected' for network installation ===
<small>[[#install-source-nothing|link to this item]] - [[rhbug:873468|Bugzilla: #873468]]</small>


It is possible that the Fedora 18 installer may fail to correctly set the default remote package source on occasion when booting the network installation image. Instead of showing 'Closest mirror' and 'GNOME Desktop', the 'Installation Source' and 'Software Selection' entries on the installer hub/home screen will show 'Nothing selected'. This will prevent installation from starting until it is rectified. Several possible causes of this bug were eliminated during development of Fedora 18, but it appears the bug may still occur in some rare cases.


== Software issues ==
If you are affected by this bug, to work around it, you can either just reboot (it will often succeed on a second try), or enter the 'Installation Source' spoke, change the remote source URL to any specific address at all (it does not have to be valid), return to the hub screen, return to the 'Installation Source' spoke, change the source back to 'Closest mirror', and return to the hub screen once again.


{{Anchor|startx-weirdness}}
{{Anchor|netinst-wifi}}
=== Various issues in desktop sessions started via startx ===
=== Network installation incorrectly refreshes installation source for WiFi or slow network card ===
<small>[[#startx-weirdness|link to this item]] - [[rhbug:806491|Bugzilla: #806491]]</small>
<small>[[#netinst-wifi|link to this item]] - [[rhbug:892665|Bugzilla: #892665]]</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.
If you boot the network installation image ({{filename|netinst.iso}}) on a machine with just a wireless network connection, or a very slow wired network card, the installer may say ''Nothing selected'' below the ''Installation source'' icon and it will be marked as a problematic state (see [https://bugzilla.redhat.com/attachment.cgi?id=674095 screenshot]). However, just opening the ''Installation Source'' dialog and ensuring that ''Closest Mirror'' is selected doesn't help. You need to manually trigger metadata refresh by first changing the network source to e.g. http://abc (hit ''Done''), and only then switching it back to ''Closest Mirror''.


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.
You can also use updates.img from http://rvykydal.fedorapeople.org/updates.nothingselected.img to fix this issue. Read [[Anaconda/Updates]].


{{Anchor|network-spoke-garbage}}
=== Garbage text appears on installer's network configuration screen ===
<small>[[#network-spoke-garbage|link to this item]] - [[rhbug:892122|Bugzilla: #892122]]</small>


{{Anchor|win8-fast-restart}}
A bug in the Fedora 18 installer can lead to some unexpected text appearing on the network configuration screen and rendering it difficult or impossible to use. The text appears in English, and it is a set of headers associated with a git commit: [https://bugzilla.redhat.com/attachment.cgi?id=672814 this image] is an example of the bug in action.
=== Possible data loss dual-booting with Windows 8 ===
<small>[[#win8-fast-restart|link to this item]] - [[rhbug:859373|Bugzilla: #859373]]</small>


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.
This appears to happen with some non-English languages. Possible workarounds are installing in English, configuring the network prior to the start of installation from the live environment (if using the live installer) or with kernel parameters (if using the traditional installer), or attempting to access the 'hidden' parts of the screen using keyboard navigation.


{{Anchor|wpa-enterprise-netinst}}
=== Cannot connect to WPA / WPA2 Enterprise network during installation ===
<small>[[#wpa-enterprise-netinst|link to this item]] - [[rhbug:892896|Bugzilla: #892896]]</small>


== Issues broken in Fedora 18 Alpha, but fixed in Fedora 18 Beta ==
The Fedora 18 installer is not capable of connecting to WPA / WPA2 Enterprise wireless networks for network installation. This is a temporary limitation and this capability should be added for future Fedora releases.


{{Anchor|this-installer-kills-disks}}
{{Anchor|installer-focus-loss}}
=== Installer reformats target disks without warning ===
=== Installer can become apparently 'stuck' in custom partitioning mode due to window focus problems ===
<small>[[#this-installer-kills-disks|link to this item]] - [[rhbug:855976|Bugzilla: #855976]]</small>
<small>[[#installer-focus-loss|link to this item]] - [[rhbug:875921|Bugzilla: #875921]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta. The installer will now ask you before removing any partitions.'''</span>
Occasionally, the Fedora 18 installer can become apparently 'stuck' in custom partitioning mode, after opening several subsidiary dialogs. The typical manifestation of this bug is that you hit the button to add a new mount point or to change the properties of a mount point, the subsidiary dialog does not appear, and the installer seems to stop responding: the cursor will still move and change shape depending on what it is hovering over, but clicks will appear to have no effect.


<span style="color:red">'''The Anaconda installer for Fedora 18 Alpha will format the entire disk unless custom partitioning is selected.'''</span>
This is a window focus problem - the dialog has in fact appeared, but is behind the main anaconda window but still focused and taking all mouse/keyboard input. The issue can be resolved quite simply by pressing the Esc key, which will close the rogue dialog. This will restore normal behaviour. The bug has no further consequences.


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'''.
{{Anchor|netinst-kickstart}}
=== Installer crashes if you need a network installation and have a local kickstart and a slow network card ===
<small>[[#netinst-kickstart|link to this item]] - [[rhbug:892669|Bugzilla: #892669]]</small>


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.
If you perform a kickstarted network installation and serve the kickstart locally (from a local partition, not from online location) on a machine with a slow network card, the installer will crash if it starts earlier than the network is set up.


This is not the final design of the partitioning process for Fedora 18, and it will be improved for the Beta and Final releases.
The solution is to serve the kickstart from an online location. That will set up the network very early in the boot process, before the installer is started.


{{Anchor|system-clock-timezone}}
=== Installer no longer attempts to infer whether hardware clock is set to local time or UTC, or allows you to configure this ===
<small>[[#system-clock-timezone|link to this item]] - [[rhbug:881403|Bugzilla: #881403]]</small>


{{Anchor|upgrade-not-available}}
In previous Fedora releases, the installer offered a configuration option to specify whether the system's hardware clock was set to local time or to UTC. It would also attempt to guess the correct setting, defaulting to 'local time' if a Windows installation was found, or UTC if not (these are the most likely cases). In Fedora 18, the configuration option is no longer present, and the heuristic to try and determine the most likely case was also lost.
=== No upgrade function available from Fedora 17 to Fedora 18 Alpha ===
<small>[[#upgrade-not-available|link to this item]] - [[rhbug:872044|Bugzilla: #872044]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta. There is a new upgrade tool {{package|fedup}}. The new process should get documented on the [[Upgrading]] page.'''</span>
The most likely consequence of this bug is that, if you do have a Windows installation, your system clock will be incorrect every time you switch operating system, as Windows will expect it to be set to local time, but Fedora will expect it to be set to UTC.


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.
The configuration option was removed intentionally as it was considered confusing, but the removal of the heuristic was not intentional. It will be restored in future Fedora releases. You can change this setting after installation using the {{command|system-config-date}} utility.


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|croatian-layout-missing}}
=== Croatian keyboard layout missing from installer ===
<small>[[#croatian-layout-missing|link to this item]] - [[rhbug:883555|Bugzilla: #883555]]</small>


This issue will be addressed for Fedora 18 Beta. Upgrade code will be in place at the time of the Beta release.
The Fedora 18 installer's Keyboard spoke is intended to offer all Xkb keyboard layouts present in Fedora, but testing has shown that the Croatian layout and its variants are missing from the list. These layouts are available for selection via desktop keyboard configuration tools after installation. We have not yet identified why the installer does not recognize these layouts as being available, but we will aim to resolve the issue for future Fedora releases.


{{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>


{{Anchor|minimal-package-sets}}
[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]].
=== Many expected packages missing from DVD / network installations ===
<small>[[#minimal-package-sets|link to this item]] - [[rhbug:856372|Bugzilla: #856372]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
{{Anchor|firstboot-user-quit}}
=== Quitting advanced user creation tool during firstboot quits firstboot ===
<small>[[#firstboot-user-quit|link to this item]] - [[rhbug:884833|Bugzilla: #884833]]</small>


One of the Fedora 18 features is a [[Features/ReworkPackageGroups|major rework of package groups]]. In Fedora 18 Alpha, this rework is not yet complete, and the package groups for the major desktops - especially GNOME - are not yet finalized. There is also a bug in the Fedora 18 Alpha installer. On the package selection screen, when you pick a 'major' package group on the left hand side, there is a mechanism by which some more package groups associated with that group may appear on the right hand side. In Alpha, however, this mechanism is broken. For instance, when you pick the GNOME package group, some extra sets of packages associated with GNOME should appear in the list on the right, but due to this bug, this does not happen. When installing some package groups from the DVD / network install in Alpha, especially GNOME, you will end up with a much smaller set of packages installed than you might expect (and that you would have got in previous releases).
On first boot after installing Fedora 18 (and any Fedora release), a small utility called 'firstboot' is run, which allows you to create a user account and configure a few other options. When creating a user account, there is an option to run an 'advanced' tool for creating more complex accounts. This option actually runs the external application '''system-config-users'''. If you then quit this application by opening the ''File'' menu and clicking on ''Quit'', it will close the whole firstboot process and proceed immediately to the login screen. If you instead close the application by hitting the X at the corner of the window, the firstboot process will continue.


One way to 'work around' this is to install from the live images, which have more complete package sets at this point in time. You can also specify any combination of package groups and packages for installation using a [[Anaconda/Kickstart|kickstart-driven install]]. Finally, of course, you can simply install the packages and package groups you want to use after system installation.
Testing shows that any user accounts you created in the 'advanced' tool will exist and function correctly even if you hit this bug, and the only subsequent step in the firstboot tool is network time configuration, which you can do from desktop configuration tools at any time, so the impact of this bug is not very high. If you run into it, do not worry: you can safely use the installed system.


The fix for the problem with optional package groups not showing up was identified prior to Alpha, but not included in the Alpha release for fear of destabilizing it. It will be included in the Beta release. The package groups themselves will also be further refined for Beta.
{{Anchor|livecd-with-wwan-card}}
=== Live installation on machines with WWAN network card freezes ===
<small>[[#livecd-with-wwan-card|link to this item]] - [[rhbug:893892|Bugzilla: #893892]]</small>


When installing from Live CD on computers with WWAN network cards (e.g. UTMS, GSM), installer can freeze on Welcome screen after hitting ''Continue'' button. To work around this issue, run installation from terminal using {{command|liveinst}} command with updates image:
su -c "liveinst --updates=http://rvykydal.fedorapeople.org/updates.wwan.img"


{{Anchor|anaconda-autopart-crash}}
The problem is caused by missing ''/etc/sysconfig/network-scripts/ifcfg-<iface name>'' file (e.g. {{command|/etc/sysconfig/network-scripts/ifcfg-wwan0}}), so another work-around would be to create the file prior to the installation either manually or using ''Network Settings'' of Live environment by saving default configuration of the WWAN device.
=== 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>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
{{Anchor|live-network-save}}
=== Live installation crashes if network configuration is modified and saved prior to installation ===
<small>[[#live-network-save|link to this item]] - [[rhbug:895900|Bugzilla: #895900]]</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.
If you use a Fedora 18 live image, change the configuration of any network device, save the changes, and then launch the live installer, you may find the installation fails with the error ''No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-foo'' (where 'foo' may be anything).


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.
This bug is actually very similar to [[#livecd-with-wwan-card|the one above]], and the same updates image can be used to avoid it, following the same instructions. Alternatively, if you really need to edit the network configuration outside of the installer, you can work around the bug by launching the installer but leaving it on the Welcome screen while you configure the network adapter, then continuing with the installation.


{{Anchor|repos-with-spaces}}
=== Installations that specify repositories with spaces in their names fail ===
<small>[[#repos-with-spaces|link to this item]] - [[rhbug:885139|Bugzilla: #885139]]</small>


{{Anchor|uefi-dvd-fail}}
The version of {{package|yum}} included with Fedora 18 had a problem when printing an informational message for repositories with spaces in their names. This problem can cause the installer to crash when handling an installation that contains such a repository. The error message would be ''TypeError: not enough arguments for format string''.
=== UEFI boot of DVD/network install media fails ===
<small>[[#uefi-dvd-fail|link to this item]] - [[rhbug:855849|Bugzilla: #855849]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
If you do a kickstart installation of Fedora 18 that specifies an additional repository, it is safest to ensure that the repository name does not contain any spaces, to avoid being affected  by this bug.


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|bootloader-password}}
=== Bootloader password is required on each boot ===
<small>[[#bootloader-password|link to this item]] - [[rhbug:840160|Bugzilla: #840160]]</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 set a bootloader password during installation of Fedora 17 (which is only possible when doing a [[Anaconda/Kickstart|kickstart-based]] install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.


See [[How_to_create_and_use_Live_USB]] for detailed instructions on the various methods of writing USB media.
Lawrence Lowe [https://bugzilla.redhat.com/show_bug.cgi?id=840160#c14 suggests] that the --unrestricted parameter can be added to ''menuentry'' lines in the grub config file to make them available without the password being entered.


The cause of this problem has been identified and it will be resolved for the Fedora 18 Beta release.
== Upgrade issues ==


{{Anchor|fedup-encrypted}}
===  Upgrade doesn't start for systems with more than one encrypted partition ===
<small>[[#fedup-encrypted|link to this item]] - [[rhbug:896010|Bugzilla: #896010]]  [[rhbug:910326|Bugzilla: #910326]]</small>


{{Anchor|uefi-boot-fail}}
This issue affects systems with multiple encrypted partitions (a single encrypted LVM with many logical volumes does not count as multiple encrypted partitions). When you run [[FedUp]] on such a system and then reboot into ''System Upgrade'' boot menu, you are asked for the disk decryption password and then the system hangs and does nothing (or alternatively, you are placed in a maintenance mode after a while). {{key press|Ctrl|Alt|Del}} combination should reboot your computer and you should be able to boot back into Fedora 17 just fine.
=== UEFI installation fails to boot ===
<small>[[#uefi-boot-fail|link to this item]] - [[rhbug:856938|Bugzilla: #856938]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
One of the fixes that might work is to [https://bugzilla.redhat.com/show_bug.cgi?id=896010#c26 append "enforcing=0" to the kernel command line].


This issue is distinct from the [[#uefi-dvd-fail|one above]]. On some UEFI-capable systems, a UEFI native installation of Fedora 18 Alpha (performed using one of the methods which produces a bootable installer) will fail to boot: the installation process will proceed successfully and a 'Fedora' UEFI boot manager entry will be present, but it will fail to successfully boot the system. What exactly happens when you try and boot it will depend on your system's firmware, but usually it will either hang at a black screen, reboot or leave you at the firmware management interface.
An updated [https://admin.fedoraproject.org/updates/fedup-0.7.3-0.git20130128.fc17 fedup] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [https://admin.fedoraproject.org/updates/fedup-0.7.3-0.git20130128.fc17 report to Bodhi] whether it solves the problem. To test the update, run this command:
<pre>su -c 'yum --enablerepo=updates-testing update fedup'</pre>
from the Fedora 17 system before beginning the upgrade to Fedora 18. Also, ensure the Fedora 17 system is fully up to date - including the {{package|systemd}} package - before beginning the upgrade.


This problem occurs because the UEFI boot manager entry for the Fedora installation does not have a leading \ in the path to the boot image. Some UEFI implementations are capable of handling this error, but others are not and will simply fail to boot.
== Hardware issues ==


A fix for this issue has already been created. If you are affected by it, you can solve the problem by re-installing using an [[Anaconda/Updates|anaconda updates image]] which includes the fix for the problem. To do so, boot the installer, hit 'e' at the bootloader menu to edit the default entry, and add the parameter {{command|updates<nowiki>=http://pjones.fedorapeople.org/updates-rhbz856938.img</nowiki>}} to the end of the linuxefi line and boot by hitting F10. Then complete installation as normal, and the installed system should now boot successfully.
{{Anchor|SandyB-GPU-Power}}
=== Intel Sandybridge GPU eats power after resume from suspend ===
<small>[[Common F18 bugs#SandyB-GPU-Power|link to this item]] - [[rhbug:866212|Bugzilla: #866212]]</small>


Alternatively, if you are familiar with adjusting UEFI boot manager entries using the {{command|efibootmgr}} tool you may be able to add the leading \ to the entry yourself.
Starting in the 3.6 kernel, there is a misbehavior in the Intel GPU code that affects Sandybridge systems, including but not limited to many newer IBM ThinkPads. After resuming from suspend, sometimes the GPU is unable to return to its sleep (rc6) state when not busy. This means it will quickly consume power and lower battery life.


Unfortunately, the problem is intermittent and may or may not happen after any specific resume from suspend.  To diagnose the problem, you can do one of the following:


{{Anchor|reboot-after-live}}
# Install the {{package|powertop}} package and run it as root (''su -c powertop'').  Use the ''Tab'' key to move to the ''Idle stats'' page.  You may need to expand the size of your terminal to see the section near the bottom marked ''GPU''.  If the stats show the system is remaining at 100% Powered On, you are currently affected.  If the stats show the system is mostly in an rc6 sleep mode, you are currently not affected.
=== Reboot fails after live installation ===
# You can see the amount of time spent in rc6 (or a deeper sleep mode) by running ''cat /sys/class/drm/card0/power/rc6_residency_ms'' -- if the number is stuck at 0, you are currently affected.  If the number is rising steadily, you are currently not affected.  Note, you may want to also check one of the other residency numbers.
<small>[[#reboot-after-live|link to this item]] - [[rhbug:857076|Bugzilla: #857076]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
You may want to add the parameter ''i915.i915_enable_rc6=1'' to your kernel boot parameters in ''/boot/grub2/grub.cfg'' to ensure rc6 is enabled, but this does not fix the problem.  Fedora 18 is now on the kernel 3.8 series, where this bug was expected to be fixed: however, some reporters have indicated that this bug may still be partially present in 3.8 kernels.


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|lenovo-nvidia-hang}}
=== Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420) ===
<small>[[#lenovo-nvidia-hang|link to this item]] - [[rhbug:752613|Bugzilla: #752613]] [https://bugzilla.kernel.org/show_bug.cgi?id=43054 Kernel bugzilla: #43054]</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.
Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 17 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.


Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the [http://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io VT-d advanced virtualization feature], the [https://en.wikipedia.org/wiki/X2APIC X2APIC level APIC], and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.


{{Anchor|debug-kernel}}
So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter ''nox2apic''. In this way, you should be able to determine which of the features you want to use.
=== The system is very slow ===
<small>[[#debug-kernel|link to this item]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.


Fedora ships a kernel with debugging options enabled during the Alpha release. This allows us to get useful information about various hardware problems, but slows down the system performance substantially. It influences all areas of the system, like CPU performance, HDD performance, graphics rendering performance and others. More information are provided in [[KernelDebugStrategy]], together with a guide how to check whether your kernel has debugging options enabled and how to find and install a non-debug kernel.
=== Atheros AR8161 based network cards/chipsets are not usable, due to missing ALX kernel module===
<small>[[Common F18 bugs#Atheros-NIC-Problem-ALX-missing|link to this item]] - [[rhbug:842367|Bugzilla: #842367]]</small>


Fedora 18 Beta will not include a debug kernel and the performance will raise considerably.
04:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 10)


The alx kernel module is not available in the current Fedora 18 kernels. It is also unlikely, that a newer compat-drivers package will be merged.
Unfortunately, to make this work, the kernel module will have to be compiled from source.


{{Anchor|nvidia-render-problems}}
'''WARNING: This might not be for the faint hearted, although not technically very difficult, as long as there are no problems'''
=== Problems with start or display of login manager or desktop on NVIDIA graphics adapters ===
<small>[[#nvidia-render-problems|link to this item]] - [[rhbug:857300|Bugzilla: #857300]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
'''THIS ONLY WORKS FOR THE 3.8 KERNEL BRANCHES, PLEASE UPDATE TO A NEWER KERNEL BEFORE PROCEEDING'''


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.
To install the alx kernel module from the compat-drivers tar ball, do the following (Note: Tested with compat-drivers-2013-02-20-u.tar.bz2 only):


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.
'''Please run these commands as your normal user!!!'''
# cd ~ (Change to your home directory)
# wget http://www.kernel.org/pub/linux/kernel/projects/backports/2013/02/20/compat-drivers-2013-02-20-u.tar.bz2
# tar -xjf compat-drivers-2013-02-20-u.tar.bz2
# cd compat-drivers-2013-02-20-u
# ./scripts/driver-select alx  (Note the ./ it is important!)
# make
# su    (Become root in current directory to install and load the module)
# make install
# modprobe alx


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:
'''To compile the source code for the kernel module, prerequisites are: kernel-devel,kernel-headers, gcc, make'''
<pre>su -c 'yum --enablerepo=updates-testing update kernel'</pre>


'''To install the requirements: yum install kernel-devel kernel-headers gcc make'''


{{Anchor|qxl-unlock-crash}}
After you have updated the kernel, you will have to repeat some of the above steps.
=== GNOME crashes when unlocking screen (usually in a KVM) ===
<small>[[#qxl-unlock-crash|link to this item]] - [[rhbug:856256|Bugzilla: #856256]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
#cd compat-drivers-2013-02-20-u
#make clean
#make
# su    (Become root in current directory to install and load the module)
# make install
# modprobe alx


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.
== Software issues ==


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.
{{Anchor|pk-empty-cat}}
=== Empty categories in the Software manager ===
<small>[[#pk-empty-cat|link to this item]] - [[rhbug:822509|Bugzilla: #822509]]</small>


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.
If you install GNOME desktop environment and run ''Software'' application, all the categories might appear empty. You need to manually refresh the software index by going to the application menu and clicking on ''Refresh Package Lists''. After this operation is complete, the categories should be populated. The exception is ''<Something> desktop'' categories, which seem to be empty all the time.


Some testing suggests that updating to the latest GNOME packages from the updates-testing repository may resolve this issue.
{{Anchor|gnome-layout-switch}}
=== GNOME does not have a default keyboard shortcut for switching keyboard layout, does not respect the X layout switch shortcut configuration, and cannot configure modifier-only shortcuts ===
<small>[[#gnome-layout-switch|link to this item]] - [[rhbug:873849|Bugzilla: #873849]]</small>


The version of the GNOME desktop installed in Fedora 18 does not include a default keyboard shortcut for switching between multiple keyboard layouts, though you can do so graphically via the menu in the top-right hand corner of the screen. The GNOME Control Center's Keyboard utility lets you configure shortcuts for 'Switch to next source' and 'Switch to previous source', but does not allow these to consist entirely of so-called 'modifier' keys, which is the most common type of shortcut to use for this function. Also, if you configure a layout switch shortcut at the X level either manually or via the Fedora system installer (which is capable of configuring a keyboard layout switch shortcut), GNOME will not respect it.


{{Anchor|packagekit-import-gpg}}
To work around these problems, you can use the {{package|gnome-tweak-tool}} utility. If you do not have it installed, install it with PackageKit or the command {{command|su -c 'yum install gnome-tweak-tool'}}. Then run it - it is present in the Overview under the name ''Tweak Tool'' - and click on ''Typing''. The very last setting in this menu, 'Modifiers-only input sources switcher shortcut', lets you choose one of several commonly-used shortcuts for this purpose.
=== PackageKit-based package management tools cannot import Fedora GPG key ===
<small>[[#packagekit-import-gpg|link to this item]] - [[rhbug:856225|Bugzilla: #856225]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
{{Anchor|encrypt-timeout-rescue}}
=== System will drop to rescue mode if encryption password not entered after some time ===
<small>[[#encrypt-timeout-rescue|link to this item]] - [[rhbug:868421|Bugzilla: #868421]]</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).
If you install Fedora 18 with all or some system partitions encrypted, then if you do not enter the encryption password for an encryption partition when prompted at boot, after several minutes the system will drop to rescue mode. It ought to wait indefinitely for password entry. If you encounter this problem, you can simply reboot from the rescue mode (use <code>reboot</code> command) and enter the password in time on the next boot attempt. Your data will not be endangered.


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.
{{Anchor|VT-not-unicode}}
=== Virtual terminals are not put into the unicode mode, breaking non-ASCII characters ===
<small>[[#VT-not-unicode|link to this item]] - [[rhbug:889710|Bugzilla: #889710]]</small>


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.
If you switch to a virtual terminal (using {{key press|Ctrl|Alt|Fx}}), and run some commands, some non-ASCII characters might be displayed incorrectly (mangled). The issue is still being investigated, but running <code>unicode_start</code> beforehand seems to fix the issue for that particular terminal. This does not affect graphical terminals, like GNOME Terminal.


A fix for this issue has been identified, but not yet incorporated into a Fedora package. This should be done soon.
{{Anchor|kernel-debuginfo}}
=== Kernel debuginfo quality problems affect systemtap, probe-perf, etc. ===
<small>[[#kernel-debuginfo|link to this item]] - [[rhbug:896741|Bugzilla: #896741]]</small>


Running some systemtap scripts or other kernel-debugging-oriented tools may result in function parameter-resolution problems, due to a change in the way the kernel is compiled.  It has started using <code>-mfentry</code> for function-tracing instrumentation, which triggers a latent debuginfo generation problem in gcc.  Using probes associated with function interiors (i.e., by file:line number or +relative line number syntaxes in systemtap) may make some of these scripts work.


{{Anchor|virt-cursor-jump}}
{{Anchor|slow-keys}}
=== Cursor frequently jumps to the edges of the screen, triggering overview in GNOME, especially in virtual machines ===
=== Keyboard "dies" (becomes unresponsive) ===
<small>[[#virt-cursor-jump|link to this item]] - [[rhbug:852841|Bugzilla: #852841]]</small>
<small>[[#slow-keys|link to this item]] - [[rhbug:816764|Bugzilla: #816764]]</small>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
Fedora 18's X server has a feature called "slow keys" which can engage when you hold down the Shift key for more than 10 seconds.  On some window managers such as XFCE there is no visual notification when this happens.  The bug link gives various possible remedies.


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|packagekit-signed-untrusted}}
=== PackageKit cannot install packages signed with an untrusted key ===
<small>[[#packagekit-unsigned|link to this item]] - [[rhbug:911442|Bugzilla: #911442]]</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.
Due to a bug, Fedora 18's PackageKit-based package management tools (which includes the default graphical tools for both GNOME and KDE desktops) cannot install packages that are signed with a key that is not currently in the trusted key list. PackageKit should allow you to install such packages after providing additional authentication. You may particularly notice this when attempting to install popular third-party packages or enable commonly-used third-party repositories, but it should never affect installation of official Fedora packages, as these should always be signed with a trusted key.


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.
To workaround this problem, if you are sure you want to install such a package, you can use the console command {{command|su -c 'yum --nogpgcheck install package.rpm'}}.


{{Anchor|update-notification-online}}
=== "Updates available" notification runs online updater ===
<small>[[#update-notification-online|link to this item]] - [[rhbug:863592|Bugzilla: #863592]]</small>


{{Anchor|grub-edit-font}}
Fedora 18 introduced a feature called [[Features/OfflineSystemUpdates|offline system updates]]. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18, at least when using GNOME. However, the feature's implementation is somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.
=== 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>


<span style="color:green">'''This problem has been fixed in Fedora 18 Beta.'''</span>
This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 18, and you can use the online update mechanism as safely in Fedora 18 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.


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.
If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.


A fix for this issue has been identified, and will be a part of the next grub2 package released for Fedora 18.
[[Category:Common bugs]]

Latest revision as of 23:59, 14 March 2018

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.

Release Notes

Read the F18_release_announcement and the Fedora 18 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)


Resolved issues

PackageKit could not install unsigned packages

link to this item - Bugzilla: #890616

Due to a bug, Fedora 18's PackageKit-based package management tools (which includes the default graphical tools for both GNOME and KDE desktops) initially could not install packages that are not signed. PackageKit should allow you to install such packages after providing additional authentication. You may particularly have noticed this when attempting to install popular third-party packages or enable commonly-used third-party repositories, but it should never affect installation of official Fedora packages, as these should always be signed with a trusted key.

This issue was fixed in the updated PackageKit-0.8.7-1.fc18 package. To solve the issue, update your Fedora 18 installation as usual. You should no longer encounter this issue after updating to that version or later of PackageKit.

Internal map files in ypserv could become unreadable after upgrade

link to this item - Bugzilla: #896612

Package ypserv started using Tokyo Cabinet to store map files instead of GDBM, which could no longer be used because of license issues. Rebuilding of maps during upgrade doesn't have to be successful every time, because there is not enough information to do so.

This issue is believed to have been fixed in the updated ypserv-2.29-8.fc18 package. To solve the issue, update your Fedora 18 installation as usual. You should no longer encounter this issue after updating to that version or later of ypserv.

Installation issues

Media consistency check can't be skipped, its output is unhelpful

link to this item - Bugzilla: #891548 Bugzilla: #891551

The installation medium is checked for errors during boot be default. The consistency check says Press [Esc] to abort check., but if you try to skip it, lots of errors are printed and you end up in an emergency mode. Use reboot command or hard-reset the machine. It is recommended to let the consistency check finish, but if you really want to skip it, boot the installer using Install Fedora menu item instead of Test this media & install Fedora.

If your media is corrupted, you will also receive lots of cryptic messages and end up in an emergency mode. The output will contain It is not recommended to use this media somewhere in the middle (see screenshot). The flood of error messages might be confusing, but the main message is clear - your media was either corrupted in the download process (check its checksum) or in the burning process (try to burn it again).

Automatic login does not work on Desktop Live image

link to this item - Bugzilla: #854722

When you boot the Fedora 18 Desktop Live image, you will not be automatically logged in to the desktop, as was the case in previous releases and as is intended. The login screen will appear with 'Live System User' as the only available user account: clicking this user will log you into the live system, which will then work as usual. There are no further consequences of this bug beyond the minor inconvenience.

Text installation sets POSIX locale

link to this item - Bugzilla: #891379

If you perform the installation in the text mode, the system will have a POSIX locale enabled by default. That can break some programs that expect unicode-enabled environment. You can change the default locale after installation by editing /etc/locale.conf and setting LANG="en_US.UTF-8" (or other locale).

Installer crashes after selecting "Malay (Malaysia)" language

link to this item - Bugzilla: #893026

If you boot the installer and select Malay (Malaysia) at the language selection screen, the installer crashes immediately after clicking the Continue button. The work-around is to start the installer in English and add Malaysian keymap manually (if you need it). In the installed system you can then change the default language using graphical configuration tools in your desktop environment or by editing /etc/locale.conf. The Malaysian translation of the Fedora 18 installer is in any case very very incomplete, so in practice you would need to be able to read English to install anyway. We apologize to Malaysian-speaking users for this error.

Installer does not automatically set up multiple keyboard layouts and switch command

link to this item - Bugzilla: #892110

Keyboard layout configuration has changed substantially between Fedora 17 and Fedora 18. This may catch speakers of some languages off guard.

In Fedora 17 and earlier versions, Fedora had sophisticated handling of a fairly small range of languages and keyboard layouts. The installer, and Fedora's keyboard configuration tool, were aware of the 'correct' configurations for a given range of keyboard types. In particular, the installer was aware of several types of keyboard for which it should configure both a 'native' layout and the U.S. English layout, and a command to switch between them. This applies to keyboards such as Russian (and many other Cyrillic keyboards) where the 'native' layout does not provide the ability to input Roman characters (and other commonly-used ASCII characters). Users of such layouts are used to switching between their native layout and the U.S. English layout to input Roman characters.

Maintaining this sophisticated handling was a development burden, though, and it made it hard to offer the full range of available keyboard layouts, and it did not offer the ability to configure more 'unusual' combinations of layouts. So in Fedora 18, the 'sophisticated' handling has been removed, and the installer now simply offers a fairly generic interface that offers all available keyboard layouts and lets you enable as many of them as you like.

On the very first screen of the installation process, where you select your language, there is a checkbox marked "Set keyboard to default layout for selected language". It is natural to assume that this checkbox does something similar to the previous 'sophisticated' behaviour: however, it does not, exactly. It just uses a fairly simple algorithm to try and pick the single keyboard layout whose name most closely matches the name of the language you selected. It will never configure more than one layout. So picking the Russian language and checking this box will only configure the Russian layout, it will not also configure a U.S. layout. This applies to all layouts where it is 'normal' to also configure the U.S. layout: just checking that box and not performing any further keyboard configuration is likely to give you a result you do not want.

If you do not check the box, the behaviour may also not be exactly what you would expect. The installer will still attempt to guess what keyboard layout most closely matches the name of the language you selected. It will then add both that layout and the U.S. layout, with the U.S. layout as default, and alt-shift as the key combination to switch between them.

If you need more than one layout, whether you check the box or not, be sure to visit the Keyboard screen in the installer and add any additional layouts you need. Also make sure you configure a command to switch between layouts: you may well need to use it during the user creation stage of installation. Previous Fedora releases automatically configured 'both shift keys' as the keyboard command to switch layouts, but in Fedora 18 you can choose between several commands in the Keyboard screen.

If you become stuck at the user creation stage without access to the U.S. layout, you can try and workaround the problem from a text mode boot, but it may be simplest to restart installation and make sure you add the U.S. layout and a layout switch command.

Keyboard layout testing and selection during installation does not work as expected

link to this item - Bugzilla: #854557

On the Keyboard screen during Fedora 18 installation there is a text entry box labelled 'Test the selected layout below:'. This label is confusing. The box does not let you test the layout currently highlighted in the list on the left hand side of the screen, but the layout that is active. There is no indicator for the active layout, so it is not easy to know which layout is active. The layout that was in the list when you first entered the screen will stay active until you do one of two things: remove it, or configure a layout switch key combination and use it. So if the English (U.S.) layout was in the list when you first entered the screen, if you add the French (French) layout, it will not be active. If you highlight it in the list, it will not be active. If you move it to the top of the list, it will still not be active. But if you remove the English (U.S.) layout, French (French) will become the active layout. Alternatively, if you add French (French), then click the 'Options' button, pick one or more keyboard layout switch combination(s), click 'OK', and then press a layout switch combination you just configured, French (French) will become active: press it again, and English (U.S.) will be active again. This should be reflected in the test box.

As there is no indication of the current active layout throughout installation, if you are configuring multiple layouts, we recommend you ensure the layout you wish to use for the rest of the install process is active using the test box before leaving the Keyboard screen, and then do not switch layouts until installation is complete.

DVD install does not include LibreOffice by default

link to this item - Bugzilla: #880653

Though it has historically been part of the default Fedora package set, the LibreOffice office suite is not included in a default DVD or network installation of Fedora 18 (it is included in the Desktop live image installation, though, where it was not before). This is partly an oversight and partly due to technical limitations which prevented it being included by default but de-selectable for those users who do not want it.

If you wish to have LibreOffice installed as part of your DVD or network installation, make sure to enter the Software Selection screen and check the LibreOffice option on the right-hand side.

Disk encryption with national keyboard layout sometimes doesn't work

link to this item - Bugzilla: #743281

The installer offers the possibility to encrypt your disk partitions. If you chose a non-US keyboard layout earlier in the installation process, there is a possibility that if you encrypt your disk with some language-specific characters you might not be able to decrypt the disk during system boot. This concerns only some languages and only some keyboard layouts, but the full list of affected layouts is unknown.

The recommended approach is to use ASCII-only characters in your disk encryption password, or (this is the safest approach) select the default US keyboard layout in the installation process, and set your custom keyboard layout only inside the desktop session.

Insufficient system memory during installation might appear as a packaging error (or some other error)

link to this item - Bugzilla: #893987

The required amount of system memory (RAM) for installation might vary depending on the installation options you choose. If you receive an error message during installation saying There was an error installing the xyz package. This is a fatal error and installation will be aborted. (screenshot) - or any other error which seems difficult to trace back to a definite source - there is some chance that this error occurred due to insufficient system memory. Either increase the system memory, or set up a larger swap partition and repeat the installation.

Windows 8 installed in UEFI mode are not present in the Fedora bootloader menu

link to this item - Bugzilla: #873207

If you install Windows 8 in the UEFI mode and then install Fedora 18 into dual-boot, Windows will not be present in the bootloader menu (GRUB) that appears right after your computer starts. This is not a bug per se, UEFI systems handle operating system selection in a different way. Your computer should support a hotkey that triggers an OS selection dialog before GRUB even loads. In this dialog you should see the Windows system. Your OS preference should also be configurable in BIOS.

UEFI boot of Fedora 18 CD or DVD disc on Mac hardware falls to a prompt

link to this item - Bugzilla: #893839

If you boot a Fedora 18 CD or DVD disc - an actual silver disc - via UEFI on an Apple Mac system, instead of reaching the normal boot menu and hence the Fedora installer, it will drop to a bootloader prompt.

This bug does not affect boot of Fedora 18 CD or DVD images written to a USB stick using one of the supported methods, so the easiest way to avoid this bug on Mac hardware is simply to boot the install from a USB stick rather than an actual optical disc. If you must use an optical disc for some reason, you can cause the installation to proceed from the prompt by entering this command: configfile (cd0,apple3)/EFI/BOOT/grub.cfg.

Partitions on Solaris 10-formatted disks may appear as free space to installer

link to this item - Bugzilla: #869482

It has been reported that the Fedora 18 installer may not correctly recognize disks formatted by the Solaris 10 installer: it may see partitions on these disks as free (unformatted) space. This may be due to the Solaris 10 installer using an unusual GPT format. If you have disks formatted by the Solaris installer that contain data of value to you, exercise caution in installing Fedora 18. See the bug report for more details.

Difficult to install to free space within an existing LVM volume group (VG)

link to this item - Bugzilla: #892269

It can difficult to install to free space within an LVM volume group (VG) using the custom partitioning mode of Fedora 18.

This applies whether you begin the partitioning process with free space within an existing volume group, or you plan to remove or shrink existing LVs (but not to remove the entire volume group) as part of your partitioning approach.

When you come to create the new mount points, after having scheduled removal or shrink of existing LVs if necessary, you will find that the installer's free space counter does not account for the free space within the existing VG - it will show zero, or a very small number representing the available space outside the VG. If you then create a new volume and leave its size unspecified, the installer will create a new LV within the existing VG, but only of the size it believed was available as 'free space' (so, uselessly tiny). You will not be able to make the new LV any larger, even though there really is space available within the VG.

It is possible to make this work, however. What you have to do is specify the correct intended size for each new volume as you create it. The installer will allow this. So if you have 100GB of free space within your existing VG, you could, say, create a / mount point and specify its size as 30GB, then create a /home mount point and specify its size as 70GB. The installer will allow this and will create these as LVs within the existing VG. Note that you will not be able to increase the size of an LV after you 'create' it, within the installer - even if there really is space available within the VG. However, you get as many tries as you like, when dealing with this bug - if you get it wrong, you can just remove the LVs and try again, as in the new installer, no operations are actually performed until you complete the partitioning step and start the installation. All the 'creations' and 'removals' are just planned operations. So don't be afraid to fiddle around until you nail it.

Crash when installing to disks containing identically-named LVM volume groups (VGs)

link to this item - Bugzilla: #887539

Testing indicates that the Fedora 18 installer may crash if you attempt an install to a system containing two or more identically named LVM volume groups (VGs) - even if you choose to delete one or both as part of the installation process.

If you are affected by this problem, there are several possible workarounds. Most simply, if you only need to install to one of the disks containing identically-named VGs, you can leave the other disk(s) out of the installation target disk set (selected on the first page of the Installation Destination spoke), or temporarily remove the other disk(s) from the system. If you need to keep the offending disks connected and use them as installation targets, you will need to remove or rename one of the VGs using another tool before beginning the Fedora installation.

Install to small btrfs volume may fail or crash

link to this item - Bugzilla: #893331, Bugzilla: #893758

Two related bugs have been discovered in Fedora 18 installation when installing to a small btrfs volume. The Fedora installer attempts to check whether your planned disk layout will be big enough to accommodate your chosen package set, but this calculation is not strict enough for btrfs installations: it will allow installation to proceed in some cases even if there is actually not quite enough space available for the installation to succeed. This affects only quite a narrow 'band' of cases - for instance, in the reported test system, the installer would refuse to install to a 7GB disk due to lack of space, and install to a 9GB disk would succeed. An 8GB disk would trigger the bug.

To ensure you do not run into this problem, if installing to a btrfs volume, try and ensure there will be sufficient space for the installation to succeed. You are unlikely to have trouble unless you are installing to a fairly small disk.

If you do encounter this bug, you will find the failure case can be quite unpredictable - this is a result of the other related bug, which is that btrfs' behaviour on running out of space can vary, and result in different effects in the Fedora installer. It is very likely that it will crash in some way, but the precise nature of the crash may vary.

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: Anaconda Boot Options and [1]. 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.

Installation source shows 'Nothing selected' for network installation

link to this item - Bugzilla: #873468

It is possible that the Fedora 18 installer may fail to correctly set the default remote package source on occasion when booting the network installation image. Instead of showing 'Closest mirror' and 'GNOME Desktop', the 'Installation Source' and 'Software Selection' entries on the installer hub/home screen will show 'Nothing selected'. This will prevent installation from starting until it is rectified. Several possible causes of this bug were eliminated during development of Fedora 18, but it appears the bug may still occur in some rare cases.

If you are affected by this bug, to work around it, you can either just reboot (it will often succeed on a second try), or enter the 'Installation Source' spoke, change the remote source URL to any specific address at all (it does not have to be valid), return to the hub screen, return to the 'Installation Source' spoke, change the source back to 'Closest mirror', and return to the hub screen once again.

Network installation incorrectly refreshes installation source for WiFi or slow network card

link to this item - Bugzilla: #892665

If you boot the network installation image (netinst.iso) on a machine with just a wireless network connection, or a very slow wired network card, the installer may say Nothing selected below the Installation source icon and it will be marked as a problematic state (see screenshot). However, just opening the Installation Source dialog and ensuring that Closest Mirror is selected doesn't help. You need to manually trigger metadata refresh by first changing the network source to e.g. http://abc (hit Done), and only then switching it back to Closest Mirror.

You can also use updates.img from http://rvykydal.fedorapeople.org/updates.nothingselected.img to fix this issue. Read Anaconda/Updates.

Garbage text appears on installer's network configuration screen

link to this item - Bugzilla: #892122

A bug in the Fedora 18 installer can lead to some unexpected text appearing on the network configuration screen and rendering it difficult or impossible to use. The text appears in English, and it is a set of headers associated with a git commit: this image is an example of the bug in action.

This appears to happen with some non-English languages. Possible workarounds are installing in English, configuring the network prior to the start of installation from the live environment (if using the live installer) or with kernel parameters (if using the traditional installer), or attempting to access the 'hidden' parts of the screen using keyboard navigation.

Cannot connect to WPA / WPA2 Enterprise network during installation

link to this item - Bugzilla: #892896

The Fedora 18 installer is not capable of connecting to WPA / WPA2 Enterprise wireless networks for network installation. This is a temporary limitation and this capability should be added for future Fedora releases.

Installer can become apparently 'stuck' in custom partitioning mode due to window focus problems

link to this item - Bugzilla: #875921

Occasionally, the Fedora 18 installer can become apparently 'stuck' in custom partitioning mode, after opening several subsidiary dialogs. The typical manifestation of this bug is that you hit the button to add a new mount point or to change the properties of a mount point, the subsidiary dialog does not appear, and the installer seems to stop responding: the cursor will still move and change shape depending on what it is hovering over, but clicks will appear to have no effect.

This is a window focus problem - the dialog has in fact appeared, but is behind the main anaconda window but still focused and taking all mouse/keyboard input. The issue can be resolved quite simply by pressing the Esc key, which will close the rogue dialog. This will restore normal behaviour. The bug has no further consequences.

Installer crashes if you need a network installation and have a local kickstart and a slow network card

link to this item - Bugzilla: #892669

If you perform a kickstarted network installation and serve the kickstart locally (from a local partition, not from online location) on a machine with a slow network card, the installer will crash if it starts earlier than the network is set up.

The solution is to serve the kickstart from an online location. That will set up the network very early in the boot process, before the installer is started.

Installer no longer attempts to infer whether hardware clock is set to local time or UTC, or allows you to configure this

link to this item - Bugzilla: #881403

In previous Fedora releases, the installer offered a configuration option to specify whether the system's hardware clock was set to local time or to UTC. It would also attempt to guess the correct setting, defaulting to 'local time' if a Windows installation was found, or UTC if not (these are the most likely cases). In Fedora 18, the configuration option is no longer present, and the heuristic to try and determine the most likely case was also lost.

The most likely consequence of this bug is that, if you do have a Windows installation, your system clock will be incorrect every time you switch operating system, as Windows will expect it to be set to local time, but Fedora will expect it to be set to UTC.

The configuration option was removed intentionally as it was considered confusing, but the removal of the heuristic was not intentional. It will be restored in future Fedora releases. You can change this setting after installation using the system-config-date utility.

Croatian keyboard layout missing from installer

link to this item - Bugzilla: #883555

The Fedora 18 installer's Keyboard spoke is intended to offer all Xkb keyboard layouts present in Fedora, but testing has shown that the Croatian layout and its variants are missing from the list. These layouts are available for selection via desktop keyboard configuration tools after installation. We have not yet identified why the installer does not recognize these layouts as being available, but we will aim to resolve the issue for future Fedora releases.

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.

Quitting advanced user creation tool during firstboot quits firstboot

link to this item - Bugzilla: #884833

On first boot after installing Fedora 18 (and any Fedora release), a small utility called 'firstboot' is run, which allows you to create a user account and configure a few other options. When creating a user account, there is an option to run an 'advanced' tool for creating more complex accounts. This option actually runs the external application system-config-users. If you then quit this application by opening the File menu and clicking on Quit, it will close the whole firstboot process and proceed immediately to the login screen. If you instead close the application by hitting the X at the corner of the window, the firstboot process will continue.

Testing shows that any user accounts you created in the 'advanced' tool will exist and function correctly even if you hit this bug, and the only subsequent step in the firstboot tool is network time configuration, which you can do from desktop configuration tools at any time, so the impact of this bug is not very high. If you run into it, do not worry: you can safely use the installed system.

Live installation on machines with WWAN network card freezes

link to this item - Bugzilla: #893892

When installing from Live CD on computers with WWAN network cards (e.g. UTMS, GSM), installer can freeze on Welcome screen after hitting Continue button. To work around this issue, run installation from terminal using liveinst command with updates image:

su -c "liveinst --updates=http://rvykydal.fedorapeople.org/updates.wwan.img"

The problem is caused by missing /etc/sysconfig/network-scripts/ifcfg-<iface name> file (e.g. /etc/sysconfig/network-scripts/ifcfg-wwan0), so another work-around would be to create the file prior to the installation either manually or using Network Settings of Live environment by saving default configuration of the WWAN device.

Live installation crashes if network configuration is modified and saved prior to installation

link to this item - Bugzilla: #895900

If you use a Fedora 18 live image, change the configuration of any network device, save the changes, and then launch the live installer, you may find the installation fails with the error No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-foo (where 'foo' may be anything).

This bug is actually very similar to the one above, and the same updates image can be used to avoid it, following the same instructions. Alternatively, if you really need to edit the network configuration outside of the installer, you can work around the bug by launching the installer but leaving it on the Welcome screen while you configure the network adapter, then continuing with the installation.

Installations that specify repositories with spaces in their names fail

link to this item - Bugzilla: #885139

The version of yum included with Fedora 18 had a problem when printing an informational message for repositories with spaces in their names. This problem can cause the installer to crash when handling an installation that contains such a repository. The error message would be TypeError: not enough arguments for format string.

If you do a kickstart installation of Fedora 18 that specifies an additional repository, it is safest to ensure that the repository name does not contain any spaces, to avoid being affected by this bug.

Bootloader password is required on each boot

link to this item - Bugzilla: #840160

If you set a bootloader password during installation of Fedora 17 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.

Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.

Upgrade issues

Upgrade doesn't start for systems with more than one encrypted partition

link to this item - Bugzilla: #896010 Bugzilla: #910326

This issue affects systems with multiple encrypted partitions (a single encrypted LVM with many logical volumes does not count as multiple encrypted partitions). When you run FedUp on such a system and then reboot into System Upgrade boot menu, you are asked for the disk decryption password and then the system hangs and does nothing (or alternatively, you are placed in a maintenance mode after a while). Ctrl+Alt+Del combination should reboot your computer and you should be able to boot back into Fedora 17 just fine.

One of the fixes that might work is to append "enforcing=0" to the kernel command line.

An updated fedup package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update fedup'

from the Fedora 17 system before beginning the upgrade to Fedora 18. Also, ensure the Fedora 17 system is fully up to date - including the systemd package - before beginning the upgrade.

Hardware issues

Intel Sandybridge GPU eats power after resume from suspend

link to this item - Bugzilla: #866212

Starting in the 3.6 kernel, there is a misbehavior in the Intel GPU code that affects Sandybridge systems, including but not limited to many newer IBM ThinkPads. After resuming from suspend, sometimes the GPU is unable to return to its sleep (rc6) state when not busy. This means it will quickly consume power and lower battery life.

Unfortunately, the problem is intermittent and may or may not happen after any specific resume from suspend. To diagnose the problem, you can do one of the following:

  1. Install the powertop package and run it as root (su -c powertop). Use the Tab key to move to the Idle stats page. You may need to expand the size of your terminal to see the section near the bottom marked GPU. If the stats show the system is remaining at 100% Powered On, you are currently affected. If the stats show the system is mostly in an rc6 sleep mode, you are currently not affected.
  2. You can see the amount of time spent in rc6 (or a deeper sleep mode) by running cat /sys/class/drm/card0/power/rc6_residency_ms -- if the number is stuck at 0, you are currently affected. If the number is rising steadily, you are currently not affected. Note, you may want to also check one of the other residency numbers.

You may want to add the parameter i915.i915_enable_rc6=1 to your kernel boot parameters in /boot/grub2/grub.cfg to ensure rc6 is enabled, but this does not fix the problem. Fedora 18 is now on the kernel 3.8 series, where this bug was expected to be fixed: however, some reporters have indicated that this bug may still be partially present in 3.8 kernels.

Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420)

link to this item - Bugzilla: #752613 Kernel bugzilla: #43054

Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 17 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.

Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the VT-d advanced virtualization feature, the X2APIC level APIC, and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.

So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter nox2apic. In this way, you should be able to determine which of the features you want to use.

The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.

Atheros AR8161 based network cards/chipsets are not usable, due to missing ALX kernel module

link to this item - Bugzilla: #842367

04:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 10)

The alx kernel module is not available in the current Fedora 18 kernels. It is also unlikely, that a newer compat-drivers package will be merged. Unfortunately, to make this work, the kernel module will have to be compiled from source.

WARNING: This might not be for the faint hearted, although not technically very difficult, as long as there are no problems

THIS ONLY WORKS FOR THE 3.8 KERNEL BRANCHES, PLEASE UPDATE TO A NEWER KERNEL BEFORE PROCEEDING

To install the alx kernel module from the compat-drivers tar ball, do the following (Note: Tested with compat-drivers-2013-02-20-u.tar.bz2 only):

Please run these commands as your normal user!!!

  1. cd ~ (Change to your home directory)
  2. wget http://www.kernel.org/pub/linux/kernel/projects/backports/2013/02/20/compat-drivers-2013-02-20-u.tar.bz2
  3. tar -xjf compat-drivers-2013-02-20-u.tar.bz2
  4. cd compat-drivers-2013-02-20-u
  5. ./scripts/driver-select alx (Note the ./ it is important!)
  6. make
  7. su (Become root in current directory to install and load the module)
  8. make install
  9. modprobe alx

To compile the source code for the kernel module, prerequisites are: kernel-devel,kernel-headers, gcc, make

To install the requirements: yum install kernel-devel kernel-headers gcc make

After you have updated the kernel, you will have to repeat some of the above steps.

  1. cd compat-drivers-2013-02-20-u
  2. make clean
  3. make
  4. su (Become root in current directory to install and load the module)
  5. make install
  6. modprobe alx

Software issues

Empty categories in the Software manager

link to this item - Bugzilla: #822509

If you install GNOME desktop environment and run Software application, all the categories might appear empty. You need to manually refresh the software index by going to the application menu and clicking on Refresh Package Lists. After this operation is complete, the categories should be populated. The exception is <Something> desktop categories, which seem to be empty all the time.

GNOME does not have a default keyboard shortcut for switching keyboard layout, does not respect the X layout switch shortcut configuration, and cannot configure modifier-only shortcuts

link to this item - Bugzilla: #873849

The version of the GNOME desktop installed in Fedora 18 does not include a default keyboard shortcut for switching between multiple keyboard layouts, though you can do so graphically via the menu in the top-right hand corner of the screen. The GNOME Control Center's Keyboard utility lets you configure shortcuts for 'Switch to next source' and 'Switch to previous source', but does not allow these to consist entirely of so-called 'modifier' keys, which is the most common type of shortcut to use for this function. Also, if you configure a layout switch shortcut at the X level either manually or via the Fedora system installer (which is capable of configuring a keyboard layout switch shortcut), GNOME will not respect it.

To work around these problems, you can use the gnome-tweak-tool utility. If you do not have it installed, install it with PackageKit or the command su -c 'yum install gnome-tweak-tool'. Then run it - it is present in the Overview under the name Tweak Tool - and click on Typing. The very last setting in this menu, 'Modifiers-only input sources switcher shortcut', lets you choose one of several commonly-used shortcuts for this purpose.

System will drop to rescue mode if encryption password not entered after some time

link to this item - Bugzilla: #868421

If you install Fedora 18 with all or some system partitions encrypted, then if you do not enter the encryption password for an encryption partition when prompted at boot, after several minutes the system will drop to rescue mode. It ought to wait indefinitely for password entry. If you encounter this problem, you can simply reboot from the rescue mode (use reboot command) and enter the password in time on the next boot attempt. Your data will not be endangered.

Virtual terminals are not put into the unicode mode, breaking non-ASCII characters

link to this item - Bugzilla: #889710

If you switch to a virtual terminal (using Ctrl+Alt+Fx), and run some commands, some non-ASCII characters might be displayed incorrectly (mangled). The issue is still being investigated, but running unicode_start beforehand seems to fix the issue for that particular terminal. This does not affect graphical terminals, like GNOME Terminal.

Kernel debuginfo quality problems affect systemtap, probe-perf, etc.

link to this item - Bugzilla: #896741

Running some systemtap scripts or other kernel-debugging-oriented tools may result in function parameter-resolution problems, due to a change in the way the kernel is compiled. It has started using -mfentry for function-tracing instrumentation, which triggers a latent debuginfo generation problem in gcc. Using probes associated with function interiors (i.e., by file:line number or +relative line number syntaxes in systemtap) may make some of these scripts work.

Keyboard "dies" (becomes unresponsive)

link to this item - Bugzilla: #816764

Fedora 18's X server has a feature called "slow keys" which can engage when you hold down the Shift key for more than 10 seconds. On some window managers such as XFCE there is no visual notification when this happens. The bug link gives various possible remedies.

PackageKit cannot install packages signed with an untrusted key

link to this item - Bugzilla: #911442

Due to a bug, Fedora 18's PackageKit-based package management tools (which includes the default graphical tools for both GNOME and KDE desktops) cannot install packages that are signed with a key that is not currently in the trusted key list. PackageKit should allow you to install such packages after providing additional authentication. You may particularly notice this when attempting to install popular third-party packages or enable commonly-used third-party repositories, but it should never affect installation of official Fedora packages, as these should always be signed with a trusted key.

To workaround this problem, if you are sure you want to install such a package, you can use the console command su -c 'yum --nogpgcheck install package.rpm'.

"Updates available" notification runs online updater

link to this item - Bugzilla: #863592

Fedora 18 introduced a feature called offline system updates. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18, at least when using GNOME. However, the feature's implementation is somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.

This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 18, and you can use the online update mechanism as safely in Fedora 18 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.

If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.