Can't log in after upgrading

not the only one - I've got this too :-( I can login with failsafe mode. I can't see any old *dpkg* files in /etc/X11 and I'm not sure what the problem is.

I think this problem was related to Envy / custom nVidia drivers. Because after I spent a while ripping things out and putting them back in, it works, kind of.

I thought it was Envy but did a fresh install on my laptop and still the same problem but the problem started ofter doing the latest updates after installation, so something in todays update must have caused it

Started from a fresh install of Tribe 5 on my laptop. A few days ago (possibly the 5th) I've had to use the failsafe session. After today's updates failsafe won't even work. Same error in my .xsession-errors as Adam. Using failsafe-xterm until I find a work around.

Finally did some debugging.

I've tried removing xserver-gl (which removed /etc/X11/Xsession.d/98xserver-xgl_start-server) - no change.
I've tried commenting out gpg-agent (no change).

My .xsession-errors:
(process:17990): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

(process:17994): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...

And the all inportant strace I'll attach :-) (strace -e trace=process -f -p (2nd gdm process))
The exec's are both referring to "/usr/bin/gdmflexiserver" which isn't itself setuid

17982 execve("/usr/bin/gnome-keyring-daemon", ["/usr/bin/gnome-keyring-daemon", "-d"], [/* 51 vars */]) = 0
17984 clone(child_stack=0xb7b494c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb7b49bd8, {entry_number:6, base_addr:0xb7b49b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7b49bd8) = 17986
17988 execve("/etc/gdm/PreSession/Default", ["/etc/gdm/PreSession/Default"], [/* 59 vars */]) = 0
17990 execve("/usr/bin/gdmflexiserver", ["gdmflexiserver", "--command=GET_CONFIG greeter/Gra"...], [/* 59 vars */]) = 0
17993 execve("/bin/sed", ["sed", "s/^\\([^ ]*\\) .*$/\\1/"], [/* 59 vars */]) = 0
17994 execve("/usr/bin/gdmflexiserver", ["gdmflexiserver", "--command=GET_CONFIG greeter/Bac"...], [/* 59 vars */]) = 0
17995 execve("/usr/bin/xsetroot", ["/usr/bin/xsetroot", "-cursor_name", "left_ptr", "-solid", "#dab082"], [/* 59 vars */]) = 0
17987 execve("/etc/gdm/Xsession", ["/etc/gdm/Xsession", "/usr/bin/gnome-session"], [/* 19 vars */]) = 0

In response to rojanu, I have neither fglrx or nvidia loaded (using the radeon driver (and module))

In my system I had the same problem. The problem was caused because an upgrade had revoked public write permission to my /tmp directory.

I fixed it with: sudo chmod a+w /tmp; sudo chmod o+t /tmp

I have the same problem, my system under feisty was running beryl with an nvidia driver and had a the four-sided cube and other effects. After upgrading to gutsy I can only login if I choose the failsafe-gnome every time, otherwise I get the following in ~/.xsession-errors:

(process:25692): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

(process:25696): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...

FWIW just checked on my box - /tmp is fine:
drwxrwxrwt 22 root root 12288 2007-09-17 08:16 /tmp//

Hm, since the upgrade to gutsy I'm seeing these setuid errors too, although I actually *can* log in. There doesn't seem to be any setuid binary on my system which would fit the bill. Maybe it's a misdetection because gdm drops permissions or something like that?

I have the same problem. it's not /tmp for me either, that looks fine. On login, the gdm window goes away, then the X server appears to crash or exit, then comes back to the login window. I tried switching to kdm, behaves the same way.

One oddity that might be related is that it's running on the 8th virtual terminal, not the 7th as normal.

Nuking xserver-xgl from orbit fixes the problem for me.

I found the same as anthony. Running

sudo aptitude purge xserver-xgl

fixed the problem for me

In theory, touching the file .config/xserver-xgl/disable will do the same thing.

It would be nice if whatever it was trying to run with xgl detected it crashing and disabled it on next boot. This is a particularly bad because you get very little useful feedback.

On an installation from the alternate CD, I found that the .gnome2 directory of my normal user account was owned by root. Doing a 'sudo chmod -R myuser:mygroup .gnome2' (with appropriate replacements) seems to have resolved this issue for me.

I am also having this problem after having done an upgrade from Fesity to Gutsy via apt.

None of the suggestions above (/tmp, .gnome2, remove xserver-gl) help.

I cannot log in with failsafe or normal session.

Had the same problem upgrading from Feisty to Gutsy with working fglrx+Xgl config. I had to revert several Xgl feisty-specific changes so stuff actually works.

I modified the suggestion in comment 7 and executed:

sudo chmod a+w /tmp; sudo chmod o+t /tmp

After that, the gnome session actually starts. I am sure it has something to do with orbit and Xgl.

However, I still get the GTK+ errors. Please help.

(process:6827): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

(process:6831): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
/etc/X11/Xsession.d/40guidance-displayconfig_restore: 11: /usr/bin/displayconfig-restore: not found
Checking for nVidia: not present.
Starting Xgl with options: -accel xv:pbuffer -accel glx:pbuffer -nolisten tcp -fullscreen -br
Could not init font path element /usr/share/fonts/X11/TTF/, removing from list!
Could not init font path element /usr/share/fonts/X11/OTF, removing from list!
Could not init font path element /usr/share/fonts/X11/CID/, removing from list!
FreeFontPath: FPE "/usr/share/fonts/X11/misc/" refcount is 2, should be 1; fixing.
Could not init font path element /usr/share/fonts/X11/TTF/, removing from list!
Could not init font path element /usr/share/fonts/X11/OTF, removing from list!
Could not init font path element /usr/share/fonts/X11/CID/, removing from list!

** (x-session-manager:6824): WARNING **: Wrong permissions for /tmp/orbit-mike

I removed Xgl and still see this error. Not sure what's happening there.

(process:7684): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

(process:7688): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
/etc/X11/Xsession.d/40guidance-displayconfig_restore: 11: /usr/bin/displayconfig-restore: not found
SESSION_MANAGER=local/longisland:/tmp/.ICE-unix/7681
/bin/bash: /usr/bin/esd: No such file or directory

** (x-session-manager:7681): WARNING **: Failed to start sound.

Checking for Xgl: not present.
No whitelisted driver found
aborting and using fallback: /usr/bin/metacity
Window manager warning: Failed to read saved session file /home/mike/.metacity/sessions/default0.ms: Failed to open file '/home/mike/.metacity/sessions/default0.ms': No such file or directory
Initializing nautilus-open-terminal extension
Initializing gnome-mount extension

Tracker version 0.6.3 Copyright (c) 2005-2007 by Jamie McCracken (<email address hidden>)

This program is free software and comes without any warranty.
It is licensed under version 2 or later of the General Public License which can be viewed at http://www.gnu.org/licenses/gpl.txt

Initialising tracker...

** (trackerd:7788): WARNING **: Tracker daemon is already running - exiting
** Message: Not starting remote desktop server

Same problem here, but removing xserver-xgl solved it for me. But it's just a workaround. I hope to be running xserver-xgl soon!

I'm running Beta here, same problem after updates few days ago (not sure what day as I was running big backup job and waited awhile to reboot)

Problem was write access to /tmp

I sudo chmod 777 /tmp

but I wasn't thinking and that removed the sticky bit, so I

sudo chmod +t /tmp

I guess a better approach would be sudo chmod a+w /tmp

the suid messages might be related to bug #152577

I get the same problem. None of the suggested fixes do anything.

I've commented out the three lines as suggested in #152577 but then all I get is:
/etc/gdm/Xsession: Beginning session startup
(session still lasts <10seconds...)

Adding "set -x" to the Default file:
...
+ echo /usr/bin/xsetroot
+ XSETROOT=/usr/bin/xsetroot
+ [ x/usr/bin/xsetroot != x ]
+ CHECKBACKCOLOR=OK
+ [ xTHEMED = xTHEMED ]
+ echo
+ sed s/^\([^ ]*\) .*$/\1/
+ CHECKBACKCOLOR=
+ [ x = xOK ]
+ BACKCOLOR=
+ [ x != xOK ]
+ [ x = xOK 1 ]
+ [ x = xOK 2 ]
+ [ x = x ]
+ BACKCOLOR=#dab082
+ /usr/bin/xsetroot -cursor_name left_ptr -solid #dab082
+ exit 0
/etc/gdm/Xsession: Beginning session setup...

putting the lines back I can confirm that this is what causes the setuid errors.
However it clearly isn't what causes the login problems! So I'll do some more digging...

Having installed kubuntu-desktop from the command line, I can now log in to KDE (via GDM). Thus, this only affects GNOME.

For me 2 solutions worked:

solution 1 (simple):
from failsafe session create new user - this new user will work perfectly

solution 2:
from terminal (Ctrl-Alt-f2 for instance) _move_ all configuration to new directory:
sth. like
mkdir invalid_conf
mv .* invalid_conf
then check (login/logout gnome session) your old account - it should work now,
then
- move half of remaining 'invalid' configuration to your home
  (eventually after login error move back half of last portion of files to invalids)
- check account (login/logout gnome session)
- rinse, repeat
this way you will find invalid configuration file, which you can throw away or repair

for me it was invalid entry in .profile which I have add myself before :-)

