Bug#966414: general: After upgrade to testing, VT1 is no longer usuable
On Tue, 28 Jul 2020 at 10:37:40 +0200, Helge Kreutzmann wrote:
> X is running on VT 7, so this is not the cause (and it does so for
> many years already).
...
> In http://0pointer.de/blog/projects/serial-console.html I read that X should
> start on VT1? Maybe systemd is no confused?
It depends what starts X on your system. Display managers are encouraged
to behave as described in that article, but not all do.
GNOME's GDM (gdm3 in Debian) is an example of a display manager that
does behave in that way. Recent versions of GDM use tty1 for GDM's own
Wayland or X11 "greeter" (login screen), and ask systemd-logind for one
additional VT per Wayland/X11 login session. By default, systemd-logind
will start allocating VTs from tty2..tty5 if they have not already been
used for a text-mode (getty) login prompt, skip tty6 (which it reserves
for a text-mode login prompt), and continue from tty7. If you switch to
tty2..tty5 before they have been used for a graphical login session,
they will get a text-mode login prompt instead; if you visit all of
tty2..tty5 before the first graphical login, then the first graphical
login will end up on tty7. See logind.conf(5) for more details.
In practice this usually means that GNOME systems have the greeter on
tty1, the first graphical login on tty2, and the second and subsequent
graphical logins (if you use "fast user switching" to get multiple
parallel graphical logins) on tty3..tty5.
Other display managers like lightdm, sddm or xdm might either be using
tty1 (as encouraged by systemd) or tty7 (more traditional on Debian
systems), and they might either reuse the greeter's X11 display for the
user's login session (as xdm traditionally did) or allocate a separate
VT for each login session (like GDM does).
GDM specifically conflicts with getty@tty1.service, so that it can take
over tty1 when the system boots in graphical mode, while leaving a getty
on tty1 when the system boots in text mode. Other display managers might
do something similar, or not.
I don't think anyone is going to be able to solve this bug, or even say
whether it *is* a bug, without more information about your system - in
particular, what display manager you are using.
> see all boot messages [on tty1], just if I need them
During a normal boot, by default the screen is cleared before showing
the login prompt, so the boot messages will not be visible anyway.
However, systemd's rescue.target (the equivalent of sysvinit single user
mode, runlevel 1) and emergency.target (like runlevel 1, but more so)
do not do this. By default, the grub bootloader generates options for
"recovery mode", which is implemented by adding "single" to the kernel
command line to select systemd rescue.target or sysvinit runlevel 1
as applicable.
smcv
Reply to: