Red Hat Bugzilla – Bug 160603
greeter always fails and uses fallback
Last modified: 2007-11-30 17:11:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Description of problem:
Everytime I boot the system or logout of an X session, I get a popup
that says the greeter apparently crashed and the system will try another
one. The other one seems to work fine, because a simple login prompt
window eventually appears.
This is a brand new install of fedora core 4 with "everything" selected
in the install and all defaults in place as initially created by the
fedora installer (I've haven't diddled any config files yet, and when
I do I'll be turning off gdm anyway so the problem will disappear, I just
thought someone might be interested in the bug).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.See description above
Possibly relevant: The system I installed on has an old voodoo 3000 video
card and has no sound hardware, so if the fancy new greeter is trying to
do some sort of open GL 3-D graphics and play the fedora login polka,
it might not be responding too well to the lack of sound and/or old video card.
I'm seeing this problem too, but rather intermittently. I have an ATI Radeon
9200, which, although it's not the latest and greatest card, does support direct
rendering. Accordingly I think the explanation for this problem probably lies
can you set enable=true in the [debug] section of /etc/X11/gdm.conf, reboot,
and attach your /var/log/messages file to this bug report?
I could attach the messages file, but I'm afraid it wouldn't do any good.
Since I submitted the bug I had disabled gdm for a while, and tweaked some
things on the system (installed a few innocous things in /usr/local,
restored things like /etc/hosts and /etc/ssh) and I ran up2date a couple
When I re-enabled gdm and tried rebooting, the normal greeter works fine
(even if I turn debug back off in the gdm.conf file :-). So I guess
where it says I can always reproduce it, I'm wrong (I don't feel like
installing from scratch to see if I can reproduce it that way :=).
It doesn't seem to be doing it for me either, now. If it starts again, I'll let
you know, but if I can't reproduce it I doubt you can do much.
Well, if either of you guys see the problem again feel free to reopen the bug.
Created attachment 116121 [details]
Debug output from gdm and the greeter
Here is the debug output from gdm and the greeter when this problem occurs
(taken from /var/log/messages).
This problem has just occurred a few more times for me. I managed to capture
the debug output, and I have attached it. The greeter seems to be receiving a
bogus command from gdm:
Jun 29 11:51:42 yeltsin gdmgreeter: Unexpected greeter command received: '^X'
It then exits, gdm apparently considers this to be a crash, and runs the
I don't think I have enough access rights to reopen the bug; at any rate I can't
see how to do it. If someone is reading this who knows how to reopen bugs,
please could you do it for me, thanks.
Thanks. That's good information that should help to figure out the problem.
This happens to me as well, exactly as described in the "opened by" report.
However, it did not begin immediately after the install; only after I'd made
considerable changes to /etc, which I cannot reconstruct. The debug output is
substantially the same as posted in the attachment with comment #6. However,
there is an additional feature to this bug that I think is worth reporting: It
ONLY happens on boot. That is, if I restart gdm, either by killing it (and
prefdm) directly, or by
then gdmgreeter works fine, and I can log in normally. I tried replacing prefdm
by a stripped down version that simply runs gdm -nodaemon, but nothing changed.
Anyway, for me at least, I cannot reproduce the bug by simply running gdm
-nodaemon; I have to actually reboot the machine to get it to fail.
The only workaround I have found is to put
in the [daemon] section of gdm.conf. Apparently gdmlogin is the "fallback"
greeter, and it works fine, either directly on boot, or when restarted after boot.
Just to add another data point, a reboot is *not* necessary to reproduce the bug
on my machine. It's always rather intermittent, but it has occurred at other
This happened to me too. FC4, "Everything", x86_64 with generic GEForce video
controller. Only started happening after we installed the nvidia driver, using
the distribution NV driver didn't cause this problem (but then the NV driver
doesn't support dual head, either). Once X was restarted, the greeter would
fail and the fallback greeter would work.
Interesting message in /var/log/gdm/:0.log
Symbol __glXgetActiveScreen from module
/usr/X11R6/lib64/modules/extensions/libdri.a is unresolved!
We'll try to remove the DRI load from the xorg.conf file to see if that changes
For some reason, this problem now seems to occur every time the greeter is
displayed on my machine. If you want any more information collected, let me
know because it should be very easy now!
This problem also appears on my machine as well and I run a fresh FC4.
This is from the Gnome 2.10.2 release notes, could they have something to do
with the problem?
- This release fixes a nasty bug which was causing the
/etc/gdm/Xsession file to always use /bin/ksh. This
caused problems on Linux, where it should be /bin/sh.
It now is only /bin/ksh on Solaris builds. (Brian
It hasn't failed on me the last 20 times I have logged in, so I guess the bug is
I agree with comment #14 - I've switched back to gdmgreeter, and I have
not seen it fail. I'm still at the original gdm-126.96.36.199-16, but yum
update has changed an enormous number of other packages since my original
report, including recently a large number of xorg-x11 packages, currently
at xorg-x11-6.8.2-37.FC4.45. I also recently upgraded to the NVIDIA 7676
driver (from 7667), and to kernel-2.6.12-1.1447_FC4 from kernel-2.6.11-1.1369_FC4.
It hasn't failed for me recently, either. I don't know what changed but
something seems to have fixed it. I'll post again if the bug recurs.
Two or three days ago I've switched back to greeter too and there were no
problem until today. Today greeter fails again and I don't, what's changed. But
looks like really random bug.
I have been having this problem on an iBook running Raw Hide. Gdm will start,
briefly display the login screen and then terminate. Eventually the X scripts
will realize gdm keeps crashing and provide the option to use the fallback
I also find that this is an intermittent problem. I happens the majority of
the time, after boot and following init 3/init 5. But sometimes the proper
greeter does start up okay.
In the debug logs, I see "gdmgreeter: Unexpected greeter command
received: 'x' where x is a non-ASCII character.
I am using gdm-188.8.131.52-1.
I have been tracking Raw Hide for a long time and first saw this problem a few
gdm-184.108.40.206-4 seems to fix my problems (see comment #18.) I am using ldap/nscd,
so perhaps the usage of getseuserbyname is what was needed (at least in my case?)
This bug has just started happenning to me since I performed a regular update
with yum on October 17th 2005. I had been running an up to date FC4 prior to
that with no problems.
I get this gdm error message:
gdmgreeter: Unexpected greeter command received '^Y'
Also, I cannot get the bug to happen by running gdm from a shell prompt while
logged in as root at runlevel 3. It only happens when gdm is run from init in
runlevel 5. This suggests to me that the bug, whatever it is, is sensitive to
some difference in the environment between those two situations. Could also be
an uninitialised data problem, which would explain why it is so intermittent.
I am using gdm-220.127.116.11-16, so either the bug wasn't ever fixed upstream (as some
people thought it might be) or it has reverted since.
I think the problem may lie with code introduced to the greeter by fedora's
It appears that the greeter_ctrl_handle_messages() function expects its argument
to be nul-terminated. However, greeter_ctrl_handler() calls
greeter_ctrl_handle_messages() with a fixed length buffer that has just been
filled in by g_io_channel_read_chars(), and not nul-terminated unless there
happenned to be a nul in the input stream. This code was all introduced by
The following change fixed the problem for me:
--- greeter.c~ 2005-10-18 08:50:56.000000000 -0700
+++ greeter.c 2005-10-18 08:57:56.000000000 -0700
@@ -692,6 +692,7 @@
if (g_io_channel_read_chars (source, buf, PIPE_SIZE -1, &len, NULL)
Thank you. I'll try to apply your patch later today and push it into rawhide
tomorrow. This makes sense to do an fc4 update for as well.
Has this been fixed?
So this got fixed in rawhide a while ago. I don't think I did a FC4 update yet.
I did my own rebuild of the rpm with the above patch in and it seems to have
fixed things. Please could we have an official FC4 update for those unable to
roll their own?
Sure. Thanks for pinging me on this.
Can you guys try one of the packages at
and tell me if they work for you?
If they do I'll push those packages as updates.
I was experiencing the same issue, upgrading my gdm RPM to one provided in #27
seems to have resolved it for me.
(In reply to comment #27)
> Hi everyone,
> Can you guys try one of the packages at
I have this problem (just started cropping up), but I can't access this website!
Get a 403 error:
You don't have permission to access /rstrode/gdm/FC4/ on this server."
Please make these available to test and/or do an official update, already
comment #28 reported that the package worked.
Sure, thanks for reminding me. I'll try to have a look at it today.
I've pushed the package to the release team. Marking MODIFIED.
gdm-18.104.22.168-16.fc4 has been pushed for FC5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Hi, ignore the "FC5" in comment 32. The update went out for FC4. Our updates
errata tool has a bug in it, where it sometimes prints the wrong distribution.