#802769 xinit: startx failed if started after su - <user> from a autologged root (getty@.service) #802769
- Package:
- xserver-xorg-core
- Source:
- xorg-server
- Description:
- Xorg X server - core server
- Submitter:
- Walter
- Date:
- 2015-12-05 12:27:08 UTC
- Severity:
- normal
Dear Maintainer,
After the apt-get upgrade which changed the xinit from 1.3.4-1 to 1.3.4-3
the before functioning system stops to work with the following error in
exec startx:
Fatal server error:
(EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied)
The invocation of the startx is:
1. The system autologs the root user using getty@.service ( via
ExecStart=-/sbin/agetty -a root %I $TERM )
2. the root user starts the <user> via su - <user>
3. the user's .bash_profile contains the exec startx ...
(but is the same if you start it manually)
The ls -al /dev/tty give:
crw------- 1 root tty 4, 1 Jan 1 01:11 /dev/tty1
if you chown <user> or chmod 666 /dev/tty1, the startx displays the
graphical screen, but the mouse is not moving the cursor.
If you autostart the <user> directly from getty@.service, all is working as
expected,
ls -al /dev/tty1
crw------- 1 <user> tty 4, 1 Jan 1 01:11 /dev/tty1
I filled this bug report because is the upgrade that broke the functioning
system (twice, on two systems build on same image), nothing other changed
in the meantime except upgrade.
Dear Maintainer, The running version maybe was before 1.3.4-1, I lost the original image and the output of the dpkg -l. I have to rebuild it to find the version of the working one.
Can you post xserver logs? I've noticed that my autologin on tty6 can no longer start X.------------------------- $ cat /etc/systemd/system/getty@tty6.service.d/autologin.conf [Service] ExecStart= ExecStart=-/sbin/agetty --autologin infoscreen --noclear %I linux $ cat /home/infoscreen/.profile #... # launch infoscreen display :1 if [ -z "$DISPLAY" ] && [ -z "$SSH_TTY" ] && [ -z "$SUDO_USER" ] ; then export DISPLAY=:1 startx -- :1 sleep .1 fi ------------------------- I get this error in /home/infoscreen/.local/share/xorg/Xorg.0.log: [ 5991.773] (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory) The problem is: X tries to grab current foreground console, instead of grabbing the console it is launched on. If I set this up on tty0, it works. So, this is a regression.
On Fri, 23 Oct 2015 12:51:50 +0200 Walter <wstemb@gmail.com> wrote: > Dear Maintainer, Hi, > After the apt-get upgrade which changed the xinit from 1.3.4-1 to 1.3.4-3 > the before functioning system stops to work with the following error in > exec startx: > > Fatal server error: > (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied) > > The invocation of the startx is: > > 1. The system autologs the root user using getty@.service ( via > ExecStart=-/sbin/agetty -a root %I $TERM ) > 2. the root user starts the <user> via su - <user> > 3. the user's .bash_profile contains the exec startx ... > (but is the same if you start it manually) > > The ls -al /dev/tty give: > crw------- 1 root tty 4, 1 Jan 1 01:11 /dev/tty1 > > if you chown <user> or chmod 666 /dev/tty1, the startx displays the > graphical screen, but the mouse is not moving the cursor. > > If you autostart the <user> directly from getty@.service, all is working as > expected, > > ls -al /dev/tty1 > crw------- 1 <user> tty 4, 1 Jan 1 01:11 /dev/tty1 > > I filled this bug report because is the upgrade that broke the functioning > system (twice, on two systems build on same image), nothing other changed > in the meantime except upgrade. Since the version 2:1.17.2-2 of the xserver, it tries to run as non-root using logind features. But this is only working if you are opening the current vt. For the time being, if you want to run the xserver on a different vt, you either first need to login on the vt before starting the xserver, or the xserver needs to run as root. To achieve this, you need to install the xserver-xorg-legacy package and configure the Xwrapper.config config file (see Xwrapper.config(5) manpage) Other solution would be to use the socket activation, but this is not yet enabled in debian see bug #803254 Cheers, Laurent Bigonville