Cómo reparar la partición del disco duro de Mac que se muestra como Fdsik_partition_scheme

Mi situación parece muy similar a cómo reparar el disco duro GUID dañado en MBR pero con suficientes diferencias que no he podido armar una solución segura.

Tengo una unidad Toshiba de 3 TB en un gabinete USB que se usa en una Mac con OS X El Capitain 10.11.3.

La unidad se configuró con una sola partición. El disco no era de arranque y no tenía un sistema instalado, así que supongo que tampoco tendría una partición de recuperación. No puedo decir con certeza que nunca haya instalado un sistema, pero no lo creo. No se ha utilizado con Bootcamp ni en ninguna computadora que no sea Mac.

La unidad funcionó normalmente durante mucho tiempo, pero luego no se reconoció recientemente. Al investigar con Disk Utility, se muestra que tiene un tipo de partición de FDisk_partition_scheme . Estoy seguro de que originalmente era el valor predeterminado típico del mapa de partición GUID formateado como OS X extendido (registrado) .

No puedo pensar en ningún uso o evento específico que pueda haber causado el cambio.

Aquí está la información que he recopilado de la unidad.

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

información de 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 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.

Aquí hay una captura de pantalla de la primera parte de la unidad en wxHexEditor. La parte EFI comienza en 4096.

Comencé a buscar la cadena HFSJ comenzando en un desplazamiento de 409642, como se sugiere en otras respuestas, pero no la encontré cerca de allí. Así que busqué desde el comienzo de la unidad y encontré la primera aparición en el desplazamiento 314598400.

Sin embargo, si sigo buscando casos de HFSJ, encuentro muchos de ellos que se ven exactamente iguales y con mucho espacio cero a su alrededor, como el primero. Esos comienzan en 360424448 y están separados por 32768. Por ejemplo, en compensaciones 360424448 360457216 360489984 360522752 360555520

Utilicé la búsqueda Buscar todo en wxHexEditor y me detuve después de unos minutos. Había encontrado un par de miles en ese punto. No estoy seguro de qué hacer con ellos, en todo caso.

También pude encontrar una sección llamada Partición del sistema EFI en el desplazamiento 3000592961536. Eso también muestra el nombre que tenía la unidad, "Rosie".

Aquí hay capturas de pantalla de la primera partición HFSJ y la partición del sistema EFI. Se agregó una captura de pantalla del desplazamiento 8192 en función de los comentarios.

Gracias por cualquier ayuda.

— Doug Smith
fuente

Si apareciera, su disco tenía un tamaño de bloque de 4096 bytes y ahora tiene un tamaño de 512 bytes. Como el tamaño del bloque no está almacenado en el disco, mi pregunta sería: ¿Cambió el hardware de alguna manera? Además, si el tamaño del bloque era de 4096 bytes, debería poder leer las antiguas entradas de la tabla GPT a partir de 8192 bytes. Hasta ahora, solo ha publicado el encabezado GPT a partir de 4096 bytes. El volcado hexadecimal se puede volver a convertir a los valores decimales correctos utilizando la información que se proporciona aquí .

— David Anderson el

@DavidAnderson, el hardware cambió porque la unidad está en una caja USB diferente. Podría obtener el caso original si eso ayuda en algo.

— Doug Smith

@DavidAnderson Cambié la captura de pantalla para agregar una para el desplazamiento 8192. Allí se muestra una partición del sistema EFI .

— Doug Smith

@klanomath Sí, su respuesta vinculada fue correcta. Mezclé bloque y compensación. Sin embargo, todos son ceros alrededor del desplazamiento 209736704. También intenté dividir eso entre 8 (26217088) en caso de que hubiera un problema con un tamaño de bloque 4096. Eso me pone dentro de una gran cantidad de datos, pero no se ve ninguna cadena HFSJ.

— Doug Smith

@klanomath, había comenzado tu proceso. Mi intento de sobrescribir los primeros 40 bloques en realidad no escribió ningún dato:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

— Doug Smith

Respuestas:

Por favor intenta lo siguiente:

Obtenga el identificador de disco de su unidad externa de 3 TB
```
diskutil list
```
A continuación, supongo que el identificador de disco es disk6
desmontar el disco:
```
diskutil umountDisk disk6
```

Sobrescriba los primeros 40 bloques:

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

Crea un nuevo gpt:
```
sudo gpt create /dev/disk6
```
Verifique la información del disco con:
```
diskutil info /dev/disk6
```
Asegúrate de que el tamaño del bloque del dispositivo sigue siendo 512 Bytes

