Tipo de partición FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unidad no montable

1

Sí, ya probé este: Tipo de partición repentinamente FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unidad no montable

Mi partición principal está en este formato ffffffff-ffff-ffff-ffff-ffffffffffff o lo que sea. Y necesito todos los datos en este disk3s2.

Aquí hay una foto de mi disco, hace un par de horas:

  • disk3s1: EFI
  • disk3s2: Macintosh (partición ffffffff-ffff-ffff-ffff-ffffffffffff con todos mis datos, ¡quiero estos datos!)
  • disk3s3: Apple_HFS Recovery HD
  • disk3s4: Nuevo (otra partición inútil, está vacía)
  • disk3s5: Apple_Boot Recovery HD

Lo que hice para intentar reparar mi disco:

diskutil umountDisk /dev/disk3
sudo gpt destroy /dev/disk3
diskutil umountDisk /dev/disk3
sudo gpt create -f /dev/disk3

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk3

Entonces, cuando intento agregar otra partición, obtengo este error:

gpt add: /dev/disk3: error: no space available on device

Por favor, ayuda si tienes alguna sugerencia, perdí muchos datos importantes.

Actualización:

diskutil list

conduce a esto:

 /dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage SSD                     119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            SSD                    +118.8 GB   disk1
                                 Logical Volume on disk0s2
                                 ...deleted it...
                                 Unencrypted

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1

y

sudo gpt -r show disk3

conduce a esto:

    start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  624732774         
  625142414         32         Sec GPT table
  625142446          1         Sec GPT header
    
pregunta Seliem 08.01.2017 - 12:10

1 respuesta

1

Los volúmenes se pueden recuperar en una sesión de TeamViewer buscando cadenas especiales similares al método descrito en esta respuesta: Mi SATA Hardrive fue expulsado y no se puede volver a montar debido a problemas .

Las suposiciones hechas:

  • disk3s4 (24.6 GB) y disk3s5 (650 MB) se encuentran al final del disco (vea la captura de pantalla diskutil list de la pregunta, ambas desaparecieron después de destruir la tabla de particiones anterior con sudo gpt destroy /dev/disk3 )
  • disk3s2 (Macintosh) ocupa / ocupa todo el espacio de disco no asignado (excepto el 1er HD de recuperación) de ~ 294 GB y está cifrado.

Para obtener el bloque de inicio de la primera recuperación HD ingrese (que debe estar en el rango de 271 GiB - 274 GiB o ~ 291 GB - ~ 295 GB del disco)

sudo hexdump -s 271g /dev/disk3 | grep "48 46 53 4a"

(¡hexdump usa GibiBytes en lugar de GigaBytes!) que reveló:

447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

0x447f801400 es el byte 294196876288 (o bloque 574603274) del disco. Como la cadena HFSJ reside en el tercer bloque de un volumen, Recovery HD comienza con el bloque 574603272.

La salida típica si el volumen anterior no era un FileVault pero un volumen HFSJ normal se vería así en su lugar:

447f800c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

El primer y segundo número de bytes muestran una diferencia de 0xc00-0x1400 = 0x800 o 2048 Bytes porque el volumen anterior de OS X tiene un encabezado de volumen alternativo en el segundo bloque, mientras que los volúmenes de FileVault no tienen uno.

Recovery HD tiene un tamaño fijo de 1269536 bloques y se puede agregar con gpt a la tabla de particiones.

sudo gpt add -i 3 -b 574603272 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk3

Ahora verifique el volumen con

diskutil verifyVolume disk3s3

Si los límites de la partición y el volumen están bien, obtendrá un código de salida 0.

En el espacio en disco no asignado entre EFI y Recovery HD se agregó una partición CoreStorage:

sudo gpt add -i 2 -b 409640 -s 574193632 -t 53746F72-6167-11AA-AA11-00306543ECAC disk3

Apareció la ventana de la contraseña de FileVault y se ingresó la contraseña, por lo que probablemente se agregó con éxito.

El disco y el volumen se verificaron con:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

el cual salió con el código 0 y todo estaba bien.

Más tarde, el volumen de FileVault se extendió al tamaño completo del disco con:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container
    
respondido por el klanomath 08.01.2017 - 20:19

Lea otras preguntas en las etiquetas