Démarrage bloqué à la vérification du journal

Support Debian
#1

Bonjour,

Sur un application industrielle (sous entendu : qui est régulièrement éteinte sauvagement) composé d’une application Java sur un debian 7, j’ai eu un problème au démarrage.
Grub s’est lancé correctement, mais j’arrive sur un message qui me dit que le journal de mon disque (en EXT4) est corrompu, et j’ai uniquement accès un busybox plutôt réduit.

J’ai réussi à corriger le problème en faisant un checkdisk avec un liveCD, et la machine est reparti.

Ceci dit, mon problème est que je voudrais que ce problème ne réapparaissent jamais, et donc à faire un checkdisk (que si nécessaire si possible) au démarrage du PC, AVANT que l’OS ne soit charger.

Est ce possible ? Comment fiabiliser mon application ?

#2

Il te suffit de faire un fichier vide "/forcefsck"
Donc en root :
# touch /forcefsck

Au prochain boot tu verras le fsck automatique !

#3

C’est sûr qu’à force de jouer à ce jeux là, on finit fatalement par perdre.

Pourquoi chercher à réparer plutôt qu’anticiper et empêcher que l’erreur de manipulation se produise ?

Est-il bien indispensable d’éteindre le système ?

#4

Je me permet de demander si cela fonctionnera même en cas d’erreur avant que le disque ne soit chargé. Pour moi, les actions du root ne sont exécuté que lorsque que l’OS à accès à la partition / , et le forcefsck ne serait alors pas visible de l’OS. Tu vois ce que je veux dire ? (j’avais une photo de l’écran quand ça merde, mais je retrouve pas…)

#5

Si ton système plante avant d’avoir accès à ‘/’ alors ce n’est pas Linux qui plante :slight_smile:
En gros ça me semble difficile d’avoir une erreur avant que le système ne la détecte …

#6

Malheureusement je n’ai pas la main la dessus. C’est un système de monitoring sur une armoire électrique, c’est comme si tu devais éteindre ton autoradio manuellement avant de couper le contact de ta voiture.
Pour éviter les dommages physiques sur le disque, on utilise un SSD. Jusque là, je dirais qu’on a eu entre quelques centaines et un milliers de démarrage sans problème mais… y a une fois où ça a planté.[quote=“debianhadic, post:5, topic:70311”]
Si ton système plante avant d’avoir accès à ‘/’ alors ce n’est pas Linux qui plante :slight_smile:En gros ça me semble difficile d’avoir une erreur avant que le système ne la détecte …
[/quote]
Je ne dis pas que c’est Linux qui plante, la source de mon problème, c’est clairement l’extinction brutal. J’avais cru comprendre que l’EXT4 était fait pour palier ce genre de problème, mais il me reste un cas qui empêche le démarrage. Et je suis bien d’accord que résoudre un problème quand on a pas encore les outils chargés en mémoire, c’est compliqué =)
J’avais regardé du côté de Grub, mais sans succès.

#7

Marchera pas puisque c’est le montage de la racine par l’initramfs qui échoue.

L’initramfs de Debian 7/Wheezy ne contient pas fsck*. On peut forcer son inclusion et ajouter ou modifier un script pour vérifier la racine avant le montage.

L’initramfs de Debian 8/Jessie (actuelle stable) contient et utilise fsck pour vérifier la racine avant de la monter.

La journalisation se base sur des hypothèses, notamment que les données envoyées au disque sont physiquement écrites dans l’ordre, ce qui n’est pas forcément le cas avec les disques actuels qui ont beaucoup de mémoire cache et la fonction NCQ activé, et notamment avec les SSD qui ont des algorithmes d’optimisation de l’écriture élaborés.

ext4 a peut-être des options de montage susceptibles d’améliorer sa tolérance à un arrêt brutal. Cf. la page de manuel de mount. Il y a aussi une option pour ne pas rejouer le journal au montage, mais c’est à ses risques et périls pour la cohérence du système de fichiers.

Edit : il y a aussi des mesures préventives comme limiter au maximum les écritures sur la racine, en mettant tout ce qui est fréquemment écrit (/var/, /home, /tmp…) sur des systèmes de fichiers séparés.

#8

salut
il existe apparement un parametre
’fsck.mode=force a passer au kernel dans grub

GRUB_CMDLINE_LINUX="fsck.mode=force"
https://wiki.archlinux.org/index.php/Fsck

#9

Je ne vois pas de fsck dans ma sequence de boot. Cela dit, c’est le même comportement avec [quote=“PascalHambourg, post:7, topic:70311”]
un fichier vide “/forcefsck”
[/quote]
Je vais fouiller du côté de l’inclusion de fsck dans l’initramfs . A ce sujet, comment je peux forcer le système à s’arrêter la au moment du boot ?

#10

le fichier /forcefsck c’est un one-shot, dans grub c’est a chaque demarrage
https://wiki.archlinux.org/index.php/Fsck

#11

Il doit être possible de transformer la rupture d’alimentation par un signal d’arrêt pour le système,
(ça c’est pas difficile à faire)

et de prévoir une réserve d’énergie suffisante pour permettre au système d’exécuter sa procédure d’arrêt correctement.

Il faudrait un peu plus d’information sur le matériel sur lequel “tourne” ce système de monitoring.

#12

Avec une option break= passée dans la ligne de commande du noyau par GRUB. Voir la page de manuel de initramfs-tools pour les valeurs possibles.
Mais pourquoi faire ? En cas d’échec du montage de la racine, l’initramfs s’arrête tout seul.

#13

Ne serait ce que pour tester un import de fsck sans attendre une défaillance du journal ^^

#14

Alors break tout seul devrait le faire.

fsck seul ne suffit pas car ce n’est qu’un frontal pour les programmes fsck. spécifiques à chaque type de système de fichiers. Il faut inclure fsck.ext4 (qui est un alias de e2fsck).

#15

Pourrais-je avoir un lien web avec lequel je pourrais récupérer les caractéristiques de cet appareil ?

Merci.

#16

C’est celui la je crois https://www.phoenixcontact.com/online/portal/fr?uri=pxc-oc-itemdetail:pid=2701401

#17

Merci beaucoup pour le lien.

Si le moniteur est bien alimenté en 24V et que la puissance demandée est aussi faible que 12W (je m’en doutais un peu), je conseillerai de l’équiper d’une (24V)ou deux (de 12V) batteries (pour obtenir la tension de 24V) d’une capacité de 1AH.

Je pensais à une ou des Batteries de type stationnaires dont la durée de vie est spécifiée et varie entre 5 à 10 ans.
Les caractéristiques intéressantes de ce type de batteries sont leur longue duré de vie , un bon rendement , et une faible auto-décharge.

Elle sera sûrement étanche.

Mais le mieux est de demander conseil à ceux qui vous ont fourni l’appareil qui vous sert de moniteur, il vous diront quel type de batterie convient.
Il faudra penser à bien leur décrire dans quel environnement l’appareil et la batterie fonctionne, mais bon…s’ils sont sérieux il poseront les bonnes question.

D’ailleurs, je serai étonné que ce type de problème ne ce soit pas déjà présenté, et il y ont peut-être une solution toute faîte pour cet appareil.

Après, pour faire un détecteur d’absence de tension qui déclenche la mise en arrêt du moniteur, je suppose que s’il y a une armoire éléctrique, il doit y avoir un électricien compétent pas loin qui saura ce qu’il faut.

Rien que de penser à ce pauvre moniteur à qui on coupe l’alimentation brutalement, j’ai mal pour lui :slight_smile: