Ho notato che il mio /var/log/boot.logfile è datato 22-04-2016, l'ultima volta che ho avviato il 15.10. Dove si trovano i boot.logfile Xenial ?

Uso journalctl

Poiché journaldcontiene tutti i registri, è possibile utilizzare il journalctlcomando con filtri adeguati. Nel caso di boot.log, che era solito contenere messaggi dal sistema init, si poteva fare:

journalctl -b0 SYSLOG_PID=1

• -b0mostra i messaggi dall'avvio corrente, -b1dall'avvio precedente e così via. Senza l' -bopzione, journalctlmostrerà i messaggi dall'inizio del registro.
• SYSLOG_PID filtra i messaggi dal PID 1, noto anche come init.

O:

journalctl -b0 --system _COMM=systemd

• _COMM=systemdcerca i messaggi dal systemdcomando. Dato che systemdè init, questo è quello a cui siamo interessati.
• --system filtra i messaggi dal registro di sistema anziché dai registri delle sessioni dell'utente.

Esempio:

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

journalctlapre i registri in un cercapersone per impostazione predefinita, quindi non è necessario eseguire il pipe less.

Registrazione persistente

Ubuntu, per impostazione predefinita, non abilita i registri giornalieri persistenti. Grazie al commento di @Auspex , devi eseguire una delle seguenti operazioni:

1. Modifica /etc/systemd/journald.confper includere:

   Storage=persistent
   

2. Crea una /var/log/journaldirectory manualmente:

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

Relazionato:

• Come posso visualizzare i messaggi di registro degli stivali precedenti in CentOS 7?

Stavo esaminando alcune segnalazioni di bug e ho notato in questo: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 che Plymouth sta effettivamente scrivendo su boot.log.

Se guardi https://launchpadlibrarian.net/257898272/plymouth-debug.log e cerchi 'boot.log' nel tuo browser otterrai le seguenti righe:

[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'

Non ho idea di come funzionano gli interni di Plymouth, ma poiché è responsabile della schermata iniziale visualizzata prima della schermata di accesso, posso solo supporre che se non esiste una schermata iniziale (schermata nera) prima di accedere alla schermata di accesso , il file non viene modificato. Se è presente una schermata iniziale visualizzata prima della schermata di accesso, l'output del processo di avvio viene reindirizzato al file boot.log.

In Ubuntu 16.04 il boot.logfile si trova ancora nella /var/logcartella, come puoi vedere qui . Il file di log di avvio è di oggi (29-04-2016). Forse qualcosa è andato storto quando hai installato Ubuntu 16.04 o hai aggiornato il sistema operativo da Ubuntu 15.10 a Ubuntu 16.04 LTS.

In alternativa è possibile esaminare il comportamento generale di avvio dal kern.logfile completo . Un'altra possibile alternativa sarebbe quella di configurare manualmente il demone syslog per generare il file di registro di avvio ed ecco un tutorial su come fare esattamente questo: Come visualizzare e configurare i log di Linux

Informazioni aggiuntive :

Ho studiato il comportamento della registrazione di avvio su due macchine diverse. Su un computer con un BIOS basato su UEFI il boot.logfile esiste, ma su un computer con un BIOS basato su legacy sembra non esistere affatto. Quindi, nel caso in cui il sistema sia installato in modalità BIOS legacy (MBR / msdos), questa potrebbe essere la spiegazione del perché il tuo boot.logfile sia datato dal 22-04-2016, è un residuo di Ubuntu 15.10.

Informazioni aggiornate 02/05/2016:

Ho continuato a studiare il comportamento del file di registrazione di avvio e ho osservato che il boot.logfile esiste ancora sulla macchina basata su UEFI, ma da alcuni giorni il file è vuoto. Un'altra alternativa che ho provato a vedere cosa succede durante il processo di avvio, era installare BootChart , ma bootchart.pngnon esisteva nella /var/logcartella come previsto dopo il riavvio del sistema ... c'era solo una /var/log/bootchartcartella vuota che non conteneva il bootchart.pngfile previsto .

Informazioni aggiornate 04/05/2016:

Oggi il boot.logfile sembra avere di nuovo "funzionalità", è pieno di informazioni parziali dal processo di avvio. Sembra essere un comportamento che cambia casualmente, che penso non possa essere risolto qui su Ask Ubuntu - quindi dovresti considerare di presentare una segnalazione di bug su Launchpad per risolverlo!

Conclusione - dopo una settimana di indagini sul boot.logcomportamento dei file in Ubuntu 16.04: non dovresti più preoccuparti /var/log/boot.loge journalctlinvece ti abitui.