This page documents common bugs in Fedora 16 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 F16 Alpha release announcement and the Fedora 16 release notes for specific information about changes in Fedora 16 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
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Installation issues
Attempting to upgrade a system with /var on a different partition or LV to / will fail
link to this item - Bugzilla: #748119
If you have your system set up with /var on a separate logical volume or partition to that used for the root filesystem (/), then anaconda will not find the RPM db in /var/lib/rpm/ and fail to offer the option to upgrade. This happens with preupgrade as well as upgrade from install media. One workaround is to copy the contents of /var/lib/rpm/ to the root filesystem volume. Anaconda will then detect your current installation and be able to upgrade it.
Cannot boot with /boot partition on a software RAID array
link to this item - Bugzilla: #750794
Attempting to boot after installing Fedora 16 with the /boot partition on a software RAID array will fail, as the software RAID modules for the grub2 bootloader are not installed. Having the /boot partition on a RAID array has never been a recommended configuration for Fedora, but up until Fedora 16 it has usually worked.
To work around this issue, do not put the /boot partition on the RAID array. Create a simple BIOS boot partition and a /boot partition on one of the disks, and place the other system partitions on the RAID array. Alternatively, you can install the appropriate grub2 modules manually from anaconda's console before rebooting from the installer, or from rescue mode. Edit the file /mnt/sysimage/boot/grub2/grub.cfg and add the lines:
insmod raid insmod mdraid09 insmod mdraid1x
Now run these commands:
chroot /mnt/sysimage grub2-install /dev/sda grub2-install /dev/sdb
Adjust the device names as appropriate to the disks used in your system.
Cannot install if two drives have BIOS boot partitions
link to this item - Bugzilla: #729640
If, while installing Fedora 16, you create a partition layout in which there are BIOS boot partitions on two different drives, the installer will crash with an error of the format IOException: Partition(s) 3 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. There is no known workaround for this issue beside avoiding such a partition layout.
Upgrade from Fedora 14 to Fedora 16 with preupgrade leaves bootloader in previous configuration
link to this item - Bugzilla: #737731
If you use the preupgrade utility to upgrade from Fedora 14 to Fedora 16, the bootloader configuration will be left in its previous state. This is due to preupgrade not recognizing that anaconda cannot 'update' the bootloader configuration in such an upgrade, due to the migration from grub to grub2 that should occur as part of the upgrade. This will result either in the system attempting to boot with a Fedora 15 kernel, or failing to boot entirely (depending on whether the previously-installed kernel is still present following the upgrade).
This issue should be resolved with an update to the Fedora 14 preupgrade shortly. We recommend waiting for this update or upgrading via the DVD or network install image, rather than using a non-fixed preupgrade package. You may also pre-upgrade first to Fedora 15, and from there to Fedora 16.
Incorrect partition type assigned to /boot partition on GPT-labelled disks
link to this item - Bugzilla: #746895
When formatting the installation disk with a GPT disk label (which Fedora 16 will usually do when a disk is being completely reformatted, unless you use the nogpt kernel parameter) and creating a /boot partition, the Fedora 16 installer will set an incorrect partition type on the partition: it will be marked as an EFI System partition. This happens because anaconda attempts to set the 'bootable' flag on the partition, but on GPT disks there is no such flag, and the request gets translated into a request to set the partition type to EFI System. In most cases this will have no practical consequences, but if you have another EFI-booted operating system installed on the same disk, it may be confused by the apparent presence of two EFI system partitions.
To work around any issues caused by this, use a GPT-capable partition editor such as parted to correct the partition type on the /boot partition.
No workable bootloader action in text mode upgrade
link to this item - Bugzilla: #742207
If you use the text mode of the Fedora installer to perform an upgrade from Fedora 15 to Fedora 16, there is no usable option at the stage where you are asked what to do with the bootloader. The update option cannot be used due to the switch from grub to grub2, and the skip option will often result in an unbootable system as the kernel(s) referenced in the bootloader configuration will no longer be installed.
The easiest workaround for this issue is to avoid using the installer's text mode, if you can. If you cannot avoid this, you should select Skip bootloader and then manually update the bootloader configuration from the installer shell (available on VT2) or from another OS (such as a live boot) following the upgrade process.
Installer doesn't ask for wifi password
link to this item - Bugzilla: #751139
If you want to install Fedora from network repositories and you have only a wireless network adapter available, you need to provide a password manually in order to connect to a secured wifi network. After the installer asks you which wireless network to connect to and you confirm your choice, another dialog called Network Connections pops up. In this dialog go to the Wireless tab, edit your chosen network a provide your password in the Wireless Security tab (WEP Passphrase or WPA Personal are most commonly used security protocols).
Hardware issues
UEFI install to Lenovo Ideapad S205 fails to boot
link to this item - Bugzilla: #748272
If you try to install Fedora 16 to a Lenovo Ideapad S205 booted via UEFI, the installed system will fail to boot. We do not yet have a complete understanding of this issue, but it appears the S205 may have a buggy UEFI implementation which prevents the efibootmgr tool from correctly writing an UEFI bootloader entry for Fedora. At present there is no known workaround for this issue. Installing in BIOS compatibility mode should avoid the problem, but it is not entirely clear from user reports and publicly available information whether the S205 actually has a BIOS compatibility mode and, if so, how to use it.
Software issues
Glibc may cause applications to crash with large groups
link to this item - Bugzilla: #750361
Groups with either a large number of users or simply a large number of characters forming the user list may have problems with the glibc shipped in the release. The symptoms of this will vary depending on how you store your group information. If using a file in /etc/group programs which attempt to access group information for a user in that group will crash. If using a local nss db, the group will simply fail to be added to the user's list of groups when the user logs in. The latter may be worked around by running "newgrp groupname". At this time, it's unknown how these bugs affect other nss backends.
Secondary group membership not correctly registered with non-disk backed user account backends
link to this item - Bugzilla: #750388
Due to a change in the default /etc/nsswitch.conf file, when using a non-file backed user account backend (as is common for remote authentication methods such as sssd), user's secondary group memberships are not correctly registered.
A test build that should resolve this problem is available from Koji: authconfig-6.1.16-2.fc16. If you are affected by this issue, please test this update and report your results to the bug report.
To resolve the issue manually, edit the file /etc/nsswitch.conf and remove the line:
initgroups: files
Starting GNOME Shell fails after upgrade from Fedora 15 with color profile installed
link to this item - Bugzilla: #741549
If you used the 
gnome-color-manager
The issue is caused by gnome-settings-daemon crashing when it encounters a color profile with an incorrect SELinux context: the correct context for color profiles changed between Fedora 15 and Fedora 16, but the upgrade process does not re-label existing profiles.
To resolve the issue, boot to a different desktop or to a console and run the command restorecon -r ~/.local/share/icc. After doing this, GNOME login should work correctly.
GNOME Shell uses excessive CPU time with System Monitor extension installed
link to this item - Bugzilla: #748241
When the
After a kernel update, Loading... message on boot refers to the wrong kernel
link to this item - Bugzilla: #732654
After you first install an updated kernel on a Fedora 16 system, the line which shows up briefly during the boot process - Loading (kernel version)... - will refer to the wrong kernel. This is because the grubby utility Fedora uses to update the bootloader configuration file does not correctly update this line.
The bug is entirely cosmetic: the correct kernel is loaded in all cases, only the message is incorrect. This issue will be resolved with an update to the