According to Montana Quiring:
Good information. Thanks.
If I put this line in /etc/inittab: x:2:respawn:/usr/X11R6/bin/startx > tty1 or x:2:respawn:/usr/X11R6/bin/startx
I get this error after it boots up: /usr/X11R6/bin/startx: line xxx: xinit: command not found /usr/X11R6/bin/startx: line xxx: xauth: command not found (xxx being a number in the 100's)
This led me to look at the startx script and I figured out that xauth and xinit were scripts in /usr/X11R6/bin/ that were not in the path when inittab was being run.
So I edited startx and made the first line: export PATH=$PATH:/usr/X11R6/bin/
Now X starts but it starts as root. *Insert frown here* I guess this makes sense because inittab is run as root, right?
That's correct. But wasn't that the case all along? I.e. when you ran "/bin/bash -login" from inittab, and it called startx from .bash_profile, that was all running as root as well?
But, I can see why you'd want to change that...
So I edited the /etc/inittab again and changed the line to: x:2:respawn:/usr/bin/sudo -H -u me /usr/X11R6/bin/startx
and I added this to sudoers: me ALL=NOPASSWD: /usr/X11R6/bin/startx
but I get this error on bootup: X: user not authorized to run the X server, aborting. xinit: Server error.
Gee wizz this has been a pain.
That's strange. I wonder what would happen on this machine if a non-root user logged in (on a virtual console tty) and ran startx from a shell prompt? I'm not sure why that would work if the above sudo command doesn't...
I wonder if console (or some other device) ownership is the issue? You may need to set up a wrapper script which first sets device ownership correctly, using pam_console_apply (if it's there) or a bunch of chown commands, then does the sudo command, then finally (maybe) resets device ownerships after the startx is finished.