Où les résultats fsck sont-ils enregistrés au démarrage, après / forcefsck?

37

Lorsque je travaille à distance, je configure un serveur pour forcer une commande fsck au démarrage avec la sudo touch /forcefsckcommande, puis redémarré.

Après le redémarrage, j’ai vérifié /var/log/fsckles résultats de la vérification du disque.
Les deux checkfs et checkroot dit: Rien n'a été encore connecté

Alors, où est-il sauver les résultats?

boot logging fsck

— Bart Silverstrim
source

Avoir le même problème sur Ubuntu 12.04 LTS. J'ai trouvé le journal fsck dans /var/log/boot.log.

15

Peut-être êtes-vous affecté par ce bogue: "Ne consigne pas les invocations fsck dans / var / log / fsck /"

— éclaboussure
source

Probablement. Ne devrait plus être surpris que cela ne soit probablement pas réglé ...

— Bart Silverstrim

Cela nous affecte également de manière très négative - nous sommes sur EC2 et lorsque les serveurs redémarrent, nous avons besoin de détails tels que celui-ci. Comment cela peut-il être considéré comme un élément de "liste de souhaits"? C'est la fonctionnalité principale, et c'est cassé.

— Tamale

@tamale Vous avez entièrement raison. J'ai aussi été touché par cela. Ma /partition avait une mauvaise idée et, en entrant en mode de récupération, elle y était forcée e2fsck. C'est parfait, mais comme il est très difficile de se souvenir des fichiers à remplacer à partir d'une sauvegarde, vous devez être en mesure de localiser les noms de fichiers apparemment corrompus.

— syntaxerror

13

Pour Ubuntu 14.xx:

J'ai trouvé des connexions fsck /var/log/upstart/mountall.log.

— Shay
source

1

Bienvenue sur Ask Ubuntu. ;-) Il y avait un bogue dans 11.10 à l'époque, donc votre réponse sur un nouveau système pour le moment n'ajoute aucune valeur à cette question de 3 ans. Pour l'avenir: regardez la date d'une question et s'il y a déjà une réponse. ;-)

— Fabby

4

@Fabby, mais pour les futurs visiteurs, cela pourrait quand même être utile, je pense? La version est donnée (@Shay, tu veux dire 14.04 ou 14.10?) Et donc je dirais que c'est une réponse valable, bien que cela puisse ne pas aider le PO (qui a trouvé une solution il y a 3 ans ...)

— Byte Commander

J'ai ajouté un tag pour aider les moteurs de recherche à montrer cela comme une vieille question.

— NGRhodes

Absolument raison! :-) C'est pourquoi je viens de laisser un commentaire. Pour mémoire: je n'ai pas voté à la baisse! ;-)

— Fabby

1

Commandant @ Byte Cette soi-disant "vieille" question m'a beaucoup aidé! Je n'aurais jamais deviné que les fsckjournaux seraient cachés dans /var/log/upstart/mountall.logresp. /var/log/upstart/mountall.*.log.gz. Assez illogique. CEPENDANT, il semble que les noms de fichiers rapportés comme étant corrompus ne soient pas consignés, mais uniquement leurs inodes.

— syntaxerror

6

Pour les partitions racine Ubuntu 16.04 et 18.04

Vous cherchez probablement /run/initramfs/fsck.log.

Une fsck du système de fichiers racine se produit nécessairement avant que le système de fichiers racine ait été monté en écriture, donc la vérification du système de fichiers a lieu tôt dans le processus de démarrage, alors que le système est toujours en cours d'exécution à partir de initramfs. Un journal fsck est écrit sur un système de fichiers sauvegardé par la RAM (tmpfs) disponible pour écriture à ce moment, et reste disponible après l’amorçage à /run/initramfs/fsck.log. Il s’agit d’un stockage volatile, de sorte que les journaux fsck sont perdus au redémarrage du système. Il serait bien que ces journaux soient copiés dans un stockage non volatile une fois que le système de fichiers racine est monté en écriture, mais cela ne semble pas être le cas.

Voici un exemple:

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

1

Pour les partitions root, cela semble être la seule réponse correcte pour 16.04 + systemd.

— Jonah Braun

5

Pour Ubuntu 16.04

La commande journalctl -b --no-pager | grep systemd-fsck

rapporte les checks.similar du système de fichiers de partition non root à ceci:

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

Pour les vérifications de la partition racine au démarrage, lancez la commande more /var/log/boot.log

Fournit des résultats similaires à ceci:

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

— Elder Geek
source

2

Tester ceci avec Ubuntu 12.04.5 LTS et j'ai trouvé le journal sur /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

— Barbouk
source

0

Pour Ubuntu 18.04

La commande journalctl -b --no-pager | grep systemd-fscketgrep systemd-fsck /var/log/syslog

les deux rapportent le système de fichiers de partition non root checks.similar à ceci:

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

Les vérifications des partitions racine montées par les résultats UUID ne semblent pas être consignées, même si elles sont forcées.

— Elder Geek
source