Comment puis-je éviter les messages «Exécuter fsck manuellement» tout en permettant d'expérimenter avec les changements d'heure système?

18

Je travaille avec un système où nous voulons permettre aux utilisateurs de jouer avec la date et l'heure s'ils le souhaitent, et où les redémarrages peuvent se produire arbitrairement. C'est très bien, sauf pour une chose: s'il y a un grand saut en arrière, l'erreur suivante apparaît au redémarrage:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

… Et puis le démarrage se bloque en attendant l'entrée de la console utilisateur, et même une fois l'accès à la console obtenu, nécessite un mot de passe root pour continuer.

C'est décidément loin d'être idéal. Existe-t-il un moyen d'ignorer la vérification ou de forcer la vérification à se produire automatiquement au redémarrage?

Google n'a fourni une aide qui nécessite l'exécution de fsck manuellement que si / quand cela se produit, ce qui n'est pas ce que je recherche. L'exécution manuelle de fsck après avoir réglé l'heure ne fonctionne pas car le système de fichiers est toujours monté à ce stade, et la désactivation complète de fsck est loin d'être idéale.

J'utilise RedHat 6.

Mise à jour : La solution que j'utilise actuellement consiste à pirater fstab pour désactiver la vérification de fsck au redémarrage. J'avais essayé de modifier la dernière heure de montage sur les disques à l'aide de debugfs, ce qui fonctionne bien pour les disques ext3, mais semble échouer de manière incohérente sur ext4.

boot rhel date fsck moi et
la source

Réponses:

15

J'allais suggérer de pirater e2fsckpour désactiver les vérifications spécifiques pour une dernière heure de montage ou des dernières heures d'écriture à l'avenir. Ceux-ci sont définis dans problem.c / problem.h et utilisés dans super.c . Mais en regardant, j'ai découvert que E2fsprogs 1.41.10 ajoute une nouvelle option à /etc/e2fsck.confappelé broken_system_clock . Cela semble être exactement ce dont vous avez besoin, et puisque vous utilisez Red Hat Enterprise Linux 6, vous devriez avoir 1.41.12, qui inclut cette option. Depuis la page de manuel:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Oui, la page de manuel ne peut pas épeler "heuristique". Oups. Mais le code fonctionne probablement de toute façon. :)

mattdm
la source
Cela a l'air fantastique, sauf que la page de manuel implique qu'elle n'affecte que ext2 et ext3, et j'utilise une combinaison d'ext3 et d'ext4. Je vais quand même l'essayer maintenant, comme si ça marche, c'est exactement ce que je recherche.
me_and
1
Ça marche! Y compris sur ext4. Je vous remercie!
me_and
1

Je doute qu'il existe un moyen de supprimer cette vérification spécifiquement, à moins de modifier le code source. Ignorer toutes les erreurs de fsck semble dangereux, et s'il y avait un autre problème?

Par conséquent, je suggère la solution de contournement suivante: modifiez les scripts de démarrage pour définir la date du système sur une date ultérieure (par exemple 2038-01-18 sur une machine 32 bits) juste avant d'exécuter fsck, et relisez-la à partir du matériel horloge par la suite ( hwclock --hctosys, avec plus d'options selon les besoins en fonction de votre matériel et de l'utilisation de GMT dans l'horloge matérielle.)

Gilles 'SO- arrête d'être méchant'
la source
Cela ne signifierait-il pas que la prochaine fois, il y aurait une fenêtre dans laquelle nous pourrions de nouveau rencontrer le même bug? c'est-à-dire que la dernière heure de montage est 2038-01-18, donc si l'heure actuelle est réglée sur cela aussi, il y a une condition de concurrence dans laquelle nous essayons (en ce qui concerne le système) de monter avant la dernière monture.
me_and
@me_and: Oui, je crains que mon kludge ne soit pas utile contre les utilisateurs malveillants. Si c'est ce à quoi vous êtes confronté, patcher fsck semble être la meilleure option.
Gilles 'SO- arrête d'être méchant'
0

Cela semble devoir être exécuté sur une machine virtuelle, où vous pouvez avoir plus de contrôle (ou simplement revenir à un instantané).

jamespo
la source
L'exécution dans une machine virtuelle n'est vraiment pas une option pour nous, et dans tous les cas, le simple fait de revenir à un instantané signifie que nous supprimons tout autre état que l'utilisateur peut avoir configuré.
me_and
0

Voici une solution qui a très bien fonctionné pour moi:

Créez /etc/e2fsck.conf:

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

Plus d'informations sur ce correctif ici:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

GoinOff
la source