So reparieren Sie die Mac-Festplattenpartition, die als FDisk_partition_scheme angezeigt wird

Question

So reparieren Sie die Mac-Festplattenpartition, die als FDisk_partition_scheme angezeigt wird

Doug Smith

Meine Situation scheint sehr ähnlich zu sein, wie man eine GUID-Festplatte repariert, die in MBR beschädigt ist, aber mit genügend Unterschieden, dass ich keine zuverlässige Lösung zusammenstellen konnte.

Ich habe ein 3-TB-Toshiba-Laufwerk in einem USB-Gehäuse, das auf einem Mac mit OS X El Capitain 10.11.3 verwendet wird.

Das Laufwerk wurde mit einer einzelnen Partition eingerichtet. Das Laufwerk war nicht bootfähig und es war kein System installiert, daher gehe ich davon aus, dass es auch keine Wiederherstellungspartition haben würde. Ich kann nicht mit Sicherheit sagen, dass nie ein System installiert war, aber ich glaube nicht. Es wurde nicht mit Bootcamp oder auf einem Nicht-Mac-Computer verwendet.

Das Laufwerk hat lange Zeit normal funktioniert, wurde dann aber kürzlich nicht erkannt. Bei der Untersuchung mit dem Festplatten-Dienstprogramm wird angezeigt, dass es den Partitionstyp FDisk_partition_scheme hat . Ich bin mir sicher, dass es ursprünglich der typische Standard der GUID-Partitionstabelle war, die als OS X Extended (Journaled) formatiert war .

Ich kann mir keine bestimmte Verwendung oder ein bestimmtes Ereignis vorstellen, das die Änderung verursacht haben könnte.

Hier sind die Informationen, die ich von der Fahrt gesammelt habe.

Diskutil-Liste /dev/disk6

/dev/disk6 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *3.0 TB     disk6
   1:                       0xEE                         375.1 GB   disk6s1

Diskutil-Info /dev/disk6

   Device Identifier:        disk6
   Device Node:              /dev/disk6
   Whole:                    Yes
   Part of Whole:            disk6
   Device / Media Name:      DT01ABA300

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Content (IOContent):      FDisk_partition_scheme
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 USB
   SMART Status:             Not Supported

   Total Size:               3.0 TB (3000592982016 Bytes) (exactly 5860533168 512-Byte-Units)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          External
   Removable Media:          No

   Virtual:                  No
   OS 9 Drivers:             No
   Low Level Format:         Not supported

fdisk /dev/disk6

Disk: /dev/disk6    geometry: 97451/255/63 [1565565872 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -  732566645] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

gpt wiederherstellen /dev/disk6

gpt recover: /dev/disk6: no primary or secondary GPT headers, can't recover

gpt -r -vv show /dev/disk6

gpt show: /dev/disk6: mediasize=3000592982016; sectorsize=512; blocks=5860533168
gpt show: /dev/disk6: PMBR at sector 0
       start        size  index  contents
           0           1         PMBR
           1  5860533167

gdisk /dev/disk6

GPT fdisk (gdisk) version 1.0.1

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

Creating new GPT entries.

Hier ist ein Screenshot des ersten Teils des Laufwerks in wxHexEditor. Der EFI-TEIL beginnt bei 4096.

Ich begann mit der Suche nach der HFSJ-Zeichenfolge ab einem Offset von 409642, wie in anderen Antworten vorgeschlagen, fand sie aber nicht in der Nähe. Also suchte ich ab dem Anfang des Laufwerks und fand das erste Vorkommen bei Offset 314598400.

Wenn ich jedoch weiter nach Vorkommen von HFSJ suche, finde ich viele von ihnen, die genau gleich aussehen und viel Nullraum um sie herum haben, wie das erste. Diese beginnen bei 360424448 und haben einen Abstand von 32768. Zum Beispiel bei Offsets 360424448 360457216 360489984 360522752 360555520

Ich habe die Find All -Suche in wxHexEditor verwendet und nach ein paar Minuten abgebrochen. Es hatte zu diesem Zeitpunkt ein paar Tausend gefunden. Ich bin mir nicht sicher, was ich davon halten soll, wenn überhaupt.

Ich konnte auch einen Abschnitt mit der Bezeichnung EFI-Systempartition bei Offset 3000592961536 finden. Das zeigt auch den Namen, den das Laufwerk hatte, "Rosie".

Hier sind Screenshots der ersten HFSJ-Partition und der EFI-Systempartition. Basierend auf den Kommentaren wurde ein Screenshot von Offset 8192 hinzugefügt.

Danke für jede Hilfe.

David Anderson

