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): gdm-2.6.0.8-16 How reproducible: Always Steps to Reproduce: 1.See description above Additional info: 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 elsewhere.
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 of times. 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[2945]: Unexpected greeter command received: '^X' It then exits, gdm apparently considers this to be a crash, and runs the alternative greeter. 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 init 3 init 5 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 Greeter=/usr/bin/gdmlogin 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 times too.
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 the behavior
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? ======================================== NEWS: gdm-2.8.0.1 ======================================== 2.8.0.1 stuff: - 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 Cameron)
It hasn't failed on me the last 20 times I have logged in, so I guess the bug is solved.....
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-2.6.0.8-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 greeter. 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[2146]: Unexpected greeter command received: 'x' where x is a non-ASCII character. I am using gdm-2.8.0.4-1. I have been tracking Raw Hide for a long time and first saw this problem a few weeks ago.
gdm-2.8.0.4-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-2.6.0.8-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 process-all-messages patch. 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 gdm-2.6.0.8-process-all-messages.patch 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) != G_IO_STATUS_NORMAL) return TRUE; + buf[len]=0; greeter_ctrl_handle_messages (buf);
Hi Josh, 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?
Hi Adam, Sure. Thanks for pinging me on this.
Hi everyone, Can you guys try one of the packages at http://people.redhat.com/rstrode/gdm/FC4/ 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 > > http://people.redhat.com/rstrode/gdm/FC4/ I have this problem (just started cropping up), but I can't access this website! Get a 403 error: "Forbidden 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-2.6.0.8-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.