Mon Ubuntu exécute fsck à chaque démarrage

À chaque démarrage, c'est la même chose:

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

Est-ce une sorte d'option qu'Ubuntu utilise pour assurer la cohérence du système de fichiers ou y a-t-il un problème avec mon disque dur? fsckprend jusqu'à 30s lors du démarrage et ainsi tripler le temps nécessaire autrement.

Sortie complète (en partie en allemand):

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

/ dev / sda1: propre, fichiers 908443/38690816, blocs 44176803/154733312

La ligne qui produit ce message est la suivante :

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

Il saute la "vérification complète" mais s'assure simplement que certains tests rapides du journal sont propres et qu'il n'y a pas d'inodes orphelins:

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

Ceci est normal et attendu. S'il s'agissait d'une véritable vérification approfondie, cela prendrait beaucoup plus de temps, mais cela prend généralement une seconde ou moins. La systemd-fsck(8)page de manuel de Systemd présente les conditions dans lesquelles une vérification complète est déclenchée:

systemd-fsck-root.service est responsable des vérifications du système de fichiers sur le système de fichiers racine, mais uniquement si le système de fichiers racine n'a pas été vérifié dans les initramfs. systemd-fsck @ .service est utilisé pour tous les autres systèmes de fichiers et pour le système de fichiers racine dans les initramfs.

Ces services sont démarrés au démarrage si passno dans / etc / fstab pour le système de fichiers est défini sur une valeur supérieure à zéro. La vérification du système de fichiers pour la racine est effectuée avant les autres systèmes de fichiers. D'autres systèmes de fichiers peuvent être vérifiés en parallèle, sauf lorsqu'ils se trouvent sur le même disque rotatif.

systemd-fsck ne connaît aucun détail sur des systèmes de fichiers spécifiques et exécute simplement des vérificateurs de système de fichiers spécifiques à chaque type de système de fichiers (/sbin/fsck.*). Cet assistant décidera si le système de fichiers doit être vérifié en fonction du temps écoulé depuis la dernière vérification, du nombre de montages, du démontage impur, etc.

Vous pouvez simplement vérifier que les tests n'ont pris presque rien à exécuter (si vous utilisez systemd):

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

Êtes-vous sûr que c'est fsck qui prend 30s et pas seulement que le prochain message de la console concernant udevd prend 30 secondes? En d'autres termes, peut-être que l'udevd prend 30 secondes pour expirer avant de travailler sur la chose libticables avant d'afficher un message sur la console?

Essayez de supprimer (ou de déplacer un autre endroit temporairement)

/lib/udev/rules.d/45-libticables.rules

et voyez si cela aide.

Ce fsck à chaque démarrage m'est arrivé à cause d'une mauvaise horloge. Il semble que systemd-fsck @ s'exécute avant systemd-timesyncd, et sans RTC sauvegardé par batterie, l'heure système est incorrecte au moment où fsck est exécuté.

J'ai confirmé que c'est bien ce qui déclenche la vérification complète (au lieu de quitter rapidement fsck), en désactivant systemd-timesynd, en réglant l'horloge sur la valeur de pré-synchronisation trouvée dans journalctl et en exécutant fsck. L'e2fsck procède ensuite à une vérification complète, une fois qu'il détecte que le dernier temps d'écriture du superbloc est dans le futur:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

Notez que ce déclencheur pour la vérification complète n'est pas lié aux autres déclencheurs du nombre maximal de montages et de l'intervalle de temps depuis la dernière vérification, vue dans dumpe2fs -h, mentionnés dans d'autres réponses ici.

Notez que, sans régler l'horloge (c'est-à-dire en laissant timesyncd la synchroniser), fsck ne fera pas une vérification complète, mais se fermera rapidement avec un message de «nettoyage du système de fichiers».

Pour contourner ce problème, j'ai désactivé fsck dans / etc / fstab en définissant le champ «pass» sur 0. Finalement, je vais acheter un RTC avec batterie pour cet appareil.

Mes recherches me permettent de conclure que le nombre de montages maximum par défaut d'Ubuntu est défini sur -1. Cela signifie que fsck ne fonctionnera jamais sur n'importe quel démarrage quel que soit le nombre de montages. Vous pouvez vérifier le vôtre par commande -

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

Vous pouvez l'augmenter selon vos besoins en utilisant tune2fs. Un exemple typique est le suivant -

sudo tune2fs -c 30 -i 1w /dev/sda8

Personnalisez-le à votre guise.