After upgrade to XFree86-3.3.5, startx fails with:
Authentication failed - cannot start X server
Perhaps you do not have console ownership?
Problem is inside Xwrapper, as the server starts OK if
invoked directly (after adding the SETUID bit).
This bug (#5001) is probably the same as #5016. I have checked my
/var/log/messages and I also get: "pam[..]: unable to
dlopen(/lib/security/pam_console.so)". In addition, several
people have reported this same problem on the Red Hat newsgroup.
So this must be a general 5.2 plus XFree86-3.3.5 problem.
This bug is fixed with XFree86-3.3.5-1.5.x.
*** Bug 5016 has been marked as a duplicate of this bug. ***
The version of /etc/pam.d/xserver installed by
XFree86-3.3.5-0.5.2 contains the line
auth required /lib/security/pam_console.so
even though the latest release of pam for 5.2 (0.64-4)
provides no such file.
*** Bug 5076 has been marked as a duplicate of this bug. ***
On Sat, 11 Sep 1999, Jon Lewis wrote:
> I broke one of my 5.2 systems at home today to debug
this. What I found
> is that pam support seems to have been added into
Xwrapper, and that it
> comes with an /etc/pam.d/xserver file that by default only
allows root to
> start X...and AFAICT, no instructions for changing that
> messed around with /etc/pam.d/xserver and got it to allow
anyone to start
> X, but I'm not happy with the way I did it. I don't feel
> down the pam docs (/usr/doc/pam-0.64/ is awfully barren)
right now, so
> I'll probably look at this more tonight.
Looked at this a little more, and now I think it's
definitely a bug. When Red Hat released XFree86-3.3.5 for
5.2 and 6.0, they included (in both
releases) pam support in Xwrapper that's been standard on
6.0 but was new to 5.2. 6.0 does come with some
documentation on console.apps and pam_console.so in
However, 5.2 knows nothing of this. 5.2 (and pam-0.64-4
which is the latest pam update for 5.2) don't have
/lib/security/pam_console.so, so the /etc/pam.d/xserver file
that comes in XFree86-3.3.5-0.5.2.i386.rpm is