@jcm33 Alors suite à la lecture de cette formidable discussion: [SYSTEMD] en manque de tty j’ai découvert que systemd (que je ne connais pas encore du tout) ne « spawnnait » pas les tty du tout comme le faisait init.
En creusant un peu plus, je suis arrivé là systemd for Administrators, Part XVI et il y est dit:
By default this automatic spawning is done for the VTs up to VT6 only (in order to be close to the traditional default configuration of Linux systems)[1]. Note that the auto-spawning of gettys is only attempted if no other subsystem took possession of the VTs yet. More specifically, if a user makes frequent use of fast user switching via GNOME he’ll get his X sessions on the first six VTs, too, since the lowest available VT is allocated for each session.
Ce qui était précisément mon cas avant que je ne reboote ma machine: sous gnome, avec mon fils et ma fille qui ont chacun leur session. Première cause possible, les diverses sessions avaient saturé les tty disponibles et en rebootant, je les ai juste libérés.
Mais je pencherais plutôt pour:
Two VTs are handled specially by the auto-spawning logic: firstly tty1 gets special treatment: if we boot into graphical mode the display manager takes possession of this VT. If we boot into multi-user (text) mode a getty is started on it – unconditionally, without any on-demand logic[2].
Je suppose donc qu’il devait manquer un fichier de config quelquepart, et qu’en faisant un passage en « runlevel 2 » (qu’on appellera plutôt multi-user.target en systemd, je découvre), ça a forcé la génération d’une configuration par défaut pour garantir l’ouverture du VT sur le tty1 (un peu critique de pouvoir ouvrir au moins une session en console donc on force), et qu’une fois cette config présente, le service d’ouverture de VT à la demande sur les tty s’est retrouvé avec ce qu’il fallait pour marcher en graphical.target
Ou un truc comme ça.