Wenn angezeigt wird, dass Ihre Festplatte eine Blockgröße von 4096 Bytes hatte und jetzt eine Größe von 512 Bytes hat. Da die Blockgröße nicht auf der Festplatte selbst gespeichert ist, wäre meine Frage: Haben Sie die Hardware in irgendeiner Weise geändert? Wenn die Blockgröße 4096 Bytes betrug, sollten Sie außerdem in der Lage sein, die alten GPT-Tabelleneinträge ab 8192 Bytes zu lesen. Bisher haben Sie nur den GPT-Header ab 4096 Bytes gepostet. Der Hex-Dump kann mit den hier angegebenen Informationen wieder in die korrekten Dezimalwerte umgewandelt werden .

Doug Smith

@DavidAnderson, Die Hardware hat sich dahingehend geändert, dass sich das Laufwerk in einem anderen USB-Gehäuse befindet. Ich könnte das Originalgehäuse bekommen, wenn das etwas hilft.

Doug Smith

@DavidAnderson Ich habe den Screenshot geändert, um einen für Offset 8192 hinzuzufügen. Dort wird eine EFI-Systempartition angezeigt .

Doug Smith

@klanomath Ja, Ihre verknüpfte Antwort war richtig. Ich habe Block und Offset verwechselt. Es sind jedoch nur Nullen um Offset 209736704 herum. Ich habe auch versucht, das durch 8 (26217088) zu teilen, falls es ein Problem mit einer Blockgröße von 4096 gab. Das bringt mich in eine Menge Daten, aber keine HFSJ-Zeichenfolge in Sicht.

Doug Smith

@klanomath, ich hatte Ihren Prozess durchlaufen. Mein Versuch, die ersten 40 Blöcke zu überschreiben, hat eigentlich keine Daten geschrieben:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

Doug Smith

@klanomath, mein Laufwerk ist gemountet und funktioniert. Die erste Vermutung zum Wiederaufbau des Hauptvolumens war richtig. Ein großes Dankeschön an Sie und David, dass Sie mit solch detaillierter Analyse und Beratung alles getan haben!

Doug Smith

verifyVolume hat einen Fehler angezeigt, den repairVolume beheben konnte. (Entschuldigung, ich habe den Fehlertext nicht gespeichert.)

Antworten (3)

So reparieren Sie die Mac-Festplattenpartition, die als FDisk_partition_scheme angezeigt wird

Wenn angezeigt wird, dass Ihre Festplatte eine Blockgröße von 4096 Bytes hatte und jetzt eine Größe von 512 Bytes hat. Da die Blockgröße nicht auf der Festplatte selbst gespeichert ist, wäre meine Frage: Haben Sie die Hardware in irgendeiner Weise geändert? Wenn die Blockgröße 4096 Bytes betrug, sollten Sie außerdem in der Lage sein, die alten GPT-Tabelleneinträge ab 8192 Bytes zu lesen. Bisher haben Sie nur den GPT-Header ab 4096 Bytes gepostet. Der Hex-Dump kann mit den hier angegebenen Informationen wieder in die korrekten Dezimalwerte umgewandelt werden .
@DavidAnderson, Die Hardware hat sich dahingehend geändert, dass sich das Laufwerk in einem anderen USB-Gehäuse befindet. Ich könnte das Originalgehäuse bekommen, wenn das etwas hilft.
@DavidAnderson Ich habe den Screenshot geändert, um einen für Offset 8192 hinzuzufügen. Dort wird eine EFI-Systempartition angezeigt .
@klanomath Ja, Ihre verknüpfte Antwort war richtig. Ich habe Block und Offset verwechselt. Es sind jedoch nur Nullen um Offset 209736704 herum. Ich habe auch versucht, das durch 8 (26217088) zu teilen, falls es ein Problem mit einer Blockgröße von 4096 gab. Das bringt mich in eine Menge Daten, aber keine HFSJ-Zeichenfolge in Sicht.
@klanomath, ich hatte Ihren Prozess durchlaufen. Mein Versuch, die ersten 40 Blöcke zu überschreiben, hat eigentlich keine Daten geschrieben:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)
@klanomath, mein Laufwerk ist gemountet und funktioniert. Die erste Vermutung zum Wiederaufbau des Hauptvolumens war richtig. Ein großes Dankeschön an Sie und David, dass Sie mit solch detaillierter Analyse und Beratung alles getan haben!
verifyVolume hat einen Fehler angezeigt, den repairVolume beheben konnte. (Entschuldigung, ich habe den Fehlertext nicht gespeichert.)

klanomath · Answer 1

Bitte versuche folgendes:

