Author Topic: [DE] Was stimmt da nicht? 3TB Platten werden nicht mehr gemountet (Read 18434 times)

ralul · « **Reply #30 on:** 2012/01/16, 19:24:32 »

Bei GPT sind die Partitionsdaten hinten auf der Platte nomal geclont (weswegen mit GPT keine Partition bis zum hinteren Anschlag es schafft). Mit gfdisk gibt es einen Expertenmodus, mit dem man diesen hinteren Clone der Partitionsdaten vorne wieder reinschreiben kann.

Viele machen sich die GPT Eintragungen mit grub ins MBR kaputt. Grub ins MBR geht nicht (oder besser gesagt: überschreibt), weil eben GPT mehr Partitionsdatenplatz braucht als die alte MBR Partitionierung. Das ist auch der Grund warum man mit GPT unendlich viele Partitionen auf unendlich großen Platten packen kann.

Da grub ins MBR nicht geht bei GPT, und es nicht zukunftsicher ist mit --force in eine /root Partition zu schreiben (es könnten Optimierer kommen, die Daten umsortieren), bietet sich eine /efi oder /boot Partition an zu nehmen.

unklarer · « **Reply #31 on:** 2012/01/16, 19:26:00 »

Quote from: "Lanzi"

ob Testdisk gpt kann ist natürlich eine interessante Frage...

mußt aber ab einer bestimmten Version achten:
http://www.cgsecurity.org/wiki/Gegenw%C3%A4rtige_Einschr%C3%A4nkungen

Warum wollt Ihr aber testdisk benutzen, wenn er http://www.rodsbooks.com/gdisk/repairing.html

(hier von Euch gepostet) angibt, das auch zu können?

Das kann ich besser lesen/verstehen (gebe ich ja zu :wink: )

Quote

Die sekundäre GPT am Ende des Datenträgers ist eine Kopie der primären GPT am Anfang des Datenträgers. Durch diese Redundanz kann im Fehlerfall die Partitionstabelle wiederhergestellt werden. Da in der GPT eine Prüfsumme eingetragen wird, kann festgestellt werden, welche der beiden GPT konsistent ist.

http://de.wikipedia.org/wiki/GUID_Partition_Table

Edit: ralul war schneller.

devil · « **Reply #32 on:** 2012/01/16, 19:43:51 »

Wäre interessant, zu sehen ob es geht. (bei beiden).

greetz
devil

Lanzi · « **Reply #33 on:** 2012/01/17, 16:31:27 »

So, mal sehen, wer sich mit mir traut...

Also, die bestellte festplatte braucht wohl noch ein paar Tage und da ich in Zeitnot bin, muss ich was riskieren...

Also, ich werde die folgenden Versuche an der Backup-Datendisk vornehmen (gehen ja beide nicht - identische Fehler):

Starten von gdisk:

Quote

GPT fdisk (gdisk) version 0.8.1

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Also ist wohl der Backup-header defekt... Aber warum wird dann die Disk nicht erkannt, wenn es nur der Backup-header ist?

Als nächstes habe ich den Main-Header mit der Option b gespeichert.

Jetzt habe ich ein disk-verify durchgeführt:

Quote

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 5860531055 sectors, needs to be 5860533168 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: partition 1 is too big for the disk.

Identified 4 problems!

Es wird ja auf http://www.rodsbooks.com/gdisk/repairing.html gewarnt, dass der Bericht etwas negativ ausfallen kann...
Allerdings bin ich jetzt am zweifeln, was ich tun soll...

die folgenden Optionen stehen zur Verfügung:

Quote

Recovery/transformation command (? for help): ?
b use backup GPT header (rebuilding main)
c load backup partition table from disk (rebuilding main)
d use main GPT header (rebuilding backup)
e load main partition table from disk (rebuilding backup)
uvm...

Wenn jemand fit ist, bitte ich um einen Tipp...

Edit: da ich normal nach dem start von gdisk mit der Partition arbeiten kann (Semi-Automated Recovery) und er den gpt selbst wählt und die Daten richtig angezeigt werden, könnte vielleicht ein einfaches w (write) schon reichen???

ralul · « **Reply #34 on:** 2012/01/17, 17:39:33 »

Du musst irgendwie wissen welche Partitionierungsdaten plausibel sind und dann alles schreiben und harmonisieren. Wenn du die Plausibilität nicht weisst, wird es schwierig
wenn du:
- zwischendurch was mit anderen Tools gemacht hast
- mit anderen Tools eine zu lange Partitions bis ans Ende geschrieben hast, so dass der GPT-Backup-Header manipuliert worden ist.
- mit gfdisk was gemacht hast, was den GPT-Backup-Header manipuliert hat.
- mit falschen Partitionsdaten etwas formatiert hast.

Ich glaube nicht, dass (mbr)-fdisk von sich aus in den GPT-Backup-Header schreibt, weil dieser Header dem fdisk unbekannt ist, denn solcherart Backup gab es nicht mit MBR. Ich habe den langen Thread nicht mehr im Kopf, weiss also nicht auf welchem Stand dein Platte ist ...

Es nützt natürlich nichts, wenn du im Expertenmodus den Backup-Header holst, aber nicht mit write das Programm gdisk aufhörst, dann war es für die Katz temporär ...

Lanzi · « **Reply #35 on:** 2012/01/17, 17:42:02 »

Hi ralul,
ich habe im Grunde garnichts mit den Platten gemacht. Davon gehe ich immer noch aus. Was ich mir denken könnte, dass bei der Installation von siduction grub auf die platte zugegriffen hat und versucht hat einen mbr zu schreiben.