Well this is wierd - I can now login - what I need to do is put "set -x" at the start of my .profile.

One day I'll sit down and start to trim my .profile to figure out which bit is doing it!

\o/ fixed it for my setup. In my case there were some bash-isms in ~/.bashrc and although I tried to be careful to only source it on interactive logins, I hadn't been careful enough. Once I fixed that I could login normally. Why the "set -x" helps I can only imagine.

So, for anyone else seeing this, it might be worth running "/bin/dash ~/.profile" to see if you get any errors.

I can confirm this bug also.
I have upgrade to Kubuntu Gutsy, and, with xserver-xgl, after logging in, I only get the screen with the login-background (so not really blank), There is some harddisk activity for a few seconds, but then nothing more. If I sudo apt-get remove xserver-xgl, the problem is gone, I can login normally. Also, I installed the latest ATI drivers with Envy, and everything else is running ok...

I can confirm this bug too.
I don't use any special video driver or card and it happens to me very often, but not always.
Also, my /var/crash folder is empty.

andrea@hivepad:~$ uname -a; lsb_release -a
Linux hivepad 2.6.24-2-generic #1 SMP Thu Dec 20 17:36:12 GMT 2007 i686 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu hardy (development branch)
Release: 8.04
Codename: hardy

The bug seems fixed for me so I close this bug, but please, feel free to reopen it if you continue to have troubles.

