Manuelles Editieren von GUID Partitionstabellen

[user1096]

Hallo !

Ich habe folgendes Problem mit einer 3 TiB großen GPT Disk. Das Laufwerk ist in 3 Partitionen unterteilt, angelegt mit WinServer2003 32-bit.
Nun beim Starten unter Windows 7 und einigen nicht mehr eindeutig nachzuvollhiehenden Operationen wird das gesamte Laufwerk nicht mehr als GPT-Disk erkannt.

Mit denn üblichen Verdächtigen läßt sich die Dateistruktur allerdings erkennen und ich hätte nun die Daten sichern und die Disk neu aufsetzen können - nach einigen Tagen Kopiererei.
Ich hab mir deshalb die GUiD-Partitionstabelle näher angesehen und falsche Partions-Typbezeicher und einige Zeiger entdeckt, die ins Nirwana zeigen - also nicht dramatisches. Mein Problem ist jetzt, die Korrekturen dieser Werte dem Betriebssystem schmackhaft zu machen.

So weit ich es sehe tauchen in der Partitionstabelle insgesamt zwei CRC32 Checksummen auf:
Die erste sichert wohl den Partionsheader und die zweite die Partitionseinträge.

Folgende Probleme ergeben sich jetzt für mich:

1) Gegen welche genauen Bytebereiche werden die CRC-Werte ermittelt?

2) Da die CRC-Berechnung sich nicht selbst als Argument verwenden kann, müßen die 4 Bytes, die jeweils dafür vorgesehen sind, irgendwie substituiert werden: Werden sie gestrichen, genullt oder was?

3) Sind die beiden Berechnungen nur konsekutiv durchzuführen? (Hängt natürlich direkt mit Frage 1 zusammen).

Ich dachte mir nun, statt zuerst 3TB weg- und dann dieselben 3TB wieder zurückzukopieren, wäre es möglcherweise ökonomischer, wenn ich die nicht mal 30 fehlerhaften Bytes korrigieren würde

Vielleicht hat ja jemand schon vor ähnlichen Fragen gestanden und Antworten gefunden oder selbst ermittelt. Meine Versuche mit verschiedenen Kombinatinen haben bisher nicht die richtigen Hashwerte ergeben.

Grüße erik

 

[enteon]

schon http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_.28LBA_1.29 gesehen?
und hier ein tool: http://blog.tpa.me.uk/2009/09/28/gdisk-fdisk-for-gpt/

 

[user1096]

Ja, danke. Gute Links, die ich auch schon gelesen hab.

Nur :
a) der Wikipedia Artikel ist nicht besonders spezifisch in seinen Aussagen, denn es wird bsw. nicht deutlich, ob die CRC-Berechnung über alle Partitionseinträge laufen muß (d.h. immer 128) oder nur über die tatsächlich benutzten.

b) gdisk ist im Prinzip ein Tool zum Partitionieren, d.h. ohne Rücksicht auf den Inhalt bereits existenter Partitionen. Der Vorteil bei diesem Tool ist allerdings , daß es freie Software ist, bei der der Sourcecode einsehbar ist. Ich müßte mir dann mal die verwendeten Routinen genauer ansehen um herauszufinden, wie die 4 CRC-Bytes berechnet werden, damit man das OS dahin bringt, sich die GPT überhaupt anzusehen.

Was ich, als notorischer "Minimalist", eigentlich suche wäre eine Aussage wei: Nehme die ersten 92-4 Bytes vom letzten LBA der Platte, dann die 512 Bytes vom vierunddreißigstvorletzten LBA, hashe beide Bereiche, trage die Werte in den Header ein und gut is.

Aber ich muß wohl doch noch etwas tiefer graben. Danke jedenfalls für Deine schnellen Hinweise.

Grüße
erik

 

[Ernst@at]

Mir ist eigentlich noch nicht untergekommen, dass GPT-Einträge "in den Wald" zeigen.
Die eigentlichen sind der Header auf LBA 1 und die PE's auf 2 bis 33 und deren Backup-Mirror auf maxLBA-1 sowie maxLBA-34 bis MaxLBA-2
Zeigt der Backup Pointer an eine LBA-Adresse, die zu groß ist, hat irgendwas die Platte verkleinert - per DCO oder HPA oder ein RAID-Controller den Array - und es ist nicht mehr die volle vom Hersteller vorgesehene Sektoranzahl verfügbar

 

[Mueli]

Schau mal - > http://technet.microsoft.com/en-us/library/cc739412(WS.10).aspx

 

[Ernst@at]

Ich bin mir nicht sicher, aber ich habe im testdisk-Source das Handling der GPT-Einträge schon mal gefunden. Vielleicht macht der beim "Write MBR" auch wieder die richtigen GPT-Einträge drauf, die CRC32-Berechnung hab ich jedenfalls gesehen(kann aber jetzt nicht sagen, ob das nur das Verify beim lesen war)...

 

[user1096]

Hallo !

Nein, mir ist schon klar, daß die Zeiger in der GPT-Definition klar definiert sind, was ich meinte war, daß bei dieser konkreten Disk völlig abstruse LBA-Werte in der Partitionstabelle standen. Das hatte mich ziemlich erstaunt, denn ich hatte zuerst nur Testdisk probehalber laufen lassen und das lieferte mir ruckzuck die korrekten Volumebezeichner, daher tippte ich anfangs nur auf falsche Partitonstypbezeichner.

(Es handelt sich in meinem Fall auch nicht um ein Software-Raid o.ä., sondern um einen stinknormalen Hardwarecontroller, der klaglos seinen Dienst versieht; d.h. um den/die Schuldigen an den fehlerhaften Einträgen auszumachen, brauche ich gar nicht so "tief stapeln".)

Wie der o.e. techNet-Artikel ja schön zeigt, ist die GPT-Disk nur ein aufgebohrtes MBR-Konstrukt, mit einigen gut duchdachten Features (wie die protective partition), viel Symmetrie, sowie einigen zusätzlichen Sicherungen und die beste Sicherung ist offensichtlich die, bei der keiner mehr Zugang erhält

 

[Ernst@at]

Wenn Du willst, mach nach der Anleitung MBR+GPT in diesem Post
eine Datei und stell sie hier rein. ein paar Posts später (#32,#34) dort siehst Du, wie eine Auswertung davon dann aussieht. Vielleicht interpretierst Du das nur falsch...
Welcher Raid-Controller ist das denn - ein AMD-Onboard oder ein Promise? Wie ich gehört habe, haben die ja die RaidXpert-Kacke für AMD geschrieben...