So beheben Sie die Mac-Festplattenpartition, die als Fdsik_partition_scheme angezeigt wird

Meine Situation scheint sehr ähnlich wie GUID - Festplatte reparieren zu MBR beschädigt , aber mit genügend Unterschieden , dass ich nicht in der Lage gewesen , eine zuversichtlich Lösung zusammen.

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 sicher sagen, dass nie ein System installiert war, aber ich denke nicht. Es wurde nicht mit Bootcamp oder auf einem Nicht-Mac-Computer verwendet.

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

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

Hier sind die Informationen, die ich vom Laufwerk gesammelt habe.

diskutil list / 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 recovery / 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. Das EFI-TEIL beginnt bei 4096.

Ich fing an, nach der HFSJ-Zeichenfolge zu suchen, beginnend mit einem Versatz von 409642, wie in anderen Antworten vorgeschlagen, fand sie aber nicht in der Nähe. Also habe ich ab dem Beginn des Laufwerks gesucht und das erste Vorkommen bei Offset 314598400 gefunden.

Wenn ich jedoch weiter nach Vorkommen von HFSJ suche, finde ich viele davon, die genau gleich aussehen und viel Platz 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 Suche Alle suchen in wxHexEditor verwendet und nach einigen Minuten gestoppt. Zu diesem Zeitpunkt hatte es 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 unter Offset 3000592961536 finden. Dieser zeigt auch den Namen des Laufwerks "Rosie".

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

Vielen Dank für jede Hilfe.

— Doug Smith
quelle

Wenn es so aussieht, hatte Ihre Festplatte eine Blockgröße von 4096 Bytes und jetzt eine Größe von 512 Bytes. Da die Blockgröße nicht auf der Festplatte selbst gespeichert ist, würde meine Frage lauten: Haben Sie die Hardware in irgendeiner Weise geändert? Wenn die Blockgröße 4096 Byte betrug, sollten Sie in der Lage sein, die alten GPT-Tabelleneinträge ab 8192 Byte zu lesen. Bisher haben Sie nur den GPT-Header ab 4096 Byte veröffentlicht. Der Hex-Dump kann anhand der hier angegebenen Informationen wieder in die richtigen Dezimalwerte konvertiert werden .

— David Anderson

@ DavidAnderson, Die Hardware hat sich geändert, da sich das Laufwerk in einem anderen USB-Gehäuse befindet. Ich könnte den Originalfall bekommen, wenn das irgendetwas hilft.

— Doug Smith

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

— Doug Smith

@klanomath Ja, Ihre verknüpfte Antwort war korrekt. Ich habe Block und Offset verwechselt. Es sind jedoch alles Nullen um den Offset 209736704. Ich habe auch versucht, dies 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 durch Ihren Prozess begonnen. Mein Versuch, die ersten 40 Blöcke zu überschreiben, schrieb eigentlich keine Daten:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

— Doug Smith

Antworten:

Bitte versuche folgendes:

Rufen Sie die Festplattenkennung Ihres externen 3-TB-Laufwerks ab
```
diskutil list
```
Unten gehe ich davon aus, dass die Festplattenkennung disk6 ist
Hängen Sie die Festplatte aus:
```
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 Festplatteninformationen mit:
```
diskutil info /dev/disk6
```
Stellen Sie sicher, dass die Geräteblockgröße immer noch 512 Byte 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 Byte 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 Byte melden. Bitte hör hier auf und füge 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
```
Abhängig von der Größe der Festplatte und der Systemversion werden EFI-Volumes unterschiedlicher Größe erstellt, wenn sie mit dem Festplatten-Dienstprogramm partitioniert werden: entweder eines mit einer Größe von 200 MiB oder eines mit einer Größe von 300 MiB. Hier ist es offensichtlich, dass Ihre Festplatte einen EFI von 300 MiB und wahrscheinlich 4096 Byte nicht zugewiesenen Speicherplatz enthält: (314598400-1024) / 512 = 614448 (= Hauptvolume des Startblocks) 614448-40-8 = 614400 (= Größe des EFI)
Erstellen Sie Ihr Hauptvolumen neu mit:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Die Größe des Hauptvolumes kann durch den ersten (beschädigten und 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 gegebenenfalls, das Volume zu reparieren.
```
diskutil repairVolume disk6s2
```

Da Sie die "beschädigte" Festplatte in einen anderen Fall und Festplattencontroller verschoben haben, wurde die logische Blockgröße geändert. Die alte Partitionszuordnung 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

Erstellen Sie Ihr Hauptvolumen neu mit:

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

Die endgültige Partitionszuordnung sieht folgendermaßen 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 dieser nach der Installation der Festplatte in einem Fall mit logischer 512b-Blockgröße erneut übersetzt:

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

Erstellen Sie Ihr Hauptvolumen neu 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 der EFI tatsächlich "leer" ist und die nicht zugewiesenen Blöcke 262144 nur Nullen enthalten, hat die Antwort "Erste und irgendwie Falsche" keinen Einfluss auf die Funktionsfähigkeit des Volumes.

— Klanomath
quelle

Dies ist keine Antwort, sondern ein Beispiel dafür, wie die GPT-Partitionsinformationen aus den von Ihnen präsentierten Daten extrahiert werden. Die sekundären (Backup-) GPT-Partitionseinträge wurden verwendet, da Sie den Inhalt der primären GPT-Partitionseinträge nicht veröffentlicht haben. Das Dokument " GUID Partition Table " wurde zur Interpretation der Daten verwendet.

Der letzte verwendbare LBA befindet sich im GPT-Header. Dies geschieht unter der Adresse 8244. Der Wert ist

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

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

(732566640 + 1) * 4096 = 3000592961536 bytes.

Wenn ich dies als Start für den Eintrag in der EFI-Partitionstabelle verwende, erhalte ich die folgenden Werte. Start der EFI-Partition 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 befindet sich unter der Adresse 3000592961576

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

Welches gibt eine Partitionsgröße von

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

Start der HFS-Partition 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 befindet sich unter der Adresse 3000592961704

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

Welches gibt eine Partitionsgröße von

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

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

— David Anderson
quelle

+1 Wir erhalten eine identische Größe und einen identischen Startblock für den EFI und einen identischen Startblock, jedoch eine andere Größe des Hauptvolumes.

— Klanomath