Comment programmer fsck au boot sous systemd ?

Bonjour,

En mars 2019 j'ai installé (en MBR) sur mon laptop la Manjaro 18 Xfce stable qui en est maintenant à la version 18.0.4 suite aux mises à jour. À l'époque j'avais programmé un fsck hebdomadaire sur la partition root avec sudo tune2fs -i 1w /dev/sda1 comme j'avais l'habitude de le faire avec mes autres distros.
J'ai remarqué que depuis aucun fsck n'a été exécuté depuis l'installation ; sudo tune2fs -l /dev/sda1 me donne :

...
Filesystem created:       Wed Mar  6 23:02:25 2019
Last mount time:          Fri May 24 21:39:19 2019
Last write time:          Fri May 24 21:39:19 2019
Mount count:              448
Maximum mount count:      -1
Last checked:             Wed Mar  6 23:02:50 2019
Check interval:           604800 (1 week)
Next check after:         Wed Mar 13 23:02:50 2019
...

sudo dmesg | grep -i fsck me renvoi :

[    2.742005] EXT4-fs (sda1): warning: checktime reached, running e2fsck is recommended

systemctl status systemd-fsck-root.service m'affiche :

● systemd-fsck-root.service - File System Check on Root Device
   Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; enabled-runtime; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Fri 2019-05-24 21:39:33 CEST; 2h 23min ago
           └─ ConditionPathIsReadWrite=!/ was not met
     Docs: man:systemd-fsck-root.service(8)

mai 24 21:39:30 Toshiba systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
mai 24 21:39:33 Toshiba systemd[1]: Condition check resulted in File System Check on Root Device being skipped.

Avec le fichier /etc/fstab suivant :

...
# <file system>			          <mount point>  <type>  <options>  <dump>  <pass>
UUID=642772fe-64dc-4c8e-9ba7-3672f1454658 /              ext4    defaults,noatime 0 1
UUID=6b2af703-7b8f-4664-b752-196ac372615d swap           swap    defaults,noatime 0 2

Or ça fonctionnait très bien il y a trois ans sur une Archlinux 32 bits (déjà sous systemd) et ça fonctionne encore très bien sur ma vieille Debian...
Pour info, mon fichier /etc/mkinitcpio.conf (auquel je n'ai pas touché) contient les hooks suivants :

...
HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems"

De longues recherches sur le net ne m'ont indiqué que des suggestions obsolètes...
Si quelqu'un pouvait éclairer ma lanterne pour m'aider à rétablir le fonctionnement attendu (une vérification de disque hebdomadaire ou mensuelle), histoire de prévenir plutôt que guérir...), cela serait bienvenu.

Cordialement, et merci par avance.

P.-S. : J'avais posté hier ce message dans un ancien fil de discussion sur le même sujet, mais j'ai l'impression que cela a nuit à sa visibilité.

Salut,

Normalement, /etc/mkinitcpio.conf devrait contenir fsck dans les hooks par défaut.

HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"

Je crois que ça a à voir avec le fait que fsck ne peut s'appliquer que sur une partition non montée et qu'il est plus simple de le faire au boot avant de monter /

J'ai oublié de préciser que j'utilise le kernel LTS recommandé : 4.19.42-1. C'est compatible avec cet ancien noyau ?
Après la modif de mkinitcpio.conf, il faudra faire un : mkinitcpio -p linux ou bien un mkinitcpio -p linux-lts avec mon kernel LTS ?

Bonjour.
C'est une des petite différences Arch/Manjaro:
Sous Manjaro nous avons la possibilité de gérer plusieurs kernels, alors que sous Arch, il n'y a que le noyau courant et le lts en secours.
Donc pour mettre à jour tous les noyaux installés après une modification de mkintcpio.conf, il faut faire # mkintcpio -P. L'option <P> pour tous les noyaux.
Pour n'appliquer la modification que sur un seul noyau ce sera pour exemple avec le 4.19: # mkinitcpio -p linux419

Hourra ! Ça fonctionne.

Au premier redémarrage une rapide vérification de la partition sda1 m'a indiqué que cela faisait 80 jours que fsck était en souffrance, et au redémarrage suivant j'ai juste un petit message m'indiquant que la partition est "clean".
Après test, ni la mise en veille, ni la mise en veille prolongée, ni la mise en veille hybride n'ont été affectées.
Un systemctl status systemd-fsck-root.service m'indique que ce service n'est pas celui qui prends en charge la vérification de sda1 mais bien le hook fsck :

● systemd-fsck-root.service - File System Check on Root Device
   Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; enabled-runtime; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Sun 2019-05-26 03:26:03 CEST; 15min ago
           └─ ConditionPathIsReadWrite=!/ was not met
     Docs: man:systemd-fsck-root.service(8)

mai 26 03:26:03 Toshiba systemd[1]: Condition check resulted in File System Check on Root Device being skipped.

La dernière ligne n'est plus dupliquée comme avant...
Je n'ai plus qu'à marquer le sujet comme résolu.

Merci de vos conseils

Bonjour, un petit retour.
J'avais donc choisi la solution # mkinitcpio -p linux419 pour mettre à jour le hook fsck de mkinitcpio.conf puisque c'était le seul kernel actif chez moi.
Or hier, grosse mise à jour dont notamment celle du noyau 4.19, et pas de problèmes, les hooks n'ont pas été réinitialisés et fsck fonctionne toujours sans qu'aucune intervention ne soit nécessaire.
Je me pose tout de même une question. J'ai trouvé dans mes recherches qu'il était aussi possible (au lieu d'utiliser le hook fsck), de mettre dans les options de démarrage de GRUB l'instruction fsck.mode=auto, plus précisément dans le fichier /etc/default/grub dans la ligne GRUB_CMDLINE_LINUX_DEFAULT. Mais dans ce cas on n'aurait pas la main sur les fréquences de fsck, ce serait systemd qui déciderait de l'opportunité d'un fsck (coupure de courant, reset ou autre).
Me trompé-je ? Ou cela ne concernerait que des kernels plus récents ?

Bonjour.
Lorsqu'on lance mkinitcpio, on recrée une image kernel dans un format de compression basique que peuvent prendre en charge les bootloaders.
Les paramètres se font en fonction de /etc/mkintcpio.conf, donc tous les kernels visés seront impactés, les plus anciens comme les plus récents.
Une mise à jour ne devrait donc pas modifier les hooks définis.

Armag67 a écrit : ↑il y a 4 ans Je me pose tout de même une question. J'ai trouvé dans mes recherches qu'il était aussi possible (au lieu d'utiliser le hook fsck), de mettre dans les options de démarrage de GRUB l'instruction fsck.mode=auto, plus précisément dans le fichier /etc/default/grub dans la ligne GRUB_CMDLINE_LINUX_DEFAULT. Mais dans ce cas on n'aurait pas la main sur les fréquences de fsck, ce serait systemd qui déciderait de l'opportunité d'un fsck (coupure de courant, reset ou autre).

fsck.mode=auto est le mode par défaut qui laisse fsck faire son boulot normalement, contrairement à =force ou =skip. D'après Arch Wiki, le hook fsck évite de déclarer fsck et ses helpers sur la ligne BINARIES= de mkinitcpio.conf.

Adds the fsck binary and file system-specific helpers. If added after the autodetect hook, only the helper specific to your root file system will be added. Usage of this hook is strongly recommended, and it is required with a separate /usr partition.