Como pausar (ou capturar) as mensagens que passam no final da sequência de inicialização?

No final da "sequência de inicialização" ¹ , vejo uma longa série de mensagens de diagnóstico passar rapidamente, logo antes de ver o prompt de login ² .

AFAICT, a maioria, se não todas, as linhas que compõem essa saída de curta duração começam com uma das strings mostradas abaixo

[  OK  ]
[FAILED]

... onde OKestá verde e FAILEDvermelho ³ .

Essas mensagens piscam muito brevemente para eu ler.

Minha pergunta é:

Existe uma maneira de facilitar a leitura dessas mensagens?

As possíveis soluções que vêm à mente incluem (em ordem de preferência):

1. enviar (ou simplesmente redirecionar) essas mensagens literalmente ⁴ para algum arquivo de log persistente;
2. ativar um mecanismo do tipo paginação ( Press any key to continue...);
3. inserir uma pausa (de tamanho configurável) após a impressão dessas mensagens;
4. permitindo que alguma tecla (ou combinação de teclas) faça uma pausa na saída da tela ⁵ .

EDIT: com base nos comentários que recebi até agora, devo concluir que a palavra literal em (1) acima não está sendo entendida ou não está sendo levada a sério, apesar de ter enfatizado o máximo que posso. Eu faria brilhar se pudesse ...

EDIT2: a sugestão que meuh deu nos comentários parece promissora para mim, mas ainda não consegui fazê-lo funcionar. Aqui está o que eu fiz:

Primeiro, adicionei o seguinte no final de /etc/rsyslog.conf:

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

... e reiniciado. Vi as mensagens de diagnóstico comuns passarem, mas nenhum /var/log/boot.logarquivo foi criado.

Então, no evento (reconhecidamente improvável) que o /var/log/boot.logarquivo já deveria existir antes, ele rsyslogpode escrever nele, eu executei (como root):

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

... onde os comandos chgrpe chmodforam criados para tornar a propriedade e as permissões /var/log/boot.logcorrespondentes às de todos os outros arquivos de log em /var/log. Então eu reiniciei, vi as mensagens, etc. O arquivo /var/log/boot.logpermaneceu vazio após esta reinicialização.

(Obtive o mesmo resultado quando alterei as permissões de /var/log/boot.logpara 666.)

Eu grepeditei a saída journalctl --boote os arquivos abaixo /var/logde qualquer coisa que eu pudesse pensar que pudesse apontar algo errado com o meu rsyslog, mas não encontrei nada. (Não conheço nada rsyslog, por isso tenho certeza de que minha pesquisa foi bastante inepta.)

Está claro que o que fiz até agora não é suficiente para permitir o log desejado. Agora estou procurando o que está faltando. No entanto, não consegui encontrar muita documentação relevante. Por exemplo, rsyslog.conf(5)nem rsyslogd(8)se digna de explicar o que local7é ( rsyslog.conf(5)é pelo menos gentil o suficiente mencioná-lo uma vez, sem fornecer mais informações).

EDIT3

Informações de distribuição:

$ 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

Informações adicionais potencialmente relevantes:

$ 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 Ou seja, o que acontece quando eu (re) inicialização minha máquina.}

^{2 FWIW, multi-user.targeté o meu padrão.}

^{3 O texto restante está todo em branco sobre um fundo preto. Isso ocorre no prompt de login subsequente.}

^{4 Acho completamente inaceitável qualquer solução que não permita que eu veja o texto exato dessas mensagens como elas apareceram durante a sequência de inicialização. Como, invariavelmente, não estou intimamente familiarizado com o que essas mensagens de diagnóstico se referem, não é possível reconhecer todas as maneiras pelas quais as informações subjacentes transmitidas pela mensagem original podem ser parafraseadas, espalhadas por várias outras mensagens. , incluído em outras mensagens etc. (Somente pesquisando on-line o texto exato da mensagem original tenho esperança de encontrar uma solução para o problema.) Tudo o que tentei até agora, incluindo journalctl -be dmesgfalhou em me fornecer as mensagens originais literalmente. Por exemplo, quando executo a inicialização, vejo apenas um vermelho FAILED, mas journalctl --boot | grep FAILED | wc -lretorna 0e journalctl --boot | grep -i FAILED | wc -l retorna 1086. Nenhuma delas é o que estou procurando.}

^{5 No meu sistema, eu teria menos de um segundo para pressionar essa tecla ou combinação de teclas e não há aviso prévio de quando esse breve intervalo é iniciado. A menos que se consiga configurar a duração do intervalo durante o qual esse pressionamento de tecla deve ocorrer, qualquer solução baseada em pressionamento de tecla é impraticável demais para ser algo além de uma manobra de último recurso. Além disso, FWIW, tentei pressionar a tecla ou a tecla quando as mensagens piscaram, mas nenhuma fez diferença.Scroll
LockPause/
Break}

Você pode definir um argumento de linha de comando do kernel (algo como console=tty0 console=ttyS0,115200n8) para enviá-lo para um console serial e, em seguida, o dispositivo que escuta na porta serial pode simplesmente registrá-lo, pois é apenas um fluxo de texto.

E o systemd é bem bobo se não registrar essas coisas de qualquer maneira. O Openrc faz isso em /var/log/rc.log. Além disso, se não fosse systemd, você provavelmente poderia modificar o inittab para não colocar um getty / Xorg lá no tty1, e impedir que qualquer coisa (como o Xorg) alternasse para outro lugar, e o texto antigo poderia permanecer como o antigo openSUSE pré-sistema). Ou copie-o para outro tty (que eu acho que o syslog faz isso em vez do inittab ... e você pode ver muitos instaladores linux fazendo isso no tty9 +) Se ele alternar para trás e para trás, ele simplesmente não voltará (shift + pgup ), mas provavelmente terá uma página de saída. Talvez alguém que saiba mais sobre o systemd conheça o novo equivalente ao inittab e você possa mudar isso.