¿Dónde se registran los resultados de fsck en el momento del arranque, después de / forcefsck?

37

Al trabajar de forma remota, configuré un servidor para forzar un fsck en el momento del arranque con el sudo touch /forcefsckcomando y lo reinicié.

Después de que se reinició, verifiqué /var/log/fscklos resultados de la comprobación del disco.
Ambos checkfs y checkroot dijeron: Nada se ha registrado todavía

Entonces, ¿dónde está guardando los resultados?

boot logging fsck

— Bart Silverstrim
fuente

Tener el mismo problema en Ubuntu 12.04 LTS. Encontré el registro fsck en /var/log/boot.log.

15

Posiblemente se vea afectado por este error: "No registra invocaciones fsck en / var / log / fsck /"

— chapoteo
fuente

Más probable. Ya no debería sorprendernos que probablemente no se va a abordar ...

— Bart Silverstrim

Esto también nos afecta de manera muy negativa: estamos en EC2 y cuando los servidores se reinician, necesitamos detalles de cosas como esta. ¿Cómo se puede considerar esto como un elemento de 'lista de deseos'? Esta es la funcionalidad principal, y está rota.

— Tamal

@tamale Tienes toda la razón. También me golpeó esto. Mi /partición tenía una peculiaridad desagradable, y al entrar en modo de recuperación, la forzó e2fsck. Esto es perfecto, pero como es realmente difícil recordar qué archivos reemplazar de la copia de seguridad, uno debe ser capaz de rastrear los nombres de los archivos supuestamente corruptos.

— sintaxis

13

Para Ubuntu 14.xx:

Encontré algunos registros de fsck /var/log/upstart/mountall.log.

— Shay
fuente

1

Bienvenido a Ask Ubuntu. ;-) Solía haber un error en 11.10 en ese momento, por lo que su respuesta en un nuevo sistema en este momento no agrega ningún valor a esta pregunta de 3 años. Para el futuro: mire la fecha de una pregunta y si ya hay una respuesta. ;-)

— Fabby

44

@Fabby pero creo que para los futuros visitantes aún podría ser útil. Se da la versión (@Shay, ¿quieres decir 14.04 o 14.10?) Y, por lo tanto, diría que es una respuesta válida, aunque podría no ayudar al OP (que encontró una solución hace 3 años ...)

— Byte Commander

Agregué una etiqueta para ayudar a los motores de búsqueda a mostrar esto como una vieja pregunta.

— NGRhodes

¡Absolutamente correcto! :-) Por eso acabo de dejar un comentario. Para el registro: ¡no voté en contra! ;-)

— Fabby

1

@Byte Commander ¡Esta supuestamente "vieja" pregunta me ayudó MUCHO! Nunca hubiera adivinado que los fsckregistros estarían escondidos en /var/log/upstart/mountall.logresp. /var/log/upstart/mountall.*.log.gz. Bastante ilógico. SIN EMBARGO, parece que los nombres de archivo reportados como corruptos no fueron registrados, solo sus inodos.

— syntaxerror

6

Para las particiones raíz de Ubuntu 16.04 y 18.04

Es probable que estés buscando /run/initramfs/fsck.log .

Un fsck del sistema de archivos raíz necesariamente ocurre antes de que el sistema de archivos raíz se haya montado como grabable, por lo que la verificación del sistema de archivos ocurre temprano en el proceso de arranque mientras el sistema aún se está ejecutando desde initramfs. Un registro fsck se escribe en un sistema de archivos respaldado por RAM (tmpfs) que está disponible para escritura en este momento, y continúa estando disponible después del arranque en/run/initramfs/fsck.log . Este es un almacenamiento volátil, por lo que los registros fsck se pierden una vez que el sistema se reinicia. Sería bueno si estos registros se copiaran en un almacenamiento no volátil después de que el sistema de archivos raíz esté montado como grabable, pero este no parece ser el caso.

Aquí hay un ejemplo:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0   238G  0 part /

$ cat /run/initramfs/fsck.log 
Log of fsck -C -a -V -t ext4 /dev/sda2 
Fri Nov 30 22:35:21 2018

fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 653295/15597568 files, 6658147/62383360 blocks

Fri Nov 30 22:35:21 2018
----------------

— ven42
fuente

1

Para las particiones raíz, esta parece ser la única respuesta correcta para 16.04 + systemd.

— Jonah Braun

5

Para Ubuntu 16.04

El comando journalctl -b --no-pager | grep systemd-fsck

informa de las comprobaciones del sistema de archivos de partición no raíz. Similar a esto:

Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks

Para verificaciones de partición raíz en el problema de arranque, el comando more /var/log/boot.log

Proporciona resultados similares a este:

/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks

— Elder Geek
fuente

2

Probando esto con Ubuntu 12.04.5 LTS y encontré el registro en /var/log/boot.log

└❯ grep -A 1 fsck /var/log/*
/var/log/boot.log:fsck from util-linux 2.20.1
/var/log/boot.log-/dev/vda1: 209262/2621440 files (0.1% non-contiguous), 3239494/10485504 blocks

— barbuk
fuente

0

Para Ubuntu 18.04

El comando journalctl -b --no-pager | grep systemd-fsckygrep systemd-fsck /var/log/syslog

ambos informan verificaciones del sistema de archivos de partición no raíz. Similar a esto:

Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[615]: Scratch: clean, 19/6520832 files, 555602/26081280 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[609]: /dev/sda1: clean, 47014/89374720 files, 294970235/357492992 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[613]: /dev/sda5: clean, 6707/32727040 files, 7464312/130885120 blocks

Las comprobaciones de las particiones raíz montadas por los resultados de UUID no parecen estar registradas, incluso si son forzadas.

— Elder Geek
fuente