Mi pregunta es, ¿cómo puedo encontrar el registro de arranque del intento de arranque del sistema anterior?

Hoy, cuando encendí mi PC por primera vez, el proceso de inicio se detuvo en el logotipo de Ubuntu, cuando presioné Esc, vi varias líneas que contenían algunos errores del kernel y se requería reiniciar en la parte inferior, así que presioné Ctrl+ ALt+ Dely el siguiente inicio salió bien sin problemas.

Tengo problemas para encontrar mensajes de la pantalla que he visto durante el primer arranque fallido. ¿Debería haber tomado una foto a mi teléfono?

/var/log/bootestá allí pero vacío, busqué en kern.log y syslog las cadenas que recordaba con la fecha de hoy, errorpero no encontré nada familiar a lo que he visto en la pantalla de arranque anterior.

$ journalctl -b -1 solo me da mensajes del kernel durante el arranque, también puedo encontrarlo en otro lugar, y no son lo que aparecía en la pantalla durante el arranque, journalctl es inútil para mí, estoy buscando mensajes que aparecen en la pantalla durante el tiempo de arranque.

Por ahora, la única opción es tomar una foto de escribir el mensaje en papel.

Reportado como un error que es una característica no documentada

Hay un informe de error presentado sobre este tema . Debido a que rsyslogya se mantiene múltiples revistas de arranque en /var/log/syslogy syslog.1, .2.gz, .3.gz... syslog.7.gzlos desarrolladores sintieron manteniendo adicionales journalctlregistros sería una pérdida de espacio en disco.

El informe de errores indica el 3 de enero de 2018 que las nuevas instalaciones rsyslogya no serán las predeterminadas y que journalctlmantendrán múltiples registros de datos de arranque.

Cree múltiples registros de arranque sin reinstalar Ubuntu

La mayoría de nosotros no haremos una nueva instalación para habilitar múltiples journalctlregistros de arranque, en cuyo 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 acuerdo con este informe de Github, se puede ignorar el mensaje de advertencia "No se puede establecer el atributo de archivo" .

Configuración opcional de almacenamiento persistente

Después de usar el registro de arranque anterior durante muchos meses, descubrí otra opción que se puede configurar en /etc/systemd/journald.conf:

Desde la página del manual journald.conf :

Almacenamiento =

Controla dónde almacenar los datos del diario. Uno de "volátil", "persistente", "automático" y "ninguno". Si es "volátil", los datos del registro del diario se almacenarán solo en la memoria, es decir, debajo de la jerarquía / run / log / journal (que se crea si es necesario). Si es "persistente", los datos se almacenarán preferiblemente en el disco, es decir, por debajo de la /var/log/journaljerarquía (que se crea si es necesario), con un respaldo de /run/log/journal(que se crea si es necesario), durante el inicio temprano y si el disco no se puede escribir. "auto" es similar a "persistente" pero el directorio /var/log/journal no se crea si es necesario, de modo que su existencia controla dónde van los datos de registro. "ninguno" apaga todo el almacenamiento, todos los datos de registro recibidos se descartarán. Reenvío a otros objetivos, como la consola, sin embargo, el búfer de registro del kernel o un socket de syslog seguirán funcionando. El valor predeterminado es "auto".

En pocas palabras, elimine el comentario y revise la línea para:

Storage=persistent

Mostrar lista de botas 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

Mostrar el último registro de arranque

$ 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 mucha atención al parámetro -b-1, es diferente de otras referencias que pueda ver. Desde la página del manual :

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

Mostrar mensajes de un arranque específico. Esto agregará una coincidencia para "_BOOT_ID =".

El argumento puede estar vacío, en cuyo caso se mostrarán los registros del arranque actual.

Si se omite la ID de arranque, un desplazamiento positivo buscará las botas comenzando desde el comienzo del diario, y un desplazamiento igual o menor que cero buscará botas comenzando desde el final del diario. Así, 1 significa el primer arranque encontrado en el diario en orden cronológico, 2 el segundo y así sucesivamente; mientras que -0 es el último arranque, -1 el arranque antes del último, y así sucesivamente. Un desplazamiento vacío es equivalente a especificar -0, excepto cuando el arranque actual no es el último arranque (por ejemplo, porque se especificó --directory para ver los registros de una máquina diferente).

Luego, de vez en cuando, con crono temporizadores , puede limpiar registros antiguos :

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

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

Tuve el mismo problema, y ​​aparentemente encontré la respuesta en el #ubuntucanal IRC.

Por cualquier motivo, me faltaba la carpeta /var/log/journal accesible al grupo para systemd-journal.

Después de agregar la carpeta, pude ver registros de botas anteriores a través de $ journalctl -b1

Los pasos para lograr la solución desde la respuesta principal aquí, desde la página del manual para systemd-journald:

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

Hice esto como su

La respuesta se puede encontrar en man journald.conf, específicamente la opción Storage=:

Controla dónde almacenar los datos del diario. Uno de "volátil", "persistente", "automático" y "ninguno". [...] "auto" es similar a "persistente" pero el directorio / var / log / journal no se crea si es necesario, de modo que su existencia controla dónde van los datos de registro. [...] El valor predeterminado es "auto".

Tenga en cuenta que no hay necesidad de rotación de registros o técnicas similares que eran comunes con el antiguo demonio syslog. El archivo de diario está configurado de forma predeterminada para crecer hasta un cierto tamaño y las entradas de registro antiguas se eliminan automáticamente cuando el archivo de diario crece demasiado.

En mi sistema, este tamaño está configurado actualmente como 120 MB, puede ajustarlo /etc/systemd/journald.confpara la unidad systemd-journald.service.

Use journalctl -bXdonde x es el arranque al que se refiere, así -b0es su arranque real y -b-1el arranque anterior (que solo funciona si tiene la carpeta que /var/log/journalpertenece al grupo 'systemd-journal' presente). No puedo decirte hasta dónde puedes llegar exactamente, pero esos dos están seguros.

Lista de botas disponibles con

journalctl --list-boots