not fixed for me yet, reopening it...

Ok, I reopen the bug.

I've been experiencing the same on and off. Quite annoying. Looking at my xorg.conf I had the 'i810' driver for my Toshiba A200, which has an Intel 945GM chipset. I changed it to the 'intel' driver. The video board is detected correctly:

(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
        965GM, 965GME/GLE, G33, Q35, Q33
(II) Primary Device is: PCI 00:02:0
(WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found
(--) Chipset 945GM found

And after this, I don't seem to have any problems. I've also untertaken a radical cleansing of the xserver-xorg packages loaded on my machine.

Hello, I've had this problem too. At first I reported it as https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/179552, but found out that mine must be a duplicate of this bug. I found out that if I disable Hyperthreading in the bios, it works perfectly. The GTK setuid/setgid error messages are still there, so they are probably totally unrelated to the bug itself. As this problem seems to happen a bit unpredictably, I believe that it is some sort of race condition in some multithreaded part of gnome-session, or between different processes. Another argument for that theory is that when I strace'd gdm (like Adrian did), login worked almost all of the times (usually something was broken when I was logged in though, such as the terminal not starting).

I have no kind of authority around here, ;-)
but I would anyway suggest that everyone here tries disabling hyperthreading/smp, ie booting in uniprocessor mode.

I'd also like to repeat a finding I did and reported at that other bug, which I've not seen anyone here report:
By echo'ing messages in the startup files, I've confirmed that it runs through /etc/gdm/PreSession/Default.
Then it runs through /etc/gdm/Xsession, however, that script calls /etc/X11/Xsession.d/99x11-common-start, which calls /usr/bin/gnome-session and after that, I can see no more output from the script. This indicates the problem lies within gnome-session.

My computer is a desktop, Pentium 4 2.8 Ghz, asus P4C800 motherboard with Intel 875P chipset, 1 Gb ram, wired net connection. I'm using Hardy, installed from alpha2, with latest updates applied. It works fine under Gutsy on the same machine.

Okay, as I was so stupid to post in a report that was marked as a duplicate of this one, I'll post my problem here (thanks for the hint Pär ;-)).
I've got the same problem as all people do here - when I try to login to a GNOME session the screen just freezes at the brown Ubuntu background. I can still move my mouse pointer though and switch to the console via Ctrl-Alt-F1 (or any other function key).
The only really weird thing is that this only happens with the new 2.6.24 kernel. As with kernel 2.6.24-2 I couldn't even boot my system without providing the "acpi=off" or "acpi="ht" boot-option. However, this problem is now gone (or it has been solved) when I dist-upgraded to kernel 2.6.24-3 this morning - but I still can't login to any gnome session. This also goes for the GNOME failsafe session and the problem isn't solved by disabling the dual core functionality in the BIOS or by providing the "acpi=off" boot-option.
As I said before, everything works fine with the old gutsy kernel 2.6.22 and other versions before, so it might have something to do with the kernel itself (but don't take my word for it, I don't know what exactly causes the problem).
I'm using the latest Hardy version, with all the upgrades and dist-upgrades so far - and apart from a self-compiled ndiswrapper (latest SVN) every package on my system is in its original state. I should also mention that I didn't compile ndiswrapper for the 2.6.24 kernel so far, so it shouldn't be the cause of this problem. I don't know if it's related to this specific bug, but the avahi daemon won't start with the 2.6.24 kernel (it just tells me that the start failed at boot time) and when I'm trying to use the command "sudo" on the console the system also hangs (I can still type things via keyboard and switch to another console, but I can't kill nor abort the process).
Well, that seems to be it for now. I'll attach a few logfiles (tell me if you need more).
Here are my system specs:
- Samsung R60Plus Notebook with a
- Core2Duo T5450 (@1.66GHz) CPU
- 2048 MB RAM
- ATI Mobility Radeon X2300
- and nothing attached but a small mouse

