Raidsystem mit seperater Betriebssystemplatte, Fehlermeldung

Liebe Helfer,
nachdem ich jetzt zwei Wochen selbst versucht habe den Fehler zu beseitigen, benötige ich dringend Hilfe.

Ich glaube, dass ich zuerst mein System erläutern sollte:
Es handelt sich um einen älteren IBM-PC, den ich etwas für meine Zwecke modifiziert habe. Das Gerät hat drei Festplatten, 2x1TB Sata als Raid 1 und eine, jetzt 160GB IDE neue Festplatte, auf der sich das Betribssystem befindet. neben einem IDE-onboard-Kontroller habe ich einen PCI-Sata-Kontroller eingesteckt. Dieser Kontroller könnte auch ein Hardware-Raid realisieren. Ich hatte mich entschieden die Hardwaremöglichkeit auf Anraten nicht zu nutzen, also ein Software-Raid.
Das ganze System läuft unter DEBIA 5.0 Lenny.

Nun zur Problematik:
Am Abend vor dem Crash habe ich das Gerät noch fehlerfrei runter gefahren. Beim Nächsten Start bekam ich die Fehlermeldung:
fsck.ext3:invalid argument while traying to open /dev/md0
/dev/md0:
The superblock could not beread or does not describe a correct ext2 filesystem.

Die komplette Fehlermeldung reiche ich am Ende nach. Ich sollte jetzt erklären, was ich alles gemacht habe.
Die üblichen Cheks fsck und der Versuch mit e2fsck -b blieben erfolglos. Dann habe ich das Raid-System elektrisch abgehangen und einen neuen Startversuch gemacht. Es folgte die gleiche Fehlermeldung. Deshalb bin ich davon ausgegangen, dass der Fehler sich auf der Festplatte mit dem Betriebssystem befindet, mein English ist leider nur rudimentär. Ich habe nach allen experimenten eine neue Festplatte besorgt, die jetzige 160 GB, eingebaut. Die alte 40 GB mit dem vermeintlichen Fehler wurde entfernt, beide sind/waren IDE und waren am internen Kontroller angeschlossen. Ich habe auf die neue Festplatte das Betriebssystem installiert und bei der Partitionierung festgestellt, dass das Partitionierungswerkzeug den Raidverbund erkannt hat die beiden Platten waren mit sdb1 und sdc1 benannt. Nach der Installation des Betriebssystem habe ich dann das Raidsystem (md0) in die fstab als /home eingetragen. Bei der Partitionierung hatte ich ein kleines /home unter /hda5 installiert. Diesen Eintrag habe ich abgeändert in "/dev/mdo /home ext3 defaults 0 2 ". Ich habe fest mit einem Erfolg gerechnet und war sehr enttäuscht, als die gleich Fehlermeldung wie zuvor erschien, nur bezogen jetzt auf die Neue Festplatte. das ist so kurz wie möglich meine Arbeitsbeschreibung.

Jetzt noch die komplette Fehlermeldung:
Setting the systen clock
Cleaning up ifupdown....
Loading kernel modules .... done
Generating udev events for MD arrays... done
Cecking file systems... fsck 1.41.3 (12-=ct-2008)
/dev/hda1: clean, 29/97536 files, 37989/390144 blocks
fsck.ext3: invalid argument while trying to open /dev/md0
/dev/md0:
The superblock could not beread or does not describe a correct ext2 filsystem.
if the device is valid and really contains an ext2 filesystem (and not swap or ufs or somting else),
then the superblock is corrupt, and you might try running e2fsck -b 8193 <device>
/dev/hda6: clean, 31/1221600 files, 120742/4883752 blocks
fsck died with exit status 8
fieled "code 8"

Soweit die Meldung, wie ich Sie abgeschrieben habe. Es gibt noch einen Hinweis, dass in "/var/log/fsck/checkfs" ein log-Datei niedergelegt ist. Offensichtlich wird die aber bei jedem Start überschrieben, so dass ich alles erst zurückbauen muss, wenn die Datei erwünscht ist.


Nun hoffe ich, dass ich alles was wichtig ist, liefere und bedanke mich schon im Voraus für jede Unterstützung. Bitte setzt nicht zuviel bei mir voraus.

Herzlichen Gruß

Josef

Mal die Ausgaben von folgendem Befehl liefern und wenn dort ein Raid "md0" dabei sein sollte, dann mal noch zusätzlich.

robi

Hallo robi,
Dank für Deine Antwort. Ich möchte, weil meine Ausführungen so umfangreich waren mir nochmals einen Hinweis erlauben. Die alte Festplatte (40GB) habe ich im Versuch auch jetzt nochmal alleine betrieben, ohne Raid, dann weist sie immer noch den beschriebenen Fehler auf, während die neue Festplatte, bei wieder geänderter "fstab" /dev/hada1 /home usw., störungsfrei und ohne Fehlermeldung läuft. Hier nun die Meldungen von "cat und file -s"

cat /proc/mdstat > "Personalities: [raid]
md0:inactive sda1 [0] sdb1 [1]
1953519728 blocks super1.0

unused devices <none>

file -s /dev/md0

/dev/md0: empty

Außerdem sind mir beim Start noch folgende Meldungen aufgefallen: mdo failed creat Bitmap -22
und
md: pers - [run] failed.

Wobei ich darauf hinweise, dass diese meldungen durchlaufen und ich möglicherweise diese nicht absolut korrekt wiedergebe.

Ich hoffe Du kannst etwas damit anfangen.

Gruß und Dank

Josef

jgoe1 schrieb:

cat /proc/mdstat > "Personalities: [raid]
md0:inactive sda1 [0] sdb1 [1]
1953519728 blocks super1.0

Zum Vergrößern anklicken....

Dein Raid ist zwar als solches gefunden worden, aber es ist nicht gestartet worden. Aus deinen Fehlermeldungen geht das nicht eindeutig hervor was genau los ist, möglich das es von deinem System so gewollt ist, möglich aber auch beide Platten sind der Meinung sie sind "down"

Versuche wie folgt das Raid zu starten.
und versuche dann mal den file-befehl, dieser sollte ein Dateisystem finden oder zu mindestens "data" aber bei dir findet er nur eine große "LEERE" nämlich nichts.
Eventuelle Fehlermeldungen bitte 1 zu 1 hier einstellen.

Wenn das so nicht zu starten ist, dann mal die Ausgabe von
hier einstellen, damit zu erkennen ist, warum das Raid nicht automatisch anläuft.

robi

Hallo robi,
Ich werde die Kommandos die ich benutzt habe jeweils in der ersten Zeile mit aufführen
Zu Deinen Vorgaben habe ich folgende Meldungen bekommen.
Letzte Meldung des Rechners beim Hochfahren:
Give root paßword for mintenance
(or type Control-D for continue):
Nach Paßworteingabe:

Sonne:~#mdadm --run /dev/mdo
[95.179995] mdo:failed to create bitmap (-22)
[95.179995] md: pers->run() failed...
mdadm: failed to run array /dev/md0: invalid argument

sonne~#mdadm --examine /dev/sd[abc] [1234]
mdadm: No md superblock detectet on /dev/sda.
mdadm: No md superblock detectet on /dev/sdb.
mdadm: cannot open [1234]: No such file or directory

sonne~#file -s /dev/sd[bc]1
/dev/sdb1: Linux rev 1.0 2xt3 filesystem data, UUID=7ac2f28a-44bc-a0e7-d6b2e68b611f (large files)

Nun habe ich, weil mir unklar war ob der zweite Befehl aneinandergereiht ist, oder tatsächlich zwei Befehle waren, nochmals eine Ausgabe aus der Kombination der Befehle aufgeführt.

sonne~#mdadm --examine /dev/sd[abc] [1234] file -s /dev/sd[bc]1
ARRAY /dev/md/0 level=raid1 metadata=1.0 num-devices=2 UUID= 784b9fdb:82414fc1:540752a0:7daf2c8a name=0

Ich hoffe, dass ich alles korrekt gemacht habe und bedanke mich nochmal für Deine Mühen.

Gruß und Dank

Josef

der wichtigste Befehl war leider falsch, da war ein Leerzeichen zu viel drin (zwischen den beiden Eckigen Klammern kein Leerzeichen.)

ich habe das eben nochmal probiert das war auch bei mir nicht drin, du hast es nur falsch abgeschrieben. Ist manchmal im Browser nicht immer richtig zu erkennen, am besten hier kopieren und in der Konsole dann einfügen und ausführen.

robi

Hallo robi,
jetzt habe ich ein Problem. Wie kriege ich das Ergebnis in eine Datei kopiert. Ich habe auf diesem Rechner nur ja keinen Zugriff und muss alles vom Monitor abschreiben, es sei denn das wird irgendwo in einer Datei abgelegt und ich kann mit einer Live-CD daran.

