Common F17 bugs
This page documents common bugs in Fedora 17 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.
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)
Attempting to chainload after installing Fedora 17 Beta's bootloader to a partition fails
If you choose to install the Fedora 17 Beta bootloader to the first sector of a partition (rather than to the MBR) and then try to 'chainload' it from whatever bootloader is installed in the MBR, the system will likely hang at a screen saying only 'GRUB'. This seems to be caused by a bug in grub2 itself.
It has been discovered that this bug can be worked around, at least if the host bootloader is grub or grub2, by using a host bootloader entry which loads the core.img of Fedora 17's grub2 as if it were a kernel, rather than using the 'chainloader' statement. See this comment for an example entry.
We believe a fix for this bug is available from grub2 upstream, and we will provide an updated grub2 package soon.
Cannot resize NTFS partitions during Fedora 17 Beta installation
Due to a bug in the
utility which creates the runtime environment for the Fedora installer - the libraries required by the 'ntfsresize' utility are deleted from the environment - it is not possible to resize NTFS partitions during installation of Fedora 17 Beta from the DVD or network installer images. You will get an error message if you try to do so.
The only way to 'work around' this issue is to do any needed NTFS partition resizing in some other environment - such as a live boot - prior to installing Fedora 17 Beta, or to install from a live image (NTFS resizing should work when running the installer from a live image). This issue will be resolved for the final release of Fedora 17.
Systems hangs on X startup with NVIDIA GeForce GTX 580 adapter (affects installation)
It has been reported that a bug in the nouveau video driver causes systems with an NVIDIA GeForce GTX 580 video adapter to hang as soon as the X graphical environment starts up. This issue also affects installation, so as soon as X is started, installation hangs.
This issue can be worked around by disabling hardware acceleration. To do this, pass the kernel parameter nouveau.noaccel=1. You can append kernel parameters at boot time - of a live image, DVD or network install image, or an installed system - by hitting the Tab key when the system reaches the bootloader menu, and typing in the desired additional parameter.
You can make the workaround 'permanent' on an installed system either by editing it into the
/boot/grub2/grub.cfg file, or by creating a file named
/etc/modprobe.d/noaccel.conf containing a single line reading:
options nouveau noaccel=1
Some translations missing after DVD install of Fedora 17 Beta (KDE, LibreOffice, a few others)
Some packages in Fedora use the 'langpacks' system for translations, where translations are packaged separately from the main package. Due to changes in the package groups definitions, in Fedora 17 Beta, these 'langpacks' translation packages have been inadvertently omitted from the DVD image (in previous releases, they were present on the DVD). This means that if you do a DVD installation without enabling remote repositories, the translation packages will not be installed for any of these packages that are included in the initial installation. Translation packages will be included if you install the packages via yum or PackageKit later - the bug is only an issue at initial install time. System updates will not add the translation packages for any affected packages, however - if you are affected by this bug at installation time, you will have to install the translation packages manually with yum or PackageKit.
Packages known to use langpacks include the KDE desktop, LibreOffice, man-pages and hunspell. So if you do a default DVD installation and you use a non-English language, you will find translations are not installed for LibreOffice, hunspell (and so for anything which uses hunspell for spell checking), or man-pages (the man pages for several core commands are included in this compendium package). If you install KDE from the DVD, you will similarly find the translations missing.
To work around this bug at installation time when using the DVD, ensure you enable remote repositories when given the opportunity. If you have already been affected by the bug, you can manually install the appropriate translation packages with yum or PackageKit. For instance, if you use French and you wish to restore the KDE and LibreOffice translations, you would install the
This issue will be corrected for the final release - the langpacks will be included in the DVD.
GNOME fails to start due to gnome-settings-daemon crash if system date is earlier than 2012-02-01
A bug in gnome-settings-daemon, a core component of the GNOME desktop, causes it to crash if the system date is earlier than the 'starttime' specified in the configuration file for the active desktop background theme. The default Fedora 17 Beta background theme specifies a 'starttime' of 2012-02-01, so if the system date is earlier than this, gnome-settings-daemon will crash and GNOME will fail to start up correctly (it will display the 'Oh no! Something has gone wrong' error screen).
To work around this issue, correct the system date, or at least set it to something later than 2012-01-31.
An updated gnome-settings-daemon 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 gnome-settings-daemon'(although it may be better to do a full update, as the update is part of a much bigger GNOME 3.4.1 update).
DKMS broken due to executable being named dkms.old instead of dkms
package contains a very old post-install scriptlet which checks for
/sbin/dkms and renames it to
/sbin/dkms.old. This appears to have been intended to prevent an old copy of dkms in /sbin from overriding the Fedora-provided copy in /usr/sbin. However, with the /usr move feature in Fedora 17,
/sbin is a symlink to
/usr/sbin, and consequently the Fedora package itself effectively provides a copy of
/sbin/dkms - which its own script promptly renames. The upshot is that there is no 'dkms' executable after installation of Fedora 17's
package, and so DKMS fails to work at all.
We will issue an update to resolve this bug shortly.
Restarting libvirtd service (including updating libvirt package) kills running virtual machines
It has long been the case that you can restart the libvirtd service without affecting running KVM virtual machines. This is often suggested as part of troubleshooting virtualization issues, and updating the
package usually restarts the service. However, a change in systemd means that, with the versions of
included in Fedora 17 Beta, restarting the libvirtd service kills (i.e. uncleanly shuts down) all running virtual machines.
We strongly recommend that, if you are planning to run any virtual machines with Fedora 17 Beta as a host, you configure yum not to automatically update the
package (see the exclude keyword in
man yum.conf for details on doing this), and shut down all running virtual machines manually prior to restarting the libvirtd service manually, or updating the
package manually. It is, of course, not a good idea to use any pre-release version of Fedora as a host for important virtual machines: pre-release versions of Fedora should never be relied on for any kind of mission critical operation.
A systemd update which resolves this issue should be available quite soon.
PackageKit sometimes locks yum too frequently and for too long
Some testers have reported that, in Fedora 17 Beta, PackageKit background operations seems to hold the yum lock (preventing any manual use of yum or PackageKit) much more frequently, and for longer periods of time, than was the case in previous releases. There is currently no clear indication of why this is, or any known workaround; we are at the early stages of investigating the problem. It is noted here purely for information.