After upgrading few days ago x11-apps/xdm-1.0.3 to -r1 package I am not able to start X on my laptop: # cat /root/startx-bug.txt # startx xauth: creating new authority file /root/.serverauth.675 xauth: (stdin):2: unknown command "539e6ee6eaed2a9d004e0cd61fb307d4" xauth: (stdin):2: unknown command "539e6ee6eaed2a9d004e0cd61fb307d4" X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.16-rc5 i686 Current Operating System: Linux vrapenec 2.6.17-rc1 #5 Thu Apr 20 10:51:51 CEST 2006 i686 Build Date: 04 April 2006 I have traced down already that the /usr/bin/startx script extracts in a for loop the auth keys, but it does not expect there are two keys: one for MIT and the other or XDM auth. I just verified grepping out just a one line "fixes" the problem: for displayname in $authdisplay $hostname$authdisplay; do authcookie=`xauth list "$displayname" \ | grep XDM | sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null; echo "authcookie is $authcookie" if [ "z${authcookie}" = "z" ] ; then xauth -q << EOF add $displayname . $mcookie EOF Further I even tried to have in startx: echo "starting xinit $clientargs -- $serverargs -deferglyphs 16 -cookie $authcookie &" xinit $clientargs -- $serverargs -deferglyphs 16 -cookie $authcookie & but still, I cannot start X through startx. In contrast, xinit fires X fine.
Well, this is the message which X spits out when started from startx. I had the impression that the xauth has to extract the XDM-AUTHORIZATION-1 key from the xauthority file, but maybe it should rather use the MIT-MAGIC-COOKIE. Or should teh server be recompiled with some extra USE flags to enable support for XDM-AUTHORIZATION-1? AUDIT: Wed Apr 26 11:41:58 2006: 30688 X: client 1 rejected from local host Auth name: XDM-AUTHORIZATION-1 ID: -1 Xlib: connection to ":0.0" refused by server Xlib: Protocol not supported by server BTW: No Xsecurity.7 manpage exists, although referenced from X.7.
Created attachment 97391 [details, diff] startx.patch This is my patch to get it working. Why is is necessary I do not know, but have hit this problem again. I have x11-apps/xinit-1.0.2-r6 now.
It should probably be using the MIT one, I don't even have any xdm-auth-1 keys in my list.
I think you are right, older is the MIT key stuff, I think coming from X11R5 or similarly old. I still don't know why not more people hit this problem. :( # emerge --info Portage 2.1.2_pre1-r3 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17.11 i686) ================================================================= System uname: 2.6.17.11 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.12.5 Last Sync: Tue, 26 Sep 2006 10:30:01 +0000 app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-java/java-config: 2.0.30 dev-lang/python: 2.3.4-r1, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/spool/PBS /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en cs cz" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 FFmpeg X Xaw3d a52 aac aalib acpi alsa amr apache2 apm asf ati avi berkdb bitmap-fonts bonobo caca cairo cdparanoia cdr cli cpudetection crypt cscope ctype cups curl dba dga directfb divx divx5 divx5linux dlloader dri dts dv dvb dvd dvdr dvdread eds elibc_glibc emacs emacs-w3 emboss emf encode ethereal evo f77 faad faad2 fam fame fbcon ffmpeg flac flash foomaticdb fortran fvwm fvwm2 gb gd gdbm ggi gif gphoto2 gpm gstreamer gtk gtk2 gtkhtml highvolume i8x0 icc iconv ieee1394 ifc imagemagick imlib imlib2 inifile innodb input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog ithreads java jpeg kerberos kernel_linux lcms leim libcaca libedit libg++ libwww linguas_cs linguas_cz linguas_en lirc live lzo mad matroska mcal mesa mhash mikmod ming mmx mmx2 mmxext mng modplug motif mozilla mp3 mpeg mule musepack mysql ncurses network nls nptl nptlonly ogg oggvorbis opengl oss pam pcre pda pdf pdflib perl plotutils plugin png poppler ppds pppd pthread pthreads python qt qt3 qt4 qtx quicktime readline reflection rtc samba scanner scp server session slp spell spl sse sse2 ssl stroke svg tcl tcltk tcpd tetex theora thread threads tiff tk truetype truetype-fonts type1-fonts udev unicode usb userland_GNU userlocales v4l v4l2 vcd video_cards_ati vorbis win32codecs winvidix wmf x264 xanim xml xml2 xmms xorg xosd xprint xv xvid xvmc zeo zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
I had the same problem. It went away when I simply removed my ~/.Xauthority file. If I do so startx generates a new one, and everything works fine. This new .Xauthority file is then cleared of it's contents when I terminate X (i.e. the file remains, but is emptied of contents). Is this normal? How large is the .Xauthority file normally? (My old one was 913 bytes, the one generated if I remove that one is only 57 bytes... Is this cause for concern?) Should the ~/.Xauthority file be re-generated each time I start X? Or should it remain the same?
BTW, I'm using x11-apps/xinit-1.0.2-r6, on a freshly installed system. (Only the files in /home/ are retained from my old Gentoo install.)
(In reply to comment #5) > Is this normal? How large is the .Xauthority file normally? (My old one was 913 > bytes, the one generated if I remove that one is only 57 bytes... Is this cause > for concern?) > > Should the ~/.Xauthority file be re-generated each time I start X? Or should it > remain the same? > josh@mifflin ~ $ ls -l .Xauthority -rw------- 1 josh josh 174 2006-12-30 09:25 .Xauthority Looking at its contents, I think the appropriate entries are replaced on start. For example, I still have entries from my old laptop in there (I can tell by the domain name). Martin, does this solution work for you? Please re-open when you respond.
It still happens time to time. I suspect startx/auth is fooled by several entries in the .Xauthority file. A pair of lines is for hostname.domain, a pair for hostname/unix, a pair for my occasional different IP address (currently not resolvable), a pair for my OpenVPN interface (not resolvable either). Yes, removing the file cures the problem temporarily. $ xauth list vrapenec.doma:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b 10.8.0.6:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b vrapenec/unix:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b vrapenec.doma:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 10.8.0.6:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 vrapenec/unix:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 10.5.2.51:0 MIT-MAGIC-COOKIE-1 aa50b84c2399006bab8e41c820fa921d vrapenec/unix:10 MIT-MAGIC-COOKIE-1 2861fe1448b374327572c4df4c0cfcdc 10.5.2.51:0 XDM-AUTHORIZATION-1 3637bae0fb8f94e700bd454fe284e82d $ xauth Using authority file /home/mmokrejs/.Xauthority xauth> source /home/mmokrejs/.Xauthority xauth: /home/mmokrejs/.Xauthority:2: line too long xauth> list vrapenec.doma:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b 10.8.0.6:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b vrapenec/unix:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b vrapenec.doma:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 10.8.0.6:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 vrapenec/unix:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 10.5.2.51:0 MIT-MAGIC-COOKIE-1 aa50b84c2399006bab8e41c820fa921d vrapenec/unix:10 MIT-MAGIC-COOKIE-1 2861fe1448b374327572c4df4c0cfcdc 10.5.2.51:0 XDM-AUTHORIZATION-1 3637bae0fb8f94e700bd454fe284e82d xauth> x11-apps/xinit-1.0.8-r3, x11-base/xorg-server-1.5.3-r1
Created attachment 180890 [details] .Xauthority
(In reply to comment #8) > $ xauth list > vrapenec.doma:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > 10.8.0.6:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > vrapenec/unix:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > vrapenec.doma:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > 10.8.0.6:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > vrapenec/unix:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > 10.5.2.51:0 MIT-MAGIC-COOKIE-1 aa50b84c2399006bab8e41c820fa921d > vrapenec/unix:10 MIT-MAGIC-COOKIE-1 2861fe1448b374327572c4df4c0cfcdc > 10.5.2.51:0 XDM-AUTHORIZATION-1 3637bae0fb8f94e700bd454fe284e82d > $ xauth > Using authority file /home/mmokrejs/.Xauthority > xauth> source /home/mmokrejs/.Xauthority > xauth: /home/mmokrejs/.Xauthority:2: line too long > xauth> list > vrapenec.doma:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > 10.8.0.6:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > vrapenec/unix:0 MIT-MAGIC-COOKIE-1 1d9e926170db4b8ac8b4c57fc826865b > vrapenec.doma:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > 10.8.0.6:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > vrapenec/unix:0 XDM-AUTHORIZATION-1 4733e9568195d8c5008a42f9107569c6 > 10.5.2.51:0 MIT-MAGIC-COOKIE-1 aa50b84c2399006bab8e41c820fa921d > vrapenec/unix:10 MIT-MAGIC-COOKIE-1 2861fe1448b374327572c4df4c0cfcdc > 10.5.2.51:0 XDM-AUTHORIZATION-1 3637bae0fb8f94e700bd454fe284e82d > xauth> Regarding the line too long issue I haven't found anything around on the net, maybe except this (look for "line too long errors from xauth" in the archive"): http://www.oldlinux.org/Linux.old/mail-archive/linux-admin/Volume2/digest16
(In reply to comment #0) > After upgrading few days ago x11-apps/xdm-1.0.3 to -r1 package I am not able > to start X on my laptop: > > # cat /root/startx-bug.txt > # startx > xauth: creating new authority file /root/.serverauth.675 > xauth: (stdin):2: unknown command "539e6ee6eaed2a9d004e0cd61fb307d4" > xauth: (stdin):2: unknown command "539e6ee6eaed2a9d004e0cd61fb307d4" > It seems this is similar to https://bugs.freedesktop.org/show_bug.cgi?id=13462 issue in the approach to take just of the two cookies.
I could not resist and opened a bug upstream about the "line too long issue" to get the message from xauth improved in future: https://bugs.freedesktop.org/show_bug.cgi?id=20245
(In reply to comment #8) > $ xauth > Using authority file /home/mmokrejs/.Xauthority > xauth> source /home/mmokrejs/.Xauthority > xauth: /home/mmokrejs/.Xauthority:2: line too long Don't do that. .Xauthority is a binary file containing your cookies, it is not a valid script file that can be used as the argument to xauth's source command.
The Xauth bits are dark magic, even to most upstream X devs. There's little we can do here, let's track the bug upstream. Here's to hoping someone actually looks at it someday. :) Thanks