FS#42084 - [xorg-xinit] xinit: cannot open /dev/tty0

Attached to Project: Arch Linux
Opened by Shawn Rutledge (ecloud) - Tuesday, 23 September 2014, 12:07 GMT
Last edited by Laurent Carlier (lordheavy) - Friday, 02 January 2015, 09:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Rather than running xdm or the like, I like to keep various .xinitrc-* files around for starting various window managers and DEs (.xinitrc-ob, .xinitrc-kde etc.) Then I symlink my current favorite to .xinitrc for the benefit of startx. Before the "rootless X" change, I could start X with a custom session like this

xinit .xinitrc-kde

but now it tries to open /dev/tty0 when I do that - it expects X to be running as root, I guess. Now I can get it to work again like this

xinit .xinitrc-kde -- /etc/X11/xinit/xserverrc

but that's more typing; seems to me that xinit needs some modification to assume that X is running as the current user unless told otherwise, if that is now going to be the default for most people.
This task depends upon

Closed by  Laurent Carlier (lordheavy)
Friday, 02 January 2015, 09:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed upstream, xinit now starts on the current TTY by default
Comment by Jan de Groot (JGC) - Tuesday, 23 September 2014, 12:46 GMT
X needs to start on the current TTY. Startx does that for you, but if you use plain xinit, you have to do that yourself.
Comment by Daniel Micay (thestinger) - Saturday, 27 December 2014, 05:26 GMT
Er, just ignore my closure request. It's *startx* that now does this by default even without our xserverrc (https://bugs.archlinux.org/task/42193), but raw xinit hasn't changed.
Comment by Daniel Micay (thestinger) - Saturday, 27 December 2014, 05:26 GMT
This should likely be closed as simply not supported though. For this to work you need to do things that are considered bad practices like adding yourself to the audio/video groups (among others) despite only needing access from the active session. Disabling non-root X support is not the *only* hack required for this to keep working, and since the session is considered broken there will likely be other problems - upstream software increasingly depends on logind.

Loading...