Noté que mi /var/log/boot.log
archivo tiene fecha 2016-04-22, la última vez que arranqué en 15.10. ¿Dónde se encuentran los boot.log
archivos Xenial ?
Noté que mi /var/log/boot.log
archivo tiene fecha 2016-04-22, la última vez que arranqué en 15.10. ¿Dónde se encuentran los boot.log
archivos Xenial ?
Respuestas:
journalctl
Como journald
contiene todos los registros, puede usar el journalctl
comando con los filtros adecuados. En el caso de boot.log
, que solía contener mensajes del sistema init, podría hacer:
journalctl -b0 SYSLOG_PID=1
-b0
muestra mensajes del arranque actual, -b1
del arranque anterior, etc. Sin la -b
opción, journalctl
mostrará mensajes desde el principio del registro.SYSLOG_PID
filtra los mensajes del PID 1, también conocido como init.O:
journalctl -b0 --system _COMM=systemd
_COMM=systemd
busca mensajes del systemd
comando. Como systemd
es init, este es el que nos interesa.--system
filtra los mensajes del registro del sistema en lugar de los registros de sesión del usuario.Ejemplo:
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
journalctl
abre los registros en un buscapersonas de forma predeterminada, por lo que no necesita canalizar less
.
Ubuntu, por defecto, no habilita registros de diario persistentes. Gracias al comentario de @Auspex , debe hacer cualquiera de:
Editar /etc/systemd/journald.conf
para incluir:
Storage=persistent
Crea un /var/log/journal
directorio manualmente:
mkdir /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
Relacionado:
journalctl -bX
es inútil para esto, la identificación no contiene mensajes que realmente aparecen en la pantalla durante el arranque, solo boot.log lo hace y solo funciona a veces en 16.04, la única forma es tomar una foto o escribirla. Tengo el mismo problema.
Estaba revisando algunos informes de errores y noté en este: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 que Plymouth realmente está escribiendo en boot.log.
Si mira https://launchpadlibrarian.net/257898272/plymouth-debug.log y busca en su navegador 'boot.log' obtendrá las siguientes líneas:
[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'
No entiendo cómo funcionan las partes internas de Plymouth, pero como es responsable de la pantalla de inicio que aparece antes de la pantalla de inicio de sesión, solo puedo suponer que si no hay pantalla de inicio (pantalla negra) antes de llegar a la pantalla de inicio de sesión , el archivo no se modifica. Si tiene una pantalla de inicio que se muestra antes de la pantalla de inicio de sesión, la salida del proceso de arranque se redirige al archivo boot.log.
GRUB_CMDLINE_LINUX_DEFAULT=""
en /etc/default/grub
que boot.log
no está escrito. Al usar GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
que boot.log
se escribe de nuevo. Yo uso Ubuntu 19.04.
En Ubuntu 16.04, el boot.log
archivo todavía se encuentra en la /var/log
carpeta como puede ver aquí . El archivo de registro de arranque es de hoy (29/04/2016). Tal vez algo salió mal cuando instaló Ubuntu 16.04 o actualizó el sistema operativo de Ubuntu 15.10 a Ubuntu 16.04 LTS.
Alternativamente, puede examinar el comportamiento de arranque general desde el kern.log
archivo completo . Otra alternativa posible sería configurar manualmente el demonio syslog para generar el archivo de registro de arranque y aquí hay un tutorial sobre cómo hacer esto exactamente: Cómo ver y configurar registros de Linux
Información Adicional :
Investigué el comportamiento de inicio de sesión en dos máquinas diferentes. En una computadora con un BIOS basado en UEFI, el boot.log
archivo existe, pero en una computadora con BIOS basado en legado parece que no existe en absoluto. Entonces, en caso de que el sistema esté instalado en el modo BIOS heredado (MBR / msdos), esta podría ser la explicación de por qué su boot.log
archivo está fechado del 22/04/2016, es un sobrante de Ubuntu 15.10.
Información actualizada 2016-05-02:
Seguí investigando el comportamiento del archivo de registro de arranque y observé que el boot.log
archivo todavía existe en la máquina basada en UEFI, pero desde hace unos días el archivo está vacío. Otra alternativa que intenté ver qué sucede durante el proceso de arranque fue instalar BootChart , pero bootchart.png
no existía en la /var/log
carpeta como se esperaba después de reiniciar el sistema ... solo había una /var/log/bootchart
carpeta vacía que tampoco contenía el bootchart.png
archivo esperado .
Información actualizada 2016-05-04:
Hoy el boot.log
archivo parece tener "funcionalidad" nuevamente, está lleno de información parcial del proceso de arranque. Parece ser un comportamiento que cambia al azar, que creo que no se puede resolver aquí en Ask Ubuntu, por lo que debe considerar presentar un informe de error en Launchpad para resolverlo.
Conclusión : después de una semana de investigación sobre el boot.log
comportamiento del archivo en Ubuntu 16.04: no debería preocuparse por /var/log/boot.log
más tiempo y simplemente acostumbrarse journalctl
.
boot.log
archivo no está en su ubicación habitual.
systemd-analyze blame
y / osystemd-analyze critical-chain
. Lo encuentro más fácil que cavar a través de archivos de registro para encontrar lo que está causando un problema.