Dove vengono registrati i risultati di fsck al momento dell'avvio, dopo / forcefsck?

37

Quando lavoro in remoto ho impostato un server per forzare un fsck al momento dell'avvio con il sudo touch /forcefsckcomando e riavviato.

Dopo il riavvio, ho controllato /var/log/fscki risultati del controllo del disco.
Sia i checkf che i checkroot hanno detto: non è stato ancora registrato nulla

Quindi dove sta salvando i risultati?

boot logging fsck

— Bart Silverstrim
fonte

Avere lo stesso problema su Ubuntu 12.04 LTS. Ho trovato il registro fsck in /var/log/boot.log.

15

Forse sei interessato da questo errore: "Non registra le invocazioni di fsck in / var / log / fsck /"

— spruzzo
fonte

Più probabilmente. Non dovresti più essere sorpreso che probabilmente non verrà affrontato ...

— Bart Silverstrim,

Questo ci riguarda anche in un modo molto negativo: siamo su EC2 e quando i server si riavvieranno abbiamo bisogno di dettagli di questo tipo. Come può essere considerato un elemento "wishlist"? Questa è la funzionalità principale ed è rotta.

— tamale,

@tamale Hai perfettamente ragione. Sono stato colpito anche da questo. La mia /partizione ha avuto una brutta stranezza e, quando si accede alla modalità di ripristino, la costringe e2fscka farlo. Questo è perfetto, ma poiché è davvero difficile ricordare quali file sostituire dal backup, si deve essere in grado di rintracciare i nomi dei file corretti.

— syntaxerror,

13

Per Ubuntu 14.xx:

Ho trovato alcuni accessi fsck /var/log/upstart/mountall.log.

— Shay
fonte

1

Benvenuto in Ask Ubuntu. ;-) All'epoca c'era un bug in 11.10, quindi la tua risposta su un nuovo sistema in questo momento non aggiunge alcun valore a questa domanda di 3 anni. Per il futuro: guarda la data di una domanda e se esiste già una risposta. ;-)

— Fabby,

4

@Fabby ma per i futuri visitatori potrebbe essere ancora utile, penso? Viene data la versione (@Shay intendi 14.04 o 14.10?) E quindi direi che è una risposta valida, anche se potrebbe non aiutare l'OP (che ha trovato una soluzione 3 anni fa ...)

— Byte Commander

Ho aggiunto un tag per aiutare i motori di ricerca a mostrarlo come una vecchia domanda.

— NGRhodes,

Assolutamente giusto! :-) Ecco perché ho appena lasciato un commento. Per la cronaca: non ho votato in negativo! ;-)

— Fabby

1

@Byte Commander Questa presunta "vecchia" domanda mi ha aiutato MOLTO davvero! Non avrei mai immaginato che i fsckregistri sarebbero stati nascosti in /var/log/upstart/mountall.logresp. /var/log/upstart/mountall.*.log.gz. Abbastanza illogico. Tuttavia, sembra che i nomi dei file segnalati come corrotti non siano stati registrati, ma solo i loro inode.

— syntaxerror,

6

Per partizioni root Ubuntu 16.04 e 18.04

Probabilmente stai cercando /run/initramfs/fsck.log.

Un fsck del filesystem di root si verifica necessariamente prima che il filesystem di root sia stato montato come scrivibile, quindi il controllo del filesystem si verifica all'inizio del processo di avvio mentre il sistema è ancora in esecuzione da initramfs. Un registro fsck viene scritto in un filesystem supportato dalla RAM (tmpfs) che è disponibile per la scrittura in questo momento e continua ad essere disponibile dopo l'avvio in /run/initramfs/fsck.log. Questa è una memoria volatile, quindi i log di fsck vengono persi al riavvio del sistema. Sarebbe bello se questi log fossero copiati in un archivio non volatile dopo che il filesystem di root è stato montato come scrivibile, ma questo non sembra essere il caso.

Ecco un esempio:

$ 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
fonte

1

Per le partizioni root, questa sembra essere l'unica risposta corretta per 16.04 + systemd.

— Jonah Braun,

5

Per Ubuntu 16.04

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

riporta i controlli del file system della partizione non root. simili a questo:

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

Per i controlli della partizione di root all'avvio, immettere il comando more /var/log/boot.log

Fornisce risultati simili a questo:

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

— Anziano Geek
fonte

2

Provando questo con Ubuntu 12.04.5 LTS e ho trovato il registro su /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
fonte

0

Per Ubuntu 18.04

Il comando journalctl -b --no-pager | grep systemd-fsckegrep systemd-fsck /var/log/syslog

entrambi riportano i controlli del file system della partizione non root.

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

I controlli delle partizioni root montate dai risultati UUID non sembrano essere registrati anche se forzati.

— Anziano Geek
fonte