La mia domanda è: come posso trovare il registro di avvio dal precedente tentativo di avvio del sistema?

Oggi quando ho acceso il mio PC per la prima volta, il processo di avvio si è fermato sul logo Ubuntu, quando ho premuto Escho visto diverse righe contenenti alcuni errori del kernel e il riavvio richiesto in basso, quindi ho premuto Ctrl+ ALt+ Dele l'avvio successivo è andato bene senza problemi.

Ho difficoltà a trovare i messaggi dalla schermata che ho visto durante il primo avvio non riuscito. Avrei dovuto scattare una foto sul mio telefono?

/var/log/bootè lì, ma vuoto, ho cercato kern.log e syslog per stringhe che ricordavo con la data odierna, errorma non ho trovato nulla di familiare a quello che ho visto nella schermata di avvio precedente.

$ journalctl -b -1 mi dà solo messaggi del kernel durante l'avvio, lo trovo anche altrove, e non sono quelli che apparivano sullo schermo durante l'avvio, journalctl è inutile per me, sto cercando messaggi che appaiono sullo schermo durante l'avvio.

Per ora, l'unica opzione è scattare una foto di scrivere il messaggio su carta.

Segnalato come un bug che è una funzionalità non documentata

C'è una segnalazione di bug archiviata su questo argomento . Perché rsysloggià mantiene molteplici riviste di avvio in /var/log/sysloge syslog.1, .2.gz, .3.gz... syslog.7.gzgli sviluppatori sentivano mantenendo in più journalctltronchi sarebbe sprecare spazio su disco.

La segnalazione di bug indica il 3 gennaio 2018 che per le nuove installazioni rsyslognon sarà più l'impostazione predefinita e che journalctlconserverà più registri dei dati di avvio.

Crea più log di avvio senza reinstallare Ubuntu

La maggior parte di noi non eseguirà una nuova installazione, quindi per abilitare più journalctllog di avvio, nel qual caso possiamo usare:

$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
Cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported

Secondo questo rapporto github, il messaggio di avviso "Impossibile impostare l'attributo del file" può essere ignorato.

Impostazione opzionale di archiviazione persistente

Dopo aver usato la registrazione di avvio precedente per molti mesi ho scoperto un'altra opzione che può essere impostata in /etc/systemd/journald.conf:

Dalla pagina man journald.conf :

= bagagli

Controlla dove archiviare i dati del journal. Uno di "volatile", "persistente", "auto" e "nessuno". Se "volatile", i dati del registro journal verranno archiviati solo in memoria, ovvero sotto la gerarchia / run / log / journal (che viene creata se necessario). Se "persistenti", i dati verranno archiviati preferibilmente su disco, ovvero sotto la /var/log/journalgerarchia (che viene creata se necessario), con un fallback a /run/log/journal(che viene creato se necessario), durante l'avvio anticipato e se il disco non è scrivibile. "auto" è simile a "persistente" ma la directory /var/log/journal non viene creata se necessario, quindi la sua esistenza controlla dove vanno i dati di registro. "none" disattiva tutta la memoria, tutti i dati di registro ricevuti verranno eliminati. Inoltro ad altri target, come la console, il buffer di registro del kernel, o un socket syslog funzionerà comunque. L'impostazione predefinita è "auto".

In poche parole rimuovere il commento e rivedere la riga per:

Storage=persistent

Visualizza l'elenco degli stivali precedenti

$ journalctl --list-boots
-15 58a9e56135564cd8a52d547b19e76bf5 Fri 2018-02-02 18:34:35 MST—Fri 2018-02-02 23:07:14 M
-14 3514e056440341b1b6e5f03d109681bc Sat 2018-02-03 06:05:12 MST—Sat 2018-02-03 08:07:44 M
-13 0d1a32dc275348589f5ecdc72180c018 Sat 2018-02-03 08:08:05 MST—Sat 2018-02-03 08:08:34 M
-12 74159b593f3a401589ee6bd78e31684b Sat 2018-02-03 08:08:51 MST—Sun 2018-02-04 08:32:09 M
-11 4b394a9aad584ab2bfabe3b77eeed78f Sun 2018-02-04 08:32:26 MST—Mon 2018-02-05 16:54:02 M
-10 8e461ed2593c4fd896ca3b71eb3c0fba Mon 2018-02-05 16:54:34 MST—Tue 2018-02-06 03:54:30 M
 -9 ec7ba0e4dfe241c0b9c978d278fcca6d Tue 2018-02-06 03:54:47 MST—Tue 2018-02-06 16:25:02 M
 -8 b5c110267c214c38b63d0a367197d118 Tue 2018-02-06 16:25:19 MST—Thu 2018-02-08 16:49:03 M
 -7 75c3b117ac6a4de984dc3ced15edb7f8 Thu 2018-02-08 16:49:22 MST—Fri 2018-02-09 03:51:09 M
 -6 7338bd1007bc42dda5c8667eeefe1a59 Fri 2018-02-09 03:51:26 MST—Fri 2018-02-09 16:55:52 M
 -5 4b6cd0121327454ca3db035c7ed42df6 Fri 2018-02-09 16:56:09 MST—Sat 2018-02-10 07:55:14 M
 -4 0d56207f9ec0405ca3a3fd638334de2f Sat 2018-02-10 07:55:32 MST—Mon 2018-02-12 22:16:05 M
 -3 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14 22:58:56 M
 -2 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17 22:46:14 M
 -1 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19 04:16:36 M
  0 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Tue 2018-02-20 18:51:42 M

Visualizza l'ultimo registro di avvio

$ journalctl -b-1
-- Logs begin at Fri 2018-02-02 18:34:35 MST, end at Thu 2018-03-01 16:43:25 MST. --
Feb 28 20:03:15 alien systemd-journald[290]: Runtime journal (/run/log/journal/) is 8.0M, 
Feb 28 20:03:15 alien kernel: Linux version 4.14.23-041423-generic (kernel@kathleen) (gcc 
Feb 28 20:03:15 alien kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.23-041423-generi
Feb 28 20:03:15 alien kernel: KERNEL supported cpus:
Feb 28 20:03:15 alien kernel:   Intel GenuineIntel
Feb 28 20:03:15 alien kernel:   AMD AuthenticAMD
Feb 28 20:03:15 alien kernel:   Centaur CentaurHauls
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registe
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Feb 28 20:03:15 alien kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 b
Feb 28 20:03:15 alien kernel: e820: BIOS-provided physical RAM map:
Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usabl
lines 1-19

Presta molta attenzione al parametro -b-1che è diverso rispetto ad altri riferimenti che potresti vedere. Dalla pagina man :

-b [ID][±offset], --boot=[ID][±offset]

Mostra i messaggi da un avvio specifico. Ciò aggiungerà una corrispondenza per "_BOOT_ID =".

L'argomento potrebbe essere vuoto, nel qual caso verranno mostrati i log per l'avvio corrente.

Se l'ID di avvio viene omesso, un offset positivo cercherà gli boot a partire dall'inizio del journal e un offset uguale o inferiore a zero cercherà gli boot a partire dalla fine del journal. Pertanto, 1 indica il primo avvio trovato nel diario in ordine cronologico, 2 il secondo e così via; mentre -0 è l'ultimo avvio, -1 l'avvio prima dell'ultimo e così via. Un offset vuoto equivale a specificare -0, tranne quando l'avvio corrente non è l'ultimo di avvio (ad esempio perché è stato specificato --directory per esaminare i log da una macchina diversa).

Quindi di tanto in tanto, con crono timer, puoi pulire i vecchi registri :

journalctl --vacuum-time=2d  # keep last two days or

journalctl --vacuum-size=300M  # keep last 300MB

Ho avuto lo stesso problema e apparentemente ho trovato la risposta sul #ubuntucanale irc.

Per qualsiasi motivo, mi mancava la cartella /var/log/journal accessibile dal gruppo al diario di sistema.

Dopo aver aggiunto la cartella, sono stato in grado di vedere i registri degli stivali precedenti tramite $ journalctl -b1

I passaggi per realizzare la soluzione dalla risposta principale qui, dalla pagina man di systemd-journald:

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

L'ho fatto come su

La risposta può essere trovata in man journald.conf, in particolare l'opzione Storage=:

Controlla dove archiviare i dati del journal. Uno di "volatile", "persistente", "auto" e "nessuno". [...] "auto" è simile a "persistente" ma la directory / var / log / journal non viene creata se necessario, quindi la sua esistenza controlla dove vanno i dati di registro. [...] Il valore predefinito è "auto".

Tieni presente che non è necessario ruotare il registro o tecniche simili comuni con il vecchio demone syslog. Il file journal è configurato per impostazione predefinita in modo che raggiunga una certa dimensione e le voci di registro precedenti vengono automaticamente eliminate quando il file journal diventa troppo grande.

Sul mio sistema questa dimensione è attualmente configurata come 120 MB, è possibile regolarla /etc/systemd/journald.confper l'unità systemd-journald.service.

Utilizzare journalctl -bXdove x è l'avvio a cui si fa riferimento, così come lo -b0è il proprio avvio effettivo e -b-1l'avvio precedente (che funziona solo se è presente la cartella /var/log/journalappartenente al gruppo "systemd-journal"). Non posso dirti fino a che punto si può andare esattamente ma quei due di sicuro.

Elenca gli stivali disponibili con

journalctl --list-boots