- sonst hatte ich weder mit fdisk noch mit gdsik bisher Zugriff...
- Partitionen wurden nicht geschrieben

ralul · « **Reply #36 on:** 2012/01/17, 17:44:04 »

... Wenn du mit der siduction Installation einen grub ins MBR geschrieben hast, ist die Vorne-GPT-Partitionierung überschrieben.

Wenn der Backup-Header in Ordnung ist kannst ihn schreiben ... und danach nochmal gdisk starten und verify

ralul · « **Reply #37 on:** 2012/01/17, 17:53:55 »

Meiner Ansicht nach, wenn die Partiton den richtigen Anfang hat:
- macht es nicht mal etwas, wenn die Partition länger ist als (mit ext4) formatiert
- wenn die Partition kürzer ist, weiss ich nicht wie der Kernel reagiert

Lanzi · « **Reply #38 on:** 2012/01/17, 18:23:52 »

Ja, das ist meine vermutung...
AAAAber: die erste Meldung von gdisk ist:

Quote

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Das widerspricht ja meiner Vermutung.
Jetzt ist die Frage, ob die Fehlermeldung nicht einfach falsch ist. Denn, wenn der Backup-header wirklich defekt ist, müsste die Disk doch trotzdem laufen...

vlt. sollte ich doch erst ein clon erstellen...

unklarer · « **Reply #39 on:** 2012/01/17, 18:53:53 »

Ähm, ich habe keine Ahnung von dem gfdisk-Teil und verstehe bestimmt auch nicht mal die Hälfte...

Diese Warnung erhälst Du doch durch Aufruf von v, was die erste Ebene ist.

Wir sind uns einig, dass das Ding repariert werden muß. Wäre es dann von der Logik her nicht r und dann v in der Zweiten, um vielleicht noch mehr Ifo zu bekommen?

ralul · « **Reply #40 on:** 2012/01/17, 18:57:04 »

ühh, das hört sich ja wie ein Bug von gdisk an, allerdings nur wenn alles stimmt, was Du vorher gesagt hast!
Du kannst mit dem Progi dd allerdings doch noch an den Backup-Header rankommen und dann per Expertenmenu c einspielen.

Lanzi · « **Reply #41 on:** 2012/01/18, 07:17:54 »

Zwischenfrage: wie kopiere ich den gpt und den Backup-gpt mit dd?
Finde im web irgendwie nichts genaues?

ralul · « **Reply #42 on:** 2012/01/18, 13:21:13 »

man dd
ist aber kompliziert

Lanzi, sag mal:
Du hattest nur eine riesige Partition drauf auf der Platte?

Dann kannst du doch mit Plausibilität vorgehen:
- richte dir in der /etc/fstab einen "noauto,ro 0 0" Eintrag für die Platte ein.
- gdisk partitioniere die Platte neu mit einer riesigen Partition. Wenn die Partition größer als vorher formatiert ist, macht das nichts.

Wenn du den Anfang richtig triffst sollten keinen Daten verloren gehen, und du siehst mit dem root Befehl
mount /media/meine_Platte
alle Daten. Vielleicht musst du die Partitionierungsdaten,die der Kernel sieht synchroniesieren, oder einfach neu booten vorher.

Plausibilität:
2048 ist eine gute Norm für ein Anfangsdatum unter Linux, das war auch auf einer Ausgabe von dir hier im Forum.
40 ist der Anfang der ersten Partition meines Apple Mini

Du kannst beides probieren, denn wenn du nur "noauto,ro" mit "0 0" hinten in der /etc/fstab einträgst wird nichts verändert an Daten. Partitionierung ändert nichts an Daten per se!

Lanzi · « **Reply #43 on:** 2012/01/18, 22:06:12 »

Ralul: Ja, es ist nur eine große Partition.
Dein Tipp klingt gut. Morgen kommt hoffentlich meine Ersatzplatte, die ich dann erst clonen muss. (Habe versucht eine der beschädigten Platten auf eine 3 Tbyte USB-Platte zu clonen, das ist aber jedesmal schief gegangen (Eingabe/ Ausgabefehler, 384 Mbyte wurden kopiert).
Frag nicht warum...

Also, bis morgen, oder realistisch Freitag bin ich hier im Standby (mein Zeitdruck hat sich etwas entschärft, weil eine wichtige Datei mittlerweile noch von mir auf dem Notebook gefunden wurde).

Also, erstmal danke an alle bis hierhin... ich melde mich, sowie es Änderungen und Neuigkeiten gibt...

Lanzi · « **Reply #44 on:** 2012/01/20, 09:17:33 »

So, habe mit dd die komplette Platte kopiert, allerdings kam nach vielen Stunden die Meldung eines Eingabe/AUsgabe Fehlers:

xxxxxxx+1 Datensätze wurden gelesen
xxxxxxx+0 Datensätze wurden geschrieben

3Tbyte an Daten kopiert, Zeit rund 34000s

Die Meldung ist jetzt nur zusammengefasst, weil ich an einem anderen Computer kopiert habe.

Fakt ist, dass die neue kopierte Platte im Anschluss keinen (!) gpt und auch keinen Backupgpt-Eintrag hat, die ich ja gerade so reparieren wollte.... Ahhh, Frust!

Woran liegt das denn jetzt?

Also habe ich als kurzen Versuch mit gdisk o einen neuen Gpt erstellt und beim schreiben mit w meldet er einen nicht näher definierten Error!
Auf dieser neuen Platte lässt sich also auch kein neuer gpt erzeugen.

Ich schau gerade nach der versteckten Kamera... finde aber keine ;-)
Ideen?