Cheers, Bernhard

Thanks Bernhard for the attachments

for those of you that are interested in a possible workaround
you can try disabling gdm at boot time with this command
   update-rc.d -f gdm remove

then you will recieve a normal terminal screen login
login as usual
then execute startx& from the command line and gnome should come up an work fine

Thanks for the hint. But unfortunately this doesn't work for me either. I did like you told me and removed the gdm autostart links with "update-rc.d -f gdm remove". Then I created a .xinitrc file with "exec gnome-session" in it and rebooted my machine. After logging in via terminal I then executed the "startx" script and my machine stops at exactly the same point as before - only that now I don't see the brown Ubuntu background but the grey background of the X server (along with its mouse pointer). I then switched back to the console and listed all running processes and it seems that gnome-session, gnome-settings-manager, metacity, pulseaudio, etc. have actually been started. But at some unknown point the system still just stops loading my GNOME session.
So it seems that this has actually nothing to do with gdm - after booting the old 2.6.22 kernel again it works fine (that's how I'm writing here).
What am I supposed to do now? Any suggestions? I'm thinking about opening a new bugreport now, but I don't know wether this is a good idea or not.

Bernhard

No need to file another bug report. This strain of bug is on several bug reports
and is being actively pursued by the developers.

What you can try is to remove the .xinitrc and just login as yourself and execute
startx&

leave .xinitrc out of the mix and let startx figure out things and see what happens
then let us know

Running startx& by itself works perfectly and loads the full gnome session like usual.

Looks like the bug is a collection of different issues, that's nothing easy to read it or to get worked. Could anybody try to summarize what the issue is exactly and how to trigger it quickly and update the summary in a clear way?

Problem summary as I see it

I have perused about 200 bug reports this weekend and that have seen various flavors of this problem
but as far as I can see the main issues are

Install gutsy, hardy (very few feisty) can be from CD or update-manager

boot first time after installation and things are fine

boot second time and all subsequent boots gdm completes login and thats it
nothing else happens.
After successful login user almost always has blank screen (gold, brown etc.) working mouse
and nothing else, stays this way forever.

I believe this summarizes the major issues that I saw on all the reports that had this sort of problem.

although mentioned in only one or two bug reports the following appears to allow normal desktop operation

  disable gdm at boot up (update-rc.d ...)
  login to terminal window
   execute startx&

Same Problem here:

X40 Thinkpad (Gutsy was running fine before - just badly upgraded to Hardy and reinstalled Gutsy)

* installation went fine (usb-stick, alternate-iso, german language, desktop-option, download language-packages during installation)
* first boot ok - even compiz runs
* first update (149 packages) successfull
* 1st boot after 1st update starts gdm, as usual
* after logging in everything is bad:
- dark (brown/gold) screen
- empty top/bottom panels flickering a few times - final: empty screen with functional mouse-cursor
- can switch to tty's

# what i noticed: my hdd is busy all the time - nautilus-debug-error.log is written in my HOME:

"0x8177888 <DATUM> 21:29:07.7605 (USER) debug log dumped due to singal 11"

* disabling gdm (update-rc.d) and starting x (startx&) does _not_ solve this problem!

what can i do??

What do you call boot, is that a second login or a reboot from the computer? That looks like a session hanging. On hardy bug #175682 is a gnome-keyring issue leading to this situation. The bug can also be due to service not closed correctly with the session, if the issue is triggered when login again could you look if there is any user task still running and if stopping those makes a difference?

Hi Sebastian,

> What do you call boot, is that a second login or a reboot from the computer?

i mean a complete reboot of the computer. nautilus is running all the time...

Greets,

Falk

Sebastien

From the text of the various bug reports it appears that the reporter means
a boot from full poweroff.

As for #175682 some have reported that killing gnome-keyring solves the problem.
After killing keyring, gdm goes on and does what it is suppose to do. #175682 is not so
clearly defined.

To get a clearer definition of this report I will perform the following steps.

