I've just done a fresh install - twice. I'm using 'ACCEPT_KEYWORDS="~x86"' and the following CFLAGS ( built with gcc-3.3.1-rc5 ): -march=pentium4 -fomit-frame-pointer -funroll-loops -pipe When I run the /etc/init.d/xdm script ( with gdm selected in /etc/rc.conf ), nothing happens for a few seconds, and then if I switch to VT7, there are 3 lines which all read: missing DISPLAY and a console dialog could not be found A thread on the issue is at http://forums.gentoo.org/viewtopic.php?t=91483&highlight=missing+display+console+dialog The suggested fix ( to hack /etc/inittab ) didn't work for me. I've tried making a .xinitrc and adding xterm to it, and running 'xinit'. When the xterm opens, I type 'gdm' and a couple of gdm processes start ( according to 'ps ax' ), but nothing else happens. Thanks for taking my bug report! Dan
please do not assign bugs, this looks like a general x problem to me for now, not gnome. Just try to start x from the commandline and check the output/logs.
X works fine. So does xdm and kdm. I'm currently not using a graphical login manager ( I don't like xdm / kdm ), and just logging in on a console and typing 'startx' which launches gnome. Gnome also works fine. The problem is with gdm, as described in the thread I linked to in the original bug report. I have now set up 3 separate PCs which ALL have the same problem. There is certainly something wrong with gdm - or possibly the startDM.sh script? I wouldn't care if it was just me that this affected; I can live without gdm, but I'm setting up 6 linux-only PCs for our sales team, and I don't want them to have to log into a console and type startx.
well that was not obvious from your initial post, which lacks information (eg. your 'emerge info'). I usually don't read forum threads because they tend to be uninformed, off-topic and inflammatory and that just won't help a bug report and in this case it really doesn't add much either except that its clear that it is gdm only after a bit of foul language. Now back to the problem. Hmm now i think of it, do you have libgsf ? If so, recompile it and try again. Otherwise check ~/.gnomerc-errors and in /var/lib/gdm the logs for anything weird. if gdm is run from the commandline, does it exit ungracefully ('echo $?' afterwards should be 0)? If it crashes (not 0), debugbuild it (add inherit debug) and get a backtrace via gdb.
I have libgsf installed. The log(s) in /var/lib/gdm/ say: _XSERVTransTRANS(TransNoListen): unable to find transport: inet6 Fatal server error: Failed to disable listen for tcp transport When reporting a problem related to a server crash ............ Also, in .gnomerc-errors, same thing: _IceTransTRANS(TransNoListen): unable to find transport: inet6
In /etc/X11/gdm/gdm.conf, change the -nolisten tcp to -nolisten inet. For some reason the 'tcp' fails to alias correctly to 'inet' (which corresponds to ipv4) and 'inet6' (which corresponds to ipv6) on Gentoo. This is seemingly regardless of whether xfree or the kernel are build supporting ipv6. http://bugs.xfree86.org/show_bug.cgi?id=651
s/build/built
so this is only with 4.3.99 releases... (?)
Yes.
reassigning, apperantly problem with the masked development series.
It would be really nice to get this figured out before 4.4 release in a few weeks.
Does this still actually occur with the latest snapshots? I just started up 4.3.99.16 here with -nolisten tcp as the options and had no hassles running X...
Andrew, do you have ipv6 in your kernel, or in xfree via ipv6 USE? I encounter the problem when neither are present.
Spyderous: i do not have ipv6 in my kernel or in my USE, hence it is safe to say im not usinf any ipv6 items. As you requested on irc, I ran : startx -nolisten tcp This case will not cause the problem to occur because of the patch you have applied to the startx script. I modified startx and can then verify this bug. Solution pending... if im lucky...
Created attachment 21519 [details, diff] Patch to fix Here we go. This patch solves the problem by checking wether IPv6 has been defined before choosing wether inet6 should be something that using -nolisten tcp alias's too... I have successfully built Xfree 4.3.99.16 with this patch applied and made sure I had no DEFAULT SERVER FLAGS in startx. Then I just ran and am running now : startx -nolisten tcp Please test...
This is in 4.3.99.901.
