How to [...] get a boot log.
journalctl -b
As mensagens que você verá também são copiadas pelo rsyslog, para os vários arquivos de log sob / var / log /.
Por padrão, o Debian está configurado para usar o rsyslog para logging persistente. Com base nesse padrão, journalctl só é capaz de mostrar mensagens recentes, que são armazenadas temporariamente por journald .
Eu geralmente recomendo a ativação do log persistente para o diário (você ainda pode continuar executando o rsyslog, se quiser). É útil ter os recursos de pesquisa de journalctl disponíveis, especialmente à medida que mais softwares iniciam o registro no log do sistema. Por exemplo, você pode solicitar o log da inicialização anterior com journalctl -b -1 . Você pode ativar o diário persistente da seguinte forma:
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
- link
Ativar o bootlogd.service não ajudará você
+ echo "(Booted up using systemd which doesn't write logs to system console. Please check 'journalctl -b' instead.)" > /var/log/boot
- logs do relatório de bugs do Debian # 791907 , anexo 0001-bootlogd-menção-ele-ganha-t-faça-qualquer-sob-systemd.patch
O acima não dá a história completa. O Systemd não grava nenhuma mensagem no console na configuração padrão do Debian , onde o sistema é inicializado com a opção quiet na linha de comando do kernel. Além disso, ele ativará as mensagens do console se um serviço não for iniciado. Eu escrevi alguns detalhes sobre isso aqui .
A mensagem de erro / comportamento do systemctl que você encontrou pode ser considerada infeliz. Se alguém se lembra de acompanhar o patch que foi aplicado
Note that systemd package will need to drop the mask of bootlogd.service for this to work.
a mensagem de erro desaparecerá, e /var/log/boot deve ser criado no momento da inicialização, começando com a mensagem citada anteriormente :-). No entanto, eu recomendaria contra fazer isso. O recurso de redirecionamento do console, que bootlogd usa, também deve ser usado por plymouth , portanto, há um conflito. Eu não sei o que aconteceria como resultado desse conflito. Eu deixaria plymouth sozinho, porque pode ser invocado em alguns casos, como solicitar senhas de criptografia de disco.
O BTW plymouth deve criar /var/log/boot.log , mostrando tudo o que foi gravado no console durante a inicialização. Pelo menos esse é o arquivo que ele usa no Fedora e no Ubuntu. Aparentemente parece que não foi totalmente confiável em algumas versões no Ubuntu .
BTW, o tipo de máscara interna estranha que gera a mensagem de erro que você viu, é um mecanismo que também foi usado para evitar a execução de sysVinit scripts de inicialização que foram reimplementados internamente.