I will reinstall hardy daily-live a/o 1/2/8 and do the following

- login first time after install (change no settings)
next
- powerdown from menus (full power off)
next
- reboot (poweron) login and see what happens

And report back here

Hi jtholmes,

> I will reinstall hardy daily-live a/o 1/2/8 and do the following

why hardy? thought we were talking about a gutsy-bug?

falk

Let me rephrase that.

We have reports on both Hardy and Gutsy havine the same problem, so i will
reinstall and perform the same tests on both Hardy and Gutsy.

I have enough computers that I can leave both of them as they
are after testing in case we need to perform further testing.
jt

The issue is weird, a reboot should not make any difference on the software stack. How many people have the issue after restarting their computer? That looks like an hardware issue there

No it is not not a hardware problem. I have dual OS & the other one (WIN XP)
is working fine.
----- Original Message -----
From: "Sebastien Bacher" <email address hidden>
To: <email address hidden>
Sent: Wednesday, January 09, 2008 03:44 AM
Subject: [Bug 136529] Re: Can't log in after upgrading

The issue is weird, a reboot should not make any difference on the
software stack. How many people have the issue after restarting their
computer? That looks like an hardware issue there

--
Can't log in after upgrading
https://bugs.launchpad.net/bugs/136529
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Sebastien
you will love the results of this testing :)

Gutsy on Non Nvidia machine using Via-Rhine video
Installed Gutsy
Boots and runs correctly every time could not find any problems wth via-rhine video

-----------------------------------------------------------------

Hardy on Non Nvidia machine using Via-Rhine video
Installed Hardy
First boot after install failed after login
killed gnome-keyring
gnome desktop comes up and runs fine

poweroff machine by selecting Shutdown from Quit menu
poweron boot
login succeeds
gnome desktop displays
select restart from quit window
machine reboots
login succeeds
gnome desktop displays

poweroff machine by selecting Shutdown from Quit menu
poweron boot
login succeeds
gnome desktop does not display
kill gnome-keyring
gnome desktop displays

the above tests performed about 7-8 times in various order.
conclusion: My Non Nvidia driver machine will boot into gnome desktop about 80% of the time
                    the rest of the time killing keyrind lets the gnome desktop display

--------------------------------------

Hardy on Nvidia (ubuntu restricted drivers, not from Nvidia web) machine
Installed Hardy
First boot after install failed after login
killed gnome-keyring
gnome desktop comes up and runs fine

poweroff machine by selecting Shutdown from Quit menu
poweron boot
login succeeds
gnome desktop does not display
killed gnome-keyring
gnome desktop displays

select restart from quit menu
soft reboot occurs
login succeeds
gnome desktop does not display
killed gnome-keyring
gnome desktop displays

conclusion: any combination of poweron boot or soft boot never displays gnome desktop unless
                    gnome-keyring is killed, then the desktop displays and operates properly.
-----------------------------------

overall conclusion for my machines

in all cases the gnome login screen is displayed and the login succeeds

in all cases killing gnome keyring allows the gnome desktop to display and perform normal tasks

normal tasks does not mean that every icon on the desktop was executed/tested

the Non Nvidia machines have somewhat random success (80-90% success rate) at displaying
the gnome desktop after poweron boot w/o killing the gnome keyring

the Nvidia equipped machine will not display the gnome desktop
after login unless the gnome-keyring process is killed, then the desktop displays
and appears to function properly, terminal windows are created with
titles, etc. etc. etc.

jtholmes

First of all, thanks for all the help here! I just wanted to add that just using "startx&" without creating a .xinitrc ends with the same results: my GNOME session won't start. After a few seconds of harddisk activity the PC just stops loading and does nothing anymore (at least as far as I can see). I have indeed upgraded my machine from Feisty to Gutsy and from there to Hardy via the dist-upgrade option (meaning via network).
I tried to do a fresh install yesterday with the daily live CD of 2008-01-08, but as this CD still seems to use the 2.6.24-2 kernel it didn't even boot at first. I then used the boot option "acpi=off" and the kernel seemed to boot at first - but then just stopped while trying to start the X session and fell back to the console. I tried to get it to run manually, but that didn't work either. I've had the same problems with the Alpha 2 live CD.
I'll now try to kill gnome-keyring after boot and report back with the results.

Bernhard

