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

Sí, ya probé este: tipo de partición de repente 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:ingrese la descripción de la imagen aquí

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

Lo que hice para tratar de 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, cada vez que intento agregar otra partición, aparece este error:

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

¡Ayúdenme si tienen alguna sugerencia, perdí muchos datos importantes!

Actualizar:

diskutil list

lleva 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

lleva 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
Dijiste "¡ Perdí muchos datos importantes! ", ¿No tienes una copia de seguridad? ¿¡Si no, porque no!?
explique los pasos relevantes que podrían haber llevado a este resultado. Hace unos meses tuve un cliente que intentaba instalar el arranque dual en su computadora para Linux y Mac. Tuvo un problema similar que finalmente pude reparar. Pero necesitamos saber qué hiciste para ayudarte a deshacerlo.
Por cierto, sus datos no se pierden (a menos que no formatee o repare un volumen con diskutil), la partición simplemente tiene el tipo incorrecto.
@ Zonker.in.Geneva Estaba a punto de instalar Mac OSX Sierra. Después de descargar y reiniciar (sin instalar, ya no funcionó). Todos los 320 GB se usan en cajeros automáticos, eso podría ser un problema. Describí en la parte superior lo que hice después de eso.
@klanomath Gracias, agregué todo lo que pediste.
@klanomath Sí, lo siento, ya lo hice
@Seliem ¿Todavía tiene el mapa de partición antiguo de disk3 (antes de eliminar la tabla de partición GUID falsa) como salida en alguna parte? La captura de pantalla de la lista diskutil de disk3 no es suficiente para restaurar el GUID pt. ¡Aunque es una pista!
@klanomath a menos que esté guardado en algún lugar de mi terminal, no tengo otro mapa. ¿Por qué? ¿Qué falta?
@Seliem Si ha cerrado la ventana de su Terminal mientras tanto, probablemente se haya perdido.
@klanomath Por supuesto que sí. Entonces, ¿qué puedo hacer ahora?
@klanomath bien, lo instalé, Usuario: "Seliem"

Respuestas (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 disco duro SATA 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 diskutil listla captura de pantalla de la pregunta: ambos desaparecieron después de destruir la tabla de particiones anterior con sudo gpt destroy /dev/disk3)
  • disk3s2 (Macintosh) ocupa/ocupa todo el espacio en disco no asignado (excepto el 1.er HD de recuperación) de ~294 GB y está encriptado.

Para obtener el bloque de inicio del primer HD de recuperación, 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. Dado que 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 fuera un FileVault sino un volumen HFSJ normal se vería así:

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 byte 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 penúltimo 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 de 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

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

El disco y el volumen fueron verificados con:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

que ambos salieron con el código 0 y todo estuvo bien.

Posteriormente, el volumen de FileVault se amplió al tamaño completo del disco con:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container
Tipo de partición FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unidad no montable
RespuestasAquíPolítica de privacidad1y, 0v