Jak naprawić partycję dysku twardego Maca wyświetlaną jako Fdsik_partition_scheme

Moja sytuacja wydaje się bardzo podobna do tego, jak naprawić uszkodzony dysk twardy GUID do MBR, ale z wystarczającymi różnicami, że nie byłem w stanie stworzyć pewnego rozwiązania.

Mam dysk Toshiba 3 TB w obudowie USB, który jest używany na komputerze Mac z systemem OS X El Capitain 10.11.3.

Dysk został skonfigurowany z jedną partycją. Dysk nie był bootowalny i nie miał zainstalowanego systemu, więc zakładam, że nie będzie miał partycji odzyskiwania. Nie mogę powiedzieć na pewno, że nigdy nie miał zainstalowanego systemu, ale nie sądzę. Nie był używany z Bootcamp ani na żadnym innym komputerze niż Mac.

Dysk działał normalnie przez długi czas, ale ostatnio nie został rozpoznany. Podczas sprawdzania za pomocą Narzędzia dyskowego pokazuje, że ma typ partycji FDisk_partition_scheme . Jestem pewien, że pierwotnie była to typowa domyślna mapa partycji GUID sformatowana jako OS X Extended (Journaled) .

Nie mogę wymyślić żadnego konkretnego zastosowania ani zdarzenia, które mogło spowodować zmianę.

Oto informacje, które zebrałem z dysku.

lista diskutil / 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.

Oto zrzut ekranu pierwszej części dysku w wxHexEditor. PART EFI zaczyna się od 4096.

Zacząłem szukać ciągu HFSJ, zaczynając od przesunięcia 409642, jak sugerowano w innych odpowiedziach, ale nie znalazłem go w pobliżu. Szukałem więc od początku dysku i znalazłem pierwsze wystąpienie z przesunięciem 314598400.

Jeśli jednak nadal szukam wystąpień HFSJ, znajduję wiele z nich, które wyglądają dokładnie tak samo i mają dużo zerowego miejsca wokół nich, jak pierwszy. Te zaczynają się od 360424448 i są oddalone od siebie o 32768. Na przykład w odsunięciach 360424448 360457216 360489984 360522752 360555520

Użyłem wyszukiwania Znajdź wszystko w wxHexEditor i zatrzymałem się po kilku minutach. W tym momencie znalazł kilka tysięcy. Nie jestem pewien, co z nimi zrobić, jeśli w ogóle.

Udało mi się również znaleźć sekcję o nazwie Partycja systemowa EFI z przesunięciem 3000592961536. Pokazuje ona także nazwę napędu, „Rosie”.

Oto zrzuty ekranu z pierwszej partycji HFSJ i partycji systemowej EFI. Dodano zrzut ekranu przesunięcia 8192 na podstawie komentarzy.

Dziękuję za wszelką pomoc.

hard-drive el-capitan disk-utility partition diskutil Doug Smith
źródło

Gdyby się pojawił, twój dysk miał rozmiar bloku 4096 bajtów, a teraz ma rozmiar 512 bajtów. Ponieważ rozmiar bloku nie jest przechowywany na samym dysku, moje pytanie brzmiałoby: czy zmieniłeś sprzęt w jakikolwiek sposób? Ponadto, jeśli rozmiar bloku wynosił 4096 bajtów, powinieneś być w stanie odczytać stare wpisy tabeli GPT, zaczynając od 8192 bajtów. Do tej pory opublikowałeś tylko nagłówek GPT, zaczynając od 4096 bajtów. Zrzut szesnastkowy można przekonwertować z powrotem na prawidłowe wartości dziesiętne, korzystając z informacji podanych tutaj .

David Anderson

@DavidAnderson, Sprzęt zmienił się, ponieważ dysk znajduje się w innej obudowie USB. Mogłabym dostać oryginalną skrzynkę, jeśli to cokolwiek pomoże.

Doug Smith,

@DavidAnderson Zmieniłem zrzut ekranu, aby dodać jeden dla przesunięcia 8192. Pokazuje tam partycję systemową EFI .

Doug Smith,

@klanomath Tak, Twoja linkowana odpowiedź była poprawna. Pomieszałem blok i przesunięcie. Jednak wszystkie zera wokół przesunięcia 209736704. Próbowałem także podzielić to przez 8 (26217088) w przypadku problemu o rozmiarze bloku 4096. To umieszcza mnie w wielu danych, ale nie widać ciągu HFSJ.

Doug Smith,

@klanomath, zacząłem od twojego procesu. Moja próba zastąpienia pierwszych 40 bloków w rzeczywistości nie zapisała żadnych danych:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

Doug Smith,

Odpowiedzi:

Spróbuj wykonać następujące czynności:

Uzyskaj identyfikator dysku zewnętrznego dysku 3 TB
```
diskutil list
```
Poniżej zakładam, że identyfikator dysku to disk6
odmontuj dysk:
```
diskutil umountDisk disk6
```

Zastąp pierwsze 40 bloków:

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

