xf86OpenConsole: Cannot open virtual console 2 (Permission denied)

[Pyloons]

install and login was successful.
os:opensuse tumbleweed.
original dm:sddm.
de:kde
i could use root login and start DE,but normal users can't.
i have done cp /etc/X11/xinit/xinitrc.common ~/.xinitrc,and given .xinitrc 777,and the shebang head as your readme.md.
but still cant open DE.
what can i do?

[SandrosFist]

For now as workaround i edited the /etc/ly/config.ini (with sudo) setting

# tty in use
tty = 1

and it worked.

[1m-N00b]

same issues
i3 didnt wok but i login shell

[bodqhrohro]

The workaround is to chown %username% /dev/tty2, probably ly should do it itself.

[NuLL3rr0r]

That's really weird. I've been using ly for over a year now and never had this issue. A new Gentoo installation and now it won't set the permission. Even if I chown /dev/tty2 to the user it won't work. tty1 won't work either.

[WolfangAukang]

Sorry if that sounds like spam, and I should indicate this is the first time I'm trying ly. I am trying to create a module on NixOS to enable ly as a display manager.

To describe my issue, I am able to login normally if using the shell option, but when I am using xinitrc option, I am getting the same issue as OP. I haven't tried with root yet to confirm if the issue still happens, though. And yeah, it works for root, but not for a normal user.

[NuLL3rr0r]

If it helps, here is my .xinitrc (the only one line I need for running i3):

cat ~/.xinitrc                                                                          
#!/bin/sh

# rxvt-unicode
[[ -f ~/.Xresources ]] && xrdb -merge ~/.Xresources

exec dbus-launch --sh-syntax --exit-with-session i3

And, this is how I start it in OpenRC:

$ cat /etc/init.d/ly 
#!/sbin/openrc-run

command=/usr/bin/ly

name="ly"
description="TUI display manager"


depend() {
	after agetty
	after *
	after local
}
start() {
	TERM_NAME=linux
	BAUD_RATE=38400
	if [ -x /sbin/getty -o -x /bin/getty ];then
		GETTY=getty
		# busybox
	elif [ -x /sbin/agetty -o -x /bin/agetty ];then
		GETTY=agetty
		# util-linux
	fi

	exec setsid ${GETTY} -nl ${command} tty2 "${BAUD_RATE}" "${TERM_NAME}"
}

[NicholasNagy]

I'm having the same issue, so I was wondering, what is the appropriate work-around?
And, what is the expected behavior of Ly? Should Ly chown /dev/tty2 every time it tries to launch?

If that is the expected behavior, I don't mind investing some time into getting this fix into a PR.

[theklaaa]

Hiya! I've just spent a fair amount of time debugging this, so I thought I'd share my insights. The specific window manager I debugged with is sway; I assume that X has similar mechanisms. I have no formal knowledge on this topic, and I apologize if the following is therefore a bit more obtuse than it would otherwise have to be.

The basic problem, as has been described above, is ownership of the respective tty. Since ly does not chown the tty to the user, another mechanism has to be present for this purpose. There may be multiple such mechanisms that work, but on the arch installation I compared with, it worked as follows:

The system had a running instance of systemd-logind. Additionally, the pam_systemd.so module was included in the pam configuration used by ly. During login, when ly calls into pam, this module is thus loaded and executed. In turn, pam_systemd then executes a dbus call (CreateSession) against logind. logind then sets up the session, but it does not yet chown the tty. After the login is successful, ly will then setuid to the target user and start the window manager, in this case sway. As part of its startup, the window manager then (sway does this through libseat but X may do it directly) send a second dbus call (TakeControl) to logind. In response to this call, logind finally chowns the tty. If the first call to CreateSession does not proceed, logind will not be aware of the user session, and the window manager will thus not be able to call TakeControl and chown the tty.

In order for CreateSession to proceed, it gets passed a number of arguments, such as the username or the target tty. pam_systemd.so, which executes this call, in turn retrieves the values for these arguments from pam, using pam_get_item(3). On the failing system, the value for PAM_TTY had not been set, which led pam_systemd to provide an empty string for tty in the CreateSession call, which in turn caused logind to throw an error and not register the user session. Since PAM_TTY is neither set by default nor by ly itself, I assume (but have not tested) that it was set by another pam module on the working system, and that this module was not included on the non-working system.

Either way, setting PAM_TTY in ly fixed the problem for me: (Obviously, if you wanted to merge this, you'd retrieve the tty value from the config and also add error handling. This is just for testing)

diff --git a/src/login.c b/src/login.c
index e704022..478d2ba 100644
--- a/src/login.c
+++ b/src/login.c
@@ -497,6 +497,8 @@ void auth(
                return;
        }

+       pam_set_item(handle, PAM_TTY, "tty2");
+
        ok = pam_do(pam_authenticate, handle, 0, buf);

        if (ok != PAM_SUCCESS)

How to check if this is your problem

Save the output of dbus-monitor --system while trying to log in via ly. Search for CreateSession in the output, and check if it succeeds or receives an error.

[WolfangAukang]

@theknyaa I've just observed your comment and I might try it this week. My question is regarding your patch:

pam_set_item(handle, PAM_TTY, "tty2");

That last part (tty2), shouldn't that number be picked from the tty variable from the config.ini? Or is there a purpose that this must be tty2?

EDIT: Nvm, I saw the comment where you indicate that the patch you posted must be used for testing specifically.

[gagero]

Has any progress been made on this? I'm encountering the same error after upgrading to the latest version.

[arf20]

Having the same issue on a Thinkpad R51, I have only installed ly, Xorg and dwm.

(sorry for the bad picture)
/dev/tty2 is owned by root in group tty
ly is running as root I think, but then Xorg is launched as my user, arf20.
Running ly with sudo from a console does work.

Ignore the xauth error in the top, already solved.