Percebi que meu /var/log/boot.logarquivo tem data 22/04/2016, última vez que inicializei em 15.10. Onde estão boot.loglocalizados os arquivos Xenial ?

Usar journalctl

Como journaldcontém todos os logs, você pode usar o journalctlcomando com filtros adequados. No caso de boot.log, que costumava conter mensagens do sistema init, você pode:

journalctl -b0 SYSLOG_PID=1

• -b0mostra mensagens da inicialização atual, -b1da inicialização anterior e assim por diante. Sem a -bopção, journalctlmostrará mensagens desde o início do log.
• SYSLOG_PID filtra mensagens do PID 1, também conhecido como init.

Ou:

journalctl -b0 --system _COMM=systemd

• _COMM=systemdprocura por mensagens do systemdcomando. Desde que systemdé init, é neste que estamos interessados.
• --system filtra as mensagens do log do sistema em vez dos logs da sessão do usuário.

Exemplo:

muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility 
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static 
lines 1-23

journalctlabre os logs em um pager por padrão, para que você não precise canalizar para less.

Registro persistente

O Ubuntu, por padrão, não habilita logs persistentes de diário. Graças ao comentário de @Auspex , você precisa:

1. Edite /etc/systemd/journald.confpara incluir:

   Storage=persistent
   

2. Crie um /var/log/journaldiretório manualmente:

   mkdir /var/log/journal
   systemd-tmpfiles --create --prefix /var/log/journal
   systemctl restart systemd-journald
   

Palavras-chave:

• Como exibir mensagens de log de inicializações anteriores no CentOS 7?

Eu estava passando por alguns relatórios de bugs e notei neste: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 que Plymouth está realmente escrevendo no boot.log.

Se você consultar https://launchpadlibrarian.net/257898272/plymouth-debug.log e procurar no seu navegador por 'boot.log', obterá as seguintes linhas:

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

Não entendo como funcionam os internos de Plymouth, mas como ele é responsável pela tela inicial que aparece antes da tela de login, só posso assumir que, se não houver tela inicial (tela preta) antes de chegar à tela de login , o arquivo não é modificado. Se você tiver uma tela inicial exibida antes da tela de login, a saída do processo de inicialização será redirecionada para o arquivo boot.log.

No Ubuntu 16.04, o boot.logarquivo ainda está localizado na /var/logpasta, como você pode ver aqui . O arquivo de log de inicialização é de hoje (29-04-2016). Talvez algo tenha dado errado quando você instalou o Ubuntu 16.04 ou atualizou o sistema operacional do Ubuntu 15.10 para o Ubuntu 16.04 LTS.

Como alternativa, você pode examinar o comportamento geral de inicialização a partir do kern.logarquivo abrangente . Outra alternativa possível seria configurar manualmente o daemon syslog para gerar o arquivo de log de inicialização e aqui está um tutorial de como exatamente fazer isso: Como exibir e configurar logs do Linux

Informação adicional :

Eu investiguei o comportamento do log de inicialização em duas máquinas diferentes. Em um computador com um BIOS baseado em UEFI, o boot.logarquivo existe - mas em um computador com BIOS baseado em legado, ele parece não existir. Portanto, caso o sistema esteja instalado no modo BIOS herdado (MBR / msdos), essa poderia ser a explicação do motivo pelo qual seu boot.logarquivo foi datado de 22-04-2016, é uma sobra do Ubuntu 15.10.

Informação atualizada 02-05-2016:

Continuei investigando o comportamento do arquivo de log de inicialização e observei que o boot.logarquivo ainda existe na máquina baseada em UEFI, mas há alguns dias o arquivo está vazio. Outra alternativa que tentei ver o que acontece durante o processo de inicialização, foi instalar o BootChart , mas bootchart.pngnão existia na /var/logpasta conforme o esperado após a reinicialização do sistema ... havia apenas uma /var/log/bootchartpasta vazia que também não continha o bootchart.pngarquivo esperado .

Informações atualizadas 04-05-2016:

Hoje, o boot.logarquivo parecia ter "funcionalidade" novamente, é preenchido com informações parciais do processo de inicialização. Parece ser um comportamento de mudança aleatória, que eu acho que não pode ser resolvido aqui no Ask Ubuntu - então você deve considerar registrar um bug no Launchpad para resolver isso!

Conclusão - após uma semana de investigação do boot.logcomportamento do arquivo no Ubuntu 16.04: Você não deve se preocupar /var/log/boot.logmais e apenas se acostumar journalctl.