Plus d'accés console en CTRL+ALT+Fx en gnome/stretch

Support Debian
#1

Bonjour,
je suis passé en stretch le weekend dernier, et je viens de voir que je n’avais plus accés aux consoles avec CTRL+ALT+Fx
Ce n’est pas un problème habituel d’ecran noir avec le pilote NVIDIA, c’est carrément la combinaison de touches qui ne fait plus rien.

sous gnome, quand je lance le clavier visuel, que ce soit avec le layout fr ou us (et plusieurs autres):

  • quand j’appuie sur F1, la touche F1 à l’écran se grise, c’est bien détecté,
  • quand j’appuie sur les touches CTRL et ALT l’appui des deux touches simultanées est bien fait,
  • par contre, si je presse ensuite la touche F1 elle ne se grise pas…

A tous hasards si l’info peut servir, je suis en NVIDIA module propriétaire, et mon clavier est un Logitech Cordless Desktop EX110

Une idée ?

#2

Bonjour,

Juste pour être sûr, Ctrl + Alt + F4 a-t-il été tenté ?

#3

salut
ça a rapport avec getty
https://wiki.debian.org/getty

root@debian:/# systemctl status *getty*
● getty@tty1.service - Getty on tty1
   Loaded: loaded (/lib/systemd/system/getty@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-06-26 21:15:46 CEST; 9min ago
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html
 Main PID: 776 (agetty)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/system-getty.slice/getty@tty1.service
           └─776 /sbin/agetty --noclear tty1 linux

juin 26 21:15:46 debian systemd[1]: Started Getty on tty1.

● system-getty.slice
   Loaded: loaded
   Active: active since Mon 2017-06-26 21:15:22 CEST; 9min ago
    Tasks: 1
   CGroup: /system.slice/system-getty.slice
           └─getty@tty1.service
             └─776 /sbin/agetty --noclear tty1 linux

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● getty.target - Login Prompts

fourni par

https://packages.debian.org/stretch/util-linux

#4

j’avais eu le même problème; la solution qui a fonctionné pour moi est içi:

https://www.debian-fr.xyz/viewtopic.php?f=8&t=760

#5

@jcsm33 oui, bien sûr. Aucune touche de fonction n’a d’effet.

@anonyme2 merci. Moi aussi, j’ai eu des écrans noirs plusieurs fois avec nvidia. Mais comme je l’ai explicitement dit dans mon message de base, ce n’est pas un soucis d’écran noir, mais un soucis de touches qui n’ont pas d’effet.

@grandtoubab Intéressant, mais toi aussi tu me parles de solutionner un truc qui ne marcherait pas dans le tty >quand je switche<, mais je le répète: mon problème est que LA COMBINAISON DE TOUCHE NE FAIT RIEN.
C’est avant de switcher que ça ne va pas.

J’ai quand même creusé ta piste un peu, mais j’ai bien un service getty qui tourne:

mj@mercure:~$ systemctl status *getty*
● system-getty.slice
   Loaded: loaded
   Active: active since Fri 2017-06-23 11:52:40 CEST; 3 days ago
    Tasks: 0
   CGroup: /system.slice/system-getty.slice

● getty.target - Login Prompts
   Loaded: loaded (/lib/systemd/system/getty.target; static; vendor preset: enabled)
   Active: active since Fri 2017-06-23 11:52:41 CEST; 3 days ago
     Docs: man:systemd.special(7)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html

Bon, je ne vois aucune trace de sous process, mais c’est a priori juste normal vu que je n’ai aucune session console ouverte.

De plus, pour util-linux, je suis bien à jour:

mj@mercure:~$ apt-cache policy util-linux
util-linux:
  Installé : 2.29.2-1
  Candidat : 2.29.2-1
 Table de version :
 *** 2.29.2-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

et pour finir, j’ai bien des sessions ouvertes sur les derniers tty:

mj@mercure:~$ ps aux | grep tty[8-9]
Debian-+   776  0.0  0.0  20760  2520 tty9     Ss+  juin23   0:00 daemon --foreground --respawn --attempts=20 --delay=10 --name=9-_-_var_-_log_-_syslog --pidfile=/run/console-log/Debian-console-log/9-_-_var_-_log_-_syslog --user Debian-console-log.adm /usr/share/console-log/logpager -- less /var/log/syslog 7000000
Debian-+   808  0.0  0.0  20760  2564 tty8     Ss+  juin23   0:00 daemon --foreground --respawn --attempts=20 --delay=10 --name=8-_-_var_-_log_-_exim4_-_mainlog --pidfile=/run/console-log/Debian-console-log/8-_-_var_-_log_-_exim4_-_mainlog --user Debian-console-log.adm /usr/share/console-log/logpager -- less /var/log/exim4/mainlog 7000000

Mais ctrl+alt+F8 ou F9, ne marchent pas, aucun effet.

#6

Alors le clavier?

pour mon hp

cat /etc/default/keyboard 
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="hpdv5"
XKBLAYOUT="fr"
XKBVARIANT="oss_latin9"
XKBOPTIONS="terminate:ctrl_alt_bksp"

BACKSPACE="guess"

avec xmodmap
on peut verifier

xmodmap -pk | grep F2
     68    	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0x1008fe02 (XF86Switch_VT_2)	0xffbf (F2)	0xffbf (F2)	0x1008fe02 (XF86Switch_VT_2)	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0xffbf (F2)	0x1008fe02 (XF86Switch_VT_2)

0x1008fe02 (XF86Switch_VT_2) semble intéressant

https://www.x.org/archive/X11R6.8.2/doc/xmodmap.1.html

#7

Ca remarche, mais je ne sais pas pourquoi…

J’ai installé un environnement xfce, repassage par gdm et lancement de session xfce, marche pas.
Reboot, test xfce, bascule gnome, marche pas.
Reboot, je précise que je veux un runlevel 2 dans le boot grub manuel, gdm ne se lance pas c’est parfait, j’arrive donc bien à un prompt console, et merveille, je peux switcher avec alt+FN entre les tty.
reboot de nouveau mais en normal, login sous gnome, et là… Ca marche !!!

C’est n’importe quoi ça, je suis content, mais ça m’énerve que ma debian change de comportement sans que je fasse rien de volontaire, ça ressemble à windaube.

#8

Je ne suis pas sûr de bien comprendre ce passage.

Debian ne propose que 2 runlevel depuis… toujours ?

C’est plutôt systemd qui ne lance pas gdm avec la saisie manuelle dans grub.

Quelle était cette saisie à propos ?

#9

Oui, de fait, je n’ai que 2 options de boot, mais par défaut, ça lance en runlevel 5.

J’ai donc juste choisi “advanced options”, puis sur la ligne linux /boot/… j’ai juste rajouté un 2, puis F10 pour lancer le boot.

#10

Juste pour vérification, que donne $ grep initdefault /etc/inittab ?

Bon, la question n’a pas de sens avec systemd…

#11

c’était pareil chez moi; impossible de passer en mode console; avez vous au moins essayé les infos que je vous ai données?

#12

@jcsm33 De fait. :smile:
mj@mercure:~$ grep initdefault /etc/inittab
grep: /etc/inittab: Aucun fichier ou dossier de ce type

@anonyme2 Non. J’avais d’autres pistes proposées qui elles, semblaient plus concerner le problème.
Ajouter un modeset au boot noyau ou repasser à nouveau n’étaient pas le genre de choses que j’avais envie de tester en premier pour corriger le problème.

#13

Ce qui reste étonnant, c’est la façon dont le problème a été résolu.

#14

@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à http://0pointer.de/blog/projects/serial-console.html 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.