Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
ah k bin grad dabei die screenshots der platten abzuspeichern.
Hää im Post oben schreibst du von textfiles und in dem howto info link schreibst du das man screens machen soll. Das verwirrt mich jetzt gerade.
Ergänzung ()
zu3. siehe anhang
Was mich stark wunder ist das die beiden hd501 obwohl sie das identische modell sind eine unterschiedliche sektor anzahl aufweisen! hd501_1 hat mehr als 2000 sektoren weniger als hd501_2.
zu7. Ich bin mir nichtmehr sicher ob ich beim partitionieren den alten mbr oder sogar die neue
gpt methode gewählt habe.
Hier mal die hardware portbelegung des ich9r die ich nie geändert habe und auf die ich sehr penibel geachtet habe:
Port1 - seagate 1
Port2 - seagate 2
Port3 - hd501_2
Port4 - hd501_1
Port5 - hd103_1
Port6 - hd103_2
Der ich9r controller steht im bios auf "RAID" mode.
Der jmicron steht im bios auf "IDE" mode.
Ok, ich seh mir das mal an.
Erstanalyse folgt bis ca. 11:00
Ergänzung ()
Erstmal zu deinen Fragen:
Screenshots, wenn nötig, z.B. von der Datenträgerverwaltung, sind als Bilder abzuspeichern.
Die hexDump-Outputs vom HxD brauch ich nur als Textfiles.
Aus Deiner Aufstellung der Port-HDD-Zuordnung geht nicht hervor, ob Du jetzt am GSATA(jMicron) Controller die Hitachi 1TB Backup-Platte auf den ersten Port gesteckt hast und die HxD-Analyse über Port2 durchführst. Das ist unbedingt notwendig, da sonst möglicherweise durch das BIOS weitere ungewollte Überschreibungen stattfinden könnten.
Außerdem sollten, bis auf ausdrückliche Anweisung, von den 4 Platten, die wir untersuchen, alle bis auf jene, die Du gerade am GSATA(jMicron) Port2 untersuchst, abgeklemmt bleiben und nicht zwischendurch wieder am ICH Controller hochfahren.
==>Frage: hängt die Hitachi jetzt am ersten Port, wie empfohlen?
Die Auswertungen, die ich hier im Anhang reingestellt habe, sind nicht 100% korrekt, weil es noch einige dunkle Flecken in der Struktur dieser Intel-RAID-Informationen gibt (die sich aber mit jeder weiteren Fallanalyse lichten), da sie nirgendwo richtig dokumentiert sind.
Aus diesen etwas einfacher lesbaren Inhalten ist folgendes entnommen:
Zuerst mal die 500GB Platten:
Member 1: Serial=S0MUJ1KLB37695 maxLBA=976773168 an SATAII_3 (hd501_2)
Member 2: Serial=S0MUJ13P655482 maxLBA=976771055 an SATAII_4 (hd501_1)
Member2 wird nur auf Member1-Info als fehlerhaft markiert, auf Member2-Info als OK
Die Memberplatte 2(hd501_1) hat- wie Du ja schon festgestellt hast, eine um 2113 Sektoren geringere Größe, woraus ersichtlich ist, dass sich hier das BIOS-Backup breitgemacht hat und gegenwärtig da drauf eine HPA aktiv ist.
Auf der Memberplatte 1(hd501-2) war aber auch schon mal eine HPA drauf – die ist aber wieder entfernt worden und das BIOS hat sich ein anderes Opfer gesucht. Eindeutig ist am letzten Sektor mal ein P35-ICH9 BIOS mit Version vom 13.11.2007 da draufgeschrieben worden.
==>Frage: Welche BIOS-Version (F???) ist bei Dir am DQ6 jetzt aktiv?
Interressant wäre auch, wie groß die maxLBA auf deiner Hitachi 1TB jetzt ist. Daraus lässt sich schließen, ob das aktuelle BIOS-Backup jetzt da drauf angelegt ist, wenn diese Größe um 2113 kleiner als 1953525168 ist.
==>Frage: Wie groß ist die maxLBA der Hitachi im HxD?
Die Aufteilung der Memberplatten 1+2 auf der 500er Matrix ist also wie folgt:
Gelöschter RAID0 lag innerhalb von Sektor 0-242747655 oder tiefer
Definierter RAID1 liegt auf Sektor 242747656-976765191 mit Stripesize=64KB und ist 350,0068359375GiB(=350GiB+7MiB) oder 358407MiB groß, also der verfügbare Rest.
Die Größe des RAID0 muss weniger als 115,751102447509765625GiB(=115GiB+769MiB+132KiB) bei der Definition betragen haben – weisst Du noch, welchen Wert Du dafür tatsächlich benutzt hast? Warum der RAID1 an einem derart unüblichem Alignment beginnt, ist mit im Moment noch nicht klar.
==>Frage: Wie groß war die Definition für den RAID0 an der 500er Matrix?
Wie sieht es auf den 1TB Platten aus:
Erstmal ist auffällig, dass diese mit einer älteren Version des Matrixmanagers(oder BootROM) erstellt wurden – Version 1.0.0 (bei den 500ern ist es 1.1.0)
==>Frage: Welche BootRom-Version zeigt er beim POST auf dem DQ6? Welche Version im Intel Matrix-Manager nach Systemstart?
Member 1: Serial=S13PJ1EQ310755 maxLBA=1953525168 an SATAII_5 (hd103_???)
Member 2: Serial=S13PJ1EQ310757 maxLBA=1953525168 an SATAII_6 (hd103_???)
Member 1 ist auf der als hdd103_unten bezeichneten Platte als fehlerhaft markiert, auf der anderen OK.
Welche der Seriennummern zu Deinen Bezeichnungen hd103_unten und hd103_oben gehört, ist so nicht eindeutig zuordenbar, da beide Platten gleiche maxLBA haben. Später, wenn diese weiteruntersucht werden, klären wir das dann, ohne die Platte auszubauen um die Seriennummer abzulesen)
Aufteilung auf den Memberplatten:
Definierter RAID0 liegt auf beiden Platten im Bereich Sektor 0-380633351 und ist 363GiB groß definiert worden.
==>Frage: Stimmt dieser Definitionswert?
Aus dem nicht mehr in den Infos ersichtlichem RAID1 dahinter kann die Größe nur anhand der möglicherweise restlich vorhandenen Größe geschlossen werden.(~568,5 GiB)
Soweit mal fürs erste – bitte um Beantwortung der mit "==>" markierten Fragen.
Danach sehen wir uns auf den Platten noch etwas genauer um.
Erstmal zu deinen Fragen:
Screenshots, wenn nötig, z.B. von der Datenträgerverwaltung, sind als Bilder abzuspeichern.
Die hexDump-Outputs vom HxD brauch ich nur als Textfiles.
Aus Deiner Aufstellung der Port-HDD-Zuordnung geht nicht hervor, ob Du jetzt am GSATA(jMicron) Controller die Hitachi 1TB Backup-Platte auf den ersten Port gesteckt hast und die HxD-Analyse über Port2 durchführst. Das ist unbedingt notwendig, da sonst möglicherweise durch das BIOS weitere ungewollte Überschreibungen stattfinden könnten.
Außerdem sollten, bis auf ausdrückliche Anweisung, von den 4 Platten, die wir untersuchen, alle bis auf jene, die Du gerade am GSATA(jMicron) Port2 untersuchst, abgeklemmt bleiben und nicht zwischendurch wieder am ICH Controller hochfahren.
==>Frage: hängt die Hitachi jetzt am ersten Port, wie empfohlen?
Ja genauso wie du es geschrieben hast, hab ich es gemacht. Hab die port infos nur nochmal zu informationsgründen hinzugefügt. Das hat wahrscheinlich mehr verwirrt als es genützt hat. Wärend dem benutzen von HxD hingen (zwangsläufig ) nur die beiden seagates am ICH9R. Die hitachi_backup an port 1 des jmicron und die jeweilige zu untersuchende platte am port2.
==>Frage: Welche BIOS-Version (F???) ist bei Dir am DQ6 jetzt aktiv?
Wen du mit Definition die Größe des Volumes meinst dann kann ich das nicht aus dem Kopf in Zahlen sagen. Für mich war wohl damals das raid1 wichtig weshalb dieses eine gerade Größe bekommen hat. Das raid0 hab ich dem untergeordnet.
==>Frage: Welche BootRom-Version zeigt er beim POST auf dem DQ6? Welche Version im Intel Matrix-Manager nach Systemstart?
ich weiß nicht was du mit der Boot Rom version meinst. Ich finde keine versions infos im Fomat x.x.x
Puh ma schaun... also Boot Rom infos finde ich im Matrix Manager nicht auch nicht mit googles hilfe.
möglicherweise meinst du "Intel Matrix Storage Manager Option ROM v7.5.0.1017 ICH9R wRAID5" ?
1TB Platten:
Member 1: Serial=S13PJ1EQ310755 maxLBA=1953525168 an SATAII_5 (hd103_1) =oben
Member 2: Serial=S13PJ1EQ310757 maxLBA=1953525168 an SATAII_6 (hd103_2) =unten
Aufteilung auf den Memberplatten:
Definierter RAID0 liegt auf beiden Platten im Bereich Sektor 0-380633351 und ist 363GiB groß definiert worden.
==>Frage: Stimmt dieser Definitionswert?
Ja, das RAID0 stimmt. Ich habe davon auch noch alle daten gesichert. Das RAID1 ist 750GB groß! Da bin ich mir schon sehr sicher. Die von dir erechneten ~568,5 GiB sind defintiv ein rechen fehler!
Hier mal die weiteren Anweisungen zum Erhalt der noch nötigen Informationen.
Hat ein wenig gedauert, weil die Vorgangsweise angepasst werden musste...
Während ich die Antworten zum Vorpost durchgehe, kannst Du die ja inzwischen extrahieren.
Nehmen wir uns als erste den 500GB-Array vor:
Die HxD hexDumps erzeugst Du wie bisher, die Markierung der gewünschten Bereiche erreichst Du nach folgender Methode:
Der Bereich wird im HxD-Menü mit “Edit/Select Block“ und Eingabe der Start-und Endwerte (die ich durchgebe und aus dem Post am besten mit copy&paste in die Felder übertragen werden), als Eingabemode muss „hex“ gewählt werden.
Darauf achten, dass in der ersten Zeile der Plattenanzeige “Offset(h)“ steht (falls nicht, im Menü: View/offset base/hexadecimal einstellen)
Dann den markierten Bereich mit “Edit/Copy as.../Editor view“ in die Zwischenablage und mit Strg+V in den jeweiligen .txt File übertragen. Mehrere verschiedene Bereiche (derselben Platte!) sollen in denselben .txt File hintereinander übertragen werden (bitte in den .txt Files selbst keine weiteren eigene Anmerkungen einfügen!), dann den .txt File unter dem hinter den Bereichen angegebenem Namen abspeichern, alle Files zippen und als Anhang ins Post stellen.
Vor der Untersuchung jeder Platte mit HDTune o.ä. Programm die Seriennummer auslesen, und die letzten drei Stellen der Seriennummer dann als Filenamen verwenden (also z.B.für die HDD mit Seriennummer S0MUJ1KLB37695 ==>695.txt).
Die benötigten Bereiche jeder der beiden 500GB Platten:
1.) Edit/Select Block: 0 – 7FF mit Edit/Copy as/Editor view übertragen
2.) im Sektoreingabefeld rechts oben Sektornummer 140000 eingeben, <Enter>, damit er die Anzeige dorthin positioniert.
Dann im Menü: Search/Find/Search for:
EB 52 90 4E 54 46 53 20
eingeben und als Datatype “hexvalues” auswählen und als Search direction: Backward.
Bei allen Sektoren, die gefunden werden, nur wenn dieser Wert am Anfang des Sektors gefunden wurde, händisch den gesamten Sektor markieren und in den .txt File übertragen.
Mit F3 den Suchvorgang wiederholen, bis nichts mehr gefunden wird.
3.) Edit:Select Block: 1CF0121000 - 1CF01217FF
4.) im Sektoreingabefeld rechts oben Sektornummer 243030000 eingeben, <Enter>, damit er die Anzeige dorthin positioniert.
Dann mit F3 weitersuchen, bis ein Sektor kleiner als 242747656 gefunden und übertragen wurde oder die Suche länger als 3 Minuten ohne Fundstelle gedauert hat, dann abbrechen.
5.) Edit/Select Block: 7470AFD000 - 7470AFDDFF
6.) nur von der Platte mit Seriennummer S0MUJ1KLB37695
Edit/Select Block: 7470C05000 - 7470C05FFF
Viel Spass
Ergänzung ()
Zu Deinem Post#23:
Zur Portbelegung: Dass am ICH9 an den ersten beiden Ports der System-Array der Seagate’s hängt, war mir schon klar. Die Frage war nur ergänzend, weil Du die Belegung am jMicron- nicht erwähnt hast...
btw, also hängt jetzt am ICH kein DVD-SATA-Laufwerk, und Du willst alle 6 Ports mit den 3 Raid-Arrays vollpflastern – wie ursprünglich geplant?
Zur Bios-Version: Das DQ6-Board hatte kein BIOS vom 13.11.2007 (zumindest kein Final, F7 Betas kann ich nicht nachprüfen) – für das DS3 gab es ein BIOS F9 mit diesem Datum. Diese BIOS-Backup Reste könnten also noch vom alten Board stammen.
Zur Hitachi: Nach der Sektorenanzahl ist hier aktuell eine HPA mit einem BIOS-Backup angelegt, auf der ersten erreichbaren HDD, die nicht unter RAID-Verwaltung gestellt ist. So lange diese Platte beim Hochfahren am Port1 vorhanden ist, nudelt uns das BIOS nicht am Port2 des jMicron herum.
Zu BootROM: der Intel MatrixManager hat ja zwei Komponenten: Einen BootROM, der Bestandteil des BIOS ist, mit dem der Controller nach BIOS-POST initialisiert wird und noch vor dem Booten vom System mit STRG+?? Aufgerufen werden kann, um dort den RAID zu konfigurieren. Ohne STRG+?? Erscheint nur kurz die Meldung, wo die Konfiguration (dtz. nur des SystemArrays) angezeigt wird, in der ersten Zeile steht die Version.
Die zweite Komponente ist der MatrixManager, der als Windows-Programm zur laufenden Statusabfrage und auch zur Konfguration verwendet wird. Dort sollte im Menü unter Help oder Info die Version eruierbar sein. Diese Version ist meist wesentlich neuer als die mit BIOS ausgelieferte.
Zu den 1TB-Platten: So früh am Morgen funktioniert das Hirn noch nicht richtig.
Der RAID0-Bereich ist zwar so groß, aber auf beide Platten verteilt. Daher bleibt für den RAID1 um 181,5GiB mehr je Platte.
Die Rechnung muss daher lauten: (1953525168-380633352)*512/2y30= ~750GiB
(2y30 ist die Notation im Windows Calculator für 2 hoch 30 oder 1024 hoch 3 für GiB –
y ist der Shortcut für „x Exp y“; einfach nachzurechnen, indem „(1953525168-380633352)*512/2y30=“ mit Copy&Paste in den Zubehör/Rechner gestellt wird. Der Rest hinter dem Komma ist der oben freibleibende Bereich, in dem die RAID-infos stehen)
Ich hatte mit noch nicht ganz offenen Augen die Anzahl der RAID0-Sektoren 761266176 statt 380633352 (Sektoren je Memberplatte) verwendet und die Hintergrundtask zur überschlagsmäßigen Plausibilitätsprüfung war vor dem ersten Liter Kaffee noch nicht gestartet )
nein die beiden oder auch nur eine 500gb platte(n) werden meine alten IDE platten im 2. pc ersetzen. Im haupt pc läuft dann am port 3 oder 4 das dvd laufwerk.
Zur Bios-Version: Das DQ6-Board hatte kein BIOS vom 13.11.2007 (zumindest kein Final, F7 Betas kann ich nicht nachprüfen) – für das DS3 gab es ein BIOS F9 mit diesem Datum. Diese BIOS-Backup Reste könnten also noch vom alten Board stammen.
das DS3 läuft in meinem 2. pc. Oh man super .. glorreich das solche bios funktionen , negativen aspekte niemand beim kauf kennt.
Zu BootROM: der Intel MatrixManager hat ja zwei Komponenten: Einen BootROM, der Bestandteil des BIOS ist, mit dem der Controller nach BIOS-POST initialisiert wird und noch vor dem Booten vom System mit STRG+?? Aufgerufen werden kann, um dort den RAID zu konfigurieren. Ohne STRG+?? Erscheint nur kurz die Meldung, wo die Konfiguration (dtz. nur des SystemArrays) angezeigt wird, in der ersten Zeile steht die Version.
Die zweite Komponente ist der MatrixManager, der als Windows-Programm zur laufenden Statusabfrage und auch zur Konfguration verwendet wird. Dort sollte im Menü unter Help oder Info die Version eruierbar sein. Diese Version ist meist wesentlich neuer als die mit BIOS ausgelieferte.
Boot Rom version beim Post bevor CTRL+I gedrückt werden kann: Serial ATA AHCI BIOS, VErsion iSRC 1.07 08042006
BIOS Intel Matrix Manager: 7.5.0.1017 ( im win matrix manager als RAID Option ROM Version deklariert)
Windows Intel Matrix Manager : Kit installed: 8.2.0.1001
Aus den gelieferten Daten für die 500er (Analyse im Anhang) geht hervor, dass
- die Plattenreihenfolge auf der Raid-Matrix
Member 1: S0MUJ1KLB37695 (hd501_2)
Member 2: S0MUJ13P655482 (hd501_1)
lautet, und damit gleichlautend mit den RAID-Infos ist.
- am RAID0 Array der Größe von 231,50 GiB
der Datenträger als ‚Basis’ initialisiert ist, sowohl der MBR als auch die einzige primäre NTFS-Partition in der Größe von 231,50 GiB intakt sind.
- am RAID1 Array der Größe von 350,00 GiB mit Stripesize von 64K
dieser Datenträger als ‚Basis’ initialisiert ist, der MBR intakt ist und sich dararauf eine primäre Partition mit 175,00GiB und eine erweiterte Partition mit 175,00GiB befinden.
Zur Wiederherstellung dieser Matrix-Arrays.sind die Daten der MBRs beider logischen Laufwerke zu sichern, indem von der HDD hd501_2 an Port2 des jMicron mit HxD die physical disk geöffnet wird wie bisher,
- der ganze Sektor 0 markiert wird (0 – 1FF), mit Strg+C in die Zwischenablage,
- im HxD Menü File/New, in diesen File mit Strg+V übertragen wird
(bei Popup Längenänderung: OK),
und danach mit File/Save as... unter dem Namen „hd501lj_raid0_mbr.bin“
in ein selbstgewähltes Verzeichnis abgespeichert wird.
- in gleicher Weise den Inhalt des Sektors 242747656 (1CF0121000 - 1CF01211FF)
in eine Datei unter dem Namen „hd501lj_raid1_mbr.bin“ sichern.
Diese beiden Dateien brauchen wir später zur Wiederherstellung des Zugriffes nach Entfernen der beiden Platten aus dem RAID-Verbund und Neudefinition des Arrays
Der NTFSboot-Mirror der einzigen primären Partition am RAID0-Array befindet sich auf Sektor 242742027 der zweiten Memberplatte. Durch diese Lage kann eindeutig festgestellt werden, dass als Stripesize des RAID0 nur 128KB definiert gewesen sein kann.
Bevor diese beiden 500er Platten jetzt dem RAID-Controller neu definiert werden, solltest Du mit dem MatrixManager kontrollieren, ob dieser keinerlei Information über die jetzt nicht angeschlossenen beiden 500GB und die beiden 1TB Platten mehr besitzt(aus den Infos, die er von den beiden Systemplatten bezieht). Er darf nur die beiden HDDs des System-RAIDs an Port 0 und 1 anlisten und keine der vier nicht angeschlossenen Platten vermissen. Ist das so?
so jetzt hab ich endlich wieder zeit nach den FH verpflichtungen.
Diese beiden Dateien brauchen wir später zur Wiederherstellung des Zugriffes nach Entfernen der beiden Platten aus dem RAID-Verbund und Neudefinition des Arrays
Bevor diese beiden 500er Platten jetzt dem RAID-Controller neu definiert werden, solltest Du mit dem MatrixManager kontrollieren, ob dieser keinerlei Information über die jetzt nicht angeschlossenen beiden 500GB und die beiden 1TB Platten mehr besitzt(aus den Infos, die er von den beiden Systemplatten bezieht). Er darf nur die beiden HDDs des System-RAIDs an Port 0 und 1 anlisten und keine der vier nicht angeschlossenen Platten vermissen. Ist das so?
Wie kann er infos von den beiden systemplatten für die anderen beziehen ? Ich dachte die raid infos werden immer auf dem jeweiligen member gespeichert?
Im moment zeigt er keine infos zu den nicht angeschloßenenen Platten an. Das war auch meiner meinung nach noch schon immer so. Unter windows werden im matrix manager die restlichen ports als unused deklariert. Auch beim Post des RAID Bios werden nur die beiden systemplatten aufgelistet.
Wie kann er infos von den beiden systemplatten für die anderen beziehen ? Ich dachte die raid infos werden immer auf dem jeweiligen member gespeichert?
Nun, da war ich mir nicht so ganz sicher - deswegen die Nachfrage.
Dass er, wenn an den Ports nichts hängt, "unused steht", ist klar, aber er hätte z.B. weitere logische RAID-Volumes als in "Error" oder so ausweisen können.
Also weiter im Text:
Jetzt kannst Du die 500er wieder- aber in der richtigen Reihenfolge - an die ICH-Ports anschließen:
an SATAII_3 Member 1: S0MUJ1KLB37695 (hd501_2)
an SATAII_4 Member 2: S0MUJ13P655482 (hd501_1)
Da wird er die beiden Platten wieder als Array erkennen.
Nun löst du die da drauf befindlichen logischen Laufwerke auf und definierst
erstmal nur den RAID0-Array neu in der ursprünglichen Größe mit Stripesize 128K.
Danach muss mit HxD eine Kontrolle der MaxLBA erfolgen:
- Das logische RAID0-Laufwerk darf nicht größer als 485495312 Sektoren
- und nicht kleiner als 485484300 Sektoren sein - sonst ist die Größe falsch definiert
- Auf Sektor 63 und 485484299 muss sich ein NTFS-Bootrecord befinden (Beginnt mit 'EB 52 90 4E 54 46 53 20' ) - sonst ist die Plattenreihenfolge verkehrt.
Wenn das alles passt, weitermachen wie folgt:
- Öffnen des RAID0-Volumes im HxD ohne dem read-only Häckchen.
Es kann durch die Neudefinition des RAIDs der Sektor 256 überschrieben sein - steht dort noch am Offset(h) 0000020000-00000201F0
wenn nicht, musst Du diese 16 Zeilen mit Copy&paste in den Sektor 256 übertragen
und anschließend genauso den Inhalt des früher erzeugten Files hd501lj_raid0_mbr.bin in den Sektor 0 übertragen. Im HxD Menü mit File/Save schreibt er diese Änderungen auf das logische Raid-Volume auch drauf.
Nach einem Neustart sollte die Ordner/Filestruktur des RAID0 im Explorer wieder angezeigt werden.
Danach definierst Du den verbleibenden Rest auf den Memberplatten wieder als RAID1 und stellst den Inhalt des früher erzeugten Files hd501lj_raid1_mbr.bin in den Sektor 0 des RAID1 Volumes.
Damit sollten mal von den 500ern beide RAID0/RAID1 Arrays wieder im Zugriff sein...
Die benötigten Bereiche jeder der beiden 1TB Platten am GSATA(jMicron) Port2 mit HxD:
1.) Edit/Select Block: 0 – 7FF mit Edit/Copy as/Editor view übertragen
2.) im Sektoreingabefeld rechts oben Sektornummer 140000 eingeben, <Enter>, damit er die Anzeige dorthin positioniert.
Dann im Menü: Search/Find/Search for:
EB 52 90 4E 54 46 53 20
eingeben und als Datatype “hexvalues” auswählen und als Search direction: Backward.
Bei allen Sektoren, bei denen dieser Wert am Anfang des Sektors gefunden wurde, händisch den gesamten Sektor markieren und in den .txt File übertragen.
Mit F3 den Suchvorgang wiederholen, bis nichts mehr gefunden wird.
3.) im Sektoreingabefeld rechts oben Sektornummer 380633352 eingeben, <Enter>, damit er die Anzeige dorthin positioniert.
im Menü: Search/Find/Search for:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
eingeben und als Datatype “hexvalues” auswählen und als Search direction: Forward
Wenn dies in der letzten Zeile eines Sektors gefunden wurde,
diesen gesamten gefundenen Sektor und die drei darauffolgenden markieren und übertragen und mit dem nächsten Punkt fortsetzen, ansonsten mit F3 weitersuchen
4.) im Menü: Search/Find/Search for:
EB 52 90 4E 54 46 53 20
eingeben und als Datatype “hexvalues” auswählen und als Search direction: Forward
Beim ersten Sektor, bei dem dieser Wert am Anfang des Sektors gefunden wurde, händisch den gesamten Sektor markieren und in den .txt File übertragen.
5.) Edit:Select Block: E8E0DB5000 - E8E0DB5FFF
Die textfiles als 755.txt für hd103_1 oben und als 757.txt für hd103_2 unten benennen, zippen und hochladen.
Aus den Auszügen der 1TB Platten geht hervor, dass
- die Plattenreihenfolge auf der RAID-Matrix
Member 1: Serial=S13PJ1EQ310755 (hd103_1) =oben
Member 2: Serial=S13PJ1EQ310757 (hd103_2) =unten
so stimmt.
- am Raid0-Array der Größe von 363,00GB mit Stripesize 128KB
dieser Datenträger als ‚Basis’ initialisiert ist, der MBR intakt ist und sich dararauf eine primäre Partition der Größe 363,00MB liegt
- der RAID1-Array als ‚Basis’ initialisiert ist, der MBR intakt ist und sich dararauf zwei Primäre Partitions je 375.00GB befinden und auf LBA 380637448 beginnt.
Der RAID-1 Array ist in den RAID-Informationen nicht vorhanden, der RAID0-Eintrag hingegen ist intakt.
Vorgangsweise zur Wiederherstellung des vollen Zugriffs auf die 1TB-Platten:
1.) Zur Wiederherstellung dieser Matrix-Arrays sind die Daten der MBRs beider logischen Laufwerke zu sichern, indem von der HDD hd103_1 an Port2 des jMicron mit HxD die physical disk geöffnet wird wie bisher,
- der ganze Sektor 0 markiert wird (0 – 1FF), mit Strg+C in die Zwischenablage,
- im HxD Menü File/New, in diesen File mit Strg+V übertragen wird
(bei Popup Längenänderung: OK),
und danach mit File/Save as... unter dem Namen „hd103uj_raid0_mbr.bin“
in ein selbstgewähltes Verzeichnis abgespeichert wird.
- in gleicher Weise den Inhalt des Sektors 380637448 (2D60221000 - 2D602211FF)
in eine Datei unter dem Namen „hd103uj_raid1_mbr.bin“ sichern.
Diese beiden Dateien brauchen wir später zur Wiederherstellung des Zugriffes nach Entfernen der beiden Platten aus dem RAID-Verbund und Neudefinition des Arrays
2.) Die Platten an den ICH-Ports anschließen
an SATAII_5 Member 1: S13PJ1EQ310755 (hd103_1) =oben
an SATAII_6 Member 2: S13PJ1EQ310757 (hd103_2) =unten
3.) Den bisher noch existierenden RAID0 belassen und den Rest als RAID1 Bereich hd103uj_raid1 definieren
4.) Kontrolle: den logische RAID1-Volume hd103uj_raid1 mit HxD öffnen
- am Sektor 2048 muss sich der NTFS-Bootrec (beginnend mit EB 52 90 4E 54 46 53 20 ...) befinden
- wenn das zutrifft, sollte Sektor 0 (der MBR) kontrolliert werden. Ist dieser gelöscht, so muss der Inhalt der Datei „hd103uj_raid1_mbr.bin“ dorthin übertragen werden.
Nach Neustart sollten wieder beide Partitions des RAID1 erkannt und angesprochen werden können...
Nach "defekten Dateien" zu suchen ist eigentlich unnötig, da hier nur der Zugriff auf das Filesystem verloren ging. Daher sollten alle Daten darauf 100% so wie vorher sein. Eine Zerstörung durch überhastetes, unüberlegtes und falsches Recovery-Gefrickel fand ja hier nicht statt.
Da während der "Auszeit" auch nicht auf ein Einzelmember eines degraded RAID1 geschrieben wurde, müssen die Daten auf beiden Members auch noch synchron sein.
mit dem "Verify" werden nur die Inhalte der RAID1-Member verglichen und eventuelle Unterschiede bzw. HDD-Sektorfehler festgestellt. Welche bei fehlerfrei lesbarem, aber unterschiedlichem Inhalt die richtige Version eines Sektors ist, kann damit aber auch nicht festgestellt werden.
Die NTFS-Struktur kann man mit chkdsk auf Fehler überprüfen.
Durch Fremdeinwirkung veränderte Sektoren von Datencluster-Inhalten (wie man es mit HxD einfach erzielen kann) können durch nichts festgestellt werden, außer man hätte bereits z.B. MD5 checksums von den Dateien parat.
Solch ein Angegment und Hilfsbereitschaft muss belohnt werden. Du hast PN!
Was ich jetzt nun immernoch nicht ganz weis ist die ursache dieses ganzen problems.
1. Ist es nun der sachverhalt das der ich9r controller nur maximal 4 arrays verwalten kann und deshalb das 5. array einfach automatisch gelöscht hat ?
2 Oder lag es am Bios-Backup "Feature" des Gigabyte BIOS. Es ist ja bisher nicht zu 100% geklärt wann dieses "feature" automatisch genutzt wird.
Für zweiteres spricht das die hd103 ein HPA verpasst bekommen hat das 2113 Sektoren am ende der Festplatte beansprucht ( und somit die raid infos dieser einer Festplatte überschrieben hat?) . In dem fall würde ich allerdings nicht verstehen wieso der controller nach dem ersten neustart nix mehr von einem raid1 wusste obwohl ja die raid infos noch auf der 2. memberplatte vorhanden waren (welche benutzt wurden um das raid1 wieder in zugriff zu nehmen).
Sollte ich jetzt jede Festplatte mit einem HPA austatten damit ich vor weiteren gleichartigen Problemen gewappnet bin ?
ad 1) dachte ich eigentlich, dass die 500er noch an Port 3+4 und jetzt die 1000er zusätzlich an Port 5+6 hängen - derartige Konstellationen mit 3x2 Memberplatten funktionieren auch am ICH9R - allerdings kann ich nicht 100%ig sagen, ob das nicht nur 3x Raid0 waren. Probiere es einfach mal aus, wenn es jetzt wieder passieren sollte, ist das in 5min behoben. Das "Verschwinden" des RAID1 von den 1000ern kann nur entweder durch (unbeabsichtigtes) Löschen oder durch einen Fehler der RAID-Software zustande gekommen sein, da die von der Software geschriebenen Informationen nur mehr den RAID0 enthielten.
ad 2) ist die Zerstörung des 500er Arrays eindeutig auf das BIOS zurückzuführen. Allerdings habe ich noch keine Überlegungen angestellt, warum das überhaupt passiert ist. Normalerweise sollte ja jede RAID-Memberplatte vor diesem Unsinn des BIOS verschont bleiben, solange der ICH9R-Controllermode auf RAID gestellt bleibt. Im Falle, dass z.B. nach einem BIOS-Recovery vom Backup mit den default-Einstellungen hochgefahren worden wäre, hätte die erste verfügbare Platte - also vom System-Array am Port 1 - zum Handkuss kommen müssen. Du hast ja auch nichts davon berichtet, dass einmal die BIOS-Einstellungen zurückgesetzt wurden.
Nach den Analysedaten trugen die 500er(die vom anderen System kamen) allerdings RAID-Signaturdaten der Version 1.1.00, während die 1000er mit Version 1.0.00 am derzeitigen System erstellt worden sind. In einem solchen Fall kann sich die RAID-Controllersoftware natürlich nur durch Ablehnung der Memberplatten wehren, da sie keine Aufwärtskompatibilität besitzen kann. Über die ausgestoßene erste Memberplatte ist dann das BIOS hergefallen...
Wenn - wie unter 1) beschrieben, einmal durch bebsichtigtes oder unbeabsichtigtes Rücksetzen des Controllermodes auf non-RAID das BIOS sein schändliches Werk treibt, dann trifft es die Platte an Port1. Ohne einem Reservesystem auf einer weiteren Platte(z.B. auf der 1TB am jMicron) lässt sich nicht untersuchen, ob auf dieser Platte schon eine HPA drauf ist (was bei früherer Verwendung als non-RAID-Platte am Port1 der Fall sein müsste).
Somit ist ein Schutz der weiter hinten liegenden Platten nicht notwendig.
Für den Fall der Fälle sollte ein Reservesystem bereitstehen, und die MBR-Daten jedes logischen Volumes(neu erstellen bei Änderung der Partitionierung oder Laufwerksbuchstabenzuordnung!) und die genauen RAID-Konfigurationsdaten jedes Arrays dort abgespeichert sein. Daraus lässt sich jederzeit nach Neuanlegen des Arrays und zurückspielen des MBR auf Sektor 0 jedes logischen Volumes die Situation in wenigen Minuten beheben.
Ich glaub ich spinne. Was für einen Monster großen Bullshit hat da Gigabyte mit diesem BIOS feature fabriziert. Ich bin grad halb am kolabieren.
Ich habe nichts weiter gemacht als das Primary Boot Device von Hard Disk auf Cdrom gewechselt um kurz darauf die ubuntu live cd zu nutzen. Gparted geöffnet, nachgeschaut ob auf dem neugekauften stick was verstecktes drauf ist und zack beim neustart steht mein seagate raid0 auf failed.
Das kotzt mich vielleicht an. Ich hab null zeit für so einen Bullshit. Ich frage mich wieso ich mich ,VOR dem kauf des mainboards, tagelang informiert habe.
Tja, man muss hellsehender Experte sein, um derartige Ereignisse vorhersehen zu können.
Im Nachhinein kann ich dazu nur folgenden Erklärungsversuch abgeben:
Die Linux-Systeme haben die Eigenschaft, defaultmäßig an allen Platten die HPA's abzumontieren, d.h. die HDD auf max native Size zurückzusetzen.
Auf der Platte an Port1 - Member des System-RAID0's wird wohl eine solche draufgewesen sein und die RAID-Info durch die HPA daher 2113 Sektoren tieferliegend angelegt.
Verschwindet die HPA, findet der RAID-Controller seine Info nicht mehr, weil diese jetzt 2113 Sektoren zu tief liegt.
Eigentlich sollte das Problem behebbar sein durch
1. Rücksetzen des ICH9R Mode im BIOS von RAID auf disabled bei Angabe einer Bootdevice, wo kein System liegt (z.B. der einzelnen 1TB am jMicron). Damit sollte auf die Platte an Port1 wieder eine HPA geschrieben werden, bevor das Boot von dieser Platte einen Fehler bringt
2. Rückstellen der BIOS-Einstellung des ICH9R auf RAID - der Controller findet seine Infos auf der HDD am Port1 wieder.
Viel unglaublicher als das eigenliche Sicherheits Feature finde ich die , man muss ja schon fast sagen , ignorante Haltung im Gigabyte forum. Da hat nicht nur der Hersteller Gigabyte versagt, sonder auch der offizielle Support. Da sag ich nur 1A gelungen, so funktioniert Kundenbindung!
Ergänzung ()
Ernst@at schrieb:
Tja, man muss hellsehender Experte sein, um derartige Ereignisse vorhersehen zu können.
Im Nachhinein kann ich dazu nur folgenden Erklärungsversuch abgeben:
Die Linux-Systeme haben die Eigenschaft, defaultmäßig an allen Platten die HPA's abzumontieren, d.h. die HDD auf max native Size zurückzusetzen.
Auf der Platte an Port1 - Member des System-RAID0's wird wohl eine solche draufgewesen sein und die RAID-Info durch die HPA daher 2113 Sektoren tieferliegend angelegt.
Verschwindet die HPA, findet der RAID-Controller seine Info nicht mehr, weil diese jetzt 2113 Sektoren zu tief liegt.
Eigentlich sollte das Problem behebbar sein durch
1. Rücksetzen des ICH9R Mode im BIOS von RAID auf disabled bei Angabe einer Bootdevice, wo kein System liegt (z.B. der einzelnen 1TB am jMicron). Damit sollte auf die Platte an Port1 wieder eine HPA geschrieben werden, bevor das Boot von dieser Platte einen Fehler bringt
2. Rückstellen der BIOS-Einstellung des ICH9R auf RAID - der Controller findet seine Infos auf der HDD am Port1 wieder.
EDIT: Es kann nicht an ubuntu liegen . Ich habe bereits nachdem mir ein HPA mit bios backup auf die hd103 geschrieben wurde und somit das raid1 nichtmehr erkannt wurde nach ubuntu live gebootet, ohne danach weitere ausfälle zu haben.
-----------------------
Also das ist jetzt interessant, ich habe gestern nach dem mein seagate raid0 vom controller als failed erkannt wurde ( member 1 wurde als non raid disk ausgegeben) mehrmals neugestartet weil ich meinen augen kaum trauen konnte. Danach hab ich den PC ausgemacht, da ich nicht mehr den nerv für die Fehlerbehebung hatte.
Heute mache ich den PC an und das raid0 wird als status NORMAL erkannt. Ja WTF was ist mit dem controller los.
)
