Common F18 bugs

In other languages: English (en) [edit]

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

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.