Wo werden fsck-Ergebnisse nach / forcefsck beim Booten protokolliert?

37

Bei der Remote-Arbeit habe ich einen Server so eingestellt, dass beim Booten mit dem sudo touch /forcefsckBefehl ein fsck erzwungen und neu gestartet wird.

Nach dem Neustart habe ich /var/log/fscknach den Ergebnissen der Festplattenprüfung gesucht.
Sowohl checkfs als auch checkroot sagten: Es wurde noch nichts protokolliert

Wo speichert es die Ergebnisse?

boot logging fsck

— Bart Silverstrim
quelle

Dasselbe Problem unter Ubuntu 12.04 LTS. Ich habe das fsck-Protokoll in /var/log/boot.log gefunden.

15

Möglicherweise sind Sie von diesem Fehler betroffen: "Protokolliert keine fsck-Aufrufe in / var / log / fsck /"

— Spritzen
quelle

Höchstwahrscheinlich. Sollte nicht mehr überraschen, dass es wahrscheinlich nicht angesprochen wird ...

— Bart Silverstrim

Dies wirkt sich auch sehr negativ auf uns aus - wir sind auf EC2 und wenn Server neu gestartet werden, benötigen wir Details von Dingen wie diesem. Wie kann dies möglicherweise als ein 'Wunschliste'-Artikel angesehen werden? Dies ist die Kernfunktionalität und sie ist defekt.

— Tamale

@tamale Du hast vollkommen recht. Das hat mich auch getroffen. Meine /Partition hatte eine unangenehme Eigenheit, und als sie in den Wiederherstellungsmodus wechselte, erzwang sie eine e2fsck. Das ist perfekt, aber da es wirklich schwierig ist, sich zu merken, welche Dateien aus der Sicherung ersetzt werden sollen, muss man in der Lage sein, die Dateinamen aufzuspüren, die Berichten zufolge beschädigt sind.

— Syntaxfehler

13

Für Ubuntu 14.xx:

Ich habe einige fsck-Logs gefunden /var/log/upstart/mountall.log.

— Shay
quelle

1

Willkommen bei Ask Ubuntu. ;-) Es gab zu der Zeit einen Bug in 11.10, daher bringt Ihre Antwort auf ein neues System im Moment keinen Mehrwert für diese 3 Jahre alte Frage. Für die Zukunft: Schauen Sie sich das Datum einer Frage an und ob es bereits eine Antwort gibt. ;-)

— Fabby

4

@ Fabby aber für zukünftige besucher könnte es trotzdem nützlich sein, denke ich? Die Version ist angegeben (@Shay meinst du 14.04 oder 14.10?) Und daher würde ich sagen, dass es eine gültige Antwort ist, obwohl es dem OP nicht helfen könnte (der vor 3 Jahren eine Lösung gefunden hat ...)

— Byte Commander

Ich habe ein Tag hinzugefügt, damit Suchmaschinen dies als alte Frage anzeigen können.

— NGRhodes

Absolut richtig! :-) Deshalb habe ich gerade einen Kommentar abgegeben. Fürs Protokoll: Ich habe nicht runtergestimmt! ;-)

— Fabby

1

@Byte Commander Diese vermeintlich "alte" Frage hat mir sehr geholfen! Ich hätte nie gedacht, dass fsckProtokolle in /var/log/upstart/mountall.logbzw. versteckt würden . /var/log/upstart/mountall.*.log.gz. Ziemlich unlogisch. Allerdings scheint es , dass die Dateinamen gemeldet korrupt sein , nicht angemeldet ist , kann nur ihre Inodes.

— Syntaxfehler

6

Für Ubuntu 16.04 und 18.04 Root-Partitionen

Sie suchen wahrscheinlich nach /run/initramfs/fsck.log.

Ein fsck des Root-Dateisystems muss vor dem Mounten des Root-Dateisystems als beschreibbar erfolgen, sodass die Dateisystemprüfung zu einem frühen Zeitpunkt des Startvorgangs erfolgt, während das System noch über initramfs ausgeführt wird. Ein fsck-Protokoll wird in ein RAM-gesichertes Dateisystem (tmpfs) geschrieben, das zu diesem Zeitpunkt zum Schreiben zur Verfügung steht und nach dem Booten unter weiterhin verfügbar ist /run/initramfs/fsck.log. Dies ist ein flüchtiger Speicher, sodass fsck-Protokolle nach dem Neustart des Systems verloren gehen. Es wäre schön, wenn diese Protokolle in einen nichtflüchtigen Speicher kopiert würden, nachdem das Root-Dateisystem als beschreibbar gemountet wurde. Dies scheint jedoch nicht der Fall zu sein.

Hier ist ein Beispiel:

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

1

Für Root-Partitionen scheint dies die einzig richtige Antwort für 16.04 + systemd zu sein.

— Jonah Braun

5

Für Ubuntu 16.04

Der Befehl journalctl -b --no-pager | grep systemd-fsck

meldet Nicht-Root-Partitionsdateisystem checks.ähnlich dazu:

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

Für Root-Partitionsprüfungen beim Booten geben Sie den Befehl aus more /var/log/boot.log

Bietet ähnliche Ergebnisse:

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

— Elder Geek
quelle

2

Testen Sie dies mit Ubuntu 12.04.5 LTS und ich fand das Protokoll auf /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
quelle

0

Für Ubuntu 18.04

Der Befehl journalctl -b --no-pager | grep systemd-fsckundgrep systemd-fsck /var/log/syslog

Beide melden Nicht-Root-Partitionsdateisystemprüfungen.

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

Von UUID-Ergebnissen bereitgestellte Überprüfungen von Root-Partitionen werden nicht protokolliert, selbst wenn sie erzwungen werden.

— Elder Geek
quelle