From Fedora Project Wiki

(add 'intel wireless adapters kill routers' (#708747))
m (add category)
 
(96 intermediate revisions by 17 users not shown)
Line 2: Line 2:


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.
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.
{{admon/note|Fedora 16 pre-release|Fedora 16 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 16 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 ==
Line 52: Line 50:
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|xfce-power-crash}}
=== Xfce power manager crashes on login ===
<small>[[#xfce-power-crash|link to this item]] - [[rhbug:736727|Bugzilla: #736727]]</small>
There was a bug in the {{package|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 [https://admin.fedoraproject.org/updates/FEDORA-2011-15825 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 {{package|xfce4-power-manager}}.
{{Anchor|preupgrade-bootloader-fail}}
=== Upgrade from Fedora 14 or 15 to Fedora 16 with preupgrade leaves bootloader in previous configuration ===
<small>[[#preupgrade-bootloader-fail|link to this item]] - [[rhbug:737731|Bugzilla: #737731]]</small>
If you used the {{command|preupgrade}} utility to upgrade from Fedora 14 or 15 to Fedora 16, the bootloader configuration may have been left in its previous state. This was 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 would 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 was fixed for Fedora 14 in the updated [https://admin.fedoraproject.org/updates/FEDORA-2011-16047/preupgrade-1.1.10-1.fc14 preupgrade-1.1.10-1.fc14] package and for Fedora 15 in the updated [https://admin.fedoraproject.org/updates/FEDORA-2011-14766/preupgrade-1.1.10-1.fc15 preupgrade-1.1.10-1.fc15] package. To ensure you do not encounter this issue, check that you have at least this version of preupgrade installed before upgrading to Fedora 16.
{{Anchor|boot-kernel-loading}}
=== After a kernel update, ''Loading...'' message on boot refers to the wrong kernel ===
<small>[[#boot-kernel-loading|link to this item]] - [[rhbug:732654|Bugzilla: #732654]]</small>
After you first installed an updated kernel on a Fedora 16 system, the line which shows up briefly during the boot process - ''Loading (kernel version)...'' - would refer to the wrong kernel. This was because the {{command|grubby}} utility Fedora uses to update the bootloader configuration file did not correctly update this line.
The bug was entirely cosmetic: the correct kernel is loaded in all cases, only the message is incorrect.
This issue was fixed in the updated [https://admin.fedoraproject.org/updates/FEDORA-2011-16908/grubby-8.3-2.fc16 grubby-8.3-2.fc16] package. To solve the issue, update your Fedora 16 installation as usual. Kernels installed after grubby is updated will have correct ''Loading...'' lines. Kernels installed before grubby is updated will not be corrected by the update.


== Installation issues ==
== Installation issues ==
{{Anchor|separate-var-anaconda-upgrade-fail}}
=== Attempting to upgrade a system with /var on a different partition or LV to / will fail ===
<small>[[#separate-var-anaconda-upgrade-fail|link to this item]] - [[rhbug:748119|Bugzilla: #748119]]</small>
If you have your system set up with {{filename|/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 {{filename|/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 [http://clumens.fedorapeople.org/748119.img update image] for the installer. For more information on update images, see [[Anaconda/Updates]]. To use this updates image, pass the kernel parameter ''updates=<nowiki>http://clumens.fedorapeople.org/748119.img</nowiki>'' 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 {{filename|/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 {{filename|/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.
{{Anchor|gpt-no-boot}}
=== Some systems, particularly Apple Macs, cannot boot GPT-labelled disks ===
<small>[[#gpt-no-boot|link to this item]] - [[rhbug:735733|Bugzilla: #735733]] [[rhbug:749325|Bugzilla: #749325]] [[rhbug:696482|Bugzilla: #696482]]</small>


{{Anchor|grub2-partition-fail}}
Fedora 16 uses the newer [https://en.wikipedia.org/wiki/GUID_Partition_Table GPT] disk label format, when formatting an entire disk during installation. (If you choose to install to some space on a disk that is already formatted, not having the entire disk reformatted, Fedora will not change the formatting of the disk). This new format brings several advantages. However, some systems have trouble booting from GPT-labelled disks.
=== Installer cannot install bootloader to a system partition (but will try and fail) ===
<small>[[#grub2-partition-fail|link to this item]] - [[rhbug:730915|Bugzilla: #730915]]</small>


Fedora 16 uses the GRUB 2 bootloader for new installations. GRUB 2 does not currently support installation to a partition (rather than the MBR), but the Fedora 16 Alpha installer will still allow you to try and install the bootloader to a partition. This will fail, and so if you attempt this, the Fedora 16 Alpha installer will not install a bootloader at all. The installed system will be functional.
Many Lenovo systems are known to be affected by this. Consequently, Fedora 16 does not in fact use the GPT label format for Lenovo systems; they are blacklisted to use the old MS-DOS format instead. Lenovo users should therefore not be affected by this issue, but it explains why you will get an MS-DOS disk label rather than a GPT one when installing Fedora 16 to a Lenovo system.


To work around this issue, you can adjust your bootloader configuration from another installed operating system. You can force installation of GRUB 2 to the Fedora partition by booting the Fedora 16 Alpha installation disc in rescue mode, using {{command|chroot}} to access the installed system, and running {{command|grub2-install --force (hd0,5)}} (where hd0,5 is the appropriate designation for the target partition).
It is now also known that Apple Macs cannot boot from GPT-labelled disks in BIOS compatibility mode. They can, of course, boot from GPT-labelled disks when booting natively via EFI (the GPT format is associated with the UEFI standard). Fedora 16 cannot successfully boot on some Apple Macs in native EFI boot mode, however (see elsewhere in this page), and on such systems, you will need to install Fedora in BIOS compatibility mode; but then you must also work around this issue.


This issue will be resolved in Fedora 16 Beta: the installer will use the --force parameter when trying to install the bootloader to a partition.
The symptoms of this issue are simply that the installation completes correctly and without errors but the installed system entirely fails to boot, not even reaching the bootloader menu. The system may report some kind of error - it may claim that no bootable disk is present - or it may simply drop to a blank screen or a flashing cursor or something of the kind. There are other problems which can cause such behaviour, but inability to boot from a GPT-labelled disk is one of the most likely.


{{Anchor|luks-partition-crash}}
If you are affected by this problem, you can work around it by passing the parameter ''nogpt'' to the Fedora installer. To do this, at the initial bootloader menu for the Fedora installation, where you can select to install, install in basic graphics mode, boot to the rescue mode and so on, hit the Tab key, then edit the command line for the Fedora installer and add the word ''nogpt''.


=== Installer crashes if an encrypted partition passphrase prompt dialog is cancelled ===
In some cases, the system BIOS is capable of booting from a GPT-labelled disk, but only if the protective MBR entry (see [https://en.wikipedia.org/wiki/GUID_Partition_Table#Legacy_MBR_.28LBA_0.29 here] for more details on this) is marked as bootable ('active'). Setting the protective MBR entry as active is a violation of the GPT specification, and so Fedora does not do so by default. We do not have a detailed list of systems which will boot from a GPT-labelled disk only if the protective MBR is marked active, but this seems to be the case with at least some HP machines, some Sony machines, and some Intel motherboards. On such a system, the more 'drastic' workaround listed above (instructing Fedora not to use a GPT disk label at all) will work, but you can also try a more limited workaround: install as normal, with a GPT disk label, and then manually set the 'active' flag on the protective MBR.
<small>[[#luks-partition-crash|link to this item]] - [[rhbug:727814|Bugzilla: #727814]]</small>


If you attempt to install Fedora 16 to a system with an encrypted partition, the installer will prompt you for the passphrase of the encrypted partition so it can examine its contents. If you cancel this dialog instead of entering the passphrase, the installer should be able to continue with installation by either overwriting the partition or leaving it untouched (depending on the partition layout you choose). Instead, the installer will crash after you choose a partition layout, with the error ''LUKSError: luks device not configured''.
To do so, use the {{command|fdisk}} utility - do '''not''' use a utility which actually understands GPT disk labels, as it will edit the attributes of the GPT partition table, not the protective MBR. You can run the commands from a live Linux (Fedora or any other distribution), Fedora's rescue mode, or from a console within the Fedora installer after completing installation but before rebooting - hit ctrl-alt-F2 to access a console.


To work around this issue, enter the passphrase for the encrypted partition(s) when prompted, even if you intend to overwrite or ignore them during installation. This issue will be resolved in Fedora 16 Beta.
Usually, you would run these commands, with root privileges:
<pre>
fdisk /dev/sda
a
1
w
q
</pre>
/dev/sda should be the actual correct device for the hard disk to which Fedora has been installed. The rest of the commands toggle the 'active' flag on the first partition, which will almost certainly be the correct one - it is very unlikely the protective MBR will list more than a single partition. The 'w' command writes the changes, so if you want to check, you can run 'p' before 'w', to print the partition table. It should show a single large partition with an asterisk (*) under the 'Boot' column, like so:
<pre>
  Device Boot      Start        End      Blocks  Id  System
/dev/sda1 *            1  125045423    62522711+  ee  GPT
</pre>


{{Anchor|anaconda-upgrade-fail}}
{{Anchor|grub2-raid1-sector63}}
=== Installer cannot upgrade system from earlier releases ===
=== Boot sometimes fails when installing to a pre-existing partition layout with complex boot configuration (e.g. software or firmware RAID-1) ===
<small>[[#anaconda-upgrade-fail|link to this item]] - [[rhbug:728188|Bugzilla: #728188]]</small>
<small>[[#grub2-raid1-sector63|link to this item]] - [[rhbug:737508|Bugzilla: #737508]]</small>


Several bugs in the Fedora 16 Alpha installer prevent upgrades from previous Fedora releases from working.
Versions of Fedora prior to Fedora 16, and many other operating systems, will by default use the MS-DOS disk label format, and create the first partition on a hard disk at sector 63. This leaves a gap of 32KiB between the MBR and the first partition. This is the space into which the core of the system bootloader must be installed on an MS-DOS labelled disk.


Upgrade functionality should be available in Fedora 16 Beta. If you are very keen to upgrade a Fedora 15 system to Fedora 16 Alpha, you may try [[Upgrading_Fedora_using_yum]], but this has not been tested and may well be difficult, or cause problems in the upgraded system. The recommended way to test Fedora 16 Alpha is to do a fresh installation.
The core part of Fedora 16's bootloader, grub2, may not fit into this 32KiB space, if the required configuration to boot the system is complex. One known problematic case comes when the /boot partition is on a software or firmware (not hardware) RAID-1 device. In this case, the core grub2 image must include RAID support, and the inclusion of this makes the core image larger than 32KiB in size.


{{Anchor|anaconda-kickstart-post}}
In more 'straightforward' cases, grub2's core image is smaller than 32KiB in size, so this bug will often not be encountered. Also, if you install Fedora 16 in such a way that the target drive is re-formatted, Fedora will use a GPT disk label and create a 1MiB 'BIOS Boot' partition. With the GPT disk label format, the bootloader core must reside on such a 'BIOS Boot' partition, and the 1MB size provides comfortably enough room for any necessary grub2 core image. The bug only occurs when installing Fedora 16 to an existing partition layout (and hence also when upgrading an existing configuration) which requires a complex grub2 core image.
=== Installing packages in %post section of a kickstart fails ===
<small>[[#anaconda-kickstart-post|link to this item]] - [[rhbug:730857|Bugzilla: #730857]]</small>


Due to a bug in the installer, when using a kickstart file to automate installation of Fedora 16 Alpha, installing a package in the %post section of the kickstart file will fail with the error ''sqlite3.OperationalError: database is locked''. If you try to install a package by hand to the installed system from a console in the installer, after installation is complete but before rebooting to the installed system, it will fail similarly.
When you encounter the bug, Fedora's installer may warn you that bootloader installation failed, but the installation will complete. However, the installed system will fail to boot. If you examine the installer logs you may find the message ''grub2-setup: warn: your core.img is unusually large, it won't fit in the embedding area''.


There is no known workaround for this bug at present, beyond reserving all package installation until after you boot the installed system. The anaconda developers are working to fix this bug for Fedora 16 Beta.
The safest workaround for the issue is to resize the first partition on the disk so that there is more empty space in front of it. A very small change will be sufficient - just having the partition start at 1MiB rather than 32KiB should suffice. Some partition types can be non-destructively resized from the beginning in this way, but in some cases it may be necessary to archive all the data on the partition, delete it, re-create it with a slightly later starting sector, and then restore the data. If you have to do this, you will likely wish to note the partition's UUID and partition label before destroying the partition, and ensure that they match when re-creating it. There are parameters you can pass to the various ''mkfs'' commands to force the UUID of the created partition: for instance, the parameter is -U for the ''mke2fs'' command.
 
An alternative workaround may be to manually install grub-legacy (rather than grub2) as the bootloader. However, the use of grub-legacy on Fedora 16 is not officially supported, and grub-legacy may well be removed entirely from future Fedora releases, so this is likely to be feasible only in the short term.
 
You may also compare [https://wiki.archlinux.org/index.php/GRUB2#MBR_aka_msdos_partitioning_specific_instructions Arch Linux's note on the same issue].
 
{{Anchor|boot-on-softraid}}
=== Cannot boot with /boot partition on a software RAID array ===
<small>[[#boot-on-softraid|link to this item]] - [[rhbug:750794|Bugzilla: #750794]]</small>
 
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 {{filename|/mnt/sysimage/boot/grub2/grub.cfg}} and add the lines:
<pre>
insmod part_msdos
insmod raid
insmod mdraid09
insmod mdraid1x
</pre>
Now run these commands:
<pre>
chroot /mnt/sysimage
grub2-install --modules="part_msdos raid mdraid09 mdraid1x" /dev/sda
grub2-install --modules="part_msdos raid mdraid09 mdraid1x" /dev/sdb
</pre>
Adjust the device names as appropriate to the disks used in your system.
 
<pre>
Edit: I spent several hours getting SWRAID to work - just following the above instructions I was still unable to boot.
 
I needed to do the following...
 
1) Install from DVD - Not the liveCD - using the livecd I couldn't chroot /mnt/sysimage - there was also no /mnt/sysimage/boot
2) Boot the DVD with 'nogpt' kernel option enabled
</pre>
 
{{Anchor|biosboot-two-drives}}
 
=== Cannot install over an existing RAID configuration ===
<small>[[#biosboot-two-drives|link to this item]] - [[rhbug:729640|Bugzilla: #729640]]</small>
 
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.
 
{{Anchor|biosboot-partition-missing}}
=== Error  "you have not created a bootloader stage1 target device" appears in partitioning menu ===
<small>[[#biosboot-partition-missing|link to this item]] - [[rhbug:752063|Bugzilla: #752063]]</small>
 
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'.
 
{{Anchor|mac-nvidia-fail}}
=== Some Macs with NVIDIA graphics adapters cannot boot via EFI and display corrupted graphics when booted via BIOS emulation ===
<small>[[#mac-nvidia-fail|link to this item]] - [[rhbug:650949|Bugzilla: #650949]]</small>
 
Several Mac owners have reported that their systems are unable to boot Fedora 16 (and, in fact, previous Fedora release) images via EFI, and display distorted graphics when booted via BIOS emulation. This affects some or all Macs with NVIDIA graphics adapters. Affected models are known to include the Macbook Pro 3,1, the Macbook Air3,1,1, and the Macbook Pro 4,1. This affects both live and non-live Fedora images: it is a kernel issue.
 
If you attempt to boot via EFI, the boot process will get some distance but eventually freeze with no further progress after printing some messages about the graphics adapter.
 
If you attempt to boot via BIOS compatibility mode, the boot process will succeed, but the display will be distorted.
 
Booting via BIOS compatibility mode and using Fedora's 'Basic graphics' mode (available from the installer boot menu) should work, but will provide only basic, non-native resolution 2D graphics. Booting via EFI is only possible if you use the text mode installation, and the installed system will also be incapable of any graphical display. Only the text console will work.
 
{{Anchor|live-iscsi}}
=== Cannot boot after install to iSCSI from live image ===
<small>[[#live-iscsi|link to this item]] - [[rhbug:736893|Bugzilla: #736893]]</small>
 
If you attempt to install Fedora 16 to an iSCSI storage device from any of the live images, the installation will complete successfully, but the installed system will fail to boot.
 
There is no known workaround for the issue at this point. However, installations from non-live images (the DVD or boot.iso images) work correctly. It is highly recommended that you install from a non-live image if you wish to install Fedora 16 to an iSCSI storage device.
 
{{Anchor|enablement-status}}
=== Upgrade from previous releases resets the enablement status of services ===
<small>[[#enablement-status|link to this item]] - [[rhbug:752846|Bugzilla: #752846]]</small>
 
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 (<code>systemd-sysv-convert --apply</code>) 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 <code>systemctl list-unit-files</code> and <code>systemctl enable ''foo''.service</code> as needed.
 
{{Anchor|boot-partition-type}}
=== Incorrect partition type assigned to /boot partition on GPT-labelled disks ===
<small>[[#boot-partition-type|link to this item]] - [[rhbug:746895|Bugzilla: #746895]]</small>
 
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.
 
{{Anchor|text-upgrade-bootloader}}
=== No workable bootloader action in text mode upgrade ===
<small>[[#text-upgrade-bootloader|link to this item]] - [[rhbug:742207|Bugzilla: #742207]]</small>
 
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.
 
{{Anchor|wifi-password}}
=== Installer doesn't ask for wifi password ===
<small>[[#wifi-password|link to this item]] - [[rhbug:751139|Bugzilla: #751139]]</small>
 
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).
 
{{Anchor|non-ascii-disk-encryption}}
=== Disk encryption with national keymap often doesn't work ===
<small>[[#non-ascii-disk-encryption|link to this item]] - [[rhbug:743281|Bugzilla: #743281]]</small>
 
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.
 
{{Anchor|kickstart-clearpart}}
=== Must explicitly specify ''clearpart --none'' to use an existing disk layout in kickstart ===
<small>[[#kickstart-clearpart|link to this item]] - [[rhbug:752216|Bugzilla: #752216]]</small>
 
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).
 
{{Anchor|4096MB-minimum-live}}
=== Minimum space for Desktop live install incorrectly calculated ===
<small>[[#4096MB-minimum-live|link to this item]] - [[rhbug:753400|Bugzilla: #753400]]</small>
 
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.
 
{{Anchor|4k-sectors}}
=== Cannot boot from disks with logical 4K (4096 byte) sector size ===
<small>[[#4k-sectors|link to this item]] - [[rhbug:743146|Bugzilla: #743146]]</small>
 
The bootloader included with Fedora 16 is not capable of booting from a disk with a 4K logical sector size.
 
This is not a regression in Fedora 16: no previous Fedora release is capable of this either. However, such disks were virtually unknown until recently.
 
So-called ''[https://en.wikipedia.org/wiki/Advanced_Format Advanced Format]'' disks with sector sizes larger than 512 bytes are now increasingly common. The 'Green' (high capacity, low spin rate) disks provided by most manufacturers are often AF drives, and some other 2TB and larger drives are also AF. Most such drives, however, have physical 4K (4096 byte) sectors but 'logical' 512 byte sectors: they appear to the operating system as if the sector size is 512 bytes. Fedora 16 is capable of booting from such drives. A few drives have both physical and logical 4K sectors - they do not present a 512 byte sector size to the operating system. Fedora 16 is not capable of booting from such drives.
 
To determine the exact status of a drive, run {{command|parted}} on it, and type 'print'. One line in the output will look like this:
<pre>
Sector size (logical/physical): 512B/512B
</pre>
If it reads 512B/512B then the drive is a conventional one and will have no problems. If it reads 512B/4096B then the drive is an AF drive but has a logical sector size of 512 bytes and should also work. If it reads 4096B/4096B then the drive is an AF drive with a logical sector size of 4096 bytes, and you cannot boot from it with Fedora 16's bootloader. Fedora 16 can read and write data from and to such drives without any problems, but its default bootloader cannot boot from them.
 
{{Anchor|preupgrade-3rdparty-repos}}
=== Preupgrade may fail if third-party repositories (especially VirtualBox) are enabled ===
<small>[[#preupgrade-3rdparty-repos|link to this item]] - [[rhbug:650854|Bugzilla: #650854]]</small>
 
Several users have reported that trying to upgrade Fedora using preupgrade with the third-party VirtualBox repository enabled can lead to severe problems. It seems that the configuration of this repository can result in an incomplete updated VirtualBox package being downloaded, and instead of recognizing the incomplete download and ignoring or re-downloading the package, Fedora will attempt to install it, which can cause the upgrade process to fail halfway through, leaving the system in an inconsistent and possibly unusable state.
 
Some users have been able to resolve this problem by manually downloading the problematic VirtualBox package and replacing the incomplete copy in {{filename|/var/cache/yum/preupgrade}}, and re-running the upgrade process. However, it is likely that this will not always work flawlessly.
 
We strongly recommend you disable all third-party repositories prior to performing a preupgrade of Fedora. You can re-enable them and upgrade their packages separately, once the main upgrade is complete.
 
{{Anchor|amd-apu-install-no-display}}
=== Screen switches off when anaconda installation sets display resolution ===
<small>[[#amd-apu-install-no-display|link to this item]] - [[rhbug:753518|Bugzilla: #753518]]</small>
 
Anaconda fails set display on systems with new AMD APU processors and monitor connected to this integrated graphics. Solution is to add <code>nomodeset</code> kernel boot parameter and choose text or vnc install method.
 
{{Anchor|systemd-syslog-ng-problems}}
=== Systemd and syslog-ng interaction problems: system freezes / syslog-ng fails to start  ===
<small>[[#systemd-syslog-ng-problems|link to this item]] - [[rhbug:742624|Bugzilla: #742624]] - [[rhbug:770810|Bugzilla: #770810]]</small>
 
Due to a unix socket type mismatch between systemd and syslog-ng you
most likely experience system freezes during system start up (with syslog-ng 3.2.4)
or syslog-ng premature terminations (with syslog-ng 3.2.5-2).
 
Fix: If you haven't made any changes to the syslog-ng configuration file (/etc/syslog-ng/syslog-ng.conf),
an update to syslog-ng-3.2.5-2 will fix the problem for you. But if you have customized it,
you will have to manually edit it and change the unix socket type of '/dev/log' from unix-stream
to unix-dgram (example below):
 
<pre>
...
source s_sys {
  file ("/proc/kmsg" program_override("kernel: "));
- unix-stream ("/dev/log");
+ unix-dgram ("/dev/log");
  internal();
  # udp(ip(0.0.0.0) port(514));
};
...
</pre>


== Hardware issues ==
== Hardware issues ==


{{Anchor|iwl-router-kill}}
{{Anchor|s205-uefi-fail}}
=== Connecting to some routers with some Intel wireless adapters can cause router to become non-responsive until reboot ===
=== UEFI install to Lenovo Ideapad S205 fails to boot ===
<small>[[#iwl-router-kill|link to this item]] - [[rhbug:708747|Bugzilla: #708747]]</small>
<small>[[#s205-uefi-fail|link to this item]] - [[rhbug:748272|Bugzilla: #748272]]</small>
 
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 {{command|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.
 
{{Anchor|fx5x00-shell-corruption}}
=== Graphical corruption in GNOME Shell (and other 3D-accelerated applications) with NVIDIA GeForce FX 5200 adapters ===
<small>[[#fx5x00-shell-corruption|link to this item]] - [[rhbug:745202|Bugzilla: #745202]]</small>
 
Multiple users of NVIDIA GeForce FX 5200 graphics adapters have reported display corruption in GNOME Shell in Fedora 16. This includes the default login screen, which is in fact a special rendering case of GNOME Shell in GNOME 3.2. The panel (at the top of the screen) is multi-colored and text contained in it is garbled, among other instances of corruption. Similar corruption may affect other 3D-accelerated applications.
 
All indications are that this bug affects at least all FX 5200 adapters. It may affect other FX 5xxx adapters too. The bug is currently under investigation by the ''nouveau'' driver maintainer. There is no direct workaround for the bug, but it appears to affect only 3D-accelerated rendering, and so if you use a 2D desktop - such as the GNOME fallback mode, or Xfce - you will not see any corruption. Using the NVIDIA proprietary driver is also reported to avoid the bug, although the Fedora project does not support, encourage or endorse the use of proprietary software.
 
== Software issues ==
 
{{Anchor|bash-etc-shells}}
=== Bash entry in {{filename|/etc/shells}} disappears after update ===
<small>[[#bash-etc-shells|link to this item]] - [[rhbug:752827|Bugzilla: #752827]]</small>


A bug in the ''iwlagn'' driver for many Intel wireless chipsets, in kernels 2.6.39 and higher (including the kernel in Fedora 16 Alpha), can cause some routers to become unresponsive shortly after a system connects to the router wirelessly using the driver. In other words, if you have an Intel wireless chipset and an affected router, your router could stop working shortly after your system connects to it. The router remains unresponsive until it is rebooted, and the issue will happen again if the system with the affected wireless adapter connects again.
Due to an error in the %postun script of {{package|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 {{filename|/etc/shells}} will be removed.


The ActionTec MI424-WR router, with firmware versions 20.10.7.5 and 20.19.8, is known to be affected by this. The popular [http://www.dd-wrt.com DD-WRT] third-party router firmware is also known to be affected: known DD-WRT / router combinations affected include DD-WRT build 17201 on the Netgear WNDR3700 v1 and v2, DD-WRT build dated 11/21/10 on the Netgear WNDR3700 v1, DD-WRT build 14896 on the TP-Link TL-WR1043ND, DD-WRT build dated 12/17/10 on the Buffalo WZR-HP-AG300H, DD-WRT build 15962 on the D-Link DIR-825, DD-WRT build 14311 on the TP-Link TL-WR1043ND, and DD-WRT build 16783 on an unspecified Buffalo router.
A [https://admin.fedoraproject.org/updates/FEDORA-2011-15725 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.


There are four possible workarounds for this issue.
The result is that this bug will always happen on the first update of the {{package|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.


# Install and boot a 2.6.38 or earlier kernel
There are several consequences of this bug, likely including some we have not yet come across. Those we know about are listed below.
# Create {{filename|/etc/modprobe.d/00-iwl_router.conf}} with the contents <tt>options iwlagn 11n_disable=1</tt> to disable 802.11n on the client end
# Disable 802.11n on the router end, in the router configuration interface
# Use a kernel with [https://bugzilla.redhat.com/attachment.cgi?id=519535 this workaround patch] applied


A future kernel update will likely include the workaround, or an alternative fix.
* It will make it impossible to set bash as the login shell for newly-created user accounts
* It prevents {{command|pkexec}} from working correctly: some other applications use {{command|pkexec}} to launch commands, so these will also be affected. The error returned by {{command|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''
* It prevents the screen brightness from being set in GNOME (either automatically on battery power, or manually via keyboard commands or the control center applet)


== Software issues ==
Fortunately, the bug is at least easy to resolve: simply run the command {{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 {{filename|/etc/shells}} manually, it is entirely safe to do so.
 
{{Anchor|glibc-large-groups}}
 
=== Glibc may cause applications to crash with large groups ===
<small>[[#glibc-large-groups|link to this item]] - [[rhbug:750361|Bugzilla: #750361]]</small>
 
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 <code>/etc/group</code> 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.
 
{{Anchor|nsswitch-group-membership}}
=== Secondary group membership not correctly registered with non-disk backed user account backends ===
<small>[[#nsswitch-group-membership|link to this item]] - [[rhbug:750388|Bugzilla: #750388]]</small>
 
Due to a change in the default {{filename|/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.
 
This issue was fixed in the updated [https://admin.fedoraproject.org/updates/FEDORA-2011-15563/authconfig-6.1.16-2.fc16 authconfig-6.1.16-2.fc16] package. To solve the issue after installation, update your Fedora 16 installation as usual, then run {{command|su -c 'authconfig --updateall'}}.  You may still run into this issue on fresh installations of Fedora 16 unless you enable the ''updates'' repository during installation in order to ensure the updated authconfig package is used at install time.
 
To resolve the issue manually, or if the authconfig-based fix does not work for your configuration, edit the file {{filename|/etc/nsswitch.conf}} and remove the line:
<pre>
initgroups: files
</pre>
 
{{Anchor|color-profile-gnome}}
=== Starting GNOME Shell fails after upgrade from Fedora 15 with color profile installed ===
<small>[[#color-profile-gnome|link to this item]] - [[rhbug:741549|Bugzilla: #741549]]</small>
 
If you used the {{package|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 {{command|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 {{command|su -c 'chcon -R -t icc_data_home_t ~/.local/share/icc'}}. After doing this, GNOME login should work correctly.
 
{{Anchor|gdm-upgrade-caribou}}
 
=== Starting GDM (login manager) fails on x86_64 systems after upgrade from Fedora 15 due to i686 caribou package being installed ===
<small>[[#gdm-upgrade-caribou|link to this item]] - [[rhbug:741075|Bugzilla: #741075]]</small>
 
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 issue is due to the i686 (32-bit) {{package|caribou}} package being installed during the upgrade, instead of the x86_64 version.
 
An updated [https://admin.fedoraproject.org/updates/FEDORA-2011-17041/caribou-0.4.1-3.fc16 caribou] 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/FEDORA-2011-17041/caribou-0.4.1-3.fc16 report to Bodhi] whether it solves the problem. To test the update, enable the ''updates-testing'' repository while upgrading from Fedora 15 to Fedora 16.
 
If you have already been affected by this problem, simply installing the x86_64 version of the {{package|caribou}} package - {{command|su -c 'yum install caribou.x86_64'}} - should resolve it.
 
{{Anchor|shell-monitor-cpu}}
=== GNOME Shell uses excessive CPU time with System Monitor extension installed ===
<small>[[#shell-monitor-cpu|link to this item]] - [[rhbug:748241|Bugzilla: #748241]]</small>
 
When the {{package|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.
 
{{Anchor|changed-time-breaks-boot}}
=== Setting back system time breaks boot ===
<small>[[#changed-time-breaks-boot|link to this item]] - [[rhbug:748920|Bugzilla: #748920]]</small>
 
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):
 
<pre>/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.</pre>


{{Anchor|smolt-fail}}
Or it can look like this (emergency mode shell):
=== Smolt crashes on being run (empty hardware profile during firstboot) ===
<small>[[#smolt-fail|link to this item]] - [[rhbug:726029|Bugzilla: #726029]]</small>


The {{package|smolt}} utility in Fedora 16 Alpha contains a bug which causes it to crash immediately when run. As well as the straightforward case of smolt crashing if you run it directly, this manifests itself in the firstboot utility: in the step which offers to let you submit your hardware profile to Fedora, the pane which should contain the profile will be entirely empty. Obviously, it is useless to attempt to submit the profile. The issue also manifests in the {{package|abrt}} bug reporting tool's ability to attach your hardware profile to an issue using smolt: if you attempt to use this function, smolt will crash and abrt will not be able to attach the profile.
<pre>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):</pre>


An updated {{package|smolt}} package should be available to resolve this issue shortly.
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:
<ol>
<li>Note that partition name in the error message ({{filename|/dev/mapper/VolGroup-lv_root}} and {{filename|/dev/sda2}} in our examples).</li>
<li>Run this command
<pre>fsck &lt;partition name&gt;</pre>
For example:
<pre>fsck /dev/sda2</pre>
and confirm you want to fix it.</li>
<li>Run
<pre>reboot</pre></li>
</ol>


{{Anchor|glibc-dns-crash}}
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.
=== Applications may crash on failed DNS lookups ===
<small>[[#glibc-dns-crash|link to this item]] - [[rhbug:730856|Bugzilla: #730856]]</small>


Though the exact circumstances in which the bug is triggered are unknown, a bug in {{package|glibc}} can cause any application to crash when a DNS lookup performed via glibc fails. This bug often manifests itself as a crash in {{package|firefox}}. If the application that crashed was run from the console, you should be able to see the message ''assertion error in res_query.c: `hp != hp2' failed''.
{{Anchor|bluetooth-file-transfer}}
=== Cannot send files via Bluetooth ===
<small>[[#bluetooth-file-transfer|link to this item]] - [[rhbug:753617|Bugzilla: #753617]]</small>


A test build that should resolve this problem is available from Koji: [http://koji.fedoraproject.org/koji/taskinfo?taskID=3289243 glibc-2.14.90-6]. If you are affected by this issue, please test this update and report your results to the [[rhbug:730856|bug report]].
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).


{{Anchor|kernel-lockdep}}
{{Anchor|abrt-ccpp-service}}
=== Kernel reports a ''possible recursive locking'' warning ===
=== Abrt will not catch crashes after upgrade from a previous Fedora release ===
<small>[[#kernel-lockdep|link to this item]] - [[rhbug:722472|Bugzilla: #722472]]</small>
<small>[[#abrt-ccpp-service|link to this item]] - [[rhbug:749603|Bugzilla: #749603]]</small>


The Fedora 16 Alpha kernel reports a ''possible recursive locking'' warning at each boot, relating to ''system-logind'' and ''sys_epoll_ctl''. This warning is informational only and does not cause any practical problems. This warning will appear in the {{package|abrt}} bug reporting tool, but please do not report it, as the issue is already known.
When upgrading from a prior Fedora release, the abrt-ccpp service is not enabled. This will prevent the abrt program from catching software crashes, which will prevent users from reporting bugs. A workaround is to enable and start the service manually. You only need to run these commands once: on future system boots, the service will now start.
<pre>
# systemctl enable abrt-ccpp.service
# systemctl start abrt-ccpp.service
</pre>


This issue was fixed in the updated ''kernel-3.0.0-3.fc16'' package. To solve the issue, update your Fedora 16 Alpha installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|kernel}}.
{{Anchor|alternate-tab-crash}}
=== GNOME Shell crashes when using the ''alternate-tab'' extension ===
<small>[[#alternate-tab-crash|link to this item]] - [[rhbug:698939|Bugzilla: #698939]]</small>


{{Anchor|kde-qxl-crash}}
If you install and enable the {{package|gnome-shell-extension-alternate-tab}} extension for GNOME Shell, you will likely find that the Shell often crashes when you use alt-tab or ctrl-tab. This problem is caused by bugs in the extension.
=== X crashes when KDE starts up in a qemu / KVM virtual machine ===
<small>[[#kde-qxl-crash|link to this item]] - [[rhbug:731245|Bugzilla: #731245]]</small>


If you try to log in to a KDE environment in Fedora 16 Alpha on a virtual machine using the Fedora qemu/kvm stack (such as a machine created via {{package|virt-manager}}, X will crash. If using a login manager, you will see the KDE startup sequence, then the login manager will reappear.
At present there is no known workaround for the problem except for removing or disabling the extension. We do not recommend the use of this extension in Fedora 16 at the present time.


To work around this issue, use the ''vesa'' driver: select the '''Boot (Basic Video)''' option if booting the live image, or the '''Install system with basic video driver''' option if booting the traditional installer. The installed system will use the same driver, and KDE should work.
[[Category:Common bugs]]

Latest revision as of 00:00, 15 March 2018

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 Package-x-generic-16.pngxfce4-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 Package-x-generic-16.pngxfce4-power-manager.

Upgrade from Fedora 14 or 15 to Fedora 16 with preupgrade leaves bootloader in previous configuration

link to this item - Bugzilla: #737731

If you used the preupgrade utility to upgrade from Fedora 14 or 15 to Fedora 16, the bootloader configuration may have been left in its previous state. This was 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 would 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 was fixed for Fedora 14 in the updated preupgrade-1.1.10-1.fc14 package and for Fedora 15 in the updated preupgrade-1.1.10-1.fc15 package. To ensure you do not encounter this issue, check that you have at least this version of preupgrade installed before upgrading to Fedora 16.

After a kernel update, Loading... message on boot refers to the wrong kernel

link to this item - Bugzilla: #732654

After you first installed an updated kernel on a Fedora 16 system, the line which shows up briefly during the boot process - Loading (kernel version)... - would refer to the wrong kernel. This was because the grubby utility Fedora uses to update the bootloader configuration file did not correctly update this line.

The bug was entirely cosmetic: the correct kernel is loaded in all cases, only the message is incorrect.

This issue was fixed in the updated grubby-8.3-2.fc16 package. To solve the issue, update your Fedora 16 installation as usual. Kernels installed after grubby is updated will have correct Loading... lines. Kernels installed before grubby is updated will not be corrected by the update.

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.

Some systems, particularly Apple Macs, cannot boot GPT-labelled disks

link to this item - Bugzilla: #735733 Bugzilla: #749325 Bugzilla: #696482

Fedora 16 uses the newer GPT disk label format, when formatting an entire disk during installation. (If you choose to install to some space on a disk that is already formatted, not having the entire disk reformatted, Fedora will not change the formatting of the disk). This new format brings several advantages. However, some systems have trouble booting from GPT-labelled disks.

Many Lenovo systems are known to be affected by this. Consequently, Fedora 16 does not in fact use the GPT label format for Lenovo systems; they are blacklisted to use the old MS-DOS format instead. Lenovo users should therefore not be affected by this issue, but it explains why you will get an MS-DOS disk label rather than a GPT one when installing Fedora 16 to a Lenovo system.

It is now also known that Apple Macs cannot boot from GPT-labelled disks in BIOS compatibility mode. They can, of course, boot from GPT-labelled disks when booting natively via EFI (the GPT format is associated with the UEFI standard). Fedora 16 cannot successfully boot on some Apple Macs in native EFI boot mode, however (see elsewhere in this page), and on such systems, you will need to install Fedora in BIOS compatibility mode; but then you must also work around this issue.

The symptoms of this issue are simply that the installation completes correctly and without errors but the installed system entirely fails to boot, not even reaching the bootloader menu. The system may report some kind of error - it may claim that no bootable disk is present - or it may simply drop to a blank screen or a flashing cursor or something of the kind. There are other problems which can cause such behaviour, but inability to boot from a GPT-labelled disk is one of the most likely.

If you are affected by this problem, you can work around it by passing the parameter nogpt to the Fedora installer. To do this, at the initial bootloader menu for the Fedora installation, where you can select to install, install in basic graphics mode, boot to the rescue mode and so on, hit the Tab key, then edit the command line for the Fedora installer and add the word nogpt.

In some cases, the system BIOS is capable of booting from a GPT-labelled disk, but only if the protective MBR entry (see here for more details on this) is marked as bootable ('active'). Setting the protective MBR entry as active is a violation of the GPT specification, and so Fedora does not do so by default. We do not have a detailed list of systems which will boot from a GPT-labelled disk only if the protective MBR is marked active, but this seems to be the case with at least some HP machines, some Sony machines, and some Intel motherboards. On such a system, the more 'drastic' workaround listed above (instructing Fedora not to use a GPT disk label at all) will work, but you can also try a more limited workaround: install as normal, with a GPT disk label, and then manually set the 'active' flag on the protective MBR.

To do so, use the fdisk utility - do not use a utility which actually understands GPT disk labels, as it will edit the attributes of the GPT partition table, not the protective MBR. You can run the commands from a live Linux (Fedora or any other distribution), Fedora's rescue mode, or from a console within the Fedora installer after completing installation but before rebooting - hit ctrl-alt-F2 to access a console.

Usually, you would run these commands, with root privileges:

fdisk /dev/sda
a
1
w
q

/dev/sda should be the actual correct device for the hard disk to which Fedora has been installed. The rest of the commands toggle the 'active' flag on the first partition, which will almost certainly be the correct one - it is very unlikely the protective MBR will list more than a single partition. The 'w' command writes the changes, so if you want to check, you can run 'p' before 'w', to print the partition table. It should show a single large partition with an asterisk (*) under the 'Boot' column, like so:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1 *             1   125045423    62522711+  ee  GPT

Boot sometimes fails when installing to a pre-existing partition layout with complex boot configuration (e.g. software or firmware RAID-1)

link to this item - Bugzilla: #737508

Versions of Fedora prior to Fedora 16, and many other operating systems, will by default use the MS-DOS disk label format, and create the first partition on a hard disk at sector 63. This leaves a gap of 32KiB between the MBR and the first partition. This is the space into which the core of the system bootloader must be installed on an MS-DOS labelled disk.

The core part of Fedora 16's bootloader, grub2, may not fit into this 32KiB space, if the required configuration to boot the system is complex. One known problematic case comes when the /boot partition is on a software or firmware (not hardware) RAID-1 device. In this case, the core grub2 image must include RAID support, and the inclusion of this makes the core image larger than 32KiB in size.

In more 'straightforward' cases, grub2's core image is smaller than 32KiB in size, so this bug will often not be encountered. Also, if you install Fedora 16 in such a way that the target drive is re-formatted, Fedora will use a GPT disk label and create a 1MiB 'BIOS Boot' partition. With the GPT disk label format, the bootloader core must reside on such a 'BIOS Boot' partition, and the 1MB size provides comfortably enough room for any necessary grub2 core image. The bug only occurs when installing Fedora 16 to an existing partition layout (and hence also when upgrading an existing configuration) which requires a complex grub2 core image.

When you encounter the bug, Fedora's installer may warn you that bootloader installation failed, but the installation will complete. However, the installed system will fail to boot. If you examine the installer logs you may find the message grub2-setup: warn: your core.img is unusually large, it won't fit in the embedding area.

The safest workaround for the issue is to resize the first partition on the disk so that there is more empty space in front of it. A very small change will be sufficient - just having the partition start at 1MiB rather than 32KiB should suffice. Some partition types can be non-destructively resized from the beginning in this way, but in some cases it may be necessary to archive all the data on the partition, delete it, re-create it with a slightly later starting sector, and then restore the data. If you have to do this, you will likely wish to note the partition's UUID and partition label before destroying the partition, and ensure that they match when re-creating it. There are parameters you can pass to the various mkfs commands to force the UUID of the created partition: for instance, the parameter is -U for the mke2fs command.

An alternative workaround may be to manually install grub-legacy (rather than grub2) as the bootloader. However, the use of grub-legacy on Fedora 16 is not officially supported, and grub-legacy may well be removed entirely from future Fedora releases, so this is likely to be feasible only in the short term.

You may also compare Arch Linux's note on the same issue.

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 part_msdos
insmod raid
insmod mdraid09
insmod mdraid1x

Now run these commands:

chroot /mnt/sysimage
grub2-install --modules="part_msdos raid mdraid09 mdraid1x" /dev/sda
grub2-install --modules="part_msdos raid mdraid09 mdraid1x" /dev/sdb

Adjust the device names as appropriate to the disks used in your system.

Edit: I spent several hours getting SWRAID to work - just following the above instructions I was still unable to boot.

I needed to do the following...

1) Install from DVD - Not the liveCD - using the livecd I couldn't chroot /mnt/sysimage - there was also no /mnt/sysimage/boot
2) Boot the DVD with 'nogpt' kernel option enabled 

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

Some Macs with NVIDIA graphics adapters cannot boot via EFI and display corrupted graphics when booted via BIOS emulation

link to this item - Bugzilla: #650949

Several Mac owners have reported that their systems are unable to boot Fedora 16 (and, in fact, previous Fedora release) images via EFI, and display distorted graphics when booted via BIOS emulation. This affects some or all Macs with NVIDIA graphics adapters. Affected models are known to include the Macbook Pro 3,1, the Macbook Air3,1,1, and the Macbook Pro 4,1. This affects both live and non-live Fedora images: it is a kernel issue.

If you attempt to boot via EFI, the boot process will get some distance but eventually freeze with no further progress after printing some messages about the graphics adapter.

If you attempt to boot via BIOS compatibility mode, the boot process will succeed, but the display will be distorted.

Booting via BIOS compatibility mode and using Fedora's 'Basic graphics' mode (available from the installer boot menu) should work, but will provide only basic, non-native resolution 2D graphics. Booting via EFI is only possible if you use the text mode installation, and the installed system will also be incapable of any graphical display. Only the text console will work.

Cannot boot after install to iSCSI from live image

link to this item - Bugzilla: #736893

If you attempt to install Fedora 16 to an iSCSI storage device from any of the live images, the installation will complete successfully, but the installed system will fail to boot.

There is no known workaround for the issue at this point. However, installations from non-live images (the DVD or boot.iso images) work correctly. It is highly recommended that you install from a non-live image if you wish to install Fedora 16 to an iSCSI storage device.

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.

Cannot boot from disks with logical 4K (4096 byte) sector size

link to this item - Bugzilla: #743146

The bootloader included with Fedora 16 is not capable of booting from a disk with a 4K logical sector size.

This is not a regression in Fedora 16: no previous Fedora release is capable of this either. However, such disks were virtually unknown until recently.

So-called Advanced Format disks with sector sizes larger than 512 bytes are now increasingly common. The 'Green' (high capacity, low spin rate) disks provided by most manufacturers are often AF drives, and some other 2TB and larger drives are also AF. Most such drives, however, have physical 4K (4096 byte) sectors but 'logical' 512 byte sectors: they appear to the operating system as if the sector size is 512 bytes. Fedora 16 is capable of booting from such drives. A few drives have both physical and logical 4K sectors - they do not present a 512 byte sector size to the operating system. Fedora 16 is not capable of booting from such drives.

To determine the exact status of a drive, run parted on it, and type 'print'. One line in the output will look like this:

Sector size (logical/physical): 512B/512B

If it reads 512B/512B then the drive is a conventional one and will have no problems. If it reads 512B/4096B then the drive is an AF drive but has a logical sector size of 512 bytes and should also work. If it reads 4096B/4096B then the drive is an AF drive with a logical sector size of 4096 bytes, and you cannot boot from it with Fedora 16's bootloader. Fedora 16 can read and write data from and to such drives without any problems, but its default bootloader cannot boot from them.

Preupgrade may fail if third-party repositories (especially VirtualBox) are enabled

link to this item - Bugzilla: #650854

Several users have reported that trying to upgrade Fedora using preupgrade with the third-party VirtualBox repository enabled can lead to severe problems. It seems that the configuration of this repository can result in an incomplete updated VirtualBox package being downloaded, and instead of recognizing the incomplete download and ignoring or re-downloading the package, Fedora will attempt to install it, which can cause the upgrade process to fail halfway through, leaving the system in an inconsistent and possibly unusable state.

Some users have been able to resolve this problem by manually downloading the problematic VirtualBox package and replacing the incomplete copy in /var/cache/yum/preupgrade, and re-running the upgrade process. However, it is likely that this will not always work flawlessly.

We strongly recommend you disable all third-party repositories prior to performing a preupgrade of Fedora. You can re-enable them and upgrade their packages separately, once the main upgrade is complete.

Screen switches off when anaconda installation sets display resolution

link to this item - Bugzilla: #753518

Anaconda fails set display on systems with new AMD APU processors and monitor connected to this integrated graphics. Solution is to add nomodeset kernel boot parameter and choose text or vnc install method.

Systemd and syslog-ng interaction problems: system freezes / syslog-ng fails to start

link to this item - Bugzilla: #742624 - Bugzilla: #770810

Due to a unix socket type mismatch between systemd and syslog-ng you most likely experience system freezes during system start up (with syslog-ng 3.2.4) or syslog-ng premature terminations (with syslog-ng 3.2.5-2).

Fix: If you haven't made any changes to the syslog-ng configuration file (/etc/syslog-ng/syslog-ng.conf), an update to syslog-ng-3.2.5-2 will fix the problem for you. But if you have customized it, you will have to manually edit it and change the unix socket type of '/dev/log' from unix-stream to unix-dgram (example below):

...
 source s_sys {
  file ("/proc/kmsg" program_override("kernel: "));
- unix-stream ("/dev/log");
+ unix-dgram ("/dev/log");
  internal();
  # udp(ip(0.0.0.0) port(514));
 };
...

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.

Graphical corruption in GNOME Shell (and other 3D-accelerated applications) with NVIDIA GeForce FX 5200 adapters

link to this item - Bugzilla: #745202

Multiple users of NVIDIA GeForce FX 5200 graphics adapters have reported display corruption in GNOME Shell in Fedora 16. This includes the default login screen, which is in fact a special rendering case of GNOME Shell in GNOME 3.2. The panel (at the top of the screen) is multi-colored and text contained in it is garbled, among other instances of corruption. Similar corruption may affect other 3D-accelerated applications.

All indications are that this bug affects at least all FX 5200 adapters. It may affect other FX 5xxx adapters too. The bug is currently under investigation by the nouveau driver maintainer. There is no direct workaround for the bug, but it appears to affect only 3D-accelerated rendering, and so if you use a 2D desktop - such as the GNOME fallback mode, or Xfce - you will not see any corruption. Using the NVIDIA proprietary driver is also reported to avoid the bug, although the Fedora project does not support, encourage or endorse the use of proprietary software.

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 Package-x-generic-16.pngbash-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 Package-x-generic-16.pngbash 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
  • It prevents the screen brightness from being set in GNOME (either automatically on battery power, or manually via keyboard commands or the control center applet)

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.

This issue was fixed in the updated authconfig-6.1.16-2.fc16 package. To solve the issue after installation, update your Fedora 16 installation as usual, then run su -c 'authconfig --updateall'. You may still run into this issue on fresh installations of Fedora 16 unless you enable the updates repository during installation in order to ensure the updated authconfig package is used at install time.

To resolve the issue manually, or if the authconfig-based fix does not work for your configuration, 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 Package-x-generic-16.pnggnome-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 issue is due to the i686 (32-bit) Package-x-generic-16.pngcaribou package being installed during the upgrade, instead of the x86_64 version.

An updated caribou 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, enable the updates-testing repository while upgrading from Fedora 15 to Fedora 16.

If you have already been affected by this problem, simply installing the x86_64 version of the Package-x-generic-16.pngcaribou package - su -c 'yum install caribou.x86_64' - should resolve it.

GNOME Shell uses excessive CPU time with System Monitor extension installed

link to this item - Bugzilla: #748241

When the Package-x-generic-16.pnggnome-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.

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

Abrt will not catch crashes after upgrade from a previous Fedora release

link to this item - Bugzilla: #749603

When upgrading from a prior Fedora release, the abrt-ccpp service is not enabled. This will prevent the abrt program from catching software crashes, which will prevent users from reporting bugs. A workaround is to enable and start the service manually. You only need to run these commands once: on future system boots, the service will now start.

# systemctl enable abrt-ccpp.service
# systemctl start abrt-ccpp.service

GNOME Shell crashes when using the alternate-tab extension

link to this item - Bugzilla: #698939

If you install and enable the Package-x-generic-16.pnggnome-shell-extension-alternate-tab extension for GNOME Shell, you will likely find that the Shell often crashes when you use alt-tab or ctrl-tab. This problem is caused by bugs in the extension.

At present there is no known workaround for the problem except for removing or disabling the extension. We do not recommend the use of this extension in Fedora 16 at the present time.