Description of problem:
In runlevel 3, after entering X with the startx command, it's impossible to logout and go back to the text only console: destop manager disappear but X remain active, without mouse and keyboard interaction.
Version-Release number of selected component (if applicable):
Fedora 14 with all update applyed. (upgrade from a fedora 13 installation)
gnome-session 2.32.0 release 1.fc14 (not sure this is the real root cause of the problem)
Steps to Reproduce:
1. boot in runlevel 3 and login (normal user or root)
2. start the X environment with the startx command (gnome desktop manager)
3. logout from X using the "log out <username>" command in the System menu
desktop manager disappear but X remain active. No keyboard nor mouse interaction are possible. The desktop background image is visualized on the screen and nothing else.
gnome session and X are fully terminated and text only console appear on the screen.
After the logout attempt the system is still active, I can login remotely with ssh and interact with it. From the remote ssh session I was able to start again the desktopmanager and kill it again, but X never die. Switcing from runlevel 3 to runlevel 5 let the graphical user login appear on the screen, but going back to runlevel 3 still does not kill X.
The hardware is a vmware virtual machine. with Fedora 13 I have never had this problem.
This bugs looks correlated or similar to bugs 649940 and 640925
I can confirm this on three machines running F14 (all the other machines here already run on opensuse, because of the bugs mentioned above, they are blocking ones in my case). And yes, this seems strongly related to 649940 and 640925.
I switched the desktop from gnome to kde and the problem persist. Probably the bug it's not gnome related.
Created attachment 470691 [details]
output of ps -ef while experiencing the problem
output of the command ps -ef after this sequence of actions:
1) boot in runlevel 3
2) login with a normal user
4) logout with the "log out <username>" button in the system menu
5) the screen show only the background image, no menu, no windows, no mouse, no keyboard
6) login into the machin remotely with ssh
7) ps -ef
Created attachment 470692 [details]
Xorg.0.log while the problem is in place
The content of the file Xorg.0.log immediately after the problem comes up. I took it remotely through an ssh connection.
I'm able to reproduce the issue with KDE, GNOME, FLUXBOX and FVWM desktop environment. I suspect the problem is in Xorg or in the kernel. I'm changing the affected component.
This is not a kernel problem, the bug is persistent with all vanilla kernels, from stable mainline to the latest 2.6.37-rc7-git2 (without any F14 patches, straight vanilla).
hdt are you experiencing the problem on f14 fresh installation or have you upgraded from f13/f2/.... ? This could be another important parameter to consider.
I did a test with an F14 fresh installation (NO upgrade from F13, NO patch after installation) and the problem occours, so we can EXCLUDE that upgrading from f13 is causing the problem.
Two of my affected machines are directly installed from a F14 DVD, one is preupgraded from F13. All three have the same bug. I don't know if this is already present in plain F14, directly afer installing. Usually, I install from DVD and run a "yum update" directly after.
htd: yes i confirm the bug is present in plain F14 DVD, yesterday i did a clean installation from a DVD without any patch and I reproduced the problem.
htd What kind of hardware are you using ?
I'm working on vmware player 3, but in the next few days i will try also on different hw.
I verified i can reproduce the problem also with the livecd. This allowed me to further investigate the problem on a different hardware, those are the results:
Test 1 (vmware hardware)
1) boot the vmware virtual machine with the F14 Livecd in runlevel 3
2) login as root
4) logout using the system menu
5) screen/keyboard/moused frozen, problem reproduced
Test 2 (Intel q35 based pc,82Q35 Express Integrated Graphics Controller )
1) boot a pc with Intel q35 chipset and an onboard graphics card with the F14 livecd, in runlevel 3
2) login as root
4) logout using the system menu
5) the text console is visualized -> the problem is NOT reproduced
So the bug seems to be hardware related!
the xorg-x11-drv-vmware driver could be the source of the problem, is someone of you able to build an updated package using the latest xorg version of the driver ?
(The last fedora version is 11.0.1 while on xorg the latest is 11.0.3)
For me this bug is present on:
- 1 physical machine with Nvidia drivers x86 PAE architecture;
- 1 Vmware (Player) virtual machine x86_64 architecture;
However on Lenovo W500 laptop, x86_64 this bug doesn't appear.
All 3 machines are installed from scratch.
I tried this on my VirtualBox 4.0.6 F14 x86_64 guest with updates-testing enabled and could not reproduce it. I booted in runlevel 3, logged in as an ordinary user, and ran startx. Logging out from X brings me back to the console prompt.
I did a test on a different pc: core i7, asus p6t mb, nvidia gt210 /gt220 and i REPRODUCED the issue.
So at this time the problem is for sure hwa related, but NOT limited to a single specific type of hw.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: