Bug 7097

Summary: authority problems when starting X
Product: [Retired] Red Hat Linux Reporter: Rene Uittenbogaard <ruittenbogaard>
Component: XFree86Assignee: Preston Brown <pbrown>
Severity: low Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-03 21:14:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rene Uittenbogaard 1999-11-18 11:24:21 UTC
Last weekend I upgraded my rh6.0 installation from XFree86-3.3.2-8 to
XFree86-3.3.5-3 using rpm -U. All the packages which it requires were
upgraded as well. I did not change the XF86Config file. Then when I tried
to use 'startx' from tty1, the following error message occurred:

Authentication failed - cannot start X server.
Perhaps you do not have console ownership?

I was, however, able to start an X session using xdm or when running startx
as root.

A related symptom was the following:
when entering 'startx -- :2' , (according to a debug 'echo' line in startx)
the startx script tries to run the command:

xinit /etc/X11/xinit/xinitrc -- :2 /home/rene/.xserverrc -auth

which gives the following error:
Unrecognized option: /home/rene/.xserverrc

After moving the .xserverrc to /etc/X11/xinit/xserverrc and issuing the
same command, it tries to run:

xinit /etc/X11/xinit/xinitrc -- :2 /etc/X11/xinit/xserverrc -auth

but this gives a different error:
Authentication failed - cannot start X server.
Perhaps you do not have console ownership?

I think this is very strange.

I was able to solve the problem by symlinking /usr/X11R6/bin/X to
/usr/X11R6/bin/XF86_SVGA and making XF86_SVGA suid root, followed by a
little hacking into the startx script in order to pass the command line
values to xinit in the correct order.
(i.e. xinit $clientargs -- $whichserver $display $serverargs)

I was wondering whether this is a bug or whether this is due to a wrong
method of upgrading the X server?

Comment 1 Jed S. Baer 2000-02-03 05:18:59 UTC
I have the same problem, RH Service request 129465 - now closed. Because the
service request became very convoluted, I've posted a summary to my website.


Just FYI, hope it helps.

Comment 2 Preston Brown 2000-02-03 21:14:59 UTC
the main problem is you probably do not have a recent pam.  We have fixed this
dependency for 6.2, but for now, make sure you have the latest errata release of