Utwórz nowy gpt:
```
sudo gpt create /dev/disk6
```
Sprawdź informacje o dysku za pomocą:
```
diskutil info /dev/disk6
```
Upewnij się, że rozmiar bloku urządzenia nadal wynosi 512 bajtów

Możesz także użyć
```
sudo gpt -r show /dev/disk6
```
Jeśli gpt pokazuje:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table
```
masz dysk i kontroler dysku, który zgłasza logiczny rozmiar bloku 512 bajtów. Proszę przejść do następnego kroku.

Jeśli gpt pokazuje:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table
```
masz dysk i kontroler dysku, który zgłasza logiczny rozmiar bloku 4096 bajtów. Zatrzymaj się tutaj i dodaj komentarz.
Najpierw odbuduj wpis EFI za pomocą:
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
W zależności od wielkości dysku i wersji systemu woluminy EFI o różnej wielkości są budowane, jeśli są partycjonowane za pomocą Narzędzia dyskowego: albo o rozmiarze 200 MiB, albo o 300 MiB. Tutaj jest oczywiste, że twój dysk zawiera 300 MiB EFI i prawdopodobnie 4096 bajtów nieprzydzielonego miejsca na dysku: (314598400-1024) / 512 = 614448 (= Rozpocznij główny wolumin bloku) 614448-40-8 = 614400 (= rozmiar EFI)
Odbuduj główny wolumin za pomocą:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Rozmiar głównego woluminu można określić na podstawie pierwszego (uszkodzonego i starego) wpisu drugiej tabeli GPT: (3000592961536/512) = 5860533128 to numer bloku. Następnie rozmiar jest obliczany przez 5860533128-614448 = 5859918680 bloków. Ponieważ 5859918680 można podzielić przez 8 (4096 rozmiar bloku fizycznego / 512 rozmiar bloku logicznego), jest to dobre przypuszczenie co do wielkości woluminu.

Najlepsze przypuszczenie to w końcu:
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Drugi najlepszy sposób to:
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Prawdopodobnie twój utracony wolumin zostanie teraz zamontowany. Sprawdź głośność za pomocą:
```
diskutil verifyVolume disk6s2
```
W razie potrzeby spróbuj naprawić wolumin.
```
diskutil repairVolume disk6s2
```

Ponieważ „uszkodzony” dysk został przeniesiony do innej skrzynki i kontrolera dysku, rozmiar bloku logicznego został zmodyfikowany. Stara mapa partycji prawdopodobnie opiera się na logicznym rozmiarze bloku wynoszącym 4096 bajtów.

Aby odzyskać mapę partycji w starym przypadku (4096b), musisz wprowadzić następujące informacje, aby przywrócić GPT (na podstawie odpowiedzi Davida Andersona):

Utwórz nowy gpt:
```
sudo gpt create /dev/disk6
```

Najpierw odbuduj wpis EFI za pomocą:

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

Odbuduj główny wolumin za pomocą:

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

ostateczna mapa partycji wygląda następująco:

 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

Na podstawie części 4096b ta „retranslacja” po zainstalowaniu dysku w obudowie o rozmiarze bloku logicznego 512b w celu:

Utwórz nowy gpt:
```
sudo gpt create /dev/disk6
```

Najpierw odbuduj wpis EFI za pomocą:

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

Odbuduj główny wolumin za pomocą:

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

Różni się to od pierwszej (zaakceptowanej) części mojej odpowiedzi, ale jest poprawna! Ponieważ EFI jest „pusty”, a nieprzydzielone bloki 262144 zawierają tylko zera, odpowiedź „pierwsza i jakoś zła” nie wpływa na działanie woluminu.

klanomath
źródło

To nie jest odpowiedź, ale raczej przykład wyodrębnienia informacji o partycji GPT z prezentowanych danych. Wykorzystano pomocnicze (zapasowe) partycje GPT, ponieważ nie opublikowano zawartości podstawowych pozycji partycji GPT. Do interpretacji danych wykorzystano dokument „ Tabela partycji GUID ”.

Ostatni użyteczny LBA znajduje się w nagłówku GPT. Dzieje się tak pod adresem 8244. Wartość to

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

Początek drugorzędnych (zapasowych) wpisów GPT rozpoczyna się w następnym bloku. Wartość wynosi

(732566640 + 1) * 4096 = 3000592961536 bytes.

Używając tego jako początku wpisu tablicy partycji EFI, otrzymuję następujące wartości. Początek partycji EFI, znaleziony pod adresem 3000592961568, to

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

Koniec partycji EFI, znaleziony pod adresem 3000592961576, to

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

Co daje rozmiar partycji wynoszący

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

Początek partycji HFS, znaleziony pod adresem 3000592961696, to

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

Koniec partycji HFS, znaleziony pod adresem 3000592961704, to

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

Co daje rozmiar partycji wynoszący

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

Jeśli zamierzasz użyć bloku o wielkości 512 bajtów, powyższe wyniki należy pomnożyć przez wartość 8, aby przekonwertować na 512 bajtów / blok.

David Anderson
źródło

+1 Otrzymujemy identyczny rozmiar i blok początkowy dla EFI i identyczny blok początkowy, ale inny rozmiar głównego woluminu.

klanomath