Common F16 bugs

Click here to set up this language box

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

Xfce power manager crashes on login

link to this item - Bugzilla: #736727

There was a bug in the xfce4-power-manager shipped with Fedora 16 which caused it to crash frequently, including on initial login, for many users. This issue has been fixed with an update, but you may still notice it on initial installation of Fedora 16 Xfce if you do not enable the updates repository during installation.

This issue was fixed in the updated xfce4-power-manager-1.0.10-2.fc16 package. To solve the issue, update your Fedora 16 installation as usual. You should no longer encounter this issue after updating to that version or later of xfce4-power-manager.

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 the Fedora 16 installer 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.

A fix for this problem is available as an update image for the installer. For more information on update images, see Anaconda/Updates. To use this updates image, pass the kernel parameter updates=http://clumens.fedorapeople.org/748119.img to the Fedora installer. You can edit the boot parameters after hitting the Tab key when the boot menu screen is shown, or if you are using preupgrade, you can also choose to edit /boot/grub/grub.conf and add the parameter after the preupgrade application has downloaded the update packages but before rebooting to complete the upgrade.

You can also manually workaround the issue by copying the contents of /var/lib/rpm/ to the root filesystem volume prior to attempting the upgrade. 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 over an existing RAID configuration

link to this item - Bugzilla: #729640

If you attempt to install Fedora 16 onto a disk which contains a RAID array, the installer may 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.

Currently the only known way to workaround the issue is to destroy the existing RAID array in some way, such as by wiping its metadata with mdadm --zero-superblock, prior to installing Fedora 16.

Error "you have not created a bootloader stage1 target device" appears in partitioning menu

link to this item - Bugzilla: #752063

Error message is shown when you try to create a new partition layout and don't create BIOS boot partition. It says "you have not created a bootloader stage1 target device". This obscure message wants to say, that user forget to create a BIOS boot partition. To avoid this, you have to create a new partition. It must be 1-2 MB large and file system type must be 'BIOS boot'.

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 14 kernel, or failing to boot entirely (depending on whether the previously-installed kernel is still present following the upgrade).

This issue is already resolved in the latest stable Fedora 15 preupgrade package, only Fedora 14 is still affected.

An updated preupgrade 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 preupgrade'

Upgrade from previous releases resets the enablement status of services

link to this item - Bugzilla: #752846

If you upgrade from a previous Fedora release, some services that you previously had enabled may be disabled and therefore they will not be started automatically on boot. This happens to services whose initscripts were converted to native systemd units. This is intentional. The rule for migration to systemd is to "start-over fresh" with default start and stop policy from the new package, and not to migrate what the user had previously configured. systemd provides a tool (systemd-sysv-convert --apply) to help do this conversion if you want after the package is updated. You can instead choose to inspect the services' enablement status manually by using systemctl list-unit-files and systemctl enable foo.service as needed.

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).

Disk encryption with national keymap often doesn't work

link to this item - Bugzilla: #743281

The installer offers a 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.

Must explicitly specify clearpart=none to use an existing disk layout in kickstart

link to this item - Bugzilla: #752216

Due to a bug in the Fedora installer, you must include either a clearpart or an autopart command in any Fedora 16 kickstart file, even if the disk layout you wish to use does not actually require existing partitions to be cleared or automatic partitioning to be done. So if you wish to re-use an existing partition layout, you must explicitly include the line clearpart=none in your kickstart, rather than relying on it as a default behaviour as you could in the past (and as the documentation indicates).

Minimum space for Desktop live install incorrectly calculated

link to this item - Bugzilla: #753400

The minimum required space for the root partition of a Fedora 16 live installation is incorrectly defined in the Fedora installer. The actual minimum size of the target partition for the Desktop live image is 4096MiB, but the installer will attempt to install to partitions that are somewhat smaller, and fail with the error RuntimeError: error copying filesystem!

There is no exact workaround for this issue: it is simply required that the target partition be 4096MiB or greater in size for a Desktop live installation. The required size varies for some spins: for the Sugar on a Stick spin it is 2048MiB, for instance.

If you must install to a smaller device than is possible with the live image you wish to use, you may try a network or DVD installation. If you select a suitably small package set, these installation methods will allow you to install to a smaller storage device.

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

Bash entry in /etc/shells disappears after update

link to this item - Bugzilla: #752827

Due to an error in the %postun script of bash-4.2.10-4.fc16, the version of Bash that was included in the Fedora 16 release images, the first time you update from that version of the package, the entry for bash in /etc/shells will be removed.

A fixed bash-4.2.10-5.fc16 has already been released. However, the %postun script from a given package version is run when that package version is removed, so it is in fact impossible to fix the broken script in the -4 package with an update, as it will always be the version of the script from the -4 package which is run when updating from that version.

