[SOLVED] No available TTYs when logged in to GNOME session (LFS v9 SysV)

I've been trying to figure out why I have no functioning TTYs as soon as I log into the GUI. GDM starts in tty7 and gnome-session in tty2, which is as I understand it how GNOME works now, which is fine I suppose, although I would prefer it if it only used one TTY. My main issue though is that I only get a black screen with a blinking dot in the upper left corner for all the other TTYs.

I can issue something like this:

/sbin/agetty -8 38400 tty3 linux

And then I do get a functioning TTY3, but I would like all of them to be available without doing anything and would prefer it not to be an ugly hack as in adding the aggety to something like ~/.bashrc (if that would even work because when I issue the command the terminal is busy until I log out of the TTY).

My /etc/inittab is as per the book and looks like this:

# Begin /etc/inittab

id:5:initdefault:

si::sysinit:/etc/rc.d/init.d/rc S

l0:0:wait:/etc/rc.d/init.d/rc 0
l1:S1:wait:/etc/rc.d/init.d/rc 1
l2:2:wait:/etc/rc.d/init.d/rc 2
l3:3:wait:/etc/rc.d/init.d/rc 3
l4:4:wait:/etc/rc.d/init.d/rc 4
l5:5:wait:/etc/rc.d/init.d/rc 5
l6:6:wait:/etc/rc.d/init.d/rc 6

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

su:S016:once:/sbin/sulogin

1:2345:respawn:/sbin/agetty --noclear tty1 9600
2:2345:respawn:/sbin/agetty tty2 9600
3:2345:respawn:/sbin/agetty tty3 9600
4:2345:respawn:/sbin/agetty tty4 9600
5:2345:respawn:/sbin/agetty tty5 9600
6:2345:respawn:/sbin/agetty tty6 9600

# End /etc/inittab

Shouldn't that mean I should have tty1 through tty6 available, except for those already taken by GDM and GNOME?

How are you getting to the tty's? Are you trying to alt-f# out of the desktop? If that's the case, check the logs and see what's killing them. Seeing as systemd likes to reap ttys when a display manager is launched, I suspect that it is likely to be elogind.

Originally Posted by Luridis How are you getting to the tty's? Are you trying to alt-f# out of the desktop? If that's the case, check the logs and see what's killing them. Seeing as systemd likes to reap ttys when a display manager is launched, I suspect that it is likely to be elogind.

Yes, I'm using the alt-f# method and yes I'm inclined to believe that elogind might be a possible suspect here as well. The whole linux-pam-dbus-elogind complex has me slightly confused. I checked the logs now, nothing obviously stands out, except for an I/O error, but not sure whether that's relevant for this particular issue. Here's /var/log/sys.log | grep elogind after a reboot, login and then creating a tty with "sudo agetty tty3":

Dec  6 10:51:00 bioLinux kernel: <37>[50676.158923] elogind-daemon[692]: System is rebooting..
Dec  6 10:51:00 bioLinux kernel: <38>[50676.186340] elogind-daemon[692]: Removed session 4.
Dec  6 10:51:00 bioLinux kernel: <36>[50676.244189] elogind-daemon[692]: Failed to restore VT, ignoring: Input/output error
Dec  6 10:51:00 bioLinux kernel: <36>[50676.741197] elogind-daemon[692]: Received signal 15 [TERM]
Dec  6 10:51:23 bioLinux kernel: <38>[    3.938367] elogind-daemon[684]: New seat seat0.
Dec  6 10:51:23 bioLinux kernel: <38>[    3.956607] elogind-daemon[684]: Watching system buttons on /dev/input/event1 (Power Button)
Dec  6 10:51:23 bioLinux kernel: <38>[    3.958678] elogind-daemon[684]: Watching system buttons on /dev/input/event0 (Lid Switch)
Dec  6 10:51:23 bioLinux kernel: <38>[    3.960526] elogind-daemon[684]: Watching system buttons on /dev/input/event2 (Sleep Button)
Dec  6 10:51:23 bioLinux kernel: <38>[    4.027822] elogind-daemon[684]: Watching system buttons on /dev/input/event4 (AT Translated Set 2 keyboard)
Dec  6 10:51:23 bioLinux kernel: <38>[    4.305100] elogind-daemon[684]: New session c1 of user gdm.
Dec  6 10:51:25 bioLinux kernel: <38>[    6.095666] elogind-daemon[684]: Sleep mode "suspend" is disabled by configuration.
Dec  6 10:51:34 bioLinux kernel: <38>[   14.437400] elogind-daemon[684]: New session 1 of user bio.
Dec  6 10:51:35 bioLinux kernel: <38>[   15.892548] elogind-daemon[684]: Sleep mode "suspend" is disabled by configuration.
Dec  6 10:51:44 bioLinux kernel: <38>[   25.011598] elogind-daemon[684]: Removed session c1.