Gruß Josef :???:

wenn du über irgend eine LiveCD gehst, solltest du einen USB-Stick oder ähnlichen anhängen können.

Die Ausgabe des Befehle einfach in eine Datei unterhalb von /tmp schreiben und auf den USB-Stick kopieren.

einfach an den Befehl deren Ausgabe du haben willst, am Ende noch folgendes anhängen.
dann die Datei /tmp/meine.logdatei auf den USB-Stick kopieren und kann kannst du das auch von einem anderem Rechner auslesen und hier her senden. Unter Windows bitte eine solche Datei mit WordPad offnen.
Auch mal hier schauen. Da stehen noch mehr solche Sachen

robi

Hallo robi,
Danke für den Hinweis. Das hat gut geklappt. Hier die gesamte Datei wie ich hoffe. Ich werde auch einmal versuchen da etwas rauszulesen und hoffe, dass mein System noch zu retten ist.

/dev/sda1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 784b9fdb:82414fc1:540752a0:7daf2c8a
Name : 0
Creation Time : Mon Mar 9 18:41:16 2009
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953519728 (931.51 GiB 1000.20 GB)
Array Size : 1953519728 (931.51 GiB 1000.20 GB)
Super Offset : 1953519984 sectors
State : clean
Device UUID : 9f2c6c80:f0ebf225:96ffdab4:fc06064c

Update Time : Thu Dec 16 18:31:37 2010
Checksum : bea63b2 - expected bea63b1
Events : 1266


Array Slot : 0 (0, 1)
Array State : Uu
/dev/sdb1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 784b9fdb:82414fc1:540752a0:7daf2c8a
Name : 0
Creation Time : Mon Mar 9 18:41:16 2009
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953519728 (931.51 GiB 1000.20 GB)
Array Size : 1953519728 (931.51 GiB 1000.20 GB)
Super Offset : 1953519984 sectors
State : clean
Device UUID : 7cbb77e0:90d8cf32:82603c43:fb28f34e

Internal Bitmap : -234 sectors from superblock
Update Time : Thu Dec 16 18:31:37 2010
Checksum : a21621b - correct
Events : 1266


Array Slot : 1 (0, 1)
Array State : uU

Herzlichen Gruß

Josef

Das Raideinzelteile sind sich nicht einig über den Status und die /dev/sda1 hat einen Fehler in der Checksumme.

was mich ein bischen stutzig macht, am Anfang hattest du erzählt es sind /dev/sdb1 und /dev/sdc1 jetzt ist es wohl doch /dev/sda1 und /dev/sdb1. Wenn sich bei dir ständig die Devicenamen ändern, ist es natürlich extrem schwer dir da genaue Befehle für solch sensiblen Aufgaben zu geben.

Ich sehe an deinen Ausgaben jetzt wegen obriger Problemen auch nur das Filesystem auf der 2. Platte. Aber die 2. Platte ist mit der größeren Wahrscheinlichkeit die, die auch okay ist.

Also prinzipell gäbe es 2 Wege, der erste das online setzen des Raid mit der Option "--force" zu erzwingen, das könnte dann eventuell ein Raid mit ein paar kleinen/großen Fehlern ergeben, die dann hinterher erst wieder beseitigt werden müssten, das machen wir heute mal nicht. Wir setzen das Raid wieder auf in dem wir /dev/sdb1 als Master nehmen.

Ich gehe im Weiteren auch davon aus, das die Devices des Raids wie in der obrigen Logdatei /dev/sda1 und /dev/sdb1 sind. Wenn sich das bei dir in der Zwischenzeit wieder geändert hat, dann musst du das bei der Anwendung der Befehle bedenken.

Ich mache im nächsten Beitrag mit einer genauen Beschreibung der einzelnen Schritte weiter, aber erstmal muss ich einen Kaffee trinken und mal kurz Tabaksteuer entrichten und dann einen kleinen Testaufbau aufsetzen, das kann also ein bischen dauern.

bis gleich
robi

