From Fedora Project Wiki

(drop fixed Alpha issues, a few other cleanups)
Line 51: Line 51:
-->
-->
== Installation issues ==
== Installation issues ==
{{Anchor|keyboard-live}}
=== Live installer crashes on adding a keyboard layout ===
<small>[[Common F20 bugs#keyboard-live|link to this item]] - [[rhbug:1009278|Bugzilla: #1009278]]</small>
The Fedora 20 Alpha live installer will crash immediately if you visit the Keyboard spoke and attempt to add a layout. This bug and the fix for it were introduced and identified shortly before Alpha release, and there was not quite time to get the fix included.
[http://koji.fedoraproject.org/koji/buildinfo?buildID=466095 anaconda-20.19] fixes the bug: if you want to do a live install and modify the keyboard layout configuration during installation, install that version of anaconda into the live system prior to running the installer. It is not available as an update at present, but you can download and install the build directly from the link.
Otherwise, you can simply defer keyboard configuration until post-install, or use a traditional installer image instead of the live image.
{{Anchor|btrfs-root-crash}}
=== Installer crashes when creating a custom btrfs layout or assigning / mount point to an existing volume ===
<small>[[Common F20 bugs#btrfs-root-crash|link to this item]] - [[rhbug:1004572|Bugzilla: #1004572]]</small>
Multiple reports indicate that the Fedora 20 Alpha installer will crash with the error ''AttributeError: 'NoneType' object has no attribute 'id''' in at least two general scenarios:
* If you set the storage type drop-down on Installation Options to ''btrfs'', enter custom partitioning, and create a partition
* If you assign the / mount point to an existing ext4 partition (or likely any existing storage volume) during custom partitioning
[https://admin.fedoraproject.org/updates/FEDORA-2013-16042/python-blivet-0.22-1.fc20 python-blivet-0.22-1.fc20] fixes this issue, but was not included in Fedora 20 Alpha. You can work around the bug by booting a live image and updating to that build of python-blivet before running the live installer. Otherwise, there is no exact workaround for this crash besides handling partitioning in a way which avoids either of those actions. This issue will be resolved for the release of Fedora 20 Beta.
{{Anchor|nfs-installer-crash}}
=== Installer crashes if NFS ISO repository is used ===
<small>[[Common F20 bugs#nfs-installer-crash|link to this item]] - [[rhbug:1009809|Bugzilla: #1009809]]</small>
Testing suggests that the Fedora 20 Alpha installer is likely to crash with the error ''KeyError: 'name''' if you attempt to use an NFS repository containing an ISO file as an install source. As we currently understand the issue, an NFS repository containing a full repository tree (rather than an ISO file) should work, and FTP and HTTP repositories have also been tested to work: please use one of these or another method instead of NFS ISO for Alpha testing.
{{Anchor|mac-uefi-esp}}
=== Apple EFI Macs: EFI install alongside existing EFI installed OS (including OS X) results in ''you have not created a bootloader stage1 target device'' error ===
<small>[[#mac-uefi-esp|link to this item]] - [[rhbug:1010495|Bugzilla: #1010495]]</small>
If you try to do a native UEFI install of Fedora 20 alongside a native UEFI install of OS X and re-use the existing EFI system partition, the installer will incorrectly consider the existing EFI system partition as invalid and report that ''you have not created a bootloader stage1 target device''. Unfortunately, the Fedora automatic partitioning algorithm will actually attempt to re-use the EFI system partition, and so you will run into this bug in any Fedora 20 installation attempt where you use the automatic partitioning algorithm and do not choose to delete the existing EFI system partition.
Practically speaking, there are a few different approaches to dealing with this problem. If you do not mind losing your OS X installation, you can simply choose to delete it (including the EFI system partition), and let Fedora occupy the rest of the disk. Fedora should create a new EFI system partition and install successfully.
If you wish to preserve your OS X installation, install Fedora 20 Final, and dual boot, you must use the installer's 'custom partitioning' path. Make sure to leave the existing EFI system partition intact, but do '''not''' set a mount point for it. Do '''not''' use the ''Create partitions for me'' button. Instead, manually create a new EFI system partition, and set it to be mounted at {{filename|/boot/efi}}. Manually create other partitions as usual. Complete custom partitioning, and your installation should proceed successfully. See the [https://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ Installation Guide] for general instructions on the partitioning process, if necessary.
You could also try installing Fedora 18 or Fedora 19 Beta. These should allow you to use automatic partitioning to install alongside OS X, assuming you do not run into any other bugs they may have contained. You could then [[Upgrading_Fedora_using_yum|upgrade to Fedora 20 with yum]]. You will still wind up with two EFI system partitions in this case.
{{Anchor|keyboard-console}}
{{Anchor|keyboard-console}}
=== Non-US keyboard layouts don't work at console ===
=== Non-US keyboard layouts don't work at console ===
Line 102: Line 63:
Placing /boot on a btrfs volume results in a kernel panic on reboot. Running either of the below commands (based on your setup) after a kernel update will fix this issue.  
Placing /boot on a btrfs volume results in a kernel panic on reboot. Running either of the below commands (based on your setup) after a kernel update will fix this issue.  


BIOS: <code>grub2-mkconfig -o /boot/grub2/grub.cfg</code>
BIOS: {{command|grub2-mkconfig -o /boot/grub2/grub.cfg}}


UEFI: <code>grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg</code>
UEFI: {{command|grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg}}


Then reboot your machine.
Then reboot your machine.


== Hardware issues ==
== Hardware issues ==
 
{{Anchor|arm-beagle-bone}}
=== ARM: Beagle Bone Black HDMI issues ===
=== ARM: Beagle Bone Black HDMI issues ===
<small>[[Common F20 bugs#arm-beagle-bone|link to this item]] - [[rhbug:1012025|Bugzilla: #1012025]]</small>
<small>[[Common F20 bugs#arm-beagle-bone|link to this item]] - [[rhbug:1012025|Bugzilla: #1012025]]</small>


Some testers have reported that attempting to run the Beagle Bone Black over HDMI doesn't currently work. At the moment to use the Beagle Bone Black you need a Serial Console. As on Fedora 20 Beta TC4 the Network/MMC/Serial console currently works and the BBone Black successfully boots. Further kernel updates to resolve the other outstanding issues will be forthcoming.
Some testers have reported that attempting to run the Beagle Bone Black over HDMI doesn't currently work. At the moment to use the Beagle Bone Black you need a serial console. As on Fedora 20 Beta TC4 the Network/MMC/Serial console currently works and the BBone Black successfully boots. Further kernel updates to resolve the other outstanding issues will be forthcoming.
 
{{Anchor|arm-beagle-bone-remove}}


== Software issues ==
== Software issues ==
{{Anchor|gnome-software-updates}}
=== Updating system with GNOME Software fails ===
<small>[[Common F20 bugs#gnome-software-updates|link to this item]] - [[rhbug:1009132|Bugzilla: #1009132]]</small>
Some testers have reported that attempting to update a Fedora 20 Alpha system using the new GNOME Software application fails, with the error ''updates-plugin-WARNING **: failed to download: The backend exited unexpectedly.'' visible in system logs. If you are affected by this, we recommend updating using the older {{command|gpk-update-viewer}} utility for now, or simply {{command|yum}} from a console.
{{Anchor|gnome-software-remove}}
=== Removing applications with GNOME Software fails ===
<small>[[Common F20 bugs#gnome-software-remove|link to this item]] - [[rhbug:1013209|Bugzilla: #1013209]]</small>
Some testers have reported that attempting to remove software from a Fedora 20 Alpha system using the new GNOME Software application fails, with segmentation fault of the GNOME Software application.  If you are affected by this, we recommend removing software using {{command|yum}} from a console.  This shouldn't happen anymore with GNOME-Software 3.10.1
{{Anchor|missing-mouse}}
{{Anchor|missing-mouse}}
=== Disappearing mouse cursor ===
=== Disappearing mouse cursor ===
<small>[[Common F20 bugs#missing-mouse|link to this item]] - [[rhbug:1008965|Bugzilla: #1008965]]</small>
<small>[[Common F20 bugs#missing-mouse|link to this item]] - [[rhbug:1008965|Bugzilla: #1008965]]</small>
Line 138: Line 84:


Moving to another tty and back typically resolves the issue.
Moving to another tty and back typically resolves the issue.
{{Anchor|network-icon}}
=== Wired connection indicator ===
<small>[[Common F20 bugs#network-icon|link to this item]] - [[rhbug:1005719|Bugzilla: #1005719]]</small>
In Fedora 20 Alpha, for wired connections, the network-manager-applet displays an 'X' over the network icon, regardless of connectivity. The fix for this issue has been pushed to stable, but we are noting it here as it is highly visible on initial installation. Note that the fix for this issue is that no connection indicator will be shown ''at all'' for wired connections after update: this is a GNOME 3.10 design decision, not a bug in itself. A connection indicator will still be shown for all forms of wireless connection.
To fix this issue simply run {{command|su -c 'yum update NetworkManager'}} and then reboot the system or simply {{command|su -c 'systemctl restart NetworkManager.service'}}.


{{Anchor|php-zip}}
{{Anchor|php-zip}}
Line 159: Line 97:
<small>[[Common F20 bugs#kde-vm|link to this item]] - [[rhbug:1027831| Bugzilla: #1027831]]</small>
<small>[[Common F20 bugs#kde-vm|link to this item]] - [[rhbug:1027831| Bugzilla: #1027831]]</small>


After installing KDE from RC5 or earlier, KDE will crash shortly after login. The workaround is to disable Desktop Effects (Alt+Shift+F12) after login and update the xorg-x11-drv-qxl-0.1.1-0.14.fc20 package to xorg-x11-drv-qxl-0.1.1-2.fc20. Simply run <code>su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-2.fc20'</code> to update.
When installing Fedora 20 Beta with the KDE desktop to a KVM-based virtual machine using the qxl virtual graphics adapter and driver, KDE will likely crash shortly after login. This can be worked around by disabling Desktop Effects. (Alt+Shift+F12) toggles desktop effects, and you can set them not to be enabled by default in the KDE Control Center.
 
An updated [http://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-2.fc20 xorg-x11-drv-qxl] 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/xorg-x11-drv-qxl-0.1.1-2.fc20 report to Bodhi] whether it solves the problem. To test the update, run this command:
<pre>su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-qxl'</pre>


{{Anchor|plasma-nm}}
{{Anchor|kde-live-wireless}}
=== KDE live networking doesn't work ===
=== KDE live wireless networking doesn't work ===
<small>[[Common F20 bugs#KDE-live-networking|link to this item]] - [[rhbug:1004621|Bugzilla: #1004621]]</small>
<small>[[Common F20 bugs#kde-live-wireless|link to this item]] - [[rhbug:1004621|Bugzilla: #1004621]]</small>


When using a Fedora 20 Beta KDE live image, the plasma-nm applet doesn't connect to available networks. The workaround is to logout and then log back in and connect.
When using a Fedora 20 Beta KDE live image, the plasma-nm applet doesn't connect to available networks. The workaround is to logout and then log back in and connect.
Line 171: Line 112:
<small>[[Common F20 bugs#seahorse-keyring|link to this item]] - [[rhbug:1012844|Bugzilla: #1012844]]</small>
<small>[[Common F20 bugs#seahorse-keyring|link to this item]] - [[rhbug:1012844|Bugzilla: #1012844]]</small>


In Fedora 20 Beta Gnome, if you open Seahorse (or "Passwords and Keys") and attempt to change the password of your keyring to an empty string or create a new keyring without a password, gnome shell crashes. The workaround for this is to always use a password on your keyring. A patch is currently pending from upstream to fix this issue.
In Fedora 20 Beta with the GNOME desktop, if you attempt to create a new keyring without a password or change the password of your keyring to an empty string (you may do this from the "Passwords and Keys" application, or you may be prompted to create a keyring password the first time GNOME attempts to store some kind of key), the GNOME shell will crash. The workaround for this is to always use a password on your keyring. A patch is currently pending from upstream to fix this issue.

Revision as of 23:55, 12 November 2013

This page documents common bugs in Fedora 20 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.

Note.png
Fedora 20 pre-release
Fedora 20 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 20 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 F20_Alpha_release_announcement for specific information about changes in Fedora 20 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)


Installation issues

Non-US keyboard layouts don't work at console

link to this item - Bugzilla: #1028207

Fedora 20 Beta installation won't honor the keymap picked during installation in virtual terminals or when decrypting the filesystem. X, however, will retain the keymap picked during installation. The current workaround is to simply defer picking a keymap until after installation.

Btrfs /boot partition results in a kernel panic after kernel update

link to this item - Bugzilla: #864198

Placing /boot on a btrfs volume results in a kernel panic on reboot. Running either of the below commands (based on your setup) after a kernel update will fix this issue.

BIOS: grub2-mkconfig -o /boot/grub2/grub.cfg

UEFI: grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Then reboot your machine.

Hardware issues

ARM: Beagle Bone Black HDMI issues

link to this item - Bugzilla: #1012025

Some testers have reported that attempting to run the Beagle Bone Black over HDMI doesn't currently work. At the moment to use the Beagle Bone Black you need a serial console. As on Fedora 20 Beta TC4 the Network/MMC/Serial console currently works and the BBone Black successfully boots. Further kernel updates to resolve the other outstanding issues will be forthcoming.

Software issues

Disappearing mouse cursor

link to this item - Bugzilla: #1008965

After logging in to a desktop in Fedora 20 Alpha, the mouse cursor can become invisible. The mouse still functions, but can't be seen. This has been seen occasionally in testing on bare metal and more often in testing on virtual machines. It definitely affects GNOME and may affect other desktop environments.

Moving to another tty and back typically resolves the issue.

ZIP support in PHP

link to this item - Bugzilla: #999313

In Fedora 20, support from ZIP have been dropped from main php package and is now provided in a separate php-pecl-zip package.

If you need zip support, as for any other extension, run su -c 'yum install php-zip'

KDE crashes when in a VM

link to this item - Bugzilla: #1027831

When installing Fedora 20 Beta with the KDE desktop to a KVM-based virtual machine using the qxl virtual graphics adapter and driver, KDE will likely crash shortly after login. This can be worked around by disabling Desktop Effects. (Alt+Shift+F12) toggles desktop effects, and you can set them not to be enabled by default in the KDE Control Center.

An updated xorg-x11-drv-qxl package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-qxl'

KDE live wireless networking doesn't work

link to this item - Bugzilla: #1004621

When using a Fedora 20 Beta KDE live image, the plasma-nm applet doesn't connect to available networks. The workaround is to logout and then log back in and connect.

Gnome-shell crashes after creating a keyring without a password

link to this item - Bugzilla: #1012844

In Fedora 20 Beta with the GNOME desktop, if you attempt to create a new keyring without a password or change the password of your keyring to an empty string (you may do this from the "Passwords and Keys" application, or you may be prompted to create a keyring password the first time GNOME attempts to store some kind of key), the GNOME shell will crash. The workaround for this is to always use a password on your keyring. A patch is currently pending from upstream to fix this issue.