Rufen Sie die Datenträgerkennung Ihres externen 3-TB-Laufwerks ab
```
diskutil list
```
Unten nehme ich an, dass die Festplattenkennung disk6 ist
Unmounten Sie die Festplatte:
```
diskutil umountDisk disk6
```

Überschreiben Sie die ersten 40 Blöcke:

sudo dd if=/dev/zero of=/dev/disk6 bs=512 count=40

Erstellen Sie ein neues gpt:
```
sudo gpt create /dev/disk6
```
Überprüfen Sie die Datenträgerinformationen mit:
```
diskutil info /dev/disk6
```
Versichern Sie sich, dass die Blockgröße des Geräts immer noch 512 Bytes beträgt

Sie können auch verwenden
```
sudo gpt -r show /dev/disk6
```
Wenn das gpt zeigt:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table
```
Sie haben eine Festplatte und einen Festplattencontroller, die eine logische Blockgröße von 512 Bytes melden. Bitte fahren Sie mit dem nächsten Schritt fort.

Wenn das gpt zeigt:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table
```
Sie haben eine Festplatte und einen Festplattencontroller, die eine logische Blockgröße von 4096 Bytes melden. Bitte halten Sie hier an und fügen Sie einen Kommentar hinzu.
Erstellen Sie zuerst den EFI-Eintrag neu mit:
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
Je nach Plattengröße und Systemversion werden bei der Partitionierung mit dem Festplatten-Dienstprogramm unterschiedlich große EFI-Volumes erstellt: entweder eines mit der Größe 200 MiB oder eines mit 300 MiB. Hier ist offensichtlich, dass Ihre Festplatte ein 300-MiB-EFI und wahrscheinlich 4096 Byte nicht zugeordneten Speicherplatz enthält: (314598400-1024)/512=614448 (=Startblock-Hauptvolume) 614448-40-8=614400 (=Größe von EFI)
Bauen Sie Ihr Hauptvolumen neu auf mit:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Die Größe des Hauptvolumens kann durch den ersten (beschädigten & alten) Eintrag der zweiten GPT-Tabelle bestimmt werden: (3000592961536/512)=5860533128 ist seine Blocknummer. Dann wird die Größe durch 5860533128-614448=5859918680 Blöcke berechnet. Da 5859918680 durch 8 teilbar ist (4096 physische Blockgröße/512 logische Blockgröße), ist dies eine gute Schätzung für die Volume-Größe.

Die beste Vermutung ist schließlich:
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Die zweitbeste Vermutung ist:
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Wahrscheinlich wird Ihr verlorenes Volume jetzt gemountet. Überprüfen Sie die Lautstärke mit:
```
diskutil verifyVolume disk6s2
```
Versuchen Sie ggf., das Volume zu reparieren.
```
diskutil repairVolume disk6s2
```

Da Sie die "beschädigte" Festplatte in ein anderes Gehäuse und einen anderen Festplattencontroller verschoben haben, wurde die logische Blockgröße geändert. Die alte Partitionstabelle basiert wahrscheinlich auf einer logischen Blockgröße von 4096 Bytes.

Um die Partitionszuordnung im alten Fall (4096b) wiederherzustellen, müssten Sie Folgendes eingeben, um die GPT wiederherzustellen (basierend auf der Antwort von David Anderson):

Erstellen Sie ein neues gpt:
```
sudo gpt create /dev/disk6
```

Erstellen Sie zuerst den EFI-Eintrag neu mit:

sudo gpt add -b 6 -i 1 -s 76800 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6

Bauen Sie Ihr Hauptvolumen neu auf mit:

sudo gpt add -b 76806 -i 2 -s 732457067 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6

Die endgültige Partitionstabelle sieht so aus:

 sudo gpt -r show disk1
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2           4         Pri GPT table
           6       76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
       76806   732457067      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   732533873       32768         
   732566641           4         Sec GPT table
   732566645           1         Sec GPT header

Basierend auf dem 4096b-Teil wird dies nach der Installation der Festplatte in einem Fall mit einer logischen Blockgröße von 512b "zurückübersetzt" zu:

Erstellen Sie ein neues gpt:
```
sudo gpt create /dev/disk6
```

Erstellen Sie zuerst den EFI-Eintrag neu mit:

sudo gpt add -b 48 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6

Bauen Sie Ihr Hauptvolumen neu auf mit:

sudo gpt add -b 614448 -i 2 -s 5859656536 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6

Dies unterscheidet sich vom ersten (akzeptierten) Teil meiner Antwort, ist aber der richtige! Da die EFI tatsächlich "leer" ist und die 262144 nicht zugeordneten Blöcke nur Nullen enthalten, hat die "erste und irgendwie falsche" Antwort keinen Einfluss auf die Funktionsfähigkeit des Volumes.

