Nota:Al principio pensé que el problema era el BCD, pero resultó ser incorrecto.
Originalmente tenía mi computadora portátil configurada de la siguiente manera:
- Una partición de 300 GB con OS X 10.10 y cifrado nativo de disco completo (FileVault).
- Una partición de 200 GB con Windows 10 y cifrado nativo de disco completo (BitLocker).
- Un administrador de arranque rEFInd instalado en el ESP en formato
/EFI/boot. - Un administrador de arranque de Microsoft instalado en el ESP en formato
/EFI/Microsoft/Boot.
Hace dos días, reduje la partición de OS X a 200 GB y agregué una partición de 100 GB en el medio, en la que instalé Ubuntu.
Desde entonces no he podido iniciar Windows.
Al ingresar al administrador de arranque de Windows, todavía se me solicita la contraseña, pero luego aparece una pantalla que dice
Su PC/dispositivo necesita ser reparado
Ha ocurrido un error inesperado.
Código de error: 0xc000000e
Luego inserté mi unidad de instalación de Windows 10 y fui a inspeccionar la partición desde la línea de comando ( ShiftF10).
Pero diskpartresultó incapaz de montar la partición porque aparentemente funciona en el MBR.
(Me aseguré de iniciar la unidad de instalación en modo EFI (a través de una sección de inicio manual en rEFInd), por lo que esperaba diskpartoperar en el GPT, pero bueno...)
El MBR originalmente contenía cuatro particiones:
- ESP
- Macintosh HD
- Recuperación HD
- CAMPO DE ENTRENAMIENTO
El GPT también contenía una partición de recuperación de BitLocker después de BOOTCAMP.
Resultó que agregar la partición de Linux había cambiado, sacó a BOOTCAMP de la lista y convirtió a "Linux HD" en la cuarta partición.
Simplemente ajusté el MBR para tener nuevamente el último punto de entrada a BOOTCAMP, "omitiendo así" la partición de Linux.
Después de eso, todavía pude iniciar OS X y Ubuntu, y ahora también pude montar la partición de Windows desde diskpart.
Y logré desbloquear la partición con
manage-bde -unlock W: -Password
demostrando que 1) no arruiné el MBR y 2) la partición aún estaba intacta.
En vista de esto, estoy bastante seguro de que el problema está en el BCR.
Por razones que aún no me quedan claras, no puedo montar el ESP desde la unidad de instalación; al intentar asignar una letra de unidad a la primera partición del disco 0 me dice "No hay ningún volumen especificado", pero list volumesolo enumera todo lo que ya está montado.
bootrec /rebuildbcdtambién falla horriblemente, eliminando el archivo BCDdesde la unidad de instalación.
Sin embargo, puedo simplemente copiar el BCD a la unidad de instalación y usarlo bcdedit.
bcedit /store BCDhuellas dactilares:
Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {default}
device unknown
path \Windows\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoveryenabled No
custom:16000060 Yes
custom:17000077 352321653
osdevice unknown
systemroot \Windows
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
nx OptIn
custom:250000c2 1
Ahora bien, estos unknownno me parecieron tan buenos, así que los cambié para partition=W:usar
bcdedit /store BCD /set {default} device partition=W:
bcdedit /store BCD /set {default} osdevice partition=W:
Y verifiqué el resultado:
Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {default}
device partition=W:
path \Windows\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoveryenabled No
custom:16000060 Yes
custom:17000077 352321653
osdevice partition=W:
systemroot \Windows
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
nx OptIn
custom:250000c2 1
Pero después de volver a enviar ese archivo BCD a mi ESP, el administrador de arranque de Windows ya ni siquiera me solicita una contraseña, sino que inmediatamente me muestra un error diferente, que dice
Su PC/dispositivo necesita ser reparado.
No se pudo cargar la aplicación o el sistema operativo porque falta un archivo requerido o contiene errores.
Archivo: \Windows\system32\winload.efi Código de error: 0xc0000225
Intenté configurar devicey osdeviceantes y después de descifrar la W:unidad, con el mismo resultado.
La configuración devicepara {bootmgr}tampoco hizo ninguna diferencia. Ahora, estoy bastante seguro de que esto fue un paso atrás, porque ya ni siquiera me pide mi contraseña.
También noté que incluso la ejecución bcdedit /store BCDrealizó muchos cambios en el archivo, dado que no hubo cambios en los datos.
Entre otras cosas, el archivo aparentemente contendría su propia ruta, tanto Volume1\EFI\Microsoft\Boot\BCDpara el archivo BCD original como ??\C:\BCDpara mi archivo modificado.
Al principio me preocupaba que esto de alguna manera "impurificara" el archivo, pero ejecuté una prueba, cambiando descriptiona , {default}lo Windows 42que, nuevamente, causó bastantes cambios en el archivo, pero el administrador de arranque de Windows aún me pidió una contraseña al usar ese archivo, por lo que una ubicación de archivo personalizada no "impurifica" el archivo, ni el que bcdeditestoy usando está roto.
Ahora, finalmente mi pregunta:
¿Cómo puedo reparar mi BCD?
O si ese no es el problema, ¿cuál es y cómo puedo solucionarlo?
Información adicional:
diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 200.4 GB disk0s2
3: Apple_Boot Recovery HD 650.1 MB disk0s3
4: Microsoft Basic Data 99.0 GB disk0s4
5: Microsoft Basic Data 199.7 GB disk0s5
6: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC 363.9 MB disk0s6
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *200.0 GB disk1
Logical Volume on disk0s2
4A45027B-2703-4C7D-816E-3419DE0F0F61
Unlocked Encrypted
sudo gpt show -l /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - "EFI System Partition"
409640 391334208 2 GPT part - "Customer"
391743848 1269760 3 GPT part - "Recovery HD"
393013608 1688
393015296 193355776 4 GPT part - "Linux HD"
586371072 2048
586373120 390019148 5 GPT part - "BOOTCAMP"
976392268 1972
976394240 710656 6 GPT part - ""
977104896 131
977105027 32 Sec GPT table
977105059 1 Sec GPT header
sudo fdisk /dev/disk0
Disk: /dev/disk0 geometry: 60821/255/63 [977105060 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 0 0 2 - 1023 254 63 [ 1 - 409639] <Unknown ID>
*2: DA 1023 254 63 - 1023 254 63 [ 409640 - 391334208] <Unknown ID>
3: AF 1023 254 63 - 1023 254 63 [ 391743848 - 1269760] HFS+
4: 07 1023 254 63 - 1023 254 63 [ 586373120 - 390019148] HPFS/QNX/AUX
El administrador de arranque de Windows con el BCD original:
El administrador de arranque de Windows con el BCD original después de ingresar mi contraseña:
El administrador de arranque de Windows con un BCD modificado:
Actualización 1:
Intenté marcar BOOTCAMP como "de arranque" en el MBR, sin ningún cambio.
Respuesta1
En realidad, el BCD estaba bien, era el MBR el que estaba causando todos los problemas.
Ya había descifrado mi unidad [1] y estaba intentando reinstalar Windows, pero al seleccionar la unidad apareció una ventana emergente que decía algo como "este disco duro usa MBR, pero los sistemas basados en EFI solo se pueden instalar en unidades GPT".
Aparentemente, en Windows, MBR tiene prioridad sobre GPT.
Seguí adelante y reemplacé mi MBR por uno "protector", usando
sudo gdisk /dev/disk0 # On Linux, use /dev/sda
r # Recovery/transformation
x # Expert mode
n # New protective MBR
w # Write changes to disk
y # Yes (confirm)
(En Linux, gdiskdebería estar instalado de forma predeterminada (de lo contrario, inténtalo sudo apt-get install gdisk), en Mac puedes obtenerlo desdeaquí.)
Esto finalmente resolvió mi problema.
[1] Parece que en realidad no es necesario, pero para que conste: suponiendo que su unidad cifrada esté etiquetada como W:, primero desbloquéela desde la línea de comando de instalación de la unidad, luego ejecútela manage-bde -off W:, verifique el progreso de vez en cuando con manage-bde -status W:y reinicie una vez cifrada. llega al 0%.