[résolu] repair filesystems suite incident raid

[glutwo]

Bonjour,
J'aijoué avec les disques pour voir si le raid fonctionne et savoir comment on est averti d' un incident.
Avec un disque dur débranché le système continue a fonctionner.
cependant au redémarrage j'ai le message " repair filesystems 1#".
Comme c'est du raid il semble que fsck ne fonctionne pas
Avez vous des liens pour m'aider.
Merci

[jibe]

Salut,

Je t'ai répondu sur le forum FreeEOS

Mais si Gaston passe par là et qu'il a mieux que ce que je te propose...

[stephdl]

je profite de ce post pour vous poser une question con, qu'apparament je n'ai pas osé faire.......
le comportement normal de la sme lors de la perte d'un disque dur en raid 1 ou en raid 5
manifestement en fonctionnement elle le signale, si on peut lui en mettre un en hot plug, elle le resynchronise..........
mais au demarrage, peut elle bouter sur n'importe quel disque dur ?. du moins en theorie puisque des fois cela ne fonctionne pas.....apparement.

pour ton probleme, j'imagine que tu as deja parcouru ce how to

http://wiki.contribs.org/Raid

[glutwo]

merci de vos réponses.
je vais parcourir tout ça une nouvelle fois. C'est un peu difficile d'y faire le tri .
Mon probleme n'est pas de faire un raid mais de le réparer.DE toute façon rien de grave puisque le serveur n'est pas en production et que j'ai la sauvegarde .
Je fais un test pour voir si je peux réparer en cas d'incident disque.
Même dans mes bouquins linux j' ai du mal a trouver quoi faire avec le message "repair filesystems".
Avec un liveCD ubuntu j'ai fais une vérif des disques qui dis que c'est OK.
/etc/raidtab et proc/mdstat semblent conformes.
Par contre fsck /dev/md0 (qui correspond au boot) me signale une erreur :

The filesystem size (according to the superblock) is 15088 bloks
The physical size of the device is 14976 blocks
Either the superblock or the parttion table is lekely to be corrupt!


mdstat me dit : md0 : active raid1 hda5(0) 14976 blocks [2/1] [U_]

Encore une fois merci .SI je m'en sors je vous le dis
A+

[jibe]

Salut,

Bon, Gaston répondrait beaucoup mieux que moi à toutes ces questions, mais je vais tenter de me lancer. Je précise que, puisqu'il ne s'agit que de raid 1 logiciel dans la question d'origine (le seul qui existe en version soft sur FreeEOS), je n'aborde pas du tout les autres types de raid.

je profite de ce post pour vous poser une question con, qu'apparament je n'ai pas osé faire.......
le comportement normal de la sme lors de la perte d'un disque dur en raid 1 ou en raid 5
manifestement en fonctionnement elle le signale, si on peut lui en mettre un en hot plug, elle le resynchronise..........
mais au demarrage, peut elle bouter sur n'importe quel disque dur ?. du moins en theorie puisque des fois cela ne fonctionne pas.....apparement.

Il faut considérer deux choses :
- Parle-t-on bien de raid 1 logiciel ?
- Je ne sais pas vraiment quel est le problème de glutwo, que je découvre peu à peu.
Donc, pour moi et jusqu'à preuve du contraire, une SME ou une FreeEOS démarre sur un seul disque (n'importe lequel des deux) en mode dégradé si l'un des deux tombe en panne (ou est supprimé volontairement). Je n'ai jamais expérimenté de non-redémarrage, et sauf si le seul disque valide a lui aussi un problème, je ne crois pas qu'il puisse ne pas y avoir redémarrage en mode dégradé.

j' ai du mal a trouver quoi faire avec le message "repair filesystems".

