Fdsik_partition_scheme으로 표시되는 Mac 하드 드라이브 파티션 수정 방법

내 상황은 MBR에 손상된 GUID 하드 드라이브를 수정하는 방법 과 매우 유사 하지만 충분한 차이로 자신감있는 솔루션을 만들 수 없었습니다.

OS X El Capitain 10.11.3이 설치된 Mac에서 사용되는 USB 인클로저에 3TB Toshiba 드라이브가 있습니다.

드라이브가 단일 파티션으로 설정되었습니다. 드라이브를 부팅 할 수없고 시스템을 설치하지 않았으므로 복구 파티션도 없을 것이라고 가정합니다. 시스템이 설치되지 않았다고 확신 할 수는 없지만 그렇게 생각하지는 않습니다. Bootcamp 또는 Mac 이외의 컴퓨터에서는 사용되지 않았습니다.

드라이브가 오랫동안 정상적으로 작동했지만 최근에 인식되지 못했습니다. 디스크 유틸리티를 조사 할 때 파티션 유형이 FDisk_partition_scheme 인 것으로 표시됩니다 . 나는 그것이 원래 OS X Extended (Journaled) 로 포맷 된 GUID 파티션 맵 의 전형적인 기본값이라고 확신합니다 .

변경을 초래 한 특정 용도 나 이벤트는 생각할 수 없습니다.

드라이브에서 수집 한 정보는 다음과 같습니다.

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 정보 / 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 복구 / 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.

다음은 wxHexEditor에있는 드라이브의 첫 부분에 대한 스크린 샷입니다. EFI PART는 4096에서 시작합니다.

다른 답변에서 제안한 것처럼 409642의 오프셋에서 시작하는 HFSJ 문자열을 찾기 시작했지만 근처에서 찾지 못했습니다. 그래서 드라이브의 시작 부분부터 시작하여 오프셋 314598400에서 첫 번째 항목을 찾았습니다.

그러나 HFSJ의 발생을 계속 검색하면 첫 번째와 같이 정확하게 똑같이 보이고 많은 공간이 있습니다. 그것들은 360424448에서 시작하여 32768 간격으로 떨어져 있습니다. 예를 들어, 오프셋에서 360424448 360457216 360489984 360522752 360555520

wxHexEditor에서 모두 찾기 검색을 사용하고 몇 분 후에 중지했습니다. 그 시점에서 몇 천 명이 발견되었습니다. 무엇을해야할지 잘 모르겠습니다.

또한 오프셋 3000592961536에서 EFI 시스템 파티션 이라는 섹션을 찾을 수있었습니다. 또한 드라이브 이름 "Rosie"도 표시됩니다.

다음은 첫 번째 HFSJ 파티션과 EFI 시스템 파티션의 스크린 샷입니다. 주석을 기반으로 오프셋 8192의 스크린 샷을 추가했습니다.

도움을 주셔서 감사합니다.

— 더그 스미스
소스

디스크의 크기가 4096 바이트이고 이제 512 바이트 크기 인 것으로 나타납니다. 블록 크기는 디스크 자체에 저장되지 않기 때문에 내 질문은 다음과 같습니다. 하드웨어를 어떤 방식으로 변경 했습니까? 또한 블록 크기가 4096 바이트 인 경우 8192 바이트에서 시작하는 이전 GPT 테이블 항목을 읽을 수 있어야합니다. 지금까지 4096 바이트에서 시작하는 GPT 헤더 만 게시했습니다. 여기에 제공된 정보를 사용하여 16 진 덤프를 올바른 10 진수 값으로 다시 변환 할 수 있습니다 .

— David Anderson

@DavidAnderson, 드라이브가 다른 USB 케이스에 있다는 점에서 하드웨어가 변경되었습니다. 도움이된다면 원래의 사례를 얻을 수 있습니다.

— 더그 스미스

@DavidAnderson 오프셋 8192에 대한 스크린 샷을 추가하기 위해 스크린 샷을 변경했습니다. 여기에는 EFI 시스템 파티션 이 표시됩니다.

— Doug Smith

@klanomath 그렇습니다. 귀하의 답변이 정확했습니다. 블록과 오프셋을 섞었습니다. 그래도 오프셋 209736704 주위의 모든 0입니다. 또한 4096 블록 크기의 문제가있는 경우 8로 나누려고했습니다 (26217088). 그것은 많은 데이터 안에 있지만 HFSJ 문자열은 보이지 않습니다.

— Doug Smith

@klanomath, 나는 당신의 과정을 시작했습니다. 처음 40 개 블록을 덮어 쓰려는 시도는 실제로 어떤 데이터도 쓰지 않았습니다.0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

— Doug Smith

답변:

다음을 시도하십시오 :

외부 3TB 드라이브의 디스크 식별자를 가져옵니다.
```
diskutil list
```
아래에서는 디스크 식별자가 disk6이라고 가정합니다.
디스크를 마운트 해제하십시오.
```
diskutil umountDisk disk6
```

처음 40 개 블록을 덮어 씁니다.

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

새 gpt를 만듭니다.
```
sudo gpt create /dev/disk6
```
다음으로 디스크 정보를 확인하십시오.
```
diskutil info /dev/disk6
```
장치 블록 크기가 여전히 512 바이트임을 확인하십시오.