Oh well, it seems my problem regarding the not-starting GNOME session is only the tip of the iceberg. Remember you told me to remove gdm from being automatically started at boot time jtholmes? Well, I did this yesterday and after it didn't work out the way it should, I restored the settings with "update-rc.d gdm defaults". Afterwards I didn't boot the kernel 2.6.24-3 anymore - until now. It seems that the running order of the programs at boot time has changed now (which isn't a problem at all) and now cupsys gets loaded before gdm. That shouldn't be a problem, only that now my systems stops booting when trying to load cupsys and GDM doesn't show up anymore. So I switched to a console, only to find out that the cups daemons are obviously running, but so is also the S20cupsys script (which should have long exited by now).
Okay, I thought that maybe it's all the fault of the printer service and deactivated it (via "update-rc.d -f cupsys remove") and rebooted my machine. GDM started up then, I logged in - and still the GNOME session just stops loading after a few seconds. So I switched to a console, did "ps -e" - only to see that now the NFS autostart script (S20nfs-kernel-service) stopped responding. The nfsd daemons were loaded, but the script didn't exit. So I also deactivated nfs, only to see that after a reboot it showed the same behaviour with the Samba daemons. And now I'm really at a loss here. To me it seems that the system just doesn't boot completely and maybe that's exactly the problem with my not-starting GNOME session. I don't know for sure though - for that I'm just too unexperienced.

Is it this bug? (fixed)

http://bugs.debian.org/455694

I want to add to jtholmes summary above about the problem: for me logging in did not work even the first time on the first boot. I had to try several times before I got a successful login. What did solve the problem for me however, was putting the computer in uniprocessor mode, ie. disabling Hyperthreading in my case. What seems to be common for me and some other people here is that I have an Nvidia graphics card.

Debian bug 455 694 seems to be solved as the source for the setuid/setgid messages are fixed. However, those messages are still there for me, even though login and the rest of the system works perfectly. So in my case, this will probably not solve the problem.

@Pär Lidén:
> What seems to be common for me and some other people here is that I have an Nvidia graphics card.

no nvidia-card here... using a thinkpad x40, intel-graphics (driver: i810/intel)

after 3 fresh gutsy-alternate-installations - corrupted after the first big update (~150 packages)
i tried the following - with success! same standard/default installation as before - just multiple
small updates - instead of the monster 150-packages-update - see my protocol:

=============================================================
gutsy updates

installation: gutsy-alternate-release, no language-packs during installation, desktop-option

• 1. update: "openoffice.org"
• boot ok, login ok
• 2. update: "ubufox, tzdata, ttf-opensymbol, sound-juicer, oo-style-human, oo-common, oo-java-common"
• boot ok, login ok
• 3. update: "linux-restricted-modules-2.6.22-14-generic, linux-restricted-modules-common"
• boot ok, login ok
• => "restricted drivers available" (HAL)
• boot ok, login ok
• 4. update: "compiz, compiz-plugins, compiz-gnome, compiz-core"
• boot ok, login ok
• 5. update: "cupsys, cupsys-client, cupsys-common, cupsys-bsd, efsprogs, e2fslibs, e2fsprogs, firefox, firefox-gnome-support, ghostscript, ghostscript-x"
• boot ok, login ok
• 6. update: "gedit, gedit-common, gnome-about, gnome-cards-data, gnome-controll-center, gnome-desktop-data, gnome-games, gnome-games-data, gnome-menus, gnome-panel, gnome-panel-data"
• boot ok, login ok
• 7. update: "linux-headers-2.6.22-14, linux-headers-2.6.22-14-generic, linux-headers-2.6.22-14-common"
• boot ok, login ok
• 8. update: "gnome-session, gnome-system-monitor, gnome-system-tools"
• boot ok, login ok
• 9. update: "libmono*, mono*"
• boot ok, login ok
• 10. update: "libgtk*, libgnomui*, libgnome*"
• boot ok, login ok
• 11. update: "gnome-screensaver, evolution*, evince, eog, bittorrent, file-roller, gcalctool"
• boot ok, login ok
• 12. update: "libnm-util0, libnm-glib0network-manager, "
• boot ok, login ok
• 13. update: "libc6, libc6-i686"
• boot ok, login ok
• 14. update: "capplets-data, findutils, foo2zjs, hwdb-client-common, hwdb-client-gnome, language-pack-de, language-pack-en, libdataserverui1.2-8, libexchange-storage1.2-3, libpanel-applet2-0, libwnck-common, libwnck22"
• boot ok, login ok
• 15. update: "gtk2-engines, gtkhtml3.14"
• boot ok, login ok
• 16. update: "all the rest - 36 updates [perl, pcre, lib*, cairo - cupsys, cups, comerr2, poppler, video-plugins, gs8, openssl etc.]"
• boot ok, login ok!
=============================================================

could it be the update-process itself which is buggy - not a specific package...?

chears,

falk

I just wanted to inform you that I've solved the problem with my system not booting properly and the not starting gnome session. In my case it was a problem with the previously (and manually) installed ndiswrapper - I removed it and built it against the new kernel and everythings is working fine now. Sorry for the possible trouble I've caused here and thanks for your help ;-).

