Mi situación es muy similar a la de cómo arreglar el disco duro GUID corrompido a MBR pero con las suficientes diferencias como para que no haya sido capaz de poner una solución segura.
Tengo una unidad Toshiba de 3TB en una carcasa USB que se utiliza en un Mac con OS X El Capitain 10.11.3.
La unidad estaba configurada con una sola partición. El disco no era arrancable y no tenía un sistema instalado, por lo que asumo que tampoco tendría una partición de recuperación. No puedo asegurar que nunca haya tenido un sistema instalado, pero no lo creo. No se ha utilizado con Bootcamp ni en ningún ordenador que no sea Mac.
La unidad funcionó con normalidad durante mucho tiempo, pero hace poco dejó de ser reconocida. Al investigar con la Utilidad de Discos, muestra que tiene un tipo de partición de FDisk_partition_scheme . Estoy seguro de que originalmente era el típico defecto de Mapa de partición GUID formateado como OS X Extended (Journaled) .
No se me ocurre ningún uso o evento específico que pueda haber causado el cambio.
Aquí está la información que he recogido de la unidad.
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 disk6s1diskutil 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 supportedfdisk /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] unusedgpt recover /dev/disk6
gpt recover: /dev/disk6: no primary or secondary GPT headers, can't recovergpt -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 5860533167gdisk /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.
Empecé a buscar la cadena HFSJ comenzando en un offset de 409642, como se sugiere en otras respuestas, pero no la encontré cerca de allí. Así que busqué empezando por el principio de la unidad y encontré la primera ocurrencia en el offset 314598400.
Sin embargo, si sigo buscando ocurrencias de HFSJ, encuentro muchas que son exactamente iguales y con mucho espacio cero alrededor, como la primera. Esos comienzan en 360424448 y están espaciados 32768. Por ejemplo, en los desplazamientos 360424448 360457216 360489984 360522752 360555520
Utilicé el Buscar todo búsqueda en wxHexEditor y se detuvo después de unos minutos. Había encontrado un par de miles en ese momento. No estoy seguro de qué hacer con ellos, si es que hay algo que hacer.
También he podido encontrar una sección denominada 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 de la partición del sistema EFI. Añadido una captura de pantalla del offset 8192 basado en los comentarios.
Gracias por cualquier ayuda.
0 votos
Parece que su disco tenía un tamaño de bloque de 4096 bytes y ahora tiene un tamaño de 512 bytes. Dado que el tamaño de bloque no se almacena en el propio disco, mi pregunta sería: ¿Ha cambiado el hardware de alguna manera? Además, si el tamaño de bloque era de 4096 bytes, entonces deberías poder leer las antiguas entradas de la tabla GPT a partir de 8192 bytes. Hasta ahora, sólo has publicado la cabecera de la GPT a partir de 4096 bytes. El volcado hexadecimal se puede convertir de nuevo a los valores decimales correctos utilizando la información dada aquí .
0 votos
@DavidAnderson, El hardware cambió en el sentido de que la unidad está en una caja USB diferente. Podría conseguir la caja original si eso ayuda en algo.
0 votos
@DavidAnderson He cambiado la captura de pantalla para añadir una para el offset 8192. Se muestra un Partición del sistema EFI allí.
0 votos
@klanomath Sí, tu respuesta enlazada era correcta. He confundido bloque y desplazamiento. Sin embargo, todo son ceros alrededor del offset 209736704. También intenté dividir eso por 8 (26217088) en caso de que hubiera un problema de un tamaño de bloque de 4096. Eso me pone dentro de un montón de datos, pero ninguna cadena HFSJ a la vista.
0 votos
@klanomath, yo había empezado por tu proceso. Mi intento de sobrescribir los primeros 40 bloques no escribió realmente ningún dato:
0+0 records in0+0 records out0 bytes transferred in 0.000013 secs (0 bytes/sec)0 votos
@klanomath, mi disco está montado y funciona. La primera suposición para reconstruir el volumen principal era correcta. Un gran agradecimiento a ti y a David por ir más allá con un análisis y un consejo tan detallados.
0 votos
VerifyVolume mostró un error que repairVolume pudo arreglar. (Lo siento, no guardé el texto del error).