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.