I upgraded from Debian Stable to Testing some days ago (see #964477
for some information why this was not entirely smooth). I did not
upgrade the kernel.

Now the virtual terminal 1 is no longer usuable. It only prints the
very few lines of the boot process and some more lines when shutting
down.

After boot I see:
/dev/mapper/samd--vg-root: clean, 571317/1020000 files, 3545957/4077568 blocks
[    3.477202] Error: Driver 'pcspkr' is already registered, aborting...
[    3.854191] DVB: Unable to find symbol simple_tuner_attach()

X is running on VT 7, so this is not the cause (and it does so for
many years already).

I'm not sure which other programm could "lock" VT1.

In http://0pointer.de/blog/projects/serial-console.html I read that X should
start on VT1? Maybe systemd is no confused?

I see that there is a
/etc/systemd/system/getty.target.wants/getty@tty1.service ->
/lib/systemd/system/getty@.service
file, but this link is from 2016 and the file under /lib does not
indicate any special handling of VT1 (however, it might explain why in
#964477 the prompts where not localized).

It would be great to have VT1 again ususable and to see all boot
messages there, just if I need them (there are in the logs, of course
as well, so this is not too important but very nice).

...

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.

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

Hello Simon,
thanks for your ultra-fast reply!

I use sddm. GNOME is not in use at all, my wife uses KDE, and I use
WindowMaker.

Thanks, yes, I looked at logind.conf(5). And tty2 and so on behave as
they did in stable, just tty1 no longer does.

I found "getty@tty1.service", however, I'm not sure I understood it.
There is not dedicated man page for it and systemd-getty-generator(8)
talks about serial gettys, not virtual ones.

SDDM, because it lets us select the window manager (although it is
rather dump, unfortnately).

So I get this might be an interaction issue between the updated SDDM and the
updated systemd?

Well, what I meant was that it would be nice to always have the full
(last screen, at least) of boot messages on VT1, but this is a rather
very minor issue.

Thanks!

Greetings

                Helge

Per description this sounds like an ssdm issue, or at least
something the sddm maintainers could help diagnosing.

Chris

reassign 96641 sddm
thanks

Hello sddm maintainers,
is there any chance to get my VT 1 back, i.e. this fixed before the
release of bullseye?

If you need any further information I'm available to provide those
(and test things if needed).

Thanks & Greetings

              Helge

From the explanations given by Simon I don't see a way how this could
work out. Sddm cannot enable getty on tty1, because this would conflict
with say gdm in case the admin decides to switch to gdm.

This is probably up to a Debian-wide policy decision on what ttty needs
to be used by DMs, and how other ttys are handled.

But that will surely not happen til bullseye release.

But this is just IMHO.

Best

Norbert

Hello Norbert,

Thanks for the explanation. It's just a pitty, it worked all the years
(ever since I can remember, actually, basically since the 90s) until I
decided to switch to Testing last year. And yes, I used different
display manager chooser (kdm, xdm (long, long ago) and the last years
sddm).

So hopefully it can be restored soon.

Greetings

            Helge

Hi Helge,

I cannot agree more with you than 100%, but tell this to, well, not
surprisingly, GNOME and their rework of everything, and Debian following
blindly.

That would surprise me.

Best

Norbert