I don't know if gdm is really the culprit, but it crashes. Can reproduce on 2 laptops. One upgrading from gnome 2.32 and the other from gnome 3.0 Reproducible: Always
Created attachment 288701 [details] gdm greeter log Seems to be a lot of dbus errors. Maybe is it the cause.
Created attachment 288711 [details] Emerge --info
(In reply to comment #1) > gnome-session[3703]: DEBUG(+): GdmSignalHandler: handling signal 15 This seems to be the key line. Something is sending a SIGTERM to gdm. Two things you may want to look at: 1. Maybe the gnome-shell greeter is at fault; you can try building gdm with USE=-gnome-shell. However, I don't think this is likely because gnome-shell likes to print lots of errors if it fails. 2. Since you upgraded, perhaps there are some files in /var/lib/gdm that gdm-3.2.0 does not like. Try wiping out that directory: # rm -rf /var/lib/gdm # mkdir /var/lib/gdm # chown gdm:gdm /var/lib/gdm # chmod 750 /var/lib/gdm
I will try this ASAP. But this is strange that it occurs on my 2 laptops, and being the only one experiencing this...
Actually, I have a suspicion of what's going on. Try adding the gdm user to the video group: # usermod -G gdm,video gdm
Created attachment 288761 [details] gdm greeter.log I think I send a log from Mageia !! THis is the right log file
Removing and recreating /var/lib/gdm didn't fix. usermod -G gdm,video gdm did not fix.
Could you also attach the slave log (e.g. /var/log/gdm/:0-slave.log) from the failed gdm startup?
Created attachment 288885 [details] slave log
And I am out of ideas :/ You should file a bug at bugzilla.gnome.org (please add gnome@gentoo.org to the bug's CC list), hopefully upstream developers will be able to help you better.
OK ! By the way it work with USE="-gnome-shell"
(In reply to comment #10) > You should file a bug at bugzilla.gnome.org (please add gnome@gentoo.org to the > bug's CC list), hopefully upstream developers will be able to help you better. Please reply to *this* bug with the new bugzilla.gnome.org bug #. I have the same problem as you and would want to follow the bug in its new home.
same problem for me, after upgrading from gnome 3.0 to 3.2, gdm crashes at startup. there are also some strange lines in /var/log/messages (attached), for exampl see lines 171 and 172. any ideas about that?
Created attachment 289029 [details] /var/log/messages
(In reply to comment #13) > there are also some strange lines in /var/log/messages (attached), for exampl > see lines 171 and 172. any ideas about that? Line 172 is a segfault in gnome-shell. It would be extemely useful if you could provide a bakctrace for that segfault (see http://www.gentoo.org/proj/en/qa/backtraces.xml and https://live.gnome.org/GnomeShell/Debugging).
ok. i've tried this (both - with one and two computers), but always gnome-shell says "unable to open x display". is there any trick? i've started kde and started "gnome-shell --replace" there. it fails with: ** (gnome-shell:12200): CRITICAL **: dbus_g_proxy_new_for_name: assertion `connection != NULL' failed ** (gnome-shell:12200): CRITICAL **: dbus_g_proxy_call: assertion `DBUS_IS_G_PROXY (proxy)' failed Speicherzugriffsfehler
When I reverted to gdm-3.0.4-r2, all was well for a few days. Now gdm succeeds and we get the greeter, but logging in again gets the "oops there is problem" msg and gnome-shell is killed. I will attach .xsession-errors in a minute.
Created attachment 289165 [details] .xsession-errors file
I encountered this issue and resolved it by editing the xdm init script's depend function to load dbus before xdm. I'll append a snippet here. /etc/init.d/xdm depend() { need localmount xdm-setup # this should start as early as possible # we can't do 'before *' as that breaks it # (#139824) Start after ypbind and autofs for network authentication # (#145219 #180163) Could use lirc mouse as input device # (#70689 comment #92) Start after consolefont to avoid display corruption # (#291269) Start after quota, since some dm need readable home after bootmisc consolefont modules netmount after readahead-list ypbind autofs openvpn gpm lircmd after quota dbus before alsasound # Start before X use consolekit xfs } I added 'dbus' after the 'after quota' to instruct the system to load dbus before loading xdm, this did the trick.
xdm changed, but without any changes.
(In reply to comment #19) > I encountered this issue and resolved it by editing the xdm init script's > depend function to load dbus before xdm. I'll append a snippet here. > I added 'dbus' after the 'after quota' to instruct the system to load dbus > before loading xdm, this did the trick. Thanks for the tip but it didn't help me. I put this in init.d/xdm # changed based on patch in gentoo bug #385525 # after quota after quota dbus but gdm still crashes. For me, gnome 3.2 has been quite a regression over 3.0. gdm-3.2.0-r1 crashes and when I revert to the 3.0 gdm, I get to the login screen but then gnome-shell crashes (described above, today's .xsession-errors will be attached in a minute). I tried to downgrade to gnome-shell-3.0.2-r1, but that needs libgnome-menu, which is not (now) in portage/layman.
Created attachment 289623 [details] new .xsession-errors file
Maybe the gnome-shell use flag should be disabled by default. It will allow at last to have a working gdm for everybody... Until the issue is fixed ! (didn't have time to report this bug upstream, if someone can, it would be great)
gdm with USE="-gnome-shell" seems to work. but after login, gnome-shell is crashed again with "oops there is problem".
(In reply to comment #23) > Maybe the gnome-shell use flag should be disabled by default. It will allow at > last to have a working gdm for everybody... Until the issue is fixed ! > (didn't have time to report this bug upstream, if someone can, it would be > great) I reported it to gnome as bug #661565 referencing our bug.
I have added a redhat tool to automatically detect and analyze segfaults to the overlay. I suspect it may be helpful in diagnosing this bug. 1. please re-emerge gnome-shell, clutter, cogl, gjs, spidermonkey, glib, and gobject-introspection with "-ggdb" in CFLAGS and "splitdebug" in FEATURES (see http://www.gentoo.org/proj/en/qa/backtraces.xml) 2. emerge app-admin/abrt from the overlay 3. /etc/init.d/abrt start 4. Try to start gnome with gnome-shell, see the "oops there is a problem" fail-whale face. 5. From a terminal or a console, run "abrt-cli list". You will see a list of reported crashes. Probably the most recent one will be gnome-shell listed as "@0". 6. Run "abrt-cli report @0" (or @1, etc., depending on how the most recent gnome-shell crash was listed). 7. When prompted, select "1" for local gnu debugger, "1" for collect .xsession-errors, and "2" for logger. 8. abrt-cli will launch your default console editor (nano, probably), and you will need to save the report file in the default location. 9. The end result will be /tmp/abrt.log. Please attach it to this bug :) When you are done, you can remove /tmp/abrt.log or rename it so that future invocations of abrt-cli don't clutter the same log file with different crashes.
Created attachment 289705 [details] abrt.log Surprisingly, gconf is the one crashing
(In reply to comment #27) > Surprisingly, gconf is the one crashing Very interesting! Please rebuild gnome-base/gconf with "-ggdb" in CFLAGS and "splitdebug" in FEATURES, and try to get an abrt log that contains a good gdb backtrace.
Already built with -ggdb
(In reply to comment #29) > Already built with -ggdb The problem is that the log you attached does not contain a backtrace; there is nothing under the "backtrace:" line. If there is a backtrace file in /var/spool/abrt/ccpp-2011-10-12-20:10:53-5376 or ~/.abrt/spool/ccpp-2011-10-12-20:10:53-5376, please attach it. Otherwise, you may have to try the experiment again (abrt is not 100% reliable, unfortunately).
Created attachment 289709 [details] abrt gconf backtrace Backtrace was generated, but not included in abrt.log
Emmanuel, are you using sys-auth/pambase with USE=mktemp? And if you are not, do you have sys-auth/pam_mktemp installed?
Yes, I'm using sys-auth/pambase with USE=mktemp
not for me. i'm not using pambase with mktemp.
(In reply to comment #34) > not for me. i'm not using pambase with mktemp. In that case your crash has a different underlying cause. Please use abrt to get a backtrace for the process that is crashing (see comments 26-31) and open a new bug.
I confirm that removing the mktemp stuff allow the gnome-shell login work in gdm !
FTR, it looks like the mktemp problem is related to pulseaudio not abiding to various environment variables which results in "permission denied" at various places which creates this problem in gdm.
(In reply to comment #37) > FTR, it looks like the mktemp problem is related to pulseaudio not abiding to > various environment variables which results in "permission denied" at various > places which creates this problem in gdm. I disagree. The problem is caused by pam_mktemp for some reason setting TMP and TMPDIR to /tmp/.private/nobody for the gdm-owned gnome-session process that then launches pulseaudio, gconf, and gnome-shell. In other words, pulseaudio and gconf are correctly failing. The problem is figuring out why pam_mktemp is using "nobody" as the username even though gdm is calling pam_open_session() with "gdm" as PAM_USER.
Fixed in gdm-3.2.1.1-r1 > commit b5418f67c79febd5d4dab3815b2ff7a7545571f1 > Author: Alexandre Rostovtsev <tetromino@gentoo.org> > Date: Wed Oct 26 03:38:14 2011 -0400 > > gnome-base/gdm: drop hardcoded env patch (#385525) > > The patch that prevented gdm from clobbering environment variables > results in gdm clobbering variables set via pam. In particular, this > badly breaks down when using sys-auth/pambase with USE=mktemp. > > So drop the patch; setting a custom environment in gdm can be done > using pam_env. > > Fixes bug #385525, reported by Emmanuel Andry <eandry@free.fr>. > > Also, use a better gdm-welcome pam file.
