[lug] serious Xauthority/gnome problem

[Hugh Brown]

I usually just move .Xauthority out of the way and let it get regenerated.

(If I'm wrong, you still have the file).

Try going in from a startx from run level 3, once that is working add gdm
to the mix by going back to run level 5.

Hugh


"D. Stimits"
> 
> I was booting up, it went normally (RH 7.1), and it was sitting at the
> standard login prompt for runlevel 5 default, gnome. When I logged in
> with regular user, it crashed (hard lockup, no ping, magic sysrq dead).
> When it came back up, my regular user was rejected from login due to
> .Xauthority it looks like. root could still login normally. And if I
> used KDE instead of gnome, my regular user could still login (and in
> fact, that is how I am managing to get to my email program Netscape). I
> went through and tried to regenerate my .Xauthority, but I am doing
> something seriously wrong, and I'm getting tired of KDE (my OpenGL
> programs crash and die there, probably due to sound daemon interaction
> rather than OpenGL itself). Here is a sample of some log messages after
> I tried to regenerate .Xauthority (and this was after an older backup
> version of .Xauthority failed):
> 
> gdm[5237]: gdm_auth_secure_display: Setting up access for :0
> gdm[5237]: gdm_auth_secure_display: Setting up socket access
> gdm[5237]: gdm_auth_secure_display: Setting up network access
> gdm[5237]: gdm_auth_secure_display: Setting up access for :0 - 2 entries
> gdm[5645]: gdm_server_start: '/usr/bin/X11/X -auth /var/gdm/:0.Xauth :0'
> gdm[5237]: gdm_server_usr1_handler: Starting display :0!
> gdm[5237]: gdm_display_manage: Managing :0
> gdm[5237]: gdm_display_manage: Forked slave: 5646
> gdm[5646]: gdm_slave_start: Starting slave process for :0
> gdm[5646]: gdm_slave_start: Opening display :0
> kernel: NVRM: AGPGART: Intel i840 chipset
> kernel: NVRM: AGPGART: aperture: 128M @ 0xf0000000
> kernel: NVRM: AGPGART: aperture mapped from 0xf0000000 to 0xd5b1c000
> kernel: NVRM: AGPGART: mode 4x
> kernel: NVRM: AGPGART: allocated 16 pages
> gdm[5646]: gdm_slave_greeter: Running greeter on :0
> gdm[5646]: gdm_slave_greeter: Greeter on pid 5654
> gdm(pam_unix)[5646]: session opened for user stimits by (uid=0)
> gdm[5646]: gdm_slave_greeter: Authentication completed. Whacking greeter
> gdm[5646]: gdm_slave_windows_kill: Killing windows on :0
> gdm[5646]: gdm_slave_session_start: stimits on :0
> gdm[5646]: gdm_auth_user_add: Adding cookie for 500
> gdm[5646]: gdm_auth_user_add: Using /home/home1/stimits/.Xauthority for
> cookies
> gdm[5646]: gdm_auth_purge: :0
> gdm[5646]: gdm_auth_user_add: Done
> 
> It appears that since it died right in the middle of the login process
> originally, something it writes during the process has been corrupted.
> Can anyone give me an idea of how to regenerate the .Xauthority for a
> regular user? Prior to this I had been getting this all the time, but it
> had no effect:
> gdm[3267]: gdm_auth_user_remove: /home/home1/stimits is not owned by uid
> 0.
> gdm[3267]: gdm_auth_user_remove: Ignoring suspiciously looking cookie
> file /home/home1/stimits/.Xauthority
> 
> Now the odd thing on that is that when I did experiment with the home
> directory .Xauthority permissions, when I set things as owned by root
> (uid 0), it then complained that it was not owned by my regular user
> instead...it couldn't make up its mind.
> 
> Right now I don't know what is wrong, but I suspect that whatever it is
> will be on top of a bad .Xauthority. Is this file regenerated each
> login? Or is it a static file? Since the man page only led me to
> generate .Xauthority files that gave even more errors with weird
> statements like "whacking greeter", I need to verify that I am doing it
> correctly. Can someone tell me a means of correct generation (and file
> perms) for an individual user's .Xauthority file for gnome sessions?
> Then I can decide whether some other part of the whole process is dead.
> 
> D. Stimits, stimits at idcomm.com
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 

------------------------------------
System Administrator/Unix Consultant
hugh at vecna.com
Vecna Technologies, Inc
6525 Belcrest Rd, Suite 612
Hyattsville MD, 20782
301.864.7253
http://www.vecna.com