Wichtig: sobald hier irgend etwas überhaupt nicht so läuft wie beschrieben, dann nicht weitermachen, sondern an dieser Stelle alles erst mal so lassen wie es ist, und hier nachfragen. Ganz genau kann ich das zwar alles auch nicht nachstellen, aber ich werde mich weitestgehend bemühen, also kleinere Abweichungen in den Ausgaben sind normal.
Die Befehlszeilen ist immer nur jeweils die erste Zeile und hat hier in Howto immer ein "#" am Anfang, (dieses # bei dir auf der Konsole nicht mit eingeben), die weiteren Zeilen sind immer die Ausgaben, nicht immer habe ich alle hier reingesetzt und die können auch mal bei dir ein kleines bisschen abweichen.

Am aller Besten erstmal das Howto komplett durchlesen.


Ausgangssituation :
Das Raid ist erkannt aber läuft nicht der Befehle "cat /proc/mdstat" zeigt den derzeitigen Status. diesen Befehl werden wird noch öfter benötigen.
als Devices haben wir sda1 und sdb1 das Raid ist md0 derzeitiger Zustand "inactive"
dieses sollte man sich schon mal merken. Denn jetzt werden wir das Raid erstmal entfernt.
Der Zustand sollte sich damit auf folgendes Ändern
Aus der Ausgabe von "mdadm --examine" haben wir erkannt, beide Raidteile passen zusammen, haben die gleiche RAID-UUID und das Datum der letzten Änderung passt auch zusammen. sda1 hat einen Checksummenfehler, desshalb nutzen wir erst einmal nur sdb1 und hoffen deine Reparaturversuche seit 16. Dezember haben nicht großartiges zusätzlich Kaputt gemacht. Wir lassen aber ersteinmal sda1 unberührt, man kann nie wissen ob wir die Daten dort eventuell noch brauchen wenn sie auf sdb1 doch kaputt sein sollten.

Wir setzen das Raid jetzt wieder auf, aber nur mit sdb1
Der Status danach könnte so hier aussehen
Jetzt starten wir dieses halbe Raid und setzen es damit online
Der Status ändert sich damit auf
Wenn das funktioniert ist das schon die halbe Miete, wenn nicht an dieser Stelle erstmal unterbrechen und die Ausgabe der letzen beiden Befehl hier her senden.

Jetzt kann das Filesystem auf md0 überprüft und gemountet werden.
Das wäre eine optimale Ausgabe, eventuell sind allerdings auch einiges kaputt und wird repariert. Das ist ersteinmal nicht weiter tragisch.
Dann wird gemountet
das sollte anschließend problemlos funktionieren.

Jetzt kann auf /mnt überprüft werden ob das Filesystem ok ist und die Dateien soweit vorhanden sind. Ist das erstmal nichts auszusetzen dann, und nur dann, kann sda1 zum raid dazugefügt werden.
der Status zeigt dann einen rebuild
diesen lassen wir bis zum Ende durchlaufen. Das wird bei 1TB natürlich eine ganzes Stück (wahrscheilich Stunden) dauern. Du kannst dir den aktuellen Status jederzeit mit "cat /proc/mdstat" anschauen.
In der Zwischenzeit kann das Filesystem schon mal weiter untersucht werden, du könntest auch schon damit arbeiten, für die abschließenden Arbeiten muss es allerdings noch mal umountet werden.
Ist der rebuild fertig und das Filesystem umountet, dann wird das Raid wieder komplett beendet und nachgeschaut ob es sich von selbst wieder richtig zusammensetzt.
das beenden
das automatische aufsetzen
der Status sollte jetzt ein sauberes Raid zeigen.
Jetzt kann rebootet werden, und wenn die /etc/fstab immer noch richtig angepasst ist, dann sollte das Raid auch schon automatisch eingehängt werden, Bei deiner Neuinstallation ist es möglich das da noch etwas gemacht werden müsste.

Viel Erfolg
robi

Hallo robi,
zunächst möchte ich mich dafür entschuldigen, dass ich Dir Deine Arbeit durch nicht korrekte Angaben unnötig erschwert habe. Zu meiner Entschuldigung möchte ich anführen, dass unter der Live-CD "Parted Magic" die einzelnen Festplatten mit sda, sdb, und sdc ausgewiesen wurden, wobei sda die Platte mit dem Betriebssystem war. Auch bei der Partitionierung wurde die für das Betriebssystem vorgesehene Platte mit hda bezeichnet. Ich glaube da habe ich noch einiges an nachhol Bedarf.
Ich werde mich jetzt an die Arbeit machen, leider bin ich erst jetzt zurückgekommen.

Gruß und Dank für die bisherige Unterstützung

Josef

Hallo robi,
seit 30 min läuft das recovery und 16% sind durch. Ich lasse das jetzt erst mal durchlaufen. Nach meiner Einschätzung und den Angaben hier wird das etwa 3,5 Std dauern. Erst dann werde ich weiter machen. Ich habe die Hosen voll, jetzt nichts riskieren. Doch jetzt schon einmal ganz, ganz lieben Dank für Deine Hilfe. Ich hoffe, dass ich nach Abschluss noch einige Fragen an dich richten darf. Den jetzigen Ablauf habe ich Dank Deiner wirklich tollen Erklärung einigermaßen nachvollziehen können.


Dank und Gruß

Josef

Hallo robi,
herzlichen Dank für Deine Hilfe und Dein wirklich exzellentes Howto. Es hat alles geklappt und mein System läuft wieder. Es wäre für mich schlimm gewesen, wenn meine Daten auf nimmer Wiedersehen verschwunden wären. Die wichtigsten Daten hatte ich zwar mit einer Laive-CD gesichert. Vielleicht kannst Du, wenn es nicht zu unverfroren ist, mir die möglichen Fehlerquellen erklären, wie es dazu kommen konnte. Es sind ja sozusagen 2 Festplatten betroffen. Die Betriebssystem-Festplatte hatte und hat einen Superblock-Fehler und wurde ganz ausrangiert. Glücklicherweise hattest Du ja eine Lösung für das Raid-System.

Ich bedanke mich nochmals aufs herzlichste.

Josef

Am Raid war nicht viel kaputt, eigentlich gar nichts wirklich. Die Raidplatten hatten nur gegensätzlichen Status gespeichert, das heißt, jede Platte war der Meinung das Raid auf der anderen Platte ist nicht online. Damit konnte/wollte der Raidtreiber das Raid nicht von sich allein aufsetzen.

So was kann durchaus mal während eines größeren Absturzes oder dem ersten hochfahren danach passieren. Man muss bedenken wenn der Rechner hart stehen bleibt können eben zu diesem Zeitpunkt Schreibvorgänge die auf beide Platte geschrieben werden müssen nicht sicher beendet und als abgeschlossen registriert werden. Sowas kann dann die Folge sein.

Einen richtigen Superblockfehler kann man sich bei einem Absturz durchaus auch mal einhandeln, wenn auch ziemlich selten. Dabei ist meist nur der eigentliche Superblock betroffen. Von diesen Superblocken gibt es im Filesystem jedoch genügend ältere Kopien mit denen man mit Hilfe eines fsck das wieder reparieren kann.

Allerdings ist der Filesystemsuperblock an einer bestimmten Stelle am Anfang der Partition und dort hat man sich schnell auch mal bei irgend welchen Konsol- oder Scriptunfällen ein paar Datenblöcke zuviel überschrieben wenn man allzu leichtfertig als root mit Befehlen spielt von denen man keine große Ahnung hat. Ebenfalls die selbe Meldung könnte man aber auch erhalten, wenn die Partitionstabelle defekt oder überschrieben wurde, bei bestimmten Fehlern in der /etc/fstab, wenn nach einem Kernel-Update etwas am Kernel der initrd oder den Filesystemmodulen nicht passt, wenn zB das Raid, eine Verschlüsselung oder das LV vorher nicht sauber wiederhergestellt werden konnte und noch bei einigen 100 anderen Fehlern mehr. Auch viele Plattendefekte können genau die selbe Fehlermeldung erzeugen. Es ist bei dieser Fehlermeldung also nicht immer wirklich das Filesystem defekt. Es ist nur der Fehler der einem oftmals zuerst ins Auge sticht, weil von da an nichts mehr geht.

Mit Howtos allein ist sowas schwer abzudecken, da es durchaus in jedem Einzelfall unterschiedlich sein kann, und es oftmals auch schon bei den ersten spontanen eigenen Reparaturversuchen ver-schlimm-bessert wird. Desshalb geht sowas auch nicht selten mal in die Hose, sobald die üblichen automatisch funktionierenden Tools solche Fehler nicht auf Anhieb beheben können und man daraufhin selbst dieses auf "Gut Glück" und ohne genügend eigenes Wissen nur mit Hilfe von Google versucht.

Es gibt gegen die meisten dieser Fälle nur ein einziges wirklich erprobtes und wirklich funktionierendes Universal-Allheil-Hilfmittel: immer ein aktuelles Backup und die Gewissheit das man auch irgendwo noch den Zettel hat auf dem drauf steht, wie man aus diesem Backup wieder seine Daten herausbekommt.

robi