Common F15 bugs

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Document bug#698654 and service upgrade bugs)
(cleanups (drop beta issues, tear out an unnecessary chunk of the systemd default runlevel essay))
Line 100: Line 100:
 
<small>[[#upgrade-runlevel|link to this item]] - [[rhbug:698654|Bugzilla: #698654]]</small>
 
<small>[[#upgrade-runlevel|link to this item]] - [[rhbug:698654|Bugzilla: #698654]]</small>
  
Depending on how Fedora 14 was initially installed, your system may not select the appropriate systemd boot target after upgrading to Fedora 15.  The problem is caused by replacing systemto  [[Features/systemd|systemd]] the <code>%postinstall</code> rpm script from the Fedora 14 package {{package|systemd-units}}.  Since {{package|systemd}} isn't the default in Fedora 14, the problem will not manifest until you upgrade to Fedora 15.   
+
Depending on how Fedora 14 was initially installed, your system may not select the appropriate systemd boot target after upgrading to Fedora 15.  The problem is caused by the <code>%postinstall</code> rpm script from the Fedora 14 package {{package|systemd-units}}.  Since {{package|systemd}} isn't the default in Fedora 14, the problem will not manifest until you upgrade to Fedora 15.   
 
+
When the {{package|systemd-units}} package is first installed on a system, it establishes the default system boot target (aka runlevel) based on how the system is being installed.  The following conditions must be true in order for an installed system to be configured for runlevel5 (or {{filename|graphical.target}})...
+
<ol>
+
<li> installation includes a package that provides <code>service(graphical-login)</code>
+
<li> installation includes the package {{package|xorg-x11-server-Xorg}}
+
<li> installation uses the graphical interface.  Confirm by inspecting {{filename|/var/log/anaconda/anaconda.log}} and check for the line:
+
<pre>12:53:41,962 INFO anaconda: Display mode = g</pre>
+
<li> installation does '''not''' use VNC.  The presence of the following information in the file {{filename|/var/log/anaconda/anaconda.log}} would indicate a VNC installation was performed.
+
<pre>16:35:30,686 INFO anaconda.stdout: The VNC server is now running.</pre>
+
</ol>
+
  
 
If you change the Fedora 14 default runlevel at any time by modifying the file {{filename|/etc/inittab}}, those changes will not affect the configured systemd default target.  After upgrade, you may need to manually adjust the configured systemd default target links using the following procedure.   
 
If you change the Fedora 14 default runlevel at any time by modifying the file {{filename|/etc/inittab}}, those changes will not affect the configured systemd default target.  After upgrade, you may need to manually adjust the configured systemd default target links using the following procedure.   
 
Confirm the systemd default target configuration by inspecting the {{filename|default.target}} symlinks as follows.  In the example below, the system has an inconsistent configuration which will cause confusion after upgrading.
 
<pre>
 
# ls -l /{etc,lib}/systemd/system/default.target
 
lrwxrwxrwx. 1 root root 36 Apr 14 09:51 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target
 
lrwxrwxrwx. 1 root root 16 May  4 07:40 /lib/systemd/system/default.target -> graphical.target
 
</pre>
 
  
 
To configure systemd to start a graphical login menu on boot (similar to runlevel 5 in Fedora 14):
 
To configure systemd to start a graphical login menu on boot (similar to runlevel 5 in Fedora 14):
Line 136: Line 119:
  
 
{{Anchor|networkmanager_shell}}
 
{{Anchor|networkmanager_shell}}
=== General buggy or missing functions in GNOME Shell network applet (hidden networks, WPA2 Enterprise, multiple configurations per interface, mobile broadband etc) ===
+
=== General buggy or missing functions in GNOME Shell network applet ===
 
<small>[[#networkmanager_shell|link to this item]]</small>
 
<small>[[#networkmanager_shell|link to this item]]</small>
  
Line 142: Line 125:
  
 
GNOME 3's fallback mode uses the old ''nm-applet'', and is not subject to this issue.
 
GNOME 3's fallback mode uses the old ''nm-applet'', and is not subject to this issue.
 
{{Anchor|hidden_wireless}}
 
=== Unable to connect to hidden wireless networks ===
 
<small>[[#hidden_wireless|link to this item]] - [[rhbug:691139|Bugzilla: #691139]]</small>
 
 
The GNOME 3 NetworkManager configuration interface in Fedora 15 Beta (the applet by the user menu, and the control center Network entry) contain a bug which causes them to hang if you try to configure a hidden wireless network by typing in its SSID. To work around this bug, you can run the standalone configuration tool {{command|nm-connection-editor}}, either by running it from a console, from the alt-f2 dialog, or by finding it in the Overview (it has the name ''Network Connections''). This tool is able to configure hidden networks correctly. This tool is a useful fallback for any situation where the GNOME 3 configuration interface is problematic or incomplete.
 
 
This issue was fixed in the updated ''control-center-3.0.0.1-3.fc15'' package. To solve the issue, update your Fedora 15 Beta installation as usual. You should no longer encounter this issue after updating to that version or later of {{package|control-center}}.
 
 
{{Anchor|nm_openconnect}}
 
=== Unable to connect to Cisco AnyConnect VPN ===
 
<small>[[#nm_openconnect|link to this item]] - [[rhbug:696107|Bugzilla: #696107]]</small>
 
 
The NetworkManager-openconnect package in Fedora 15 Beta has not been updated to work with NetworkManager 0.9, and connecting to a Cisco AnyConnect VPN is only possible using the command-line ''openconnect'' tool.
 
 
This issue was fixed in the updated ''[https://admin.fedoraproject.org/updates/NetworkManager-openconnect-0.8.1-9.git20110419.fc15 NetworkManager-openconnect-0.8.1-9.git20110419.fc15]'' package. You should no longer encounter this issue after updating to that version of later of {{package|NetworkManager-openconnect}}.
 
 
{{Anchor|bluez_upgrade}}
 
=== Bluetooth not working after upgrade to F15 Beta ===
 
<small>[[#bluez_upgrade|link to this item]] - [[rhbug:694519|Bugzilla: #694519]]</small>
 
 
If the system was upgraded to a version of bluez prior to 4.87-5.fc15, then the bluetoothd service would not have been updated to run under systemd. The permanent fix is to run:
 
 
''/bin/systemctl enable bluetooth.service''
 
 
as root
 
 
{{Anchor|fail_whale}}
 
=== ''Oh no! Something has gone wrong'' error screen always appears shortly after login ===
 
<small>[[#fail_whale|link to this item]] - [[rhbug:698190|Bugzilla: #698190]]</small>
 
 
Due to a problem with the Fedora update system, for a short time in the Fedora 15 repositories the {{package|gnome-shell}} package was at version 3.0.0.2-2.fc15 while the {{package|gnome-menus}} package was at version 3.0.0-1.fc15, despite the fact that gnome-shell-3.0.0.2-2.fc15 and gnome-menus 3.0.0-2.fc15 are part of a [https://admin.fedoraproject.org/updates/gnome-menus-3.0.0-2.fc15,gnome-shell-3.0.0.2-2.fc15,gnome-panel-3.0.0.1-2.fc15 single update]. This combination of packages results in an unavoidable crash in GNOME Shell shortly after it starts up. The first time it crashes, it will re-start itself and a crash notification will appear. The second time it crashes, the GNOME 3 ''Oh no! Something has gone wrong'' error screen will appear.
 
 
If you updated to packages from the Fedora 15 repository without the Fedora 15 ''updates-testing'' repository enabled between 2011-04-15 and 2011-04-21, you may have encountered this issue. The most likely scenario in which this would occur is using the preupgrade tool to upgrade from Fedora 14 to Fedora 15, as preupgrade does not use the ''updates-testing'' repository by default.
 
 
To resolve this issue, update to ''gnome-menus-3.0.0-2.fc15'' or later. You may need to use an alternative desktop to manage this. If you do not have one available, leave the GNOME session at the error message screen (to ensure a network connection will be available), switch to a console with ''ctrl-alt-f2'', log in as root, and run {{command|yum update gnome-menus}} (or just {{command|yum update}}). Then log in to GNOME again.
 
 
Note that the ''Oh no! Something has gone wrong'' is a general-purpose error screen and may occur due to other bugs; this is just one case which is known to have affected several users. If you are seeing the screen and you have ''gnome-menus-3.0.0-2.fc15'' or later installed, you are experiencing a different issue.
 
  
 
{{Anchor|pxe_fail}}
 
{{Anchor|pxe_fail}}

Revision as of 13:53, 24 May 2011

This page documents common bugs in Fedora 15 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 F15 Beta Announcement and the Fedora 15 release notes for specific information about changes in Fedora 15: known issues, 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

Unable to retrieve FTP repodata

link to this item - Bugzilla: #679709

Due to a bug in the installer, when adding FTP-based package repositories during installation, the installer may report a failure while attempting to access FTP-based repository. No fix is available at this time. To workaround the problem, users are advised to first add an HTTP-based package repository URL (such as http://download.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os). Once added, you may edit the newly created package repository, and change the repository URL to the desired FTP-based repository URL.

For additional guidance on installation package repositories, consult the installation guide.

Installation failure when using ksdevice=bootif without bootif=

link to this item - Bugzilla: #704188

When installing Fedora 15 while using the boot argument ksdevice=bootif, the installer will fail abnormally if no BOOTIF= value is provided by the PXE server. Future versions of Fedora will not exhibit this failure. In the meantime, ensure your PXE server is making proper use of the IPAPPEND configuration variable. This variable controls what networking arguments are passed to the kernel, and is typically responsible for providing a BOOTIF= value.

For additional guidance, consult the syslinux IPAPPEND documentation.

Issues when upgrading from previous releases

Service not enabled after upgrading from Fedora 14

link to this item - Bugzilla: #703234, #703221, #703227, #703230, #703236, #703235, #703233, #703232

In Fedora 15, upstart has been replaced by a service called systemd. Due to improper rpm package upgrade scripts, some system services previously enabled in Fedora 14, may not be enabled after upgrading to Fedora 15. To determine if a service is impacted, run the systemctl status command as shown below.

# systemctl is-enabled foo.service && echo "Enabled on boot" || echo "Disabled on boot"

To enable a service on boot, run the following systemctl command (where foo is replaced with the name of the service):

# systemctl enable foo.service

Corrected packages may be available in the Fedora 15 updates repository. Depending on how you upgrade your Fedora 14 system (DVD-upgrade, or network upgrade), if the updates repository is included, packages with corrected upgrade scripts will be included and properly transfer your Fedora 14 service configuration to Fedora 15.

Graphical login does not start after upgrade

link to this item - Bugzilla: #698654

Depending on how Fedora 14 was initially installed, your system may not select the appropriate systemd boot target after upgrading to Fedora 15. The problem is caused by the %postinstall rpm script from the Fedora 14 package Package-x-generic-16.pngsystemd-units. Since Package-x-generic-16.pngsystemd isn't the default in Fedora 14, the problem will not manifest until you upgrade to Fedora 15.

If you change the Fedora 14 default runlevel at any time by modifying the file /etc/inittab, those changes will not affect the configured systemd default target. After upgrade, you may need to manually adjust the configured systemd default target links using the following procedure.

To configure systemd to start a graphical login menu on boot (similar to runlevel 5 in Fedora 14):

# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
# ln -sf graphical.target /lib/systemd/system/default.target<pre>

To configure systemd to start a text login prompt on boot (similar to runlevel 3 in Fedora 14):

# ln -sf /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target
# ln -sf runlevel3.target /lib/systemd/system/default.target<pre>

Software Issues

General buggy or missing functions in GNOME Shell network applet

link to this item

GNOME Shell features an integrated NetworkManager configuration interface, provided by an applet in the top panel and a configuration interface in System Settings. However, as of Fedora 15 Beta, these tools have not yet achieved feature parity with the configuration interface from GNOME 2, provided by the old nm-applet. Some features are still missing and there are known bugs with others. Major ones will be listed individually here, but as a general principle, if you encounter problems or missing features trying to configure your network using the GNOME 3 applet and System Settings interface, you can run the standalone nm-connection-editor tool, which makes all the operations not yet implemented in the GNOME 3 interface available. You can launch nm-connection-editor from a console, from the alt-f2 Run dialog, or from the overview (type nm-connection-editor or search for an entry named Network Connections).

GNOME 3's fallback mode uses the old nm-applet, and is not subject to this issue.

repomd.xml file reported missing or broken

link to this item - Bugzilla: #703025

When Adding F15 TC1 to a PXE server and using a PXE boot menu to upgrade, the installer will complain about a bad or missing repomd.xml file. This happens when the PXE upgraded machine has no internet connectivity (for example because it is crosscabled to a PXE server). You can hit the "edit" button, and then fix the url to your local http server (usually running on the PXE server). Then you will hit the same issue again, as the installer also searches for the "updates testing" repo. Just point it with url to the same "base" f15 repo on your PXE/http server. Don't forget the unselect the "is mirror URL" tickbox.

Laptop screen dims when switching to battery power or idle mode but never brightens again

link to this item - GNOME Bugzilla: #650405

Due to a bug in the screen brightness control logic in gnome-power-manager, laptop screens will dim as expected when switching from mains to battery power and dim further when the system is idle in battery mode, but will never brighten again when the system is no longer idle, or when you connect back to the mains. Eventually the screen will end up at its lowest possible brightness and be stuck there.

The only workaround is to disable screen dimming via the control center, or to manually reset the brightness to 100% via the keyboard (if you have brightness keys) or the control center every so often.

An updated gnome-power-manager 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-power-manager'