EDIT: Looking at the time in the log, it seems that the last entry is when I log in through GDM. Is this expected behavior, or a possible hint of what my issue is?

I would start by disabling gdm and booting into the shell. Then create an .xinitrc that exec's your gnome-session and see if you can alt-F# there. If so, you know that this is related to the display manager. Personally, I've never really tried to do this with a display manager installed.

FYI
with Gnome, f3 > f6 all switch and give algin prompt

f1 gdm
f2 desktop
f7 blinking cursor

Originally Posted by Luridis I would start by disabling gdm and booting into the shell. Then create an .xinitrc that exec's your gnome-session and see if you can alt-F# there. If so, you know that this is related to the display manager. Personally, I've never really tried to do this with a display manager installed.

Yes, of course, very clever Should have thought of that, elimination method... I'll do that once I get back from work.

Originally Posted by spiky0011 FYI with Gnome, f3 > f6 all switch and give algin prompt f1 gdm f2 desktop f7 blinking cursor

Yes, except I've configured GDM to start from 7 to save a slot.

I'll post the result of the testing soon

All the TTYs are there when booting directly into shell and starting GUI with "startx". So that means something related to GDM is killing it. At least we have some more information now.

So I tried with lightdm instead of GDM and it did not kill the TTYs, so it's definitely something that GDM does that kills it. At least now I have a functioning workaround, but I'd prefer to use GDM if possible.

GDM is tighly integrated with systemd | elogind. I still think it is worth a look there.

Originally Posted by Luridis GDM is tighly integrated with systemd | elogind. I still think it is worth a look there.

Yes, I think so too. I got another clue today, which may or may not be related, but I think so. When logged on through GDM "sudo nautilus" won't work until I enter "xhost +SI:localuser:root", but when logged on through lightdm that issue isn't there. I don't know much about elogind or dbus or any of that stuff, but might this be a clue to a common cause? As far as I'm aware, everything in that department is done as per the book, but still something is probably off there.

EDIT: There's one thing I actually haven't done as the book says and that is the part in this section that says:

Note that this boot script only starts the system-wide D-Bus daemon. Each user requiring access to D-Bus services will also need to run a session daemon as well.

That's because it suggests that the dbus session be started with the xinitrc file, which I'm not sure whether is executed when running gnome with wayland or not. Manually running dbus-launch in a terminal didn't seem to affect the "sudo nautilus" issue anyway.

What happens if you start a non wayland Gnome?
gnome on xorg

Originally Posted by spiky0011 What happens if you start a non wayland Gnome? gnome on xorg

When using gnome on xorg through gdm the "sudo nautilus" issue is gone, but the tty issue is still there. This is confusing me. With lightdm I can do" sudo nautilus" just fine with wayland, but not with gdm.

Hi
As you have mentioned "xhost +SI:localuser:root" that is a Wayland problem,and you will need that I have it in .bashrc of user. So I can run a root terminal.

You say you set GDM to start tty7 unset that and leave it as standard

When you use lxdm is it launching Wayland?

echo $XDG_SESSION_TYPE

Originally Posted by spiky0011 Hi As you have mentioned "xhost +SI:localuser:root" that is a Wayland problem,and you will need that I have it in .bashrc of user. So I can run a root terminal.

Yes, done that But didn't know it was a wayland thing, thanks!

Originally Posted by spiky0011 You say you set GDM to start tty7 unset that and leave it as standard When you use lxdm is it launching Wayland? echo $XDG_SESSION_TYPE

Initially gdm did start up with the default settings, I changed it partly to see if affected this issue. Do you mean lightdm? I don't have lxdm installed, but yes lightdm gives me the choice same as gdm.

Actually although lightdm does give the option to choose between wayland or xorg, running "echo $XDG_SESSION_TYPE" reveals it's always running on X. Seems we've narrowed the issue down a bit further.