web-dev-qa-db-fra.com

Mon Ubuntu exécute fsck à chaque démarrage

À chaque démarrage, c'est pareil:

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

Est-ce une sorte d’option utilisée par Ubuntu pour assurer la cohérence du système de fichiers ou y at-il un problème avec mon disque dur? fsck prend jusqu'à 30 secondes lors du démarrage, ce qui permet de multiplier par trois le temps nécessaire autrement.

Sortie complète (partiellement 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
bootfsck
19
s3lph

/ dev/sda1: clean, fichiers 908443/38690816, 44176803/154733312

La ligne produisant ce message est this :

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

Il passe 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'un véritable contrôle approfondi, cela prendrait beaucoup plus de temps, mais cela prend généralement une seconde ou moins. La page de manuel Systemd systemd-fsck(8) contient 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 initramfs. systemd-fsck @ .service est utilisé pour tous les autres systèmes de fichiers et pour le système de fichiers racine dans initramfs.

Ces services sont démarrés au démarrage si passno dans/etc/fstab du système de fichiers est définie 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 en rotation.

systemd-fsck ne connaît pas de détails 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 réellement être vérifié en fonction du temps écoulé depuis la dernière vérification, du nombre de montages, du démontage non nettoyé, etc.

Vous pouvez simplement vérifier que les tests n’ont pris que très peu de temps à courir (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
25
Braiam

Etes-vous sûr que c'est fsck qui prend 30 secondes et pas seulement que le prochain message de la console concernant udevd prend 30 secondes? En d’autres termes, udevd met peut-être 30 secondes à temporiser son travail sur libticables avant d’afficher un message à la console?

Essayez de retirer (ou de déménager temporairement ailleurs)

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

et voir si cela aide.

1
Joseph Santaniello

Ce fsck sur chaque démarrage m'est arrivé en raison d'une mauvaise horloge. Il semble que systemd-fsck @ s'exécute avant systemd-timesyncd et, sans RTC sauvegardé sur batterie, l'heure système est incorrecte au moment de l'exécution de fsck.

J'ai confirmé que c'est bien ce qui déclenche la vérification complète (au lieu de quitter fsck rapidement), en désactivant systemd-timesynd, en définissant clock sur la valeur de pré-synchronisation trouvée dans journalctl et en exécutant fsck. E2fsck procède ensuite à une vérification complète une fois qu'il a détecté 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'a aucun lien avec les autres déclencheurs du nombre de montages maximum et de l'intervalle de temps depuis la dernière vérification, comme indiqué dans dumpe2fs -h, mentionné dans d'autres réponses ici.

Notez que, sans régler l'horloge (c.-à-d. En laissant timesyncd la synchroniser), fsck n'effectuera pas une vérification complète, mais se terminera rapidement avec un message 'nettoyage du système de fichiers'.

Pour résoudre ce problème, j'ai désactivé fsck dans/etc/fstab en définissant le champ 'pass' sur 0. Éventuellement, j'achèterai une batterie sauvegardée RTC pour cet appareil.

0
alexei