|
|
| Line 54: |
Line 54: |
|
| |
|
| == Installation issues == | | == Installation issues == |
|
| |
| {{Anchor|grub2-partition-fail}}
| |
| === 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.
| |
|
| |
| 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, with GRUB 2 partition numbering starting at 1 as opposed to 0 with old GRUB). Alternatively, specify an ordinary partition device name such as /dev/sda5. Note that with --force the warnings are still printed.
| |
|
| |
| 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.
| |
|
| |
| {{Anchor|luks-partition-crash}}
| |
|
| |
| === Installer crashes if an encrypted partition passphrase prompt dialog is cancelled ===
| |
| <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 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.
| |
|
| |
| {{Anchor|anaconda-upgrade-fail}}
| |
| === Installer cannot upgrade system from earlier releases ===
| |
| <small>[[#anaconda-upgrade-fail|link to this item]] - [[rhbug:728188|Bugzilla: #728188]]</small>
| |
|
| |
| 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.
| |
|
| |
| {{Anchor|anaconda-kickstart-post}}
| |
| === 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.
| |
|
| |
| 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.
| |
|
| |
|
| == Hardware issues == | | == Hardware issues == |
|
| |
| {{Anchor|iwl-router-kill}}
| |
| === Connecting to some routers with some Intel wireless adapters can cause router to become non-responsive until reboot ===
| |
| <small>[[#iwl-router-kill|link to this item]] - [[rhbug:708747|Bugzilla: #708747]]</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.
| |
|
| |
| 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.
| |
|
| |
| There are four possible workarounds for this issue.
| |
|
| |
| # Install and boot a 2.6.38 or earlier kernel
| |
| # 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 test build that should resolve this problem is available from Koji: [http://koji.fedoraproject.org/koji/buildinfo?buildID=260789 kernel-3.1.0-0.rc3.git5.1.fc16]. If you are affected by this issue, please test this update and report your results to the [[rhbug:708747|bug report]].
| |
|
| |
| {{Anchor|nvidia-nv28GL-gnome-shell-crash}}
| |
| === GNOME Shell crashes with nVidia NV28GL ===
| |
| <small>[[#nvidia-nv28GL-gnome-shell-crash|link to this item]] - [[rhbug:708004|Bugzilla: #708004]] [[rhbug:534141|Bugzilla: #534141] [[rhbug:704998|Bugzilla: #704998]</small>
| |
|
| |
| GNOME Shell can crash when running Fedora 16 Alpha with some specific Nvidia chipsets. It is recommended that users try this [https://admin.fedoraproject.org/updates/xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16?_csrf_token=6fa758c0591f5ba5eab0ec9d484783008f84e4cc update] and check whether it fixes the issues.
| |
|
| |
|
| == Software issues == | | == Software issues == |
|
| |
| {{Anchor|smolt-fail}}
| |
| === 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.
| |
|
| |
| An updated {{package|smolt}} package should be available to resolve this issue shortly.
| |
|
| |
| {{Anchor|glibc-dns-crash}}
| |
| === 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''.
| |
|
| |
| 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]].
| |
|
| |
| {{Anchor|kernel-lockdep}}
| |
| === Kernel reports a ''possible recursive locking'' warning ===
| |
| <small>[[#kernel-lockdep|link to this item]] - [[rhbug:722472|Bugzilla: #722472]]</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.
| |
|
| |
| 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|kde-qxl-crash}} | | {{Anchor|kde-qxl-crash}} |
| Line 148: |
Line 66: |
|
| |
|
| 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. | | 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. |
|
| |
| {{Anchor|gtt-crash}}
| |
| === GNOME Tweak Tool crashes on startup ===
| |
| <small>[[#gtt-crash|link to this item]] - [[rhbug:719791|Bugzilla: #719791]]</small>
| |
|
| |
| {{package|gnome-tweak-tool}}, the helper application for tweaking some GNOME settings which are no longer exposed in the official GNOME configuration tools in GNOME 3, crashes at each startup in the version included in Fedora 16 Alpha. There is no workaround for this.
| |
|
| |
| An updated [http://admin.fedoraproject.org/updates/gnome-tweak-tool-3.1.0-1.fc16 gnome-tweak-tool] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [http://admin.fedoraproject.org/updates/gnome-tweak-tool-3.1.0-1.fc16 report to Bodhi] whether it solves the problem. To test the update, run this command:
| |
| <pre>su -c 'yum --enablerepo=updates-testing update gnome-tweak-tool'</pre>
| |
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.
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
Read the F16 Alpha release announcement and the Fedora 16 release notes for specific information about changes in Fedora 16 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
Installation issues
Hardware issues
Software issues
X crashes when KDE starts up in a qemu / KVM virtual machine
link to this item - Bugzilla: #731245
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 
virt-manager
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.
virt-manager