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

Hoje, quando liguei meu PC pela primeira vez, o processo de inicialização parou no logotipo do Ubuntu, quando eu pressionei Esc, vi várias linhas contendo algum erro do kernel e reinicialização necessárias na parte inferior, então pressionei Ctrl+ ALt+ Dele a próxima inicialização deu certo sem problemas.

Tenho problemas para encontrar mensagens na tela que vi durante a primeira inicialização sem êxito. Eu deveria ter tirado uma foto no meu telefone?

/var/log/bootestá lá, mas vazio, procurei no kern.log e no syslog as strings que lembrei da data de hoje, errormas não encontrei nada familiar ao que vi na tela de inicialização anterior.

$ journalctl -b -1 me fornece apenas mensagens do kernel durante a inicialização, também posso encontrá-las em outros lugares, e elas não são o que apareciam na tela durante a inicialização, o journalctl é inútil para mim, estou procurando mensagens aparecendo na tela durante o tempo de inicialização.

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

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

Há um relatório de bug arquivado neste tópico . Como rsyslogjá mantém vários diários de inicialização /var/log/sysloge syslog.1, ... .2.gz, os desenvolvedores achavam que manter logs extras desperdiçaria espaço em disco..3.gzsyslog.7.gzjournalctl

O relatório de erros afirma em 3 de janeiro de 2018 que para novas instalações rsyslognão será mais o padrão e journalctlmanterá vários logs de dados de inicialização.

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

A maioria de nós não fará uma nova instalação, portanto, para ativar vários journalctllogs de inicialização, 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 ignorada.

Configuração opcional de armazenamento persistente

Depois de usar o log de inicialização anterior por muitos meses, descobri outra opção que pode ser definida em /etc/systemd/journald.conf:

Na página do manual journald.conf :

Armazenamento =

Controla onde armazenar os dados do diário. Um de "volátil", "persistente", "automático" e "nenhum". Se "volátil", os dados do log do diário serão armazenados apenas na memória, ou seja, abaixo da hierarquia / run / log / journal (criada se necessário). Se "persistente", os dados serão armazenados preferencialmente no disco, ou seja, abaixo da /var/log/journalhierarquia (criada se necessário), com um fallback para /run/log/journal(criado se necessário), durante a inicialização antecipada e se o disco não for gravável. "auto" é semelhante a "persistente", mas o diretório /var/log/journal não é criado, se necessário, de modo que sua existência controla onde os dados do log vão. "none" desativa todo o armazenamento, todos os dados de log recebidos serão descartados. Encaminhando para outros destinos, como o console, o buffer de log do kernel ou um soquete do syslog ainda funcionará. O padrão é "auto".

Em poucas palavras, 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-1que é diferente de outras referências que você pode ver. Na página do manual :

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

Mostrar mensagens de uma inicialização específica. Isso adicionará uma correspondência para "_BOOT_ID =".

O argumento pode estar vazio; nesse caso, os logs da inicialização atual serão mostrados.

Se o ID de inicialização for omitido, um deslocamento positivo procurará as botas a partir do início do diário e um deslocamento igual ou menor que zero procurará as botas a partir do final do diário. Assim, 1 significa a primeira bota encontrada no diário em ordem cronológica, 2 a segunda e assim por diante; enquanto -0 é a última inicialização, -1 a inicialização antes da última e assim por diante. Um deslocamento vazio é equivalente a especificar -0, exceto quando a inicialização atual não é a última (por exemplo, porque --directory foi especificado para examinar logs de uma máquina diferente).

De vez em quando, com cronou temporizadores, você pode limpar logs antigos :

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

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

Eu tive o mesmo problema e, aparentemente, encontrei a resposta no #ubuntucanal irc.

Por alguma razão, estava faltando o /var/log/journal grupo de pastas acessível ao systemd-journal.

Depois de adicionar a pasta, pude ver os logs das botas anteriores via $ journalctl -b1

As etapas para realizar a solução da resposta superior aqui, na página de manual do systemd-journald:

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

Eu fiz isso como su

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

Controla onde armazenar os dados do diário. Um de "volátil", "persistente", "automático" e "nenhum". [...] "auto" é semelhante a "persistente", mas o diretório / var / log / journal não é criado, se necessário, de modo que sua existência controla aonde os dados do registro vão. [...] O padrão é "auto".

Lembre-se de que não há necessidade de rotação de logs ou técnicas semelhantes que eram comuns com o antigo daemon syslog. Por padrão, o arquivo de diário está configurado para crescer até um determinado tamanho e as entradas de log antigas são excluídas automaticamente quando o arquivo de diário cresce muito.

No meu sistema, esse tamanho está atualmente configurado como 120 MB. Você pode ajustá-lo /etc/systemd/journald.confpara a unidade systemd-journald.service.

Use journalctl -bXonde x é a inicialização a que você se refere, assim -b0como a inicialização real e -b-1a inicialização anterior (o que só funciona se você tiver a pasta /var/log/journalpertencente ao grupo 'systemd-journal' presente). Não posso te dizer até onde exatamente você pode ir, mas esses dois com certeza.

Listar as botas disponíveis com

journalctl --list-boots