David Anderson · Answer 2

Dies ist keine Antwort, sondern ein Beispiel dafür, wie Sie die GPT-Partitionsinformationen aus den von Ihnen präsentierten Daten extrahieren können. Die sekundären (Sicherungs-) GPT-Partitionseinträge wurden verwendet, da Sie die Inhalte der primären GPT-Partitionseinträge nicht gepostet haben. Zur Interpretation der Daten wurde das Dokument „ GUID Partition Table “ verwendet.

Die letzte verwendbare LBA ist im GPT-Header zu finden. Dies geschieht bei Adresse 8244. Der Wert ist

70 14 aa 2b 00 00 00 00 little endian = 0x2baa1470 = 732566640 @ 4096 bytes/block.

Der Beginn der sekundären (Sicherungs-)GPT-Einträge beginnt beim nächsten Block. Der Wert ist

(732566640 + 1) * 4096 = 3000592961536 bytes.

Wenn ich dies als Anfang des EFI-Partitionstabelleneintrags verwende, erhalte ich die folgenden Werte. Beginn der EFI-Partition, gefunden unter der Adresse 3000592961568, ist

06 00 00 00 00 00 00 00 little endian = 0x6 = 6 @ 4096 bytes/block.

Das Ende der EFI-Partition, gefunden unter der Adresse 3000592961576, ist

05 2c 01 00 00 00 00 00 little endian = 0x12c05 = 76805 @ 4096 bytes/block.

Das ergibt eine Partitionsgröße von

76805 - 6 + 1 = 76800 @ 4096 bytes/block.

Beginn der HFS-Partition, gefunden unter der Adresse 3000592961696, ist

06 2c 01 00 00 00 00 00 little endian = 0x12c06 = 76806 @ 4096 bytes/block.

Das Ende der HFS-Partition, gefunden unter der Adresse 3000592961704, ist

70 94 a9 2b 00 00 00 00 little endian = 0x2ba99470 = 732533872 @ 4096 bytes/block.

Das ergibt eine Partitionsgröße von

732533872 - 76806 + 1 = 732457067 @ 4096 bytes / block.

Wenn Sie eine Blockgröße von 512 Bytes verwenden, müssen die obigen Ergebnisse mit einem Wert von 8 multipliziert werden, um in 512 Bytes/Block umzuwandeln.

+1 Wir erhalten eine identische Größe und einen identischen Startblock für das EFI und einen identischen Startblock, aber eine andere Größe des Hauptvolumens.

Becker · Answer 3

Hast du es am Ende zurückbekommen?? Ich habe das gleiche, nachdem ich versucht habe, mit MacDrive einige große Dateien über USB auf eine Win10 zu ziehen, ist es eingefroren und ich hatte meine vertrauenswürdige Mac-Festplatte, die genau wie Ihre mit der 0xEE-Partition geschlagen wurde

UPDATE: Ich habe mein Problem mit einfacheren Schritten behoben. Es gibt ein testDisk-Tool, das den Start-, Endpunkt und die Größe der Partitionen auf der Festplatte auflistet, dann erlaubte mir die pdisk (die c-Option), diese Daten einzugeben, und plötzlich konnte ich meine HD lesen ganz wie vorher bekomme ich eine Warnung aber alle Daten sind wieder da

Ja, ich habe es zurückbekommen und ich bin froh zu hören, dass du es auch getan hast. Vielen Dank für die Dokumentation Ihrer einfacheren Schritte.

So reparieren Sie die Mac-Festplattenpartition, die als FDisk_partition_scheme angezeigt wird

Doug Smith

David Anderson

Doug Smith

Doug Smith

Doug Smith

Doug Smith

Doug Smith

Doug Smith

Antworten (3)

klanomath

David Anderson

klanomath

Becker

Doug Smith

Das Festplatten-Dienstprogramm auf Mavericks schlägt fehl, weil „die Festplatte zu klein ist“

APFS kann nicht erweitert werden, nachdem die alte Partition als freier Speicherplatz gelöscht wurde [duplizieren]

Kann disk0-Ressource ausgelastet nicht unmounten

Wie repariere ich ein beschädigtes USB-Laufwerk unter OS X?

Warum formatiert meine 3 TB Seagate HD immer wieder als Logical Volume Group?

Yosemite Disk Utility: Sie können dieses Volume nur in zwei Teile aufteilen

Das Festplattendienstprogramm lässt mich keine Partitionen erstellen oder deren Größe ändern

Wie kann ich eine Partition (logisches CoreStorage-Volume?) aus dem Terminal löschen?

Corestorage-Fehler: Festplatte fehlt, wie werden Daten wiederhergestellt?

Partition kann nicht gelöscht werden