당신은 또한 사용할 수 있습니다
```
sudo gpt -r show /dev/disk6
```
gpt가 표시되는 경우 :
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table
```
512 바이트의 논리적 블록 크기를보고하는 디스크 및 디스크 컨트롤러가 있습니다. 다음 단계를 계속하십시오.

gpt가 표시되는 경우 :
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table
```
4096 바이트의 논리 블록 크기를보고하는 디스크 및 디스크 컨트롤러가 있습니다. 여기서 멈추고 의견을 추가하십시오.
먼저 다음을 사용하여 EFI 항목을 다시 빌드하십시오.
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
디스크 크기와 시스템 버전에 따라 디스크 유틸리티로 파티션 된 경우 크기가 다른 EFI 볼륨이 만들어집니다. 크기는 200MiB 또는 300MiB입니다. 여기에는 디스크에 300MiB EFI와 4096 바이트의 할당되지 않은 디스크 공간이 포함되어 있음이 분명합니다. (314598400-1024) / 512 = 614448 (= 시작 블록 주 볼륨) 614448-40-8 = 614400 (= EFI 크기)
다음을 사용하여 기본 볼륨을 재구성하십시오.
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
메인 볼륨의 크기는 두 번째 GPT 테이블의 첫 번째 (손상 및 오래된) 항목으로 확인할 수 있습니다. (3000592961536/512) = 5860533128은 블록 번호입니다. 그런 다음 크기는 5860533128-614448 = 5859918680 블록으로 계산됩니다. 5859918680은 8 (4096 개의 물리적 블록 크기 / 512 개의 논리적 블록 크기)로 나눌 수 있기 때문에 볼륨 크기에 대한 좋은 추측입니다.

가장 좋은 추측은 마침내 :
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
두 번째 가장 좋은 추측은 다음과 같습니다.
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
잃어버린 볼륨이 이제 마운트되었습니다. 다음을 사용하여 볼륨을 확인하십시오.
```
diskutil verifyVolume disk6s2
```
필요한 경우 볼륨을 수리하십시오.
```
diskutil repairVolume disk6s2
```

"손상된"디스크를 다른 케이스 및 디스크 제어기로 이동 했으므로 논리 블록 크기가 수정되었습니다. 이전 파티션 맵은 4096 바이트의 논리적 블록 크기를 기반으로합니다.

이전 (4096b) 사례에서 파티션 맵을 복구하려면 David Anderson의 답변을 기반으로 GPT를 복원하기 위해 다음을 입력해야했습니다.

새 gpt를 만듭니다.
```
sudo gpt create /dev/disk6
```

먼저 다음을 사용하여 EFI 항목을 다시 빌드하십시오.

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

다음을 사용하여 기본 볼륨을 재구성하십시오.

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

최종 파티션 맵은 다음과 같습니다 :

 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

4096b 부분을 기준으로 512b 논리 블록 크기의 경우 디스크를 설치 한 후 다음과 같이 "재번역"됩니다.

새 gpt를 만듭니다.
```
sudo gpt create /dev/disk6
```

먼저 다음을 사용하여 EFI 항목을 다시 빌드하십시오.

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

다음을 사용하여 기본 볼륨을 재구성하십시오.

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

이것은 내 대답의 첫 번째 (허용 된) 부분과 다르지만 올바른 것입니다! EFI가 실제로 "비어 있고"할당되지 않은 262144 블록에는 0 만 포함되므로 "첫 번째 방법과 잘못된 방법"은 볼륨의 작동에 영향을 미치지 않습니다.

— 클라 노 매스
소스

이것은 대답이 아니라 제시 한 데이터에서 GPT 파티션 정보를 추출하는 방법의 예입니다. 기본 GPT 파티션 항목의 내용을 게시하지 않았기 때문에 보조 (백업) GPT 파티션 항목이 사용되었습니다. " GUID 파티션 테이블 " 문서 는 데이터를 해석하는 데 사용되었습니다.

마지막으로 사용 가능한 LBA는 GPT 헤더에서 찾을 수 있습니다. 주소 8244에서 발생합니다. 값은

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

보조 (백업) GPT 항목의 시작은 다음 블록에서 시작합니다. 값은

(732566640 + 1) * 4096 = 3000592961536 bytes.

이것을 EFI 파티션 테이블 항목의 시작으로 사용하여 다음 값을 얻습니다. 주소 3000592961568에있는 EFI 파티션 시작은

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

주소 3000592961576에있는 EFI 파티션의 끝은

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

어느 파티션 크기를 제공합니다

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

주소 3000592961696에있는 HFS 파티션의 시작은

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

주소 3000592961704에있는 HFS 파티션의 끝은

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

어느 파티션 크기를 제공합니다

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

512 바이트의 블록 크기를 사용하려는 경우 위의 결과에 8을 곱하여 512 바이트 / 블록으로 변환해야합니다.

— 데이비드 앤더슨
소스

+1 EFI에 대해 동일한 크기 및 시작 블록과 동일한 시작 블록이지만 다른 크기의 기본 볼륨을 얻습니다.

— klanomath