Tout simplement, il faut le réparer
Bon, c'est vrai que ce n'est pas toujours évident. Généralement, le message est un peu plus long et donne quelques indications importantes, mais ce n'est pas forcément plus clair !
En fait, il faut savoir quel filesystem on a, et la procédure de réparation en dépend. Mais en fait, ton erreur de taille signalée par fsck, elle est sur lequel des deux disques ? Et ces deux disques, sont-ils exactement identiques ou sinon quelles sont les différences ?

[lurey]

bonsoir, (et mes excuses si je suis à côté de la question, mais je crois pas...)
Lorsque j'ai un pb avec un disque en Raid 1 logiciel, je me logue en admin (vu mon install, c'est à distance avec le client ssh PuTTY) là, sur le premier panneau bleu, à la 5ème ligne, il y a "gérer la redondance des disques".
Lorsqu'il y a eu un incident de disque, il est possible, de ce menu, de refaire le mirroir sur l'autre. ça prend un peu de temps, car je pense, tout est réinscrit. En fait, ça fonctionne comme lorsqu'on vient de mettre un (nouveau) deuxième disque.

[jibe]

bonsoir, (et mes excuses si je suis à côté de la question, mais je crois pas...)

Non, tu n'es pas à coté de la question, mais pas sur la bonne machine
FreeEOS n'a pas les mêmes options, en plus je ne suis pas tout à fait certain que le problème soit seulement un problème de resynchronisation...

Mais effectivement, sur SME 7.x, ta manip est bonne et suffisante dans la majorité des cas.

[glutwo]

bonjour,
effectivement ma distrib est une free Eos .Mais ce forum a l'air plus vivant.
La machine est un HP vectra vl800 .les deux disques sont identiques maxtor 250 G0
seul 132G0 sont reconnu mais il y en a assez.
Je veux juste faire un serveur de fichiers , c'est pour ça que je teste le raid et voir si je peux le réparer.
Je pense qu'une reinsta corrigera le pb en formatant les disques.
C'est vrai que j'ai été sauvage en débranchant l'alimentation du disque a chaud.
Je confirme le serveur a continuer a fonctionner, c'est au redemarrage que j'ai le message d'erreur.
C'est le hdc que fdisk -l signale avec des erreurs.
Est ce que je dois le formater et refaire les partitions a l'identique du hda et relancer une reconstruction du raid?
Tant qu' a faire autant réinstaller et a ce propos quelle difference entre freeEos et sme ( c'est pas un troll)
A+

[glutwo]

je recopie le message d'erreur qui apparait au lancement de la machine après la ligne
initializing USB mouse: [ OK ]
Your system appears to have shut down uncleanly
Press Y within 1seconds to force file system integrity check...
checking root filesystem
/1: The filesystem size (according to the superblock) is 33417082 blocks
The physical size of the device is 33417056 blocks
Either the superblock or the partition table is likely to be corrupt§

/1: unexpected inconsistenc; run fsck manually.
(i.e. , whithout -a or -p options )

puis le message qui invite a se logger en admin.

Bon , sous windows je ferais un chkdsk /r .

La je sais que c'est le 2eme disque hdc qui a un pb.
Est qu'il faut reformater et refaire les partitions apres.
hier j'ai tenté une manip de gaston qui consiste a recopier les partitions de a sur c (genre >fstabout, je suis pas sur de la syntaxte) qui n'a pas fonctionné .
je pense que suis d'abord sur un probleme de disque avant d'etre un pb de raid.
merci de m'avoir lu jusqu'au bout et bonsoir a tous.

[jibe]

Salut,

effectivement ma distrib est une free Eos .Mais ce forum a l'air plus vivant.

Effectivement, Ixus a nettement plus de membres que le forum FreeEOS. Normal : on y trouve non seulement pas mal d'utilisateurs de FreeEOS et de SME, mais aussi d'autres distribs et même des windowsiens. La sécurité informatique ne se limite pas à FreeEOS

Tu peux bien sûr rester ici pour résoudre ton problème. Avec un peu de chance, Gaston interviendra, ce qu'il ne fera pas sur le forum FreeEOS !

