Como encontrar o log de inicialização anterior após o Ubuntu 16.04+ ser reiniciado?

Question

Minha pergunta é: como posso encontrar o log de inicialização da tentativa anterior de inicialização do sistema?

Hoje, ao ligar meu PC, o processo de inicialização parou no logotipo do Ubuntu, quando pressionei Esc Eu vi várias linhas contendo algum erro do kernel e reiniciei na parte inferior, então pressionei Ctrl + ALt + Del e a próxima inicialização foi OK sem problemas.

Eu tenho dificuldade em encontrar mensagens na tela que vi durante a primeira inicialização malsucedida. Devo ter tirado uma foto para o meu celular?

/var/log/boot está lá, mas vazio, eu procurei kern.log e syslog para strings que eu lembrei com a data de hoje como error mas não encontrei nada familiar ao que eu vi na tela de inicialização anterior.

$ journalctl -b -1 me dá apenas mensagens do kernel durante a inicialização, eu posso encontrar isso em outro lugar também, e eles não são o que estava aparecendo na tela durante a inicialização, journalctl é inútil para mim, estou procurando mensagens que aparecem na tela durante o boot .

Por enquanto, a única opção é tirar uma foto de escrever a mensagem no papel.

    

Answer 1

Relatado como um bug que é um recurso não documentado

Há um relatório de bug arquivado neste tópico . Como rsyslog já mantém vários diários de inicialização em /var/log/syslog e syslog.1 , .2.gz , .3.gz ... syslog.7.gz , os desenvolvedores sentiram que manter% extra dejournalctl logs desperdiçaria espaço em disco.

O relatório de erros afirma em 3 de janeiro de 2018 que para novas instalações rsyslog não será mais o padrão e que journalctl manterá vários registros de dados de inicialização.

Crie vários registros de inicialização sem reinstalar o Ubuntu

A maioria de nós não fará uma nova instalação, para habilitar vários registros de inicialização de journalctl . Nesse caso, podemos usar:

$ 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

De acordo com este relatório do github , a mensagem de aviso "Não é possível definir o atributo do arquivo" pode ser ignorado.

Configuração de armazenamento persistente opcional

Após usar o registro de inicialização anterior por muitos meses, eu descobri outra opção pode ser definido em /etc/systemd/journald.conf :

Na página de manual do journald.conf :

Storage=

Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".

Resumindo, remova o comentário e revise a linha para:

Storage=persistent

Exibir lista de inicializações anteriores

$ 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

Exibir o último log de inicialização

$ 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

Preste muita atenção ao parâmetro -b-1 , é diferente de outras referências que você possa ver. Na página de manual :

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

Show messages from a specific boot. This will add a match for "_BOOT_ID=".

The argument may be empty, in which case logs for the current boot will be shown.

If the boot ID is omitted, a positive offset will look up the boots starting from the beginning of the journal, and an equal-or-less-than zero offset will look up boots starting from the end of the journal. Thus, 1 means the first boot found in the journal in chronological order, 2 the second and so on; while -0 is the last boot, -1 the boot before last, and so on. An empty offset is equivalent to specifying -0, except when the current boot is not the last boot (e.g. because --directory was specified to look at logs from a different machine).

Então, de vez em quando, com cron ou temporizadores você pode limpar registros antigos :

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

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

    

Answer 2

Eu tive o mesmo problema e, aparentemente, encontrei a resposta no #ubuntu irc-channel.

Por qualquer razão, estava faltando a pasta /var/log/journal group-accessible para systemd-journal.

Depois de adicionar a pasta, consegui ver os registros das inicializações anteriores por meio de $ journalctl -b1

    

Answer 3

A resposta pode ser encontrada em man journald.conf , especificamente a opção Storage= :

Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".

Tenha em mente que não há necessidade de rotação de logs ou técnicas similares que eram comuns com o antigo daemon syslog. Por padrão, o arquivo de diário é configurado para aumentar até um determinado tamanho e as entradas de log antigas são excluídas automaticamente quando o arquivo de diário fica muito grande.

No meu sistema, este tamanho está atualmente configurado como 120MB, você pode ajustá-lo em /etc/systemd/journald.conf para a unidade systemd-journald.service.

    

Answer 4

Use journalctl -bX em que x é a inicialização a que você se refere, portanto -b0 é sua inicialização real e -b-1 a inicialização anterior (que só funciona se você tiver a pasta /var/log/journal pertencente ao grupo 'systemd-journal 'presente). Não posso dizer o quão exatamente você pode ir, mas os dois com certeza.

Lista de botas disponíveis com

journalctl --list-boots

    

Answer 5

As etapas para realizar a solução a partir da resposta principal aqui, da página man do systemd-journald:

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

Eu fiz isso como su