gdm hangs after login in gutsy

Bug #157622 reported by CJ Corsi
This bug report is a duplicate of:  Bug #136529: Can't log in after upgrading. Edit Remove
6
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Confirmed
Undecided
Unassigned
meta-gnome2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

On a fresh Gutsy install after 1 restart, gdm hangs after a completed (successful) login. The login will be performed, the login screen will disappear and the brownish gradient default desktop will show up. The login sound will be played, but no panels, desktop, or anything else will be loaded. It is possible to open a console terminal on all virtual terminals 1 - 6.
This problem does not show itself until the system has been up once normally and then restarted.
The problem shows itself even after purging xserver-xorg, gdm, and related packages, and even with another fresh install.
It also shows up regardless of whether compiz is enabled or the nvidia restricted drivers are in use. I have also tried installing the nvidia binary driver directly from the nvidia website, but this did not help anything.
The only thing that has seemed to work so far is dpkg-reconfigure'ing xserver-xorg, which allowed it to be opened once before going back to the problem. I used mostly defaults in the installation (only setting my resolutions and refresh rate). This does not work a second time around. The first time (when it did allow it to work once more), I was greeted with a messagebox notifying me that keyboard settings between gnome and xserver were inconsistent (pc105 vs. pc104, respectively), and asking if I would like to keep gnome settings. I chose to keep gnome settings over Xorg's settings. I have a slight thought that it may be the dialog woke it up from its slumber, and the reason it (reconfiguring) did not help further times was because gnome had already decided to keep its own settings and didn't prompt again.
Restarting into a recovery console and manually starting GDM (/etc/init.d/gdm start) works perfectly, including with compiz and binary nvidia drivers both from apt and the nvidia website.
Going to a console while GDM is frozen and attempting to run "sudo" results in the terminal freezing with no way of killing the command (including CTRL-C or killing it from another terminal). Running su and entering the root password (I have set it manually) works, however, and I can simply kill off the other terminal by killing the shell. Possibly gnome has frozen the authentication server? (I do not know much about this or how it works).
dmesg and the X log contain nothing of note (no difference between a working and non-working session).
Also, I've removed the fast user switching gnome plugin, which makes no difference (the panel plugin, at least).
Final note: Running uptime/top in one of the consoles while gnome is hung reveals a constantly growing load (up from around 1.7 initial, to up to about 12 when checked once. It does not jump or spike, it simply gradually goes up and settles).

It seems to be possibly related to a bug posted in a comment under bug #113067 by Rob Hughes
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/113067

Let me know if I need to clarify / add anything.

General Specs:
AMD Athlon X2 3800+ (@2.5GHz, but stable)
1GB RAM
A939 Motherboard (nForce4 chipset)
GeForce 6600PX video
2.6.22-14 Kernel (Generic)

CJ

Revision history for this message
CJ Corsi (cjmovie) wrote :

I left it on tonight at the brownish screen gdm stops at for about 12 hours, and still nothing happened. I'm guessing this rules out it being related to bug #61711, which I originally expected not to be the problem anyways.
As a side note, when I start gdm from the recovery console, it pops up with a messagebox saying that the "HAL cannot be initialized!". Is it possible that this is the reason it works in the recovery console, that it pops up a messagebox again?

Revision history for this message
CJ Corsi (cjmovie) wrote :

Sorry, I meant to reference bug #128803 above. I've also tried killing gnome panels as it recommends, but this does nothing.
Another side note is that no process is using CPU time, so I can only think that the high CPU load is some sort of artificial inflation from IO?

Revision history for this message
Dwight Shepherd (dwight-shepherd) wrote :

I am now experiencing this same problem. Its weird though cause it just started happening. The Login screen will come up and it accepts the user name and password that i put it. The login screen transitions to the brownish screen and then just hangs there. I can restart X by Zapping it.

I can stop gdm with /etc/init.d/gdm stop and run startx and X starts fine.

if you need any other info please let me know

Revision history for this message
Giorgio Vazzana (mywing) wrote :

When I upgraded from Feisty to Gutsy two days ago, I had the same problem. Looking at .xsession-errors I found the following error:

1198440598.912730 Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting
1198440598.916107 Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting
1198440608.837906 Session manager: gsm-remote-desktop.c:130: activation of OAFIID:GNOME_RemoteDesktopServer failed: System exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0

This led me to think it was something related with remote desktop. So I fixed the problem by disabling it (the server name is "vino-server"). To do so, run from a terminal "vino-preferences" and disable remote desktop. Now reboot and it should work. This seems to fix bug #172444 too. I hope this helps.

P.S.: I think there might be a bug in vino or in the gnome-session package (since gsm-remote-desktop.c belongs to that package), so this is just a quick fix.

Revision history for this message
jtholmes (jtholmes) wrote :

I have almost the exact same problem with hardy fresh install
hardy daily a/o 1/1/08 also occurred in hardy 12/31/07
dont know about alpha2 did not test it

my equipment
intel 2.6
nvidia fx5200
asus p4p800
1G mem

gutsy and other [K]Ubunus OS's on same machine work fine

all console windows are accessable so
you can kill gdm and all x-session stuff

killed gdm and all X related procs
started X
executed gnome-session
things work this way but logout brings me back to identical situation

X, gdm, gnome-session all are running fine but no gnome desktop
To test further I did the following

moved /usr/bin/gnome-session to /usr/bin/orig.gnome-session
wrote a shell containing the line
strace /usr/bin/orig.gnome-session
killed all X and gdm stuff
restarted gdm
logged in again with my little one line shell in the middle of
gdm and gnome-session and things work perfectly

in my old Unix coding days we referred to this type
of behavior as a 'race condition'
maybe that is what we have here

Revision history for this message
jtholmes (jtholmes) wrote :

I said things work perfectly using my little one line shell
not quite so.

All application, file explorer, etc. windows are locked to upper
left of display just under top bar (containing Application, Places, System etc.)
and cant be moved
no resize, move to other desktop etc. no window decorations

No normal gnome colored title bar on any Application, Terminal etc. windows
opened

Revision history for this message
Jouni Mettala (jouni-mettala) wrote :

Marking as confirmed. Four users are having same pronlem.

Changed in gdm:
status: New → Confirmed
Revision history for this message
jtholmes (jtholmes) wrote :

I just loaded Hardy daily-live 1/1/08 on an Asus P5VD2 MX SE Motherboard
that has Via UniChrome Pro IGP on board Video and gdm
problem does not exist.

gdm works fine, on initial boot after install
and all subsequent boot up, gnome desktop displays
etc. etc., saves current desktop for use on next boot up.

so I imagine that it has something to do with Nvidia or Nv drivers
but only on selective machines, and/or selective Nvidia Cards.

but directly relates to gdm because startx works and I believe
startx would/should use the same Nvidia/Nv drivers?

anyhow just some more information to help the bug squasher

jtholmes (jtholmes)
Changed in meta-gnome2:
status: New → Confirmed
Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Thank you for this bug report.
This bug has been reported so I mark this one as duplicate, but feel free to reopen it if I'm wrong or report any other bug you find!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.