También puedes usar
```
sudo gpt -r show /dev/disk6
```
Si el gpt muestra:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table
```
tiene un disco y un controlador de disco que informan un tamaño de bloque lógico de 512 bytes. Continúa con el siguiente paso.

Si el gpt muestra:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table
```
tiene un disco y un controlador de disco que informan un tamaño de bloque lógico de 4096 bytes. Por favor, deténgase aquí y agregue un comentario.
Primero reconstruya la entrada EFI con:
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
Dependiendo del tamaño del disco y la versión del sistema, se crean volúmenes EFI de diferente tamaño si se particionan con la Utilidad de Discos: ya sea uno con el tamaño de 200 MiB o uno con 300 MiB. Aquí es obvio que su disco contiene un EFI de 300 MiB y probablemente 4096 bytes de espacio en disco no asignado: (314598400-1024) / 512 = 614448 (= Volumen principal del bloque de inicio) 614448-40-8 = 614400 (= tamaño de EFI)
Reconstruya su volumen principal con:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
El tamaño del volumen principal puede determinarse mediante la primera entrada (corrupta y antigua) de la segunda tabla GPT: (3000592961536/512) = 5860533128 es su número de bloque. Entonces el tamaño se calcula por 5860533128-614448 = 5859918680 bloques. Dado que 5859918680 es divisible por 8 (tamaño de bloque físico 4096 / tamaño de bloque lógico 512), esta es una buena suposición para el tamaño del volumen.

La mejor suposición es finalmente:
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
La segunda mejor suposición es:
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Probablemente su volumen perdido se monte ahora. Verifique el volumen con:
```
diskutil verifyVolume disk6s2
```
Si es necesario, intente reparar el volumen.
```
diskutil repairVolume disk6s2
```

Como movió el disco "dañado" a un caso y controlador de disco diferente, se modificó el tamaño del bloque lógico. El antiguo mapa de partición probablemente se basa en un tamaño de bloque lógico de 4096 bytes.

Para recuperar el mapa de partición en el caso anterior (4096b), tendría que ingresar lo siguiente para restaurar el GPT (según la respuesta de David Anderson):

Crea un nuevo gpt:
```
sudo gpt create /dev/disk6
```

Primero reconstruya la entrada EFI con:

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

Reconstruya su volumen principal con:

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

el mapa de partición final se ve así:

 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

Basado en la parte 4096b, esto se "vuelve a traducir" después de instalar el disco en un caso de tamaño de bloque lógico 512b para:

Crea un nuevo gpt:
```
sudo gpt create /dev/disk6
```

Primero reconstruya la entrada EFI con:

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

Reconstruya su volumen principal con:

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

¡Esto difiere de la primera parte (aceptada) de mi respuesta, pero es la correcta! Como el EFI en realidad está "vacío" y los bloques no asignados 262144 contienen solo ceros, la respuesta "primera y de alguna manera incorrecta" no afecta la operabilidad del volumen.

— klanomath
fuente

Esta no es una respuesta, sino un ejemplo de cómo extraer la información de partición GPT de los datos que presentó. Las entradas de la partición GPT secundaria (de respaldo) se usaron porque no publicó el contenido de las entradas de la partición GPT primaria. El documento " Tabla de particiones GUID " se utilizó para interpretar los datos.

El último LBA utilizable se puede encontrar en el encabezado GPT. Esto ocurre en la dirección 8244. El valor es

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

El inicio de las entradas GPT secundarias (de respaldo) comienzan en el siguiente bloque. El valor es

(732566640 + 1) * 4096 = 3000592961536 bytes.

Usando esto como el inicio de la entrada de la tabla de particiones EFI, obtengo los siguientes valores. El inicio de la partición EFI, que se encuentra en la dirección 3000592961568, es

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

El final de la partición EFI, que se encuentra en la dirección 3000592961576, es

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

Lo que da un tamaño de partición de

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

El inicio de la partición HFS, que se encuentra en la dirección 3000592961696, es

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

El final de la partición HFS, que se encuentra en la dirección 3000592961704, es

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

Lo que da un tamaño de partición de

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

Si va a utilizar un tamaño de bloque de 512 bytes, los resultados anteriores deberán multiplicarse por un valor de 8 para convertir a 512 bytes / bloque.

— David Anderson
fuente

+1 Obtenemos un bloque de inicio y tamaño idéntico para el EFI y un bloque de inicio idéntico pero un tamaño diferente del volumen principal.

— klanomath