C'est le hdc que fdisk -l signale avec des erreurs.

Hé, tu ne l'avais pas dit, ça !
Effectivement, si tu as débranché l'alim du disque en plein fonctionnement (ce que tu n'avais pas dit comme ça non plus), il y a certainement des incohérences soit dans le filesystem soit dans la table de partition. Encore une chance si un aterrissage des têtes n'a pas fait plus de dégats ! L'IDE n'a jamais permis le hotplug (ni le hotunplug ) ! A ne jamais faire !

Donc, ton disque comporte des incohérences. Il faut au moins lui remettre une table de partitions correcte avant de reconstruire le raid ! Après, tu fais les manips indiquées par Gaston pour la reconstruction. Je ne l'ai jamais tenté sur FreeEOS, mais je pense que ça devrait fonctionner. Sinon, il y a la solution "bourrin" (ça m'arrive à moi aussi, Gaston ) : tu clones le bon disque sur le mauvais avec dd ou g4l.

[EDIT]
Bon, tu as posté pendant que je rédigeais ma prose (moi aussi j'ai des mouffles, Gaston )...

Ca ne change pas grand chose à ce que j'ai dit. J'ajoute simplement qu'il faut d'abord t'assurer, comme tu sembles d'ailleurs t'en douter, que le disque soit encore bon. Un contrôle des mauvais secteurs ne serait pas un luxe je pense.
[/EDIT]

[EDIT2]
J'ai oublié la question des différences SME/FreeEOS. La principale réside dans l'emploi sur SME de volumes logiques. LVM se combine donc avec le raid, ce qui ne rend pas les choses très simples pour les réparations. Mais ça reste très faisable malgré tout.

L'autre différence, c'est que FreeEOS ne fait que du raid 1, alors que SME sait faire du raid 1, 5 ou 6, et cela automatiquement à l'installation en fonction du nombre de disques détectés.
[/EDIT2]

[glutwo]

oui, apparemment nous étions d'écrire en même temps.

"Encore une chance si un aterrissage des têtes n'a pas fait plus de dégats ! L'IDE n'a jamais permis le hotplug (ni le hotunplug Laughing ) ! A ne jamais faire ! "
J'y ai pensé , mais je me suis dis qu'une coupure de courant faisait la meme chose.
la commande fsck /dev/hdc
me dit en gros qu"elle ne peut rien faire pour moi.
"fsck.ext2: Bad magic number in super-block while tryng to open /dev/hdc
j'ai trouvé ca "http://nuticiel.ac-corse.fr/TICE/biblio/tutoriel_commande_dd.pdf
j'ai donc lancé "dd if=/dev/hda of=/dev/hdc"
et le curseur clignote, clignote,

faut attendre demain pour voir.
c'est pas si bourrin , apres tout copier un disque sur l'autre c'est bien du raid .
bonsoir
A+

[Gaston]

Bonsoir,
j'ose esp"rer que tu joues avec un serveur de test, parce que là depuis que tu sembles manipuler tes disques dans tous les sens, toute récupération d'un état sain me semble à abandonner (désolé si je suis rude, mais c'est l'impression que me donne ce fil de discussion).
Donc quelques remarques :
- un serveur Linux avec des disques raid1 CORRECTEMENT configurés redémarre sur n'importe lequel des disques. il FAUT et il SUFFIT que lors de la création, le changement de disque, le MBR avec le boot de grub est été (ré)écrit . Ce point est totalement géré sur un SME 7.x dans la "gestion de la redondance" (pour les autres je sait pas (plus) dire).

- deux disques faisant partie d'un raid doivent avoir les mêmes caractéristiques (ou variantes compatibles entre elles). Si l'application de la table de partition du disque sain sur un nouveau disque ne fonctionne pas ("sfdisk -d" puis "sfdisk <") on doit se dire qu'il faut revoir son approche du problème.
NEANMOINS la "gestion de la redondance" de SME7.1.3 (pour versions antérieures je ne sait dire) permet de gérer des disques de tailles différentes (d'où la possibilité d'intégrer des disques plus gros pour augmenter la capacité de stockage). La lecture du script est enrichissante de ce point de vue.
Il est inutile et suicidaire de d'insister sur une méthodolgie qui semble ne pas fournir les résultats attendus dès le début, si on ne sait pas trop ce que l'on fait (veut faire).

Pour statuer sur les messages d'erreur, il semble que tu ais appliqué une structure de partition + petite à un disque + grand AVEC des données, tu as une incohérence entre les infos du FS/LVM et le partitionnement. Je dirai que le plus simple est de sauvegarder les données et repartir sur des bases saines.
Je ne pense pas que le "dd" en cours aboutisse à quoique ce soit d'exploitable, la copie est en effet une copie block à block. ce n'est pas le cas du mirroring.

G.

[jibe]

J'y ai pensé , mais je me suis dis qu'une coupure de courant faisait la meme chose.

Pas exactement... En fait, en cas de coupure de courant, la tension en sortie d'alim baisse progressivement. Rapidement, certes, mais malgré tout assez lentement pour que ça puisse être détecté par le disque qui va tenter de parquer ses têtes avant l'arrêt total. Mais dans le cas d'un débranchement du connecteur molex, la coupure est brutale (en plus pas forcément franche, ce qui ne fait qu'aggraver les choses).

