Arreglando un arranque de partición de Windows usando herramientas OS X

Question

Arreglando un arranque de partición de Windows usando herramientas OS X

#1 de GolDDranks (0 votos)

2

Tengo un sistema de arranque triple en mi Mac Book Pro de principios de 2013: OS X, Windows 7 y Ubuntu. Estoy usando rEFInd como mi gestor de arranque. Mis botas de instalación de Windows utilizan el arranque de BIOS heredado, y OS X y Ubuntu arrancan con un arranque EFI nativo.

Todo ha estado funcionando hasta que actualicé a OS X Yosemite. Eso rompió mi Windows:

"No hay dispositivo de inicio: inserte el disco de inicio y presione cualquier tecla"

Supongo que debería haber respaldado el sector de arranque antes de actualizar, ¡pero ahora es demasiado tarde! Dado que Windows se inicia en modo BIOS, lee el MBR híbrido y, de hecho, la partición de Windows no se marcó como de inicio. Después de marcarlo como arranque con fdisk, el mensaje cambió a:

"Falta el sistema operativo"

He revisado el MBR con fdisk, y GPT con gdisk y son compatibles y están sincronizados. Después de horas de buscar y probar en Google, finalmente me di cuenta de cuál era el problema:

Algunas semanas antes había cambiado el tamaño de la partición de Windows, reduciendo la partición de OS X en OS X, y luego, usando un cierto software de Windows, ampliando la partición de Windows para acomodar el nuevo espacio libre que ahora mentía antes de la partición de Windows. Ahora parece que ese programa actualizó SOLAMENTE MBR: desde el punto de vista de GPT hay un espacio sin particiones antes de la partición de Windows, y desde el punto de vista de MBR ese espacio es usado por Windows.

Sin embargo, al instalar Yosemite, sincronizó el MBR híbrido para cumplir con el GPT, marcando la sección superior de la partición de Windows como espacio libre. ¡Ese "espacio libre", por supuesto, contiene el gestor de arranque de Windows y un montón de datos!

Mi pregunta es, ¿hay alguna forma de analizar la parte aparentemente no particionada del disco y determinar el primer sector de la partición de Windows? Supongo que eso es posible, pero necesito las herramientas adecuadas para eso.

Para información, aquí están mis datos de GPT:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       731723959   348.7 GiB   AF05  Macintosh HD
   3       731723960       732993495   619.9 MiB   AB00  Recovery HD
   4       799528960       906948607   51.2 GiB    0700  WINDOWS 1
   5       906948608       977104895   33.5 GiB    0700  UBUNTU

y los datos de MBR protector / híbrido:

 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AC 1023 254  63 - 1023 254  63 [    409640 -  731314320] <Unknown ID>
 3: AB 1023 254  63 - 1023 254  63 [ 731723960 -    1269536] Darwin Boot 
*4: 0C 1023 254  63 - 1023 254  63 [ 732993496 -  173955112] Win95 FAT32L

Tenga en cuenta que hay un espacio de 66535465, 31.7 GiB antes de la partición de Windows 51.2 GiB. Cuando Windows funcionó, vio su partición como aproximadamente 80 particiones GiB. Por lo tanto, el inicio "real" de esa partición de Windows se encuentra en algún lugar dentro de esa brecha. ¿Cómo escanearlo?

windows bootcamp boot partition refind

pregunta GolDDranks 18.10.2014 - 04:30

1 respuesta

Lea otras preguntas en las etiquetas windows bootcamp boot partition refind

El botón de encendido apaga la MacBook, pero no la vuelve a encender Agregar fuentes X a XQuartz

score 0 · Accepted Answer

Pondré esto como una respuesta, aunque no solucionó mi problema, al final se trató de un caso perdido. Consecuencia: hice una copia de seguridad de la partición de Windows en mi partición OS X:

sudo dd bs=512 if=/dev/disk0 of=windows_backup skip=732993496 count=173955112

Ahora tenía un volcado hexadecimal de 80 gigas que podía examinar con seguridad. Usé un editor hexadecimal para buscar todo tipo de metadatos:

"NTFS" (codificado en ASCII) que inicia un volumen NTFS.
"ARCHIVO" (codificado en ASCII) que inicia un registro de entrada de archivo en la tabla de archivos maestra o $ MFT en NTFS.
nombres de archivos del sistema NTFS (como "MFT", probado con little-endian UTF-16 y ASCII)

... y así sucesivamente. Pero sin éxito. Pude encontrar todo tipo de datos desde el volcado, pero todos los metadatos, incluido el registro de inicio (el primer sector del volumen), el archivo $ Boot (los primeros 15 sectores después del registro de inicio), el archivo $ MFT que mantiene un registro de todos los archivos en el sistema de archivos, se han ido.

Lo que me desconcierta es que ni siquiera pude encontrar el archivo $ MFTMirr, que es el archivo de copia de seguridad de los archivos de metadatos y se almacena a la mitad del volumen.

Pude encontrar una copia de seguridad del sector de arranque desde su ubicación estándar, el último sector del volumen. Sin embargo, los datos eran antiguos, desde la era antes de cambiar el tamaño del volumen. El sector de arranque ha almacenado el desplazamiento del archivo de metadatos del archivo $ MFT, pero la inspección de las referencias fue discutible, no había nada de valor allí.

Al final, llegué a la conclusión de que el volumen estaba totalmente subido. La moraleja de la historia? El registro de arranque maestro híbrido es malo. Además, parece que el programa que redimensionó el volumen hizo un trabajo mediocre, al no actualizar algunos de los metadatos.