Comment mettre en pause (ou capturer) les messages qui volent à la fin de la séquence de démarrage?

Vers la fin de la "séquence de démarrage" ¹ , je vois une longue série de messages de diagnostic passer très rapidement, juste avant de voir l'invite de connexion ² .

AFAICT, la plupart, sinon la totalité, des lignes composant cette sortie de courte durée commencent par l'une des chaînes ci-dessous

[  OK  ]
[FAILED]

... où le OKest en vert et le FAILEDest en rouge ³ .

Ces messages clignotent trop brièvement pour que je puisse les lire.

Ma question est:

Existe-t-il un moyen de rendre ces messages plus faciles à lire?

Les solutions possibles qui vous viennent à l'esprit comprennent (par ordre de préférence):

1. envoyer (ou simplement rediriger) ces messages textuellement ⁴ vers un fichier journal persistant;
2. activer un mécanisme de type pagination ( Press any key to continue...);
3. insérer une pause (de longueur configurable) après l'impression de ces messages;
4. activer une touche (ou une combinaison de touches) pour suspendre la sortie vers l'écran ⁵ .

EDIT: sur la base des commentaires que j'ai obtenus jusqu'à présent, je dois conclure que le mot mot pour mot dans (1) ci-dessus n'est pas compris ou n'est pas pris au sérieux, même si j'ai insisté autant que possible. Je le ferais flasher si je pouvais ...

EDIT2: la suggestion que meuh a faite dans les commentaires me semble prometteuse, mais je n'ai pas encore réussi à la faire fonctionner. Voici ce que j'ai fait:

Tout d'abord, j'ai ajouté ce qui suit à la fin de /etc/rsyslog.conf:

# Save boot messages also to boot.log
local7.* /var/log/boot.log

... et redémarré. J'ai vu passer les messages de diagnostic habituels, mais aucun /var/log/boot.logfichier n'a été créé.

Ensuite, dans le cas (certes peu probable) où le /var/log/boot.logdoit déjà exister avant de rsyslogpouvoir y écrire, j'ai exécuté (en tant que root):

touch /var/log/boot.log
chgrp adm /var/log/boot.log
chmod 640 /var/log/boot.log

... où les commandes chgrpet chmodétaient destinées à faire correspondre la propriété et les autorisations /var/log/boot.logde tous les autres fichiers journaux sous /var/log. J'ai ensuite redémarré, vu les messages, etc. Le fichier /var/log/boot.logest resté vide après ce redémarrage.

(J'ai obtenu le même non-résultat lorsque j'ai changé les autorisations de /var/log/boot.logen 666.)

J'ai grepédité la sortie de journalctl --bootet les fichiers sous /var/logpour tout ce à quoi je pouvais penser qui pourrait indiquer quelque chose de mal avec moi rsyslog, mais je n'ai rien trouvé. (Je ne suis pas du tout familier rsyslog, donc je suis sûr que ma recherche était assez inepte.)

Il est clair que ce que j'ai fait jusqu'à présent n'est pas suffisant pour activer la journalisation souhaitée. Je cherche maintenant ce qui me manque. Je n'ai cependant pas pu trouver beaucoup de documentation pertinente. Par exemple, ni rsyslog.conf(5)ne rsyslogd(8)daigne expliquer ce qu'est local7( rsyslog.conf(5)est au moins assez gracieux pour le mentionner une fois, sans donner plus d'informations).

EDIT3

Informations sur la distribution:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.3 (jessie)
Release:    8.3
Codename:   jessie
$ uname -a
Linux myhost 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux

EDIT4

Informations supplémentaires potentiellement pertinentes:

$ cat /lib/systemd/system/rsyslog.service
[Unit]
Description=System Logging Service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=http://www.rsyslog.com/doc/

[Service]
Type=notify
ExecStart=/usr/sbin/rsyslogd -n
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=syslog.service

$ cat /proc/$(pgrep rsyslogd)/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128529               128529               processes 
Max open files            1024                 4096                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128529               128529               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

$ sudo ls /proc/$(pgrep rsyslogd)/fd | wc -l
10

^{1 C'est-à- dire ce qui se passe lorsque je (re) démarre ma machine.}

^{2 FWIW, multi-user.targetest ma valeur par défaut.}

^{3 Le texte restant est entièrement en blanc sur fond noir. Cela est vrai pour l'invite de connexion suivante.}

^{4 Je trouve totalement inacceptable toute solution qui ne me permet pas de voir le texte exact de ces messages tels qu'ils sont apparus lors de la séquence de démarrage. Étant donné que, invariablement, je ne connais pas intimement l’un quelconque de ces messages de diagnostic, il m’est impossible de reconnaître toutes les façons dont les informations sous-jacentes véhiculées par le message original peuvent être paraphrasées, réparties sur plusieurs autres messages , subsumé dans d'autres messages, etc. (Ce n'est qu'en recherchant en ligne le libellé exact du message d'origine que j'ai un espoir de trouver une solution au problème.) Tout ce que j'ai essayé jusqu'à présent, y compris journalctl -bet dmesgn'a pas réussi à me donner les messages originaux textuellement. Par exemple, lorsque je lance le démarrage, je ne peux voir qu'un seul rouge FAILED, mais journalctl --boot | grep FAILED | wc -lrevient 0et journalctl --boot | grep -i FAILED | wc -l revient 1086. Je ne cherche ni l'un ni l'autre de ces éléments.}

^{5 Dans mon système, j'aurais moins d'une seconde pour appuyer sur une telle touche ou combinaison de touches, et il n'y a aucun avertissement du début de ce bref intervalle. À moins que l'on soit en mesure de configurer la durée de l'intervalle pendant lequel une telle pression sur une touche doit se produire, toute solution basée sur une pression sur une touche est trop impraticable pour être autre chose qu'une manœuvre de dernier recours. De plus, FWIW, j'ai essayé d'appuyer sur la touche ou sur la touche lorsque les messages clignotaient, mais aucun n'a fait de différence.Scroll
LockPause/
Break}

Vous pouvez définir un argument de ligne de commande du noyau (quelque chose comme console=tty0 console=ttyS0,115200n8) pour les envoyer à une console série à la place, puis le périphérique qui écoute sur le port série peut simplement l'enregistrer, car il ne s'agit que d'un flux de texte.

Et systemd est assez idiot s'il n'enregistre pas ces trucs de toute façon. Openrc le fait dans /var/log/rc.log. De plus, si ce n'était pas systemd, vous pourriez probablement modifier inittab pour ne pas y mettre un getty / Xorg sur tty1, et empêcher quoi que ce soit (comme Xorg) de basculer ailleurs, et l'ancien texte pourrait rester en place (comme il l'a fait sur l'ancien pre-systemd openSUSE). Ou copiez-le sur un autre tty (ce que je pense que syslog fait cela plutôt que inittab ... et vous pourriez voir de nombreux installateurs linux le faire sur tty9 +) S'il bascule et revient, il ne reviendra pas en arrière (shift + pgup ), mais aura probablement une page de sortie. Peut-être que quelqu'un qui en sait plus sur systemd connaît le nouvel équivalent d'inittab et vous pouvez changer cela.