Et puis, des disques durs qui ont des problèmes après une coupure de courant, ce n'est pas exceptionnel non plus !

Je ne pense pas que le "dd" en cours aboutisse à quoique ce soit d'exploitable, la copie est en effet une copie block à block. ce n'est pas le cas du mirroring.

Ah bon ? Et pourquoi donc ? Que le type de duplication soit différent, d'accord. Que les données ne soient pas réparties physiquement de la même façon, d'accord. Mais en quoi cela a-t-il de l'importance ? A la fin du dd, il aura bien deux disques avec les mêmes données, tous deux capables de fonctionner. Pourquoi le raid ne l'accepterait-il pas ? (d'ailleurs, je n'en suis plus très sûr, mais il me semble que je l'avais fait sur ma SME)

Ou alors, c'est parce que les deux disques sont différents ?

[glutwo]

bonjour ,
il est 7 h et la commande DD tourne toujours.
Pour répondre a Gaston, oui c'est en test, oui les deux HD sont identiques.
Je les repris dans un NAS netgear qu'on arrivait pas a faire fonctionner.
Je les ais mis dans un (vieux) vectra VL800 P4 1,7 256Mo pour faire un serveur de fichiers.
les HD sont deux Maxtor de 250 Go mais je pense que le bios du vectra les limite a 132, je n'ai trouvé d'upgrade chez HP.
J'ai pensé que ce serais un bonne méthode de faire rentre un peu de Linux dans un monde de brute.
Je voulais simplement savoir comment gerer un PB en cas de besoin.
Comme je l'ai dis plus haut , j'ai la sauvegarde et je sais que le plus simple est de réinstaller.
En parcourant les fils j'ai mieux compris mon pb.
et c'est promis je ne debranche plus a chaud.
J'avais fait un test avec un 1 HD puis en remettant l'autre çà s'est reconstruit en une 20 de mn.
Merci a tous de vous intéresserez a mon expérience.
Je vous tiens au courant du dd.
A+

[jibe]

Salut,

les HD sont deux Maxtor de 250 Go mais je pense que le bios du vectra les limite a 132, je n'ai trouvé d'upgrade chez HP.

Je ne sais pas ce qu'il en est de ton bios, mais en tous cas tu n'auras jamais plus de 132 Go avec la version actuelle (1.3.3) de FreeEOS : c'est dû à la limitation du noyau 2.2...

Pour ton dd, il est normal que ce soit long. G4U/G4L est souvent plus rapide. G4U étant inclu dans UBCD, c'est généralement ce que j'utilise.