Seguí un tutorial para crear arranque dual con macOS Sierra 10.12 y Kali-Linux 2.0.
Creé una unidad USB de arranque y arranqué en una sesión en vivo de Kali-Linux para usar GParted y cambiar el tamaño de mi partición macOS.
Seleccioné la partición macOS y la cambié de tamaño de 239 GB a 200 GB. Obtuve 2 particiones, con la partición de 39 GB formateada como "sin asignar".
Pero ahora, cuando trato de iniciar macOS, aparece el logotipo de Apple, luego una cruz blanca y no puedo iniciar macOS.
Traté de iniciar Recovery HD manteniendo presionado cmdR, luego traté de usar SOS pero dice que necesito un disco de recuperación del Asistente. Podemos crear un disco de recuperación USB conectando una unidad USB a nuestra MacBook y luego usar el asistente para crear una unidad USB de arranque que pueda reparar discos, pero como dije, mi MacBook no puede arrancar en macOS, así que no puedo crear es... ¿Hay alguna forma de descargar la iso de la unidad USB de recuperación directamente para crear mi propia unidad USB de recuperación a partir de ella?
Leí en alguna parte que necesito volver a escribir los códigos de arranque correctos y mis datos no se pierden. ¿Es eso cierto?
¿Qué crees que puedo hacer?
Editar:
Aquí está la salida de diskutil/gpt:
(Perdón por la baja tasa de compresión, no tengo 10 reputación para publicar más de 2 fotos)
No esperaba el resultado de Diskutil. ¿Tanta partición es normal?
Editar2 :
Aquí está la otra pantalla que tenía después de escribir comandos:
editar 3
GParted realmente no creó espacio en disco sin asignar. En cambio, el MBR se volvió falso. El CoreStorage LVG y todos los contenedores subsiguientes también se corrompieron, porque la pila completa no se redimensionó según lo requerido. Por lo general, en macOS, se cambia el tamaño de toda la pila con el comando diskutil cs resizeStack ...
. Por lo que puedo decir de forma remota, el límite final de la segunda partición simplemente se movió a números de bloque más bajos, lo que generalmente funciona con volúmenes HFS+ normales en GParted, pero no en este caso con una pila CoreStorage. Afortunadamente, algunas estructuras de datos invisibles de la pila CS no se sobrescribieron.
Además, la partición de recuperación no se movió correctamente. Pero este es un problema diferente.
En lugar del MBR, debe tener un pMBR. Después de eliminar el MBR falso, debe destruir y volver a crear la tabla de particiones GUID:
Obtenga una descripción general (¡especialmente el comando gpt es importante!):
diskutil list
gpt -r show disk0
Desmontar disk0:
diskutil umountDisk /dev/disk0
Eliminar el MBR:
dd if=/dev/zero of=/dev/disk0 bs=512 count=1
Destruya la tabla de particiones GUID y cree una nueva (esto también crea un pMBR nuevo):
gpt destroy disk0
gpt create -f disk0
Reconstruya todas las particiones GUID anteriores:
gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
gpt add -i 3 -b 488965176 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
gpt add -i 2 -b 409640 -s 409602008 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Si obtiene un error de recurso ocupado después de uno de los pasos, simplemente desmonte el disco 0 nuevamente con
diskutil umountDisk /dev/disk0
Compruebe el disco con diskutil verifyDisk disk0
después.
Ingrese diskutil cs list
y verifique si aparecen los cuatro contenedores de CoreStorage: un grupo de volúmenes lógicos, un volumen físico y una familia de volúmenes lógicos y un volumen lógico.
Con el UUID del volumen lógico, monte el LV:
Ejemplo:
+-> Logical Volume 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
---------------------------------------------------
Disk: disk17
Status: Online
Luego usa:
diskutil mount 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
Luego, después de obtener el identificador de disco del LV montado, diskutil list
verifique el volumen:
diskutil verifyVolume disk17 # probably it's disk17, disk16 or disk18
A continuación, supongo que el identificador del disco es disk17
Si la familia de volúmenes lógicos y el volumen lógico no aparecen, intente lo siguiente:
Obtenga una descripción general (¡especialmente el comando gpt es importante!):
diskutil list
gpt -r show disk0
Desmontar disk0:
diskutil umountDisk /dev/disk0
Elimine la entrada de partición actual para la segunda partición:
gpt remove -i 2 disk0
Agregue una nueva segunda entrada de partición "expandida":
gpt add -i 2 -b 409640 -s 488555536 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Luego repita todos los pasos de verificación:
Compruebe el disco con diskutil verifyDisk disk0
después.
Ingrese diskutil cs list
y verifique si aparecen los cuatro contenedores de CoreStorage: un grupo de volúmenes lógicos, un volumen físico y una familia de volúmenes lógicos y un volumen lógico.
Con el UUID del volumen lógico, monte el LV:
Ejemplo:
+-> Logical Volume 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
---------------------------------------------------
Disk: disk17
Status: Online
Luego usa:
diskutil mount 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
Luego, después de obtener el identificador de disco del LV montado, diskutil list
verifique el volumen:
diskutil verifyVolume disk17 # probably it's disk16, disk17 or disk18
Si obtiene errores, haga una copia de seguridad de los datos o de toda la partición en un volumen externo y luego repare el volumen con diskutil repairVolume disk17
.
Una posibilidad para hacer una copia de seguridad de los datos es dd
. Adjunte una unidad formateada HFS+ con al menos 250 GB de espacio libre. Obtenga la ruta al volumen externo con ls /Volumes
. Luego desmonte disk17 y disk0 con diskutil umountDisk disk17
y diskutil umountDisk disk0
.
Luego clone la partición en un archivo:
dd if=/dev/disk0s2 of=/Volumes/ExternalDriveName/disk0s2.rawdevice bs=4m
Si el nombre del volumen contiene espacios, escape los espacios con barras invertidas: ...of=/Volumes/ExternalDriveName\ With\ Spaces/disk0s2.rawdevice...
.
También puede utilizar asr
para restaurar la partición en otro disco (como una "copia de seguridad" temporal). comprobar man asr
_
klanomath