Can't log in after upgrading
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gdm (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
I upgraded from Feisty Fawn to Gusty, and now I can't log in! Both default gnome and failsafe gnome play log in sounds (after I installed a pulseaudio compat library, this was not done automatically), but show nothing. remotely launching an xterm on DISPLAY 0 gives me something to work with, and gnome-session has gotten far enough to load my theme, but not much else (including metacity / compiz).
Not too many programs will start due to dbus errors (can not connect to bus), and the following is in .xsession-errors (although I've tried many times, I can't pin down the name of the program):
(process:16743): 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://
Refusing to initialize GTK+.
(process:16747): 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://
Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
/etc/X11/
/usr/bin/xmodmap: unable to open file '/usr/share/
/usr/bin/xmodmap: 1 error encountered, aborting.
SESSION_
Adrian Bridgett (adrian-bridgett) wrote : | #1 |
Adam Petaccia (mighmos) wrote : | #2 |
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.
rojanu (rojanu) wrote : | #3 |
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
Bob/Paul (ubuntu-launchpad-bobpaul) wrote : | #4 |
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.
Adrian Bridgett (adrian-bridgett) wrote : | #5 |
- strace (17990 and 17994 complained about) Edit (6.5 KiB, text/plain)
Finally did some debugging.
I've tried removing xserver-gl (which removed /etc/X11/
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://
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://
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/
17982 execve(
17984 clone(child_
17988 execve(
17990 execve(
17993 execve("/bin/sed", ["sed", "s/^\\([^ ]*\\) .*$/\\1/"], [/* 59 vars */]) = 0
17994 execve(
17995 execve(
17987 execve(
Adrian Bridgett (adrian-bridgett) wrote : | #6 |
In response to rojanu, I have neither fglrx or nvidia loaded (using the radeon driver (and module))
David Marín (davefx) wrote : | #7 |
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
Adrian Tritschler (ajft) wrote : | #8 |
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://
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://
Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
Adrian Bridgett (adrian-bridgett) wrote : | #9 |
FWIW just checked on my box - /tmp is fine:
drwxrwxrwt 22 root root 12288 2007-09-17 08:16 /tmp//
Daniel Elstner (daniel-elstner) wrote : | #10 |
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?
anthony baxter (anthony) wrote : | #11 |
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.
anthony baxter (anthony) wrote : | #12 |
Nuking xserver-xgl from orbit fixes the problem for me.
Philip Peitsch (philip-peitsch) wrote : | #13 |
I found the same as anthony. Running
sudo aptitude purge xserver-xgl
fixed the problem for me
anthony baxter (anthony) wrote : | #14 |
In theory, touching the file .config/
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.
Mark Workman (markmarkmark-workman) wrote : | #15 |
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.
Ryan T. Sammartino (ryan-sammartino) wrote : | #16 |
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.
michael37 (misha37) wrote : | #17 |
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://
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://
Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
/etc/X11/
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/
Could not init font path element /usr/share/
Could not init font path element /usr/share/
FreeFontPath: FPE "/usr/share/
Could not init font path element /usr/share/
Could not init font path element /usr/share/
Could not init font path element /usr/share/
** (x-session-
michael37 (misha37) wrote : | #18 |
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://
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://
Refusing to initialize GTK+.
/etc/gdm/Xsession: Beginning session setup...
/etc/X11/
SESSION_
/bin/bash: /usr/bin/esd: No such file or directory
** (x-session-
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/
Initializing nautilus-
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://
Initialising tracker...
** (trackerd:7788): WARNING **: Tracker daemon is already running - exiting
** Message: Not starting remote desktop server
w.d (wouter-dijk) wrote : | #19 |
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!
StarryTripper (matthew-dunlap) wrote : | #20 |
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
Oliver Grawert (ogra) wrote : | #21 |
the suid messages might be related to bug #152577
Alex Ruddick (alexrudd0) wrote : | #22 |
I get the same problem. None of the suggested fixes do anything.
Adrian Bridgett (adrian-bridgett) wrote : | #23 |
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=
+ [ 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...
Alex Ruddick (alexrudd0) wrote : | #24 |
Having installed kubuntu-desktop from the command line, I can now log in to KDE (via GDM). Thus, this only affects GNOME.
vramin (vramin) wrote : | #25 |
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 :-)
Adrian Bridgett (adrian-bridgett) wrote : | #26 |
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!
Adrian Bridgett (adrian-bridgett) wrote : | #27 |
\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.
Clau (claudiu-covaci) wrote : | #28 |
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...
Andrea Corbellini (andrea.corbellini) wrote : | #29 |
- .xsession-errors Edit (2.0 KiB, text/plain)
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
Andrea Corbellini (andrea.corbellini) wrote : | #30 |
The bug seems fixed for me so I close this bug, but please, feel free to reopen it if you continue to have troubles.
Changed in gdm: | |
assignee: | nobody → andrea-bs |
status: | Confirmed → Fix Released |
Clau (claudiu-covaci) wrote : | #31 |
not fixed for me yet, reopening it...
Changed in gdm: | |
assignee: | andrea-bs → claudiu-covaci |
Andrea Corbellini (andrea.corbellini) wrote : | #32 |
Ok, I reopen the bug.
Changed in gdm: | |
assignee: | claudiu-covaci → nobody |
status: | Fix Released → Triaged |
Paaguti-hotmail (paaguti-hotmail) wrote : | #33 |
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.
Pär Lidén (par-liden) wrote : | #34 |
Hello, I've had this problem too. At first I reported it as https:/
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/
Then it runs through /etc/gdm/Xsession, however, that script calls /etc/X11/
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.
Bernhard Sessler (burnhead) wrote : | #35 |
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
Bernhard Sessler (burnhead) wrote : | #36 |
Bernhard Sessler (burnhead) wrote : | #37 |
jtholmes (jtholmes) wrote : | #38 |
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
Bernhard Sessler (burnhead) wrote : | #39 |
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-
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.
jtholmes (jtholmes) wrote : | #40 |
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
Changed in gdm: | |
importance: | High → Critical |
Michael Favia (michaelfavia) wrote : | #41 |
Running startx& by itself works perfectly and loads the full gnome session like usual.
Sebastien Bacher (seb128) wrote : | #42 |
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?
Changed in gdm: | |
importance: | Critical → High |
jtholmes (jtholmes) wrote : | #43 |
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&
Falk Pauser (falk-pauser) wrote : | #44 |
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-
"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??
Sebastien Bacher (seb128) wrote : | #45 |
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?
Falk Pauser (falk-pauser) wrote : | #46 |
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
jtholmes (jtholmes) wrote : | #47 |
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
Falk Pauser (falk-pauser) wrote : | #48 |
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
jtholmes (jtholmes) wrote : | #49 |
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
Sebastien Bacher (seb128) wrote : | #50 |
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
P.K.Banerjee (pkbanerjee123) wrote : Re: [Bug 136529] Re: Can't log in after upgrading | #51 |
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:/
You received this bug notification because you are a direct subscriber
of a duplicate bug.
jtholmes (jtholmes) wrote : | #52 |
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
-------
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
-------
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
Bernhard Sessler (burnhead) wrote : | #53 |
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
Bernhard Sessler (burnhead) wrote : | #54 |
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-
bojohan (bojohan+launchpad) wrote : | #55 |
Is it this bug? (fixed)
Pär Lidén (par-liden) wrote : | #56 |
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.
Pär Lidén (par-liden) wrote : | #57 |
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.
Falk Pauser (falk-pauser) wrote : | #58 |
@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
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
• 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-
• 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-
• boot ok, login ok
• 6. update: "gedit, gedit-common, gnome-about, gnome-cards-data, gnome-controll-
• boot ok, login ok
• 7. update: "linux-
• boot ok, login ok
• 8. update: "gnome-session, gnome-system-
• 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-glib0netw
• 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, libdataserverui
• 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
Bernhard Sessler (burnhead) wrote : | #59 |
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 ;-).
jtholmes (jtholmes) wrote : | #60 |
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.
P.K.Banerjee (pkbanerjee123) wrote : | #61 |
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:/
You received this bug notification because you are a direct subscriber
of a duplicate bug.
rshriram (rshriram) wrote : Cant login after installing Xgl with fglrx, X200M | #62 |
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?
b (ben-ekran) wrote : | #63 |
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.
jtholmes (jtholmes) wrote : | #64 |
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
rshriram (rshriram) wrote : same error with xfce4 & gdm - I have a hunch for the race condition | #65 |
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/
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 ...
jtholmes (jtholmes) wrote : | #66 |
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.
SM (amruta-ahuja) wrote : | #67 |
Changing the tmp directory permissions also worked for me.
Jan Kunder (jan-kunder) wrote : | #68 |
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
Pär Lidén (par-liden) wrote : | #69 |
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://
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. ;-)
Michael Favia (michaelfavia) wrote : | #70 |
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.
Mark A. Hershberger (hexmode) wrote : | #71 |
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.
b (ben-ekran) wrote : | #72 |
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.
b (ben-ekran) wrote : | #73 |
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..
Michael Favia (michaelfavia) wrote : | #74 |
@b: to switch window manager run "metacity --replace &", "compiz --replace &", or the gnome gui: "gnome-
seems related to bug #154596 to me. which is basically jockey improperly adding nvidia to your xorg.conf (missing 1 all important line).
Jeremiah C. Foster (jeremiah-foster) wrote : | #75 |
I fixed this problem by editing my .profile file. It read:
export XAUTHORITY=
I changed it to:
export XAUTHORITY=
And GNOME actually booted.
Spyros Theodoritsis (madmetal) wrote : | #76 |
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.
Spyros Theodoritsis (madmetal) wrote : | #77 |
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.
Spyros Theodoritsis (madmetal) wrote : | #78 |
failure message when i log into gnome
/etc/gdm/Xsession: Beginning session setup...
/etc/gdm/Xsession: Executing /usr/bin/
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.
Sebastien Bacher (seb128) wrote : | #79 |
Could you try if that's still an issue in jaunty or karmic?
Changed in gdm (Ubuntu): | |
status: | Triaged → Incomplete |
Falk Pauser (falk-pauser) wrote : Re: [Bug 136529] Re: Can't log in after upgrading | #80 |
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
Sebastien Bacher (seb128) wrote : | #81 |
closing the bug it's a collection of issue and some seem fixed, open new bugs if you still have one
Changed in gdm (Ubuntu): | |
status: | Incomplete → Fix Released |
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.