Come mettere in pausa (o acquisire) i messaggi che volano al termine della sequenza di avvio?

Verso la fine della "sequenza di avvio" ¹ , vedo una lunga serie di messaggi diagnostici che volano molto rapidamente, proprio prima di vedere il prompt di accesso ² .

AFAICT, la maggior parte, se non tutte, delle linee che compongono questo output di breve durata iniziano con una delle stringhe mostrate di seguito

[  OK  ]
[FAILED]

... dove OKè in verde e FAILEDè in rosso ³ .

Questi messaggi lampeggiano troppo brevemente per consentirmi di leggere.

La mia domanda è:

C'è un modo per rendere questi messaggi più facili da leggere?

Le possibili soluzioni che vengono in mente includono (in ordine di preferenza):

1. cercare (o semplicemente reindirizzare) quei messaggi alla lettera ⁴ in un file di registro persistente;
2. abilitazione di un meccanismo di tipo paging ( Press any key to continue...);
3. inserendo una pausa (di lunghezza configurabile) dopo che quei messaggi sono stati stampati;
4. abilitando alcuni tasti (o combinazioni di tasti) per mettere in pausa l'output sullo schermo ⁵ .

EDIT: sulla base dei commenti che ho ricevuto finora, devo concludere che la parola testualmente in (1) sopra non viene capita o non viene presa sul serio, anche se ho enfatizzato il più possibile. Lo farei lampeggiare se potessi ...

EDIT2: il suggerimento che meuh ha dato nei commenti mi sembra promettente, ma non sono ancora riuscito a farlo funzionare. Ecco cosa ho fatto:

Innanzitutto, ho aggiunto quanto segue alla fine di /etc/rsyslog.conf:

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

... e riavviato. Ho visto passare i soliti messaggi diagnostici, ma nessun /var/log/boot.logfile è stato creato.

Quindi, nell'evento (certamente improbabile) che /var/log/boot.logdeve esistere già prima che rsyslogpossa scrivergli, ho eseguito (come root):

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

... dove i comandi chgrpe chmodavevano lo scopo di far corrispondere la proprietà e le autorizzazioni di /var/log/boot.logquelle di tutti gli altri file di registro in /var/log. Quindi ho riavviato, ho visto i messaggi, ecc. Il file è /var/log/boot.logrimasto vuoto dopo questo riavvio.

(Ho avuto lo stesso non-risultato quando ho cambiato i permessi di /var/log/boot.loga 666.)

Ho modificato grepl'output journalctl --boote i file sotto /var/logper qualsiasi cosa a cui potevo pensare che potesse puntare a qualcosa di sbagliato con il mio rsyslog, ma non ho trovato nulla. (Non ho alcuna familiarità con rsyslog, quindi sono sicuro che la mia ricerca fosse piuttosto inetta.)

È chiaro che ciò che ho fatto finora non è sufficiente per abilitare la registrazione desiderata. Ora sto cercando ciò che mi manca. Tuttavia, non sono stato in grado di trovare molta documentazione rilevante. Ad esempio, rsyslog.conf(5)né si rsyslogd(8)degna né di spiegare ciò che local7è ( rsyslog.conf(5)è almeno abbastanza gentile da menzionarlo una volta, senza fornire ulteriori informazioni).

Edit3

Informazioni Distro:

$ 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

Ulteriori informazioni potenzialmente rilevanti:

$ 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 Vale a dire ciò che accade quando riavvio la macchina.}

^{2 FWIW, multi-user.targetè il mio valore predefinito.}

^{3 Il testo rimanente è tutto in bianco su uno sfondo nero. Questo vale per il successivo prompt di accesso.}

^{4 Trovo assolutamente inaccettabile qualsiasi soluzione che non mi consenta di visualizzare il testo esatto di questi messaggi così come sono comparsi durante la sequenza di avvio. Dal momento che, invariabilmente, non ho una profonda familiarità con qualunque di questi messaggi diagnostici si riferisca, non è possibile per me riconoscere tutti i modi in cui le informazioni di base trasmesse dal messaggio originale possono essere parafrasate, diffuse su più altri messaggi , incluso in altri messaggi, ecc. (Solo cercando online l' esatta formulazione del messaggio originale, ho qualche speranza di trovare una soluzione al problema.) Tutto ciò che ho provato finora, incluso journalctl -be dmesgnon è riuscito a darmi i messaggi originali alla lettera. Ad esempio, quando eseguo l'avvio posso vedere solo un rosso FAILED, ma journalctl --boot | grep FAILED | wc -lritorna 0e journalctl --boot | grep -i FAILED | wc -l ritorna 1086. Nessuno di questi è quello che sto cercando.}

^{5 Nel mio sistema, avrei meno di un secondo per premere un tale tasto o una combinazione di tasti, e non è possibile avvisare quando inizia questo breve intervallo. A meno che uno non sia in grado di configurare la durata dell'intervallo durante il quale deve avvenire una tale pressione dei tasti, qualsiasi soluzione basata sulla pressione dei tasti è troppo poco pratica per essere qualcosa di più di una manovra di ultima istanza. Inoltre, FWIW, ho provato a premere il tasto o il tasto quando i messaggi lampeggiavano, ma nessuno dei due faceva differenza.Scroll
LockPause/
Break}

È possibile impostare un argomento della riga di comando del kernel (qualcosa del genere console=tty0 console=ttyS0,115200n8) per inviarli a una console seriale, quindi il dispositivo che ascolta sulla porta seriale può semplicemente registrarlo, poiché da allora è solo un flusso di testo.

E systemd è piuttosto sciocco se non registra comunque questa roba. Openrc lo fa in /var/log/rc.log. Inoltre, se non fosse systemd, probabilmente potresti modificare inittab per non mettere un getty / Xorg lì su tty1, e impedire a qualsiasi cosa (come Xorg) di passare altrove, e il vecchio testo potrebbe rimanere messo (proprio come faceva con il vecchio preSistema openSUSE). O copiarlo su un altro tty (che penso sia syslog che lo fa piuttosto che inittab ... e potresti vedere molti installatori di Linux farlo su tty9 +) Se si sposta da e verso, semplicemente non scorrerà indietro (shift + pgup ), ma probabilmente avrà una pagina di output. Forse qualcuno che sa di più su systemd conosce il nuovo equivalente di inittab e puoi cambiarlo.