Common F20 bugs

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(/root permissions incorrect on pre-release installations)
(add 1018017 (dbus error spam with ModemManager installed but disabled))
Line 234: Line 234:
  
 
This may be disconcerting, but testing indicates it does not actually prevent the screen reader applications from working correctly; you can safely proceed to use them. It is not necessary to report the crash, as the issue is already known and we are attempting to find a solution, but it will not harm anything if you do.
 
This may be disconcerting, but testing indicates it does not actually prevent the screen reader applications from working correctly; you can safely proceed to use them. It is not necessary to report the crash, as the issue is already known and we are attempting to find a solution, but it will not harm anything if you do.
 +
 +
{{Anchor|modemmanager-dbus-spam}}
 +
=== Repeated dbus error messages logged with ModemManager.service disabled ===
 +
<small>[[Common F20 bugs#modemmanager-dbus-spam|link to this item]] - [[rhbug:1018017|Bugzilla: #1018017]]</small>
 +
 +
If you have NetworkManager installed and active, but you disable ModemManager.service - which you might well choose to do if you have no cellular modem - this will result in error messages being printed to the system logs every two minutes:
 +
<pre>
 +
Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service'
 +
Dec 14 09:27:02 localhost dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service'
 +
Dec 14 09:27:02 localhost dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.
 +
Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.
 +
</pre>
 +
There is no more serious consequence of this problem, but you may find the log spam annoying. You can avoid it by re-enabling ModemManager.service, or by removing ModemManager entirely with {{command|su -c 'yum remove ModemManager'}}.

Revision as of 18:42, 14 December 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.

Contents

Release Notes

Read the Fedora 20 release announcement and the Fedora 20 release notes 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)


Major issues

System fails to boot after install using LVM Thin Provisioning

link to this item - Bugzilla: #1040669

Fedora 20 introduces install-time support for LVM Thin Provisioning as a feature. Unfortunately, a late change to fix another serious bug inadvertently introduced a serious bug in this support. If you install Fedora 20 using the release packages (a live install, DVD install, or network install using a repository that contains the frozen release-time package set rather than including updates) and place any system partition (/home and other data partitions are not affected) on a thin-provisioned LV, the installed system will fail to boot. After a delay of 2-3 minutes, it will drop you an emergency mode. The cause of the bug is that tools needed for accessing thin provisioned LVs are erroneously left out of both system-specific and generic initramfs builds due to the broken change in Dracut, the tool that generates the initramfs.

There is no simple workaround for this issue if you are affected by it. Obviously, you can avoid it by not installing to thin-provisioned LVM. Once the fix for the issue reaches the official repositories, which should be soon, network installs which include the update repository should not be affected by the issue.

If you do find yourself affected by the issue and wish to rescue the installation rather than re-install, you can use the installer's rescue mode.

Boot to rescue mode and choose Continue to mount your installed system and go to a shell. Now run the following:

chroot /mnt/sysimage /bin/bash
yum update --enablerepo=updates-testing --advisory=FEDORA-2013-23326
dracut -f
exit
reboot

This should update Package-x-generic-16.pngdracut to the fixed version and re-generate the initramfs to include the necessary tools. Now your system should boot normally (though an SELinux relabel may run on the first boot).

Crash when switching from a complete repository to a DVD-based repository: NoSuchGroup: 3d-printing

link to this item - Bugzilla: #1033749

If you start a Fedora 20 (non-live) install and configure a repository with a complete set of packages - such as the default remote repository configuration, or any full Fedora 20 mirror - then switch to a remote repository which contains only the restricted set of packages on the DVD image - such as a repository which simply is the DVD image, accessed via any protocol, or any other repository somehow generated solely from the DVD package set - the installer will likely crash with a NoSuchGroup: 3d-printing error.

In practice what this means is if you boot the network install image entirely normally, with an active network connection - so that the default remote repository is automatically configured - and then attempt to switch to, say, an NFS or HTTP repository which just contains the DVD ISO image (or has the contents of the DVD ISO image mounted or copied to it), the installer will likely crash.

There are several possible workarounds for this. You can simply set things up so your install repository contains the full package set, not the subset from the DVD image. You can pass in your desired repository configuration with the inst.repo boot parameter or using a kickstart with the repo command - this will cause your chosen repository to be configured straight away, and so avoid the bug. Or you can boot with the askmethod parameter, which has the effect of telling the installer not to try and configure the default remote repository automatically, but to wait for you to enter the Installation Source hub and choose a repository configuration yourself, which again should avoid the bug. You could even boot from the DVD image itself, though that does not seem likely to be a very useful workaround for the majority of cases where you would actually want to install from a separate repository containing only the DVD image file or contents.

/root permissions incorrect on pre-release installations

link to this item - Bugzilla: #1037688

This issue does not affect systems installed with or upgraded after the release of the final release version of Fedora 20, but we are documenting it as it may be of significant interest to those who used Fedora 20 prior to release.

If you used any Fedora 20 pre-release (or test compose or release candidate build), the permissions on the /root directory are likely to be incorrect: an older version of the Package-x-generic-16.pngrootfiles package set the permissions to 0755 (users other than root can read files in the /root directory). We felt it not a good idea to try and fix this with an update, as sysadmins who manually change their /root permissions would not want us to override those changes, but we would like to make those who installed from pre-releases aware of the issue. The usual default Fedora permissions (and those set by the final release version of Fedora 20) are 0550. You can run su -c 'chmod 0550 /root' to set those permissions, which will prevent users other than root from reading files in /root.

Installation issues

Problem with Installation Source spoke when installing from a partially complete kickstart

link to this item - Bugzilla: #972265

If you attempt to install Fedora 20 using a partially-complete kickstart - in particular, a kickstart which specifies a package set but no installation source - you will find that the interactive process for setting that option behaves strangely. On the Installation Source spoke, you may not be able to use the default Closest mirror option. If you are affected by this problem, you can manually enter the URL of the Fedora 20 mirror list, and check the This URL refers to a mirror list. box. The URLs for the 64-bit and 32-bit mirror lists are https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=x86_64 and https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=i386 respectively.

Network configuration changes made after clicking Configure in installer (nm-connection-editor) are not applied unless interface is turned off and on again

link to this item - Bugzilla: #1018471

The Fedora installer's network configuration screen has a button labelled 'Configure', which launches the nm-connection-editor utility to allow configuration of the network connection. Due to issues in the interaction between the installer and the separate nm-connection-editor process, configuration set in the nm-connection-editor process will not take effect unless and until you turn the connection off and then on again. We will attempt to remedy this for future Fedora releases, but it now cannot be resolved in Fedora 20, as the installer cannot be updated after release.

In custom partitioning, cannot change size of a pre-existing LV after setting a mount point for it and scheduling it to be reformatted

link to this item - Bugzilla: #1040445

If you use custom partitioning while installing Fedora 20 to a system with a pre-existing LVM LV, assign a mount point to that LV, and set it to be re-formatted, you will no longer be able to request that its size be changed. Any attempts to change the 'Desired Capacity' field and hit 'Update Settings' will result in the size returning to the previous value.

This issue is easy to work around; as long as the volume is not both assigned a mount point and scheduled to be reformatted, you can successfully adjust its size (as long as that adjustment is achievable within the container, of course). So if you run into this problem, simply temporarily undo the mount point assignment and/or 'reformat' check box, make the size change, and then re-apply the mount point and 'reformat'.

In custom partitioning, cannot change size of a pre-existing partition then reset it to initial value

link to this item - Bugzilla: #1040352

If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing partitions, then change the target size of any partition and subsequently change your mind and decide you did not want to resize it after all, you will not be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.

If you do run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.

In custom partitioning, cannot change size of a pre-existing LV multiple times then reset it to initial value

link to this item - Bugzilla: #1040413

If you use custom partitioning while installing Fedora 20 to a system with one or more pre-existing LVM LVs, and change the target size of an LV more than once during one custom partitioning 'run', you will no longer be able to set it back to precisely its original size (and cancel the resize request). Any attempt to do so will cause the value to change to a previous setting, which can look quite strange.

If you're a bit indecisive about what size you want your LVs to be and run into this problem, you can work around it by hitting the 'Reset All' button, which will let you start over from scratch with the storage configuration as it actually exists on the disk(s) prior to Fedora 20 installation beginning.

Installation crashes during partitioning if disk was scanned after an encrypted volume has already been unlocked

link to this item - Bugzilla: #1008732

This is a complex issue. Broadly speaking, if you somehow trigger the installer to do a disk scan after having already accessed a previously-existing encrypted storage volume, then the installation may crash during the partitioning stage with the error LUKSError: luks device not configured. The bug report contains several different possible reproduction scenarios; all are fairly involved, but it is something you may be most likely to run into when installing to a system with an existing encrypted storage volume and then running through partitioning multiple times or using the Refresh Disks function in the custom partitioning screen.

As there are various ways to encounter this issue and they are all quite involved it's difficult to suggest a precise workaround, but broadly speaking, the workaround is to reboot and try the install again, without using the Refresh Disks button (which actually rescans the disks on the system, as opposed to Reset all which just resets the custom partitioning screen to the state it was in when you first entered - it is safe to use that button) or running the installer or the partitioning phase multiple times.

Exiting shell from rescue mode does not return to menu or reboot, but sticks at Pane is dead

link to this item - Bugzilla: #1038855

If you use the Fedora 20 installer's rescue mode, and enter the interactive shell to try and rescue your installed system, then on exiting the shell it would be expected that you would return to the top-level rescue mode menu, or perhaps that the system would reboot. Instead, you wind up stuck on a screen that says Pane is dead. At this point, your partitions are still mounted, and a hard reset could possibly cause data loss. Do not do a hard shut down or reboot. You can hit ctrl-alt-f2 to get a second shell and run 'reboot', or just hit ctrl-alt-del to trigger a clean reboot.

Upgrade issues

Upgrade from Fedora 18 with fedup 0.8 fails due to GPG key problems

link to this item - Bugzilla: #1040689

Version 0.8 of the FedUp upgrader adds checking of GPG keys on packages as a feature. However, this requires that the version of Fedora you are upgrading from have the package signing keys of the version of Fedora you are upgrading to available. At present, the Fedora 20 package signing keys are not correctly available in Fedora 18, so if you try to upgrade from Fedora 18 to Fedora 20 using a 0.8 version of fedup, it will fail at the end of the package download phase with the error message Downloading failed: The GPG keys listed for the "Fedora 20 - x86_64" repository are already installed but they are not correct for this package.

At time of writing, the Fedora 18 repositories do not contain fedup 0.8, but users may find it available through Koji or other means. We will aim to ensure fedup 0.8 is not made available through the Fedora 18 repositories until an update is provided that makes the relevant package signing keys correctly available as well. upgrades using fedup 0.7, as presently available in the Fedora 18 repositories, will not encounter this issue.

If, for some reason, you need to upgrade using fedup 0.8 - for instance, it fixes a bug you are encountering using fedup 0.7 - you can work around this issue by passing the --nogpgcheck parameter to fedup. As the name suggests, this disables the GPG check.

Hardware issues

ARM: HDMI output and USB peripherals not working on Beagle Bone Black

link to this item - Bugzilla: #1012025

Fedora 20 GA has non functional USB/HDMI. At the moment, to use the Beagle Bone Black, you will need a serial console attached to the 6 ping serial header. There's full details here. The 3.12.5 kernel has full working usb/hdmi/network. It is currently in the kernel-nodebug repository, but there is a low expectation of support or testing of nodebug kernels. The 3.12 kernel should make it to updates-testing soon. Unofficial updated images are planned to be made available by the Fedora ARM team for the convenience of Beagle Bone Black users shortly after the 3.12 kernel lands with the only difference being the 3.12 kernel in the image.

Software issues

ZIP support in PHP

link to this item - Bugzilla: #999313

In Fedora 20, support from ZIP has 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'.

GNOME Shell crashes after creating a keyring without a password

link to this item - Bugzilla: #1012844

In Fedora 20 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.

An updated clutter 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. However, note that one tester has reported that the update causes graphical corruption issues on an Intel video adapter. To test the update, run this command:

su -c 'yum --enablerepo=updates-testing update --advisory=FEDORA-2013-22280'

Panorama Stitcher application crashes when launched from system menus in KDE

link to this item - Bugzilla: #1040922

Attempting to launch the application Panorama Stitcher from the KDE menus in Fedora 20 will result in it crashing. This application is only present on the menus by default if you install from DVD, not if you install from the KDE live image. The panorama function is really one of the many Kipi image manipulation plugins for KDE, and is usually expected to be accessed from a Kipi-enabled graphics manipulation application; its presence in the menus is only a convenience. If you do want to invoke the panorama function directly, you can call it with some image files as arguments - panoramagui image.jpg image2.jpg image3.jpg ... - and it will run successfully.

An updated digikam 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 --advisory=FEDORA-2013-23252'

Cannot browse / discover SMB/CIFS (Windows, Samba) shares with firewalld enabled

link to this item - Bugzilla: #1038959

Testing has indicated that, in Fedora 20, it is not possible to browse SMB/CIFS shared resources - i.e. Windows or Samba file or device shares - with the default FirewallD firewall enabled, even if you enable the 'samba-client' firewalld service. By comparison, in Fedora 19, browsing appears to work even without needing to enable that service. The issue is not specific to a particular desktop or file manager utility, it seems to be an issue in the firewalling layer. You can connect to a share by entering the path explicitly, and shares that are advertised via zeroconf/Bonjour may show up when you browse.

Besides using zeroconf or simply directly entering share addresses, there are two possible workarounds for the bug, but neither is without consequences. You can simply disable the firewall (from the firewall configuration tool, or with su -c 'systemctl stop firewalld.service'), or place the relevant network interface in the 'trusted' firewall zone (which allows all traffic to and from that interface, so is more or less identical in effect to disabling the firewall) - you can do this from your desktop's network configuration utility. Either of these approaches, obviously, results in your losing the security benefits of the firewall. Alternatively, you can configure a custom firewalld rule to accept all from source port 137/udp; this is less drastic than disabling the firewall entirely, but still possibly constitutes a slight lowering of protection.

If you do use a workaround to enable browsing, we would suggest doing so only long enough to discover the shares you wish to configure, then setting up some sort of permanent configuration / bookmark for them, so you no longer need the browsing functionality and can drop the workaround.

We are currently investigating and attempting to come up with a correct resolution for this problem.

libvirt guests are killed on host shutdown

link to this item - Bugzilla: #1031696

When hosting virtual guests via libvirt in recent Fedora releases it is intended that, if you shut the host down with the guests still running, they will be suspended and then resumed when you boot the host up again. This does not currently work in Fedora 20. If you shut the host down with guests running, they will simply be uncleanly shut down (the processes are killed).

We are currently investigating to try and find a fix for this issue. In the mean time, if your virtual guests are of any value to you, please shut them down cleanly before shutting down the host. We apologize for any inconvenience this may cause.

KVM guests using the qxl graphics driver may display sluggish graphics performance on Fedora 20 hosts

link to this item - Bugzilla: #1020393

With a sufficiently recent version of Fedora's virtualization stack, such as that in Fedora 20, a feature is available for guests that use the qxl virtual graphics adapter and driver which is intended to provide smooth playback of video in the guest guests. However, it seems this 'streaming' mode can erroneously be invoked when certain non-video operations happen in guest machines, and this causes very sluggish graphics performance and artifacting. In particular, the way GNOME 3 handles screen redraws means this problem affects guests running GNOME 3 very badly, but it can also be seen on other desktops in certain circumstances, such as when scrolling through a web page that contains many large images.

We have implemented a workaround for the qxl driver in Fedora 20 which means that Fedora 20 guests are not affected by this bug, and we will likely provide the workaround for Fedora 19 as an update. However, the bug may still be observed on other guest operating systems that include a qxl driver which is new enough to take advantage of the streaming feature, but does not contain this workaround. If you are unfortunate enough to be affected, you can edit the configuration of the virtual machine (e.g. via virsh), and change the line that looks like this:

    <graphics type='spice' autoport='yes'/>

to look like this instead:

    <graphics type='spice' autoport='yes'>
      <streaming mode='off'/>
    </graphics>

This disables the 'streaming' feature for the virtual machine, which should completely avoid the problem occurring on any guest operating system.

Alternative on-screen keyboards do not work correctly in GNOME

link to this item - Bugzilla: #1019073

A bug in the Package-x-generic-16.pngmutter window manager for GNOME 3 means that on-screen keyboards other than GNOME's own native one (available from the 'Universal Access' control panel applet or panel menu if enabled) will not work correctly: clicking on a key on the keyboard will not result in the character appearing in the currently-active application.

An updated package that addresses this issue should be available soon.

Crash in speech-dispatcher process when launching GNOME or KDE screen readers

link to this item - Bugzilla: #995639

Both GNOME and KDE desktops in Fedora 20 include a screen reader application, a tool for visually-impaired users which reads the contents of the screen aloud. GNOME's is Package-x-generic-16.pngorca, KDE's is Package-x-generic-16.pngjovie. Commonly, when launching either of these, you will be notified of a crash in the Package-x-generic-16.pngspeech-dispatcher component.

This may be disconcerting, but testing indicates it does not actually prevent the screen reader applications from working correctly; you can safely proceed to use them. It is not necessary to report the crash, as the issue is already known and we are attempting to find a solution, but it will not harm anything if you do.

Repeated dbus error messages logged with ModemManager.service disabled

link to this item - Bugzilla: #1018017

If you have NetworkManager installed and active, but you disable ModemManager.service - which you might well choose to do if you have no cellular modem - this will result in error messages being printed to the system logs every two minutes:

Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service'
Dec 14 09:27:02 localhost dbus[671]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service'
Dec 14 09:27:02 localhost dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.
Dec 14 09:27:02 localhost dbus-daemon[671]: dbus[671]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory.

There is no more serious consequence of this problem, but you may find the log spam annoying. You can avoid it by re-enabling ModemManager.service, or by removing ModemManager entirely with su -c 'yum remove ModemManager'.