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.
fuente
0+0 records in
0+0 records out
0 bytes transferred in 0.000013 secs (0 bytes/sec)
Respuestas:
Por favor intenta lo siguiente:
Obtenga el identificador de disco de su unidad externa de 3 TB
A continuación, supongo que el identificador de disco es disk6
desmontar el disco:
Sobrescriba los primeros 40 bloques:
Crea un nuevo gpt:
Verifique la información del disco con:
Asegúrate de que el tamaño del bloque del dispositivo sigue siendo 512 Bytes
También puedes usar
Si el gpt muestra:
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:
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:
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:
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:
La segunda mejor suposición es:
Probablemente su volumen perdido se monte ahora. Verifique el volumen con:
Si es necesario, intente reparar el volumen.
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:
Primero reconstruya la entrada EFI con:
Reconstruya su volumen principal con:
el mapa de partición final se ve así:
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:
Primero reconstruya la entrada EFI con:
Reconstruya su volumen principal con:
¡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.
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
El inicio de las entradas GPT secundarias (de respaldo) comienzan en el siguiente bloque. El valor es
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
El final de la partición EFI, que se encuentra en la dirección 3000592961576, es
Lo que da un tamaño de partición de
El inicio de la partición HFS, que se encuentra en la dirección 3000592961696, es
El final de la partición HFS, que se encuentra en la dirección 3000592961704, es
Lo que da un tamaño de partición de
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.
fuente