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.
- 1 Release Notes
- 2 My bug is not listed
- 3 Installation issues
- 4 Hardware issues
- 5 Software issues
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Installer cannot install bootloader to a system partition (but will try and fail)
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.
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
chroot to access the installed system, and running
grub2-install --force (hd0,5) (where hd0,5 is the appropriate designation for the target partition).
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.
Installer crashes if an encrypted partition passphrase prompt dialog is cancelled
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 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.
Installer cannot upgrade system from earlier releases
Several bugs in the Fedora 16 Alpha installer prevent upgrades from previous Fedora releases from working.
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.
Installing packages in %post section of a kickstart fails
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.
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.
Connecting to some routers with some Intel wireless adapters can cause router to become non-responsive until reboot
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.
The ActionTec MI424-WR router, with firmware versions 126.96.36.199 and 20.19.8, is known to be affected by this. The popular 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.
There are four possible workarounds for this issue.
- Install and boot a 2.6.38 or earlier kernel
/etc/modprobe.d/00-iwl_router.confwith the contents options iwlagn 11n_disable=1 to disable 802.11n on the client end
- Disable 802.11n on the router end, in the router configuration interface
- Use a kernel with this workaround patch applied
A future kernel update will likely include the workaround, or an alternative fix.
Smolt crashes on being run (empty hardware profile during firstboot)
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
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.
Applications may crash on failed DNS lookups
Though the exact circumstances in which the bug is triggered are unknown, a bug in
can cause any application to crash when a DNS lookup performed via glibc fails. This bug often manifests itself as a crash in
. 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.
Kernel reports a possible recursive locking warning
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
bug reporting tool, but please do not report it, as the issue is already known.
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
X crashes when KDE starts up in a qemu / KVM virtual machine
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
, X will crash. If using a login manager, you will see the KDE startup sequence, then the login manager will reappear.
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.