I don't know if this is a local config problem or a gdm problem, but I keep my root-level X configuration stuff pretty close to stock, so if something doesn't work, it's usually a genuine bug somewhere. This has happened post-upgrade to gnome 2.6. Gdm fails repeatedly to start, finally giving me a message about how the display server has restarted 6 times, etc. I can still run my gnome desktop from a CLI prompt with startx, so it's not an X problem. Each failure generates the same series of very cryptic log messages, e.g. Jun 2 20:06:08 [gdm] failsafe dialog failed (inhibitions: 0 0) Jun 2 20:06:08 [gdm] failsafe dialog failed (inhibitions: 0 1) Jun 2 20:06:08 [gdm] failsafe dialog failed (inhibitions: 1 1) Jun 2 20:06:12 [gdm] failsafe dialog failed (inhibitions: 0 0) Jun 2 20:06:12 [gdm] failsafe dialog failed (inhibitions: 0 1) Jun 2 20:06:12 [gdm] failsafe dialog failed (inhibitions: 1 1) I've re-emerged gdm a couple of times with no luck. I'll be glad to try any suggestions any of the gentoo developers want me to try out, although I'll be gone a bunch during the next 3 weeks so I may be slow to respond.
*** Bug 52838 has been marked as a duplicate of this bug. ***
there should be gdm log files in /var/lib/log/gdm/ & the xfree logfiles in /var/log . Check them for relevance and attach them here please.
They're not very informative, but I'll post them nonetheless. The X server complains about unresolved symbols in libdri.a (and this shows up in both the X server and gdm logs) but this doesn't cause X not to run. If I comment out the Load for dri in XF86Config the complaint goes away but the problem with gdm doesn't. As I noted, I can still run gnome from a CLI invocation of startx from my user account on the box, which is my primary desktop system.
Created attachment 32597 [details] XFree86 log saved after gdm failure to start The 'Load dri' directive is commented out in my XF86Config file so the complaints about symbol resolution aren't shown, although this seems to make no difference in practice.
Created attachment 32598 [details] gdm log - /var/log/gdm/:0.log - one of several effectively identical log files in the directory
This is interesting. See <http://www.redhat.com/archives/fedora-test-list/2004-March/msg01472.html> which is a report of pretty much the same problem, and there's some evidence that it may be related to fonts. The last package I emerged prior to having the problem was fontconfig-2.2.2. I'm going to try reverting to fontconfig-2.2.1, and try the other remedies suggested there and see if they work. I'll post here accordingly.
As per the thread on the fedora archive, I cleaned out /tmp, no help. It looks as if a pango problem was implicated in the Red Hat case, however pango was upgraded here on May 2 and gdm has worked since then. xfs is started, so that's not an issue. Backversioning fontconfig didn't help, nor did removing my /etc/fonts/local.conf from the equation. I'm going to try to capture the full X server invocation line that gdm is trying to run and see what may be going on there. I'm starting X as a non-priv user with 'startx -- /usr/X11R6/bin/X -audit 0 -terminate' which works, lets the server talk TCP, and is as functional as starting from the gdm greeter.
I found the immediate cause of this problem, but not the underlying cause. It appears that gdm, or a related component, is choking on the several Microsoft Verdana True Type fonts which I had installed. Removing these from the library of installed fonts (which includes a large number of _other_ MS TTF fonts) and re-running fc-cache solved the problem. I arrived at this by a rather drawn-out process of elimiination, once I had determined that it was indeed a font problem with one or more of my MS fonts. What's of interest here is that these fonts have been installed on this desktop system since last fall, and I had no problems with them previously. Why should this problem should crop up now? No errors are printed by fc-cache, gdm, X, or any other component that I can find, nor is there any diagnostic information I can find anywhere to indicate why these particular fonts are causing problems and others aren't. If this bug should be closed and re-opened with another subject then mark it as resolved and let me know. There's still a bug somewhere, but maybe it belongs somewhere else.
well it could be some rare bug in between xft/fontconfig/freetype, but then we get in the domain of backtraces. What X, xft (probably included in X so may not be relevant) & freetype versions do you use ? What is your 'emerge info' ? I have verdana local and it works just fine here.
X was rebuilt today XFree86 Version 4.3.0.1 Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-gentoo-r9 i686 [ELF] Build Date: 03 June 2004 ----------- xft is not installed and conflicts with xfree-4.3.0-r2 ----------- freetype ... * media-libs/freetype Latest version available: 2.1.5-r1 Latest version installed: 2.1.5-r1 ----------- There used to be a set of verdana fonts in /usr/X11R6/lib/X11/fonts/truetype but the truetype directory no longer exists. Don't know what happened to the fonts. Perhaps they were part of the xft font lib which isn't installed. ------------ # emerge info Portage 2.0.50-r7 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.20-gentoo-r9) ================================================================= System uname: 2.4.20-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.10 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=pentium4 -march=pentium4 -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=pentium4 -march=pentium4 -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://gentoo.noved.org/ http://gentoo.noved.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acl acpi alsa apache2 apm arts avi berkdb bindist bonobo cdr crypt cups curl doc dvd dvdr encode esd evo fastcgi flash foomaticdb gdbm gif gnome gpm gps gstreamer gtk gtk2 gtkhtml guile imap imlib ipv6 java jikes jpeg libg++ libwww mad maildir mcal mikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl plotutils png ppds python quicktime readline samba sasl scanner sdl slang slp snmp spell sse ssl svga tcltk tcpd tetex tiff truetype usb x86 xml xml2 xmms xosd xv zeo zlib"
I pulled a set of Verdana fonts off of a backup tape here. They're Microsoft TTF fonts, but binary-different from the ones causing the problem. The embedded font version numbers indicate that the ones from tape are a newer version (2.35 vs. 2.31). There's no date in the file other than a copyright date of 1996. These Verdana fonts don't cause the problem :-) This doesn't look like a gentoo issue at all, so I'm resolving it to upstream. It may or may not be something that the upstream devs want to address, maybe just something people want to note for future reference. I suspect that the problem is in the greeter, which barfs on the bad fonts, crashes, and causes X to shut down since no other client is connected. This would explain why I could run a session using startx as a non-priv user but couldn't run gdm, and also why there's no X error logged since X shuts down normally after the greeter dies. Ideally, the greeter should just ignore the problem fonts, or issue a error message, or at least log an informative error somewhere before dying. I think I recall having similar problems with the gdm greeter a couple of years ago. I suspect that there may be errors or deviations from spec in the 2.31 version of the font which cause the problem, and which were fixed in the 2.35 version. Both work on Windows, but hey, MS doesn't care about adherence to spec, unless it's their own spec, and if they deviate from it they'll just bugger up their software to work with the deviant spec, and everyone else can just go to hell, especially if they use FOSS stuff. Thanks for your help and encouragement, foser!
Please check your permissions on /tmp. I had rwxrwx--- when gdm showed the same error-messages. They should read rwxrwxrwt. I don't know yet which kind of package changes the permissions on /tmp. But the problem is easily solved this was. Regards, Andy.