The result is that this bug will always happen on the first update of the bash package after a fresh Fedora 16 installation, unless you enable the updates repository during installation and so get a fixed version of the package. We will attempt to produce a fix which reverses the effect of the broken script on update, in order to mitigate the problem.

There are several consequences of this bug, likely including some we have not yet come across. Those we know about are listed below.

• It will make it impossible to set bash as the login shell for newly-created user accounts
• It prevents pkexec from working correctly: some other applications use pkexec to launch commands, so these will also be affected. The error returned by pkexec will be The value for the SHELL variable was not found the /etc/shells file
• It prevents login to a VSFTPD server if the user's login shell is set to bash
• It prevents SELinux sandboxing from working correctly: attempts to launch an application inside a sandbox will fail with the error Error: User shell is not valid

Fortunately, the bug is at least easy to resolve: simply run the command su -c 'yum reinstall bash'. This will reinstall the bash package, which resolves the issue. If you have no network access in order to reinstall the package, you can simply re-add bash to /etc/shells manually, it is entirely safe to do so.

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 tool to install a color profile for any of your hardware in Fedora 15, then after upgrading to Fedora 16, you may not be able to log in to GNOME Shell with SELinux enabled. Login will fail with the "Oh no! Something has gone wrong" error screen that GNOME pops up if a component is crashing repeatedly.

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 su -c 'chcon -R -t icc_data_home_t ~/.local/share/icc'. After doing this, GNOME login should work correctly.

Starting GDM (login manager) fails on x86_64 systems after upgrade from Fedora 15 due to i686 caribou package being installed

link to this item - Bugzilla: #741075

Several users have reported that, after upgrading from the x86_64 version of Fedora 15 to Fedora 16, GDM (the default login manager) failed to start, displaying the "Oh no! Something has gone wrong" error screen. This turned out to be due to the i686 (32-bit) caribou package being installed instead of the x86_64 version. Installing the x86_64 version of the caribou package resolves the problem. We are investigating why this problem occurs: if you have any information, please add it to the bug report.

GNOME Shell uses excessive CPU time with System Monitor extension installed

link to this item - Bugzilla: #748241

When the gnome-shell-extension-systemMonitor package - the System Monitor extension for GNOME Shell - is enabled, GNOME Shell can come to consume an excessive amount of CPU time. The issue can be worked around temporarily simply by restarting the Shell (a quick way to do this is to hit alt-f2 and enter the command as the single character 'r'). There is no known permanent workaround besides removing or disabling the extension.

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 grubby package.

Setting back system time breaks boot

link to this item - Bugzilla: #748920

If you set back your system time for more than one day into the past, Fedora will not boot on next system restart. It will complain about your disk mount time being too far in the future. Typically the error message looks like this (dracut shell):

/dev/mapper/VolGroup-lv_root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
 (i.e., without -a or -p options)
dracut Warning: e2fsck returned with 4
dracut Warning: /dev/mapper/VolGroup-lv_root: Superblock last mount time (Tue
Oct 25 14:40:08 2011,
dracut Warning: now = Sun Sep 25 14:41:50 2011) is in the future.
dracut Warning: *** An error occurred during the file system check.
dracut Warning: *** Dropping you to a shell; the system will try
dracut Warning: *** to mount the filesystem(s), when you leave the shell.

Or it can look like this (emergency mode shell):

systemd-fsck[605]: /dev/sda2: Superblock last mount time (Tue Oct 25 10:40:12
2011,
systemd-fsck[605]: now = Sun Sep 25 10:41:59 2011) is in the future.
systemd-fsck[605]: /dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
systemd-fsck[605]: (i.e., without -a or -p options)
[   13.652068] systemd-fsck[605]: fsck failed with error code 4.
Welcome to emergency mode. Use "systemctl default" or ^D to activate default
mode.
Give root password for maintenance
(or type Control-D to continue):

You have to use the shell to correct the filesystem that is claimed to be "inconsistent". If you have multiple partitions you may need to do the following procedure for all of them. The easiest approach is:

1. Note that partition name in the error message (/dev/mapper/VolGroup-lv_root and /dev/sda2 in our examples).
2. Run this command

   fsck <partition name>

   For example:

   fsck /dev/sda2

   and confirm you want to fix it.
3. Run

   reboot

It may happen that you are presented with the error message, but you are not given any emergency shell. In that case please boot from the Fedora installation media and select Troubleshooting -> Rescue a Fedora system. After the rescue tool mounts your system disks you can just reboot, everything should be corrected.

Cannot send files via Bluetooth

link to this item - Bugzilla: #753617

Due to changes in the kernel bluetooth interface, you will not be able to transfer files to another device via Bluetooth in Fedora 16. There is no known workaround for this issue besides transferring the files to the device in some other way (e.g. via USB cable or wifi).