1 votos

Tipo de partición FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unidad imposible de montar

Sí, ya he probado este: tipo de Partición de repente FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unidad imposible de montar

Mi partición principal es en este ffffffff-ffff-ffff-ffff-ffffffffffff formato o lo que sea. Y necesito todos los Datos de esta disk3s2.

Aquí está una foto de mi Disco, un par de horas: enter image description here

  • disk3s1: EFI
  • disk3s2: Macintosh (ffffffff-ffff-ffff-ffff-ffffffffffff partición con todos mis Datos, quiero Datos!)
  • disk3s3: Apple_HFS Recuperación HD
  • disk3s4: Nuevo (Otro inútil Partición, su vacío.)
  • disk3s5: Apple_Boot Recuperación 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

Así que cada vez que intento añadir otra partición, me sale este Error:

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

Por favor, ayuda si usted tiene alguna sugerencia, he perdido un montón de Datos importantes!!!


Actualización:

diskutil list

conduce a este:

 /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 este:

    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

2voto

klanomath Puntos 19587

Los volúmenes pueden ser recuperados en una sesión de TeamViewer mediante la búsqueda de especial cadenas similar al método que se describe en esta respuesta: Mi SATA disco fue expulsado, y no se puede volver a montar, debido a los problemas.

Los supuestos hechos:

  • disk3s4 (24.6 GB) y disk3s5 (650 MB) está situado al final del disco (ver diskutil list captura de pantalla de la cuestión - tanto desaparecido después de la destrucción de la vieja tabla de particiones sudo gpt destroy /dev/disk3)
  • disk3s2 (Macintosh) ocupa/ocupado todo el espacio en disco sin asignar (excepto el 1 de Recuperación HD) de ~294 GB y está encriptada.

Para obtener el bloque de salida de la primera Recuperación de HD entrar (que tiene que estar en la 271 GiB - 274 GiB o ~291 GB - ~295 GB rango de la disco)

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

(hexdump utiliza 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 se Byte 294196876288 (o bloque de 574603274) del disco. Desde la cadena HFSJ reside en la tercera cuadra de un volumen, el disco duro de Recuperación se inicia con el bloque de 574603272.

La salida típica si el volumen anterior no era un FileVault, pero una normal HFSJ volumen tendría este aspecto 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 primero y el segundo byte número muestran una diferencia de 0xc00-0x1400=0 x 800 o 2048 Bytes debido a que el anterior OS X volumen tiene una alternativa cabecera de volumen en el último segundo bloque, mientras que FileVault volúmenes no tiene uno.

La Recuperación de HD tiene un tamaño fijo de 1269536 bloques y puede ser añadido con gpt a la tabla de partición.

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

Ahora compruebe el volumen con

diskutil verifyVolume disk3s3

Si la partición de los límites y el volumen son/es ACEPTAR que usted conseguirá un código de salida 0.

En el espacio en disco sin asignar entre EFI y el disco duro de Recuperación de un CoreStorage partición se añadió:

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

El FileVault la contraseña en la ventana emergente y la contraseña se ha introducido, por lo que fue añadido con éxito, probablemente.

El disco y el volumen fueron verificados con:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

que ambos salido con el código 0 y todo fue bien.

Más tarde, el FileVault volumen se amplió el tamaño total del disco con:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X