Hello Simon,
thanks for your ultra-fast reply!
On Tue, Jul 28, 2020 at 10:05:34AM +0100, Simon McVittie wrote:
> 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.
I use sddm. GNOME is not in use at all, my wife uses KDE, and I use
WindowMaker.
> 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.
Thanks, yes, I looked at logind.conf(5). And tty2 and so on behave as
they did in stable, just tty1 no longer does.
> 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 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.
> 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.
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?
> > 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.
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
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: PGP signature