Le système de fichiers local n'est pas correctement démonté pendant l'arrêt

Question

J'ai un système de fichiers avec deux disques durs et plusieurs partitions montés séparément localement.

/root, /home, /usr, /var, /local/share, /home/bernhard/fotos/bilder, /backup sont sur des partitions séparées et sont tous "ext3".

Pendant le démontage, le message "démontage du système de fichiers local" n'apparaît plus et lors du démarrage de toutes les partitions mais la partition racine doit recharger le journal, ce qui indique un démontage incorrect. La partition racine et/usr sont sur sda, les autres sur sdb ou d'autres périphériques montés sur usb. la seule partition non montée sans problème semble être la partition racine sur sda4.

Je me demande si le script pour démonter tous les périphériques a une boucle "attendre le succès" ou si le script lui-même a été corrompu. Cependant, hier, je suis passé à 11.04 et l'erreur persiste.

pmount ne semble pas approprié car les périphériques ne sont pas branchés à chaud mais simplement montés au démarrage du système. De toute évidence, monter/usr et ensuite/usr/local/share ainsi que/home et plus tard/home/bernhard/fotos/bilder posent des problèmes pour umount; les appareils peuvent être occupés et donc mal montés.

Quelqu'un a-t-il une idée d'un script pour organiser le démontage de manière ordonnée? Comment attendre le démontage du support secondaire? Savez-vous également où placer un tel script pour qu'il soit utilisé à la place de la commande umount d'origine?

Cela pourrait être une solution générale.

MvG · Answer

Je n'ai pas de 11.04 ici pour expérimenter, mais il me semble que le script / etc/init.d/umountfs devrait faire le démontage. Vous y trouverez que tous les points de montage réguliers sont passés à umount en une seule invocation. Il est laissé à umount de traiter ceux-ci dans un ordre raisonnable, ce qui, à mon avis, devrait être capable. Il ne semble pas y avoir de boucle "Wait for success" dans ce script. Et même si un appareil n'a pas été démonté avec succès, umount -r devrait monter ces systèmes de fichiers en lecture seule, il ne devrait donc pas être nécessaire de relire le journal.

Afin d'obtenir plus d'informations sur ce problème, vous pouvez souhaiter éditer ce script d'une ou plusieurs des manières suivantes:

Ensemble VERBOSE=yes pour plus de sortie
Placer un sleep 20 au début et à la fin de do_stop, chacun précédé d'un echo approprié. De cette façon, vous verrez quelle sortie provient de ce script et aurez le temps de la lire pendant l'arrêt. Bien sûr, vous devez désactiver votre écran de démarrage afin que vous puissiez réellement voir cette sortie.
Peut-être aussi faire un set -x pour que vous puissiez voir le fonctionnement interne du script Shell, les arguments passés à umount en particulier.
Vous pouvez même faire apparaître un Shell là-dedans, vous pouvez donc expérimenter pendant l'arrêt, par exemple pour identifier les raisons pour lesquelles certains systèmes de fichiers sont occupés et ne peuvent pas être démontés.
Essayez d'ajouter votre propre logique de classement, en utilisant la syntaxe bash normale pour ordonner les arguments à umount ou pour effectuer plusieurs invocations de umount. Je pense que cela ne devrait pas être nécessaire si le script fonctionne comme prévu, et s'il ne fonctionne pas comme prévu, il devrait y avoir une sorte de message d'erreur. Je ne mettrais donc cela en œuvre que s'il n'y a pas d'autre indice quant à ce qui ne va pas.