Sorry for the delay

Yes someone previously said that those of us using an Nvidia card seem
to have the problem.

That is correct, at least for me. I can never get gnome desktop to display
until i kill gnome-keyring proc on my Nvidia card machine, with Ubuntu
restricted Nvidia drivers.

The gnome case number on this is 502603 in case anyone is interested.
It does not have the same title but is the source of the problem and the
developer of gnome-keyring is working on the problem but he is not
experiencing the problem so he has to rely on others to tell him what
the symptoms are.

I expect your advice to solve the problem. Don't forget I am a mechanical
engineer, not a software specialist.
----- Original Message -----
From: "jtholmes" <email address hidden>
To: <email address hidden>
Sent: Friday, January 11, 2008 07:07 PM
Subject: [Bug 136529] Re: Can't log in after upgrading

Sorry for the delay

Yes someone previously said that those of us using an Nvidia card seem
to have the problem.

That is correct, at least for me. I can never get gnome desktop to display
until i kill gnome-keyring proc on my Nvidia card machine, with Ubuntu
restricted Nvidia drivers.

The gnome case number on this is 502603 in case anyone is interested.
It does not have the same title but is the source of the problem and the
developer of gnome-keyring is working on the problem but he is not
experiencing the problem so he has to rely on others to tell him what
the symptoms are.

--
Can't log in after upgrading
https://bugs.launchpad.net/bugs/136529
You received this bug notification because you are a direct subscriber
of a duplicate bug.

well, i got fglrx latest version (xorg-driver-fglrx from repository) installed and i also installed the xserver-xgl .. i used to get the setuid and getuid messages earlier .. but now, all i get is **Warning: GTK cannot open display :1" .. thats it.. Xorg. looks fine.. there seem to be no errors .. i disabled composite and aiglx .. i even modified gdm.conf, the GdmXserverTimeout parameter to 30 seconds, for Xgl's sake .. but alas, i cant login into gnome, with Xgl .... i had to remove it and then login .. the thing is compiz wont work in my system with just fglrx stuff.. Xgl is the solution..
any pointers?

Oddly enough I was getting this error all morning.
Digging deeply into the problem gnome-session was bailing each time.

gnome-session would work when I log in initially after reboot, but any subsequent logins with my user did not work (the same freeze we're seeing above.)

Good news is now it works, I only did two things:

1. I change the keyboard layout (I was getting tired of the message about X and Gnome keyboards being different and having to choose one)

2. I killed bonobo manually once after loging in.

After some digging I don't see how "2" would have done it, since I've not rebooted and I can still login as many times as I want, without doing any manual kills.

So for all those still having this trouble try changing your keyboard settings.

I'm using "nv" with an nvidia card, no compiz, no xgl. Looks like my login problem was not related to the gnome-keyring bug.

good luck all.

I havent finished testing the patch but it appears that something is in a race
condition.
I fixed a shell to sleep 2 seconds then call gnome-keyring and it the gnome
desktop appears to come up just fine.

However, in reality I believe there are several flavors of this bug.

I believe it is a race contion for the following reason
After login my screen flashes, goes blank for about 1.5 seconds
then displays the gold/brown background and nothing else but the
mouse pointer which is movable.

I may be way off base here, but doesn't the screen go blank a result of
something making a request to the video driver,
likewise doesn't the gold/brown background that comes up next a result
of something making another request to the video driver?

I know I never have this bug when the hardware is not nvidia

i tried xgl with xfce but i ended in the same situation as above..

btw, i have fglrx drivers. my glxinfo hangs FIRST TIME .. for that matter, first time usage of glxinfo/fglrxinfo/xgl hangs.. after which things go fine..

wen glxinfo hangs, system usage peaks..!!.. the bug may/may not be in gdm but rather to do something with the glx stuff.. i put up a start-xgl-xfce4.sh script like startx , where i did

glxinfo &
pkill glxinfo

<rest of stuff>

the script worked though it crashed :(, due to some esoteric problems b/w xfce,xgl and X display ...

There appears to be another patch from Stef Walter
this time to gkr-async and the title of the patch is
fix race condition.

I would suspect it will get to ubuntu in the next day or
so. The comment from one of the debian testers was
that it fixed the login etc. problems, however, the original
bug had to do with SSH, and evolution.
So we will see.

The patch for gnome-keyring we got a few days ago
came from the same case in Debian, case 502603
for those that are interested.

I have believed all along that the problem was a race
condition, because just every so often (1 in 100 times)
things would work right with no problems.

Also, when I delayed gnome-keyring startup with a two sec sleep
things work as they should.

Changing the tmp directory permissions also worked for me.

Hi.

I can confirm THE BUG in Gutsy.

1. No *xgl* installed
2. Just basic glx installed
3. TODAY updated (last one was in November 2007 - test machine) system still failed to login (didn't try newuser or failsafe login)
4. sudo chmod a+w /tmp; sudo chmod o+t /tmp (tnx David) just worked for me

There seems to be different problems reported at the same bug number here. One problem is caused by gnome-keyring. Killing gnome-keyring makes the boot proceed. The latest updates seem to solve the problem mostly for me, but I have experienced still at least one time where I had to kill gnome-keyring. This problem is related to bug #175682, and gnome bug #502603 (http://bugzilla.gnome.org/show_bug.cgi?id=502603), and affects only users of gdm.

Then there seems to be some people where the bug is fixed by changing /tmp permissions, others change keyboard layouts, switch video drivers, and so on. Shouldn't those be separated, and each put in it's own bug, as it quite clearly must be completely different underlying problems? Just that the symptom is the same, log in hangs.

Just a thought, but I'm not the one in charge here though. ;-)

Confirming that i performed no edits or permanent workarounds and this bug was resolved for me with a recent (1-2weeks) update to what seemed like gnome-keyring though others were obviously instream. As i said actions attempted except temporary workaround to start a gnome session while broken (killing gdm and startx form the CLI). Thx for resolution and good luck hunting down the other variants.

I had this problem after doing a fresh installation of Gutsy and then running "aptititude dist-upgrade" with a local copy of the Ubuntu repository.

To resolve it, I uninstalled ubuntu-desktop (and everything that it automatically pulls in) and then re-installed it. I got some errors (related to dbus or udev?) about power-manager settings but those are gone now.

Well I see I posted here on Jan 14th, and here I am again, as it has come back.

Hard to tell what changed, as I keep the system up to date, and end up being logged in somtimes for weeks at a time, so I would not notice the problem until I log out and back in.

To refresh I do have an nvidia card, but not using GL (no xgl, no nvidia driver, no compiz).

None of the fixes above made any difference (including the gnome-keyring killing).

Login always works on my partner's login.

Well now I just rebooted and very strange things happened when I logged in (which worked) but metacity did not load so it seems the gnome startup was only partially complete. I'll reboot and try again.

I'm running on an old duron 800 with 1GB ram, this machine has been been network updated since breezy days...

I did notice that the last time I rebooted the ubuntu splash (on the console) is now much bigger, as in the resolution has changed.

Alright, I'm going to shut off the machine and try again and report back.

Well again I mess around for a couple hours and it stops happening.

In the process I did end up with my window decorations missing, so I had to use gconf-editor to change my window manager to metacity, before it was set to compiz, which I disabled ages ago.

Anyhow I hope it does not come back again in another few months.

I found the trick about metacity in bug #87960

..b..

@b: to switch window manager run "metacity --replace &", "compiz --replace &", or the gnome gui: "gnome-appearance-properties" via a command line or "alt+f2"
seems related to bug #154596 to me. which is basically jockey improperly adding nvidia to your xorg.conf (missing 1 all important line).

I fixed this problem by editing my .profile file. It read:

export XAUTHORITY=/home/your_user_name/.Xauthority

I changed it to:

export XAUTHORITY=/home/jeremiah/.Xauthority

And GNOME actually booted.

i upgraded to hardy RC today and the same bug occurred.
i can only log into failsafe xterm and then i type gnome-session to enter gnome normally..
none of the above solutions helped to solve the problem.

i did what jeremiah suggested but now i can only log into gnome failsafe..
if i log into gnome aftere 5 seconds i get a failure message and it returns to log in screen.

failure message when i log into gnome

/etc/gdm/Xsession: Beginning session setup...
/etc/gdm/Xsession: Executing /usr/bin/gnome-session failed, will try to run x-terminal-emulator
No protocol specified

(zenity:5953): Gtk-WARNING **: cannot open display: :0
No protocol specified
cannot open display:
Run 'gnome-terminal --help' to see a full list of available command line options.

Could you try if that's still an issue in jaunty or karmic?

Sebastien Bacher schrieb:
> Could you try if that's still an issue in jaunty or karmic?
>
> ** Changed in: gdm (Ubuntu)
> Status: Triaged => Incomplete
>
Have jaunty on all my machines without any issues (same hardware as
running hardy + intrepid before). For me this issue seems to be solved.

Greetings,

Falk

closing the bug it's a collection of issue and some seem fixed, open new bugs if you still have one