I can't find anything in the logs. xorg-x11 segfaults immediately no messages created. It happens on all my systems. Force copying of glibc-2.3.4.20041102-r1 libraries fixes the problem but then there is a libthread* issue. Tried compiling xorg-x11 and gdm again but still end up at the blue screen saying that X has not been configured properly. Yes, even took the time to configure X but ended up with the same result. emerged glibc-2.3.5-r1, got no relief there either. Ran revdep-rebuild and it was clean too. Font libraries are pointing in the right direction. Wish there was more to go on, but there isn't anything in the logs??? Like the libraries weren't even compiled for a 2.4.30 kernel! Currently in fallback mode (emerge 2.3.4.20041102-r1) as I've been working on this for the last 8 hours and need the systems.
You lack to post the output from emerge info ldd `which X` What does that output?
See comment #1 and reopen then.
libz.so.1 => /lib/libz.so.1 (0x40029000) libm.so.6 => /lib/libm.so.6 (0x4003a000) libpam.so.0 => /lib/libpam.so.0 (0x4005d000) libdl.so.2 => /lib/libdl.so.2 (0x40065000) libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x40069000) libXau.so.6 => /usr/lib/libXau.so.6 (0x4006c000) libc.so.6 => /lib/libc.so.6 (0x4006f000) /lib/ld-linux.so.2 (0x40000000) Gentoo Base System version 1.6.12 Portage 2.0.51.22-r1 (default-linux/x86/2005.0/2.4, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.4.30 i686) ================================================================= System uname: 2.4.30 i686 AMD Athlon(TM) XP 3000+ distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mcpu=i686 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=i686 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi berkdb bitmap-fonts cdr clearpasswd cluster crypt cups curl directfb eds emboss encode esd fam foomaticdb fortran gd gdbm gif gnome gpm gstreamer gtk gtk2 guile imagemagick imap imlib ipv6 java jpeg libg++ mad matrox mikmod milter motif mozilla mozsvg mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pam_console pdflib perl png python quicktime readline sdl slang spell ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
I have the same Problem. opengl update xorg-x11 fixed this but nvidia seems to be my problem here. I even re-emerged xorg and nvidia-glx
Changed summary description back to original problem. Let the newcommer open their own. I don't have nvidia drivers and that is not the problem I opened. xorg-x11-6.8.0-r2 fails to start after glibc-2.3.5 update
okey, next thing you can test: strace -o log X (and trim down / compress log if needed and upload it here).
Created attachment 63709 [details] strace of X on affected system bzip2 compressed log from strace of X on affected system
The strace log is chopped at the end, so we can't see what happens just before it crash. I can see it atleast it able to write something to stderr: write(2, "Could not init font path element"..., 79) = 79 write(0, "Could not init font path element"..., 79) = 79
Created attachment 63719 [details] strace -o gdm.log gdm
Bzzt! I borked the previous test here is the gdm.log from a system with the glibc-2.3.5. Note- When I ran the strace on X it worked! It may be gdm that has the problem. I've attached the gdm.log strace. If this is indeed the problem please change the summary info so this gets into the hands of the correct reviewer. -thanks The strace from X would not be complete because I had to kill it but when I ran strace on gdm it captured the data as the program failed.
okey, gdm forks out a new process, in order to follow new processes, you need to strace -f -f = follow fork
Now I'm stuck when I run "strace -o mygdm.log -f gdm", it works! Suggestions?
if it works with strace, but not without, it is timing dependent (since a traced program runs a lot slower) (or threads not flushing cache). Anybody else has suggestions? It works if you downgrade your glibc?
Yes, going back to glibc-2.3.4_20041102-r1 (the previously installed version works). It fails with "strace -o gdm.log gdm" but using the -f (=follow) option it works.
Created attachment 63806 [details] xorg.log.tar.bz2 This is my `strace -o xorg.log -f X` output. I have the same issue here. Running with nvidia drivers (opengl-update did noth elp)
Created attachment 63862 [details] xorg.log.tar.bz2 Previous attachment was somehow borked. Re-attaching. I am using xorg-x11-6.8.2-r2 btw.
My problem might be related to nvidia as well. See bug 90047.
it seems that the problem is related to kernel 2.4. using kernel 2.6 the problem dissapears. so the problem is one of (or combination of): glibc (threads) | kernel 2.4 (threads)
Anyway, trying the fix from bug 90047 solves the problem for me. Were the nvidia drivers and `opengl-update xorg-x11` wfm. I am running gentoo-sources-2.6.12 without ntpl.
this is most certainly my fault... probably in opengl-update assuming that the linuxthreads glibc is --without-__thread...
actually, that'd be in the logic in the nvidia-glx ebuild... rrr... I hate when bugs crop up AFTER something goes stable... heh...
Tobias' problem was actually because portage thought he had glibc-2.2.5 and 2.3.5 installed (some problem in portage seems to have given him an empty SLOT file in 2.2.5). I have updated the nvidia-glx 'want_tls' functions to work right with glibc-2.3.5 on i486 and i586, so if someone has something similar, it can be fixed by re-emerging nvidia-glx (or manually fixing the libnvidia-tls.so* symlinks in /usr/lib/opengl/nvidia/lib Konstantin, what is your CHOST? Also, what do you get from: ls -ld /var/db/pkg/sys-libs/glibc-* David, what video drivers are youu using? I don't see you mention nvidia anywhere, so I assume this is different from the other two users' problems.
also, could you guys still having problems try USE=glibc-compat20 emerge '=sys-libs/glibc-2.3.5-r1' You'll need to add it to /etc/portage/package.unmask
I'm using Matrox drivers compiled into the kernel. My cards range from MG400 to MG550. I'll try the USE=glibc-compat20.
Hmm, well it looks like success. Knocked it around pretty hard (ALT-CTL-BSD) until gdm/X failed (took numerous tries) then did a restart on xdm and it came back like a champ. I've even used gdmXnestchooser and tested it that way as well using both root and a user. Tested several applications without any problem. Procedure I followed: added sys-libs/glibc ~x86 to /etc/portage/package.keywords added sys-libs/glibc-2.3.5-r1 to /etc/portage/package.unmask Then # USE="glibc-compat20" FEATURES="-distcc -ccache" USE=glibc-compat20 emerge '=sys-libs/glibc-2.3.5-r1' NOTE: a.) My reasoning for staying with 2.4.30 is that my servers are MOSIX clustered b.) I disabled distcc and ccache because the first emerge died and took down one of the other servers. When can we expect the glibc bump? Having alternate glibc packages entered into my /etc/portage/package.* files is hardly something I'd want to do long term. I could always take them out but then they would be backleveled when the next update is run, unless of coursed I added it to the package.mask.
Ok, so looks like people with linuxthreads-only glibc are experiencing problems going from --without-__thread to --with-__thread ... David, do you have the Xorg.0.log from your failures?
No, I never kept the old logs. So the strace trace temporarily corrected the threading problem to get gdm started? Is it a threading problem after all like that huge mess they're having with 586 hosts? http://bugs.gentoo.org/show_bug.cgi?id=90236 Here's my xdm-error log: _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/alfred.computer-critters.com:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.4.30 i686 [ELF] Current Operating System: Linux alfred.computer-critters.com 2.4.30 #1 SMP Wed May 11 11:26:26 EDT 2005 i686 Build Date: 07 July 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 18 14:45:51 2005 (==) Using config file: "/etc/X11/xorg.conf" Using vt 8 (EE) Failed to load module "speedo" (module does not exist, 0) (EE) Failed to load module "xtt" (module does not exist, 0) xdm error (pid 2695): IO Error in XOpenDisplay xdm error (pid 2689): Display :0 cannot be opened _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/alfred.computer-critters.com:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.4.30 i686 [ELF] Current Operating System: Linux alfred.computer-critters.com 2.4.30 #1 SMP Wed May 11 11:26:26 EDT 2005 i686 Build Date: 07 July 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 18 14:45:53 2005 (==) Using config file: "/etc/X11/xorg.conf" Using vt 9 (EE) Failed to load module "speedo" (module does not exist, 0) (EE) Failed to load module "xtt" (module does not exist, 0) xdm error (pid 2700): IO Error in XOpenDisplay xdm error (pid 2689): Display :0 cannot be opened _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/alfred.computer-critters.com:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.4.30 i686 [ELF] Current Operating System: Linux alfred.computer-critters.com 2.4.30 #1 SMP Wed May 11 11:26:26 EDT 2005 i686 Build Date: 07 July 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 18 14:45:55 2005 (==) Using config file: "/etc/X11/xorg.conf" Using vt 8 (EE) Failed to load module "speedo" (module does not exist, 0) (EE) Failed to load module "xtt" (module does not exist, 0) xdm error (pid 2705): IO Error in XOpenDisplay xdm error (pid 2689): Display :0 cannot be opened _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/alfred.computer-critters.com:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.4.30 i686 [ELF] Current Operating System: Linux alfred.computer-critters.com 2.4.30 #1 SMP Wed May 11 11:26:26 EDT 2005 i686 Build Date: 07 July 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 18 14:45:56 2005 (==) Using config file: "/etc/X11/xorg.conf" Using vt 7 (EE) Failed to load module "speedo" (module does not exist, 0) (EE) Failed to load module "xtt" (module does not exist, 0) xdm error (pid 2710): IO Error in XOpenDisplay xdm error (pid 2689): Display :0 cannot be opened xdm error (pid 2689): Display :0 is being disabled
Since it was asked for my CHOST ist i686 (athlon-xp) I re-emerged nvidia-glx (07/22/05 at 8pm central european summer time) did an opengl-update nvidia, startx still I get a segfault In /var/db/pkg/sys-libs/glibc-* I have an entry for 2.2.5 and 2.3.5 Konstantin
Konstantin: emerge unmerge \~sys-libs/glibc-2.2.5 && emerge nvidia-glx
thanks that did the trick
David, with the 2.3.5-r1 being released (it's still in package.mask for a little while longer), you won't need USE=glibc-compat20. Just keep USE=-linuxthreads-tls (notice the '-'). You don't need to use glibc-compat20 as I broke up the function of that USE flag into two separate USE flags (one for the glibc-compat addon, and one for the --with-__thread toggle). You should be able to switch to USE=linuxthreads-tls, but you'll need to recompile some packages that don't do things "the right way". I know qt is (or maybe "was") one such package, and depending on what your X log file said, you could probably see what culprit was messing things up here for you. If you use KDE, chances are it was qt acting up.
Yes, that worked nicely, thank you. Thanks for the heads-up when adding linuxthreads in the future, fortunately going forward I won't have to contend with QT issues as the cluster farm was built USE="-qt -kde".
ok, 2.3.5-r1 has been released, so closing this bug.
