I see this same thing after updating to all packages in the update channel as of
11:00 CDT on 10/3/03

Same behavoir noted here after installation via the RHN beta channel, and a
subsequent reboot of the machine. (14H06 - EST - Fri. 03 Oct. 2003). Additional
NOTE: the programs in my Gnome Startup are still present, but do NOT start.
(viz: tkseti, kmail, licq)

... also I am *now unable* to login to the KDE desktop "cannot find login 
script ... will attempt gnome login session", and I get logged into the 
gnome desktop!

I find now that I cannot *print*, either! "Unable to open USB device
"usb/dev/usb/lp0": No such device. I guess this is because I'm actually
logged in to the desktop in "Failsafe mode"?

Hmm, not good.

Seems like there is some issue with the base session script (BaseXsession key in
the config)  From the looks of it it's not installed.  AFAIK it should point to
/etc/X11/xdm/Xsession , if it points somewhere else, that is why it's failing. 
GDM will get very confused if it can't find this script but will attempt some
sort of a login (just directly execing gnome-session in failsafe mode)

The "can't use USB" thing would almost on the face of it look like a different
problem entierly.

The greeter crashing seems also a different problem.

It would be useful to get some output using the debug option (config file) and
see the output generated in /var/log/messages

My guess is that a whole bunch of files don't get installed right.

Confirm additional comment #3.  There is no way to get into KDE.

Since today's updates included a new kernel, I tested with an older one,
(2.4.22-1.2061.nptl) with the same results.  Another thought is that it might be
processor dependent.  I have an Athlon XP, and I remember Elton Woo as having an
Athlon of some kind. 

I have the same problem on my Pentium 4.

ARe these lines from /var/log/messages of any interest?

Oct  3 16:34:16 gstpc su(pam_unix)[4971]: session opened for user root by
gerry(uid=500)
Oct  3 16:34:21 gstpc gconfd (root-5024): starting (version 2.4.0), pid 5024
user 'root'
Oct  3 16:34:21 gstpc gconfd (root-5024): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Oct  3 16:34:21 gstpc gconfd (root-5024): Resolved address
"xml:readwrite:/root/.gconf" to a writable config source at position 1
Oct  3 16:34:21 gstpc gconfd (root-5024): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2
Oct  3 16:35:14 gstpc ntpd[4629]: kernel time discipline status change 41
Oct  3 16:36:18 gstpc ntpd[4629]: kernel time discipline status change 1
Oct  3 16:36:21 gstpc gconfd (root-5024): GConf server is not in use, shutting down.
Oct  3 16:36:21 gstpc gconfd (root-5024): Exiting

I can confirm that changing the line "BaseXsession" in /etc/X11/gdm/gdm.conf
(line 103) to BaseXsession=/etc/X11/xdm/Xsession fixes all messages except the
greeter crashing.  On a default installation the line reads
BaseXsession=/etc/X11/gdm/Xsession after all updates from the RHN channel.

I have the same problem. I have a PIII machine. After I updated my system today
with rhn I got the same msgs.

The log file for gdm /var/log/gdm/0.log doesn't show any error. The file
/var/log/message says:

Oct  3 22:02:10 130 gdmgreeter[3874]: No default session link found. Using
Failsafe GNOME.

I also recreated the user to see if any msg changed but there was no difference
at  all.

I had this same problem, and I changed my greeter theme to something other than
bluecurve. I believe that is what corrected this for me.

Reference Additional Comment #14.  Changing the theme and REBOOTING made the GDM
login screen appear, but I still got the error messages and logged into a
default Gnome session.

From comment #14 I gather that the spec file fails to patch the gdm.conf file
properly.  The default gdm.conf file did change a little bit between version
2.4.4.0 and 2.4.4.3 so I suppose the patch didn't apply.  Furthermore there
needed to be some adjustments to the config for everything to play nice which I
suppose got somehow lost.  I haven't looked at the new package but it sure does
look like this is the problem.

I've got the same problem as of this morning with the rawhide updates.

I have the same exact, duplicating issue with profound consternation. From
kernel message:

Oct  5 10:13:59 raxet gdm(pam_unix)[6595]: session opened for user maxer by (uid=0)
Oct  5 10:14:00 raxet gdm[6606]: gdm_slave_session_start: Cannot find or run the
base Xsession script, will try GNOME failsafe
Oct  5 10:14:19 raxet gconfd (maxer-6616): starting (version 2.4.0), pid 6616
user 'maxer'
Oct  5 10:14:20 raxet gconfd (maxer-6616): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Oct  5 10:14:20 raxet gconfd (maxer-6616): Resolved address
"xml:readwrite:/home/raxet/.gconf" to a writable config source at position 1
Oct  5 10:14:20 raxet gconfd (maxer-6616): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2

This happens to me also on my Dell XPS T550 desktop machine. This is not a 
processor dependant bug. I believe the same problem hangs my Sony Vaio PCG-F350 
laptop during the boot process. This is an older, 364 MHz Pentium II machine. 
If I want to use the Vaio at all I need to boot into runlevel 3. I also believe 
this issue may be breaking Ximian Evolution, which has had constant problems 
ever since Fedora Core was first released. Evolution is actually more stable 
under the initial Severn 1 release.

Yup, I'm seeing this (greeter crashing and falling back to Gnome failsafe
session) too after the latest updates, gdm version 2.4.4.3-1

I just built libart_lgpl-2.3.16-1, when this reaches rawhide. It might fix the
greeter crashing problem.

This problem also occured on a Compaq Armada M700 Laptop following the update
performed yesterday to include the kernel update.

The problem still exists (comment #22) with the libart_lgpl-2.3.16-1 update
installed. However, there were other updates including a kernel update that I'll
install.

Just for the record: the graphical greeter works for me when using the bijou gdm
theme from http://art.gnome.org/themes/gdm_greeter/257.php

The problem still exists, in exactly the same fashion as my original bug post,
with the latest updates on the test2 RHN channel.

Downgraded gdm to verison 2.4.4.0-2, per suggestion by Sjoerd Mullender, to
correct the problem.

There's no need to continue confirming this bug I'd say ;-)

Please report any success with libart_lgpl-2.3.16-1 when that becomes available,
otherwise a new gdm package should be along in a day or two.

Downgrading certainly should work around the problem for now.

twaugh said the libart upgrade didn't fix it. Oh well, I just know that there
was some asserts in the old libart that triggered in greeter. This is something
else then.

I can confirm that the problems still exists with libart_lgpl-2.3.16-1 installed.

*** Bug 106371 has been marked as a duplicate of this bug. ***

*** Bug 106376 has been marked as a duplicate of this bug. ***

*** Bug 106344 has been marked as a duplicate of this bug. ***

The "greeter crash" is not really a "greeter crash" if I'd understand it
correctly.  There is a slight bug where a theme not found will be reported as a
crash, this is fixed upstream in CVS (will make 2.4.4.4 at some point too).  
This should really have nothing to do with libart.  not looking at the packages
themselves I'd say it's most likely a screwup in the gdm spec file.  Other
packages which might be screwed up and cause such things are xinitrc and the
artwork package (whatever the name might be in fedora).

I'm kind of thinking however that it is strange that the graphical greeter
didn't load the circles theme, perhaps 1) circles is screwed (it is not screwed
upstream) or 2) the gdm package spec file removes the circles theme.  The
greeter will try to load a theme called "circles" as a backup.

*** Bug 106436 has been marked as a duplicate of this bug. ***

Someone mentioned that switching to something other than the Bluecurve them, got
it working after one crash.  Some of you might want to test that to see if that
at least gets you a better working system.

gdm-2.4.4.3-4 (building now) will have the BaseXSession fix, but it still has
the greeter crash. I'll start looking into that now.

Ok, i tracked down the Bluecurve crash.
Basically the new greeter_canvas_item.c has some code to try to linewrap text
that doesn't fit. It then takes a string like "Shut _down", expands it to "Shut
<u>d</u>own", and then tries to shorten it to fit. Of course, it accidentally
picks "Shut <u>" when trying different sizes, which spews this warning:

GnomeCanvas-WARNING **: Failed to set cell text from markup due to error parsing
markup: Error on line 1 char 25: Element 'markup' was closed, but the currently
open element is 'u'

Then later it crashes inside pango when setting some other markup with:
CRITICAL **: file pango-attributes.c: line 773 (pango_attr_list_unref):
assertion `list->ref_count > 0' failed
** Segmentation fault

gdm-2.4.4.3-5 which is building at the moment has a patch that fixes this
problem for me. Please test it out.

I downloaded gdm-2.4.4.3-5, the greeter now works perfect but i still can't get
gnome to work properly (not sure if it has to do with this bug but i think so
cause it worked before i updated gdm...)!

I get this everytime i start gnome:

"There was an error starting the GNOME Settings Daemon.

Some things, such as themes, sounds, or background settings may not work correctly.

The Settings Daemon restarted too many times.

The last error message was:

Child process did not give an error message, unknown failure occurred

GNOME will still try to restart the Settings Daemon next time you log in."

Just rebooted my computer once more and everything works fine...

Sorry!

gdm-2.4.4.3-5 fixes this.

gdm-2.4.4.3-5 from RHN up2dates works here as well now.

When will this be in rawhide?? Are rawhide and rhn beta channels different??
This is what I am seeing:
ftp.redhat.com:/pub/redhat/linux/rawhide/i386/RedHat/RPMS> ls -l gdm*
-rw-r--r--    1 ftp      ftp       1921467 Oct 06 16:26 gdm-2.4.4.3-3.i386.rpm
lftp ftp.redhat.com:/pub/redhat/linux/rawhide/i386/RedHat/RPMS>

Rawhide doesn't get pushed automatically, you probably just have to wait a bit.

Until then, you can work around the errors by changing these settings in
/etc/X11/gdm/gdm.conf:

BaseXsession=/etc/X11/xdm/Xsession
DefaultSession=default.desktop
GraphicalTheme=circles

You can change GraphicalTheme to whatever themes you have installed ("ls
/usr/share/gdm/themes"), apparently only the default theme make problems with
the older gdm version.

Ok, add another metoo to the list. It looks like you guys have squashed yet
another bug.

IOW WORKSFORME

Thanks!!

George didn't like that patch, alex.  He sent another one to try out.  I'll try
building gdm with it later today.

Created attachment 95083 [details]
different patch

Well, i didn't like the linebreaking code at all. :)

george: A better way to do this would probably be to split up the markup into
separate text and attribute-lists. Then you don't have to fuck around with
semi-parsing the markup, all you have to to is keep track of where you
insert/remove stuff from the string and correct the corresponding offsets in the
attribute-list. 

For instance, I think both patches gets all confused by escaped characters like
">". My patch was just a minimal change to avoid crashing, not in any way the
"right" solution. The really right solution involves using PangoLayout for
line-breaking anyway, but i'm not sure the canvas currently lets you set
max-width for the pangolayout.

When i say "split up" i mean calling pango_parse_markup() of course.

This should now be closed?

It seems like the new patch is buggy. kmaras reported it turning "Shut _Down" to
"Steng ne_<u>d</u>" in norwegian.

Even worse. He claims it actually displays "Steng ne_<u>d</u></u>". I.e. there
is no underlines. Might be because markup parse fails due to the two closing tags.

Changing the english text from "Shut_down" to "Steng ne_d" is an easy way to
reproduce this behaviour.

Steng ne_dd works though, so this must be some sort of corner case.

Different bug entierly actually and I just fixed it in HEAD on cvs.  I will make
a new upstream release tomorrow.  A simple fix is to take greeter_item.c, find
the place where 'underline--' and then there's a check like:

if (underline == 0)
  g_string_append (str, "</u>");

change that to

if (underline == 0) {
  g_string_append (str, "</u>");
  underline = -1;
}

I fixed it in a more complicated way on HEAD, but the above should do.

*** Bug 106860 has been marked as a duplicate of this bug. ***

As far as I can see this bug is fixed. If anyone objects, one can
always reopen the bug ;-).