Observação:Originalmente, pensei que o BCD era o problema, o que acabou se revelando errado.
Originalmente, meu laptop estava configurado da seguinte maneira:
- Uma partição de 300 GB com OS X 10.10 e criptografia nativa de unidade completa (FileVault).
- Uma partição de 200 GB com Windows 10 e criptografia nativa de unidade completa (BitLocker).
- Um gerenciador de inicialização rEFInd instalado no ESP no formato
/EFI/boot. - Um gerenciador de inicialização da Microsoft instalado no ESP no formato
/EFI/Microsoft/Boot.
Dois dias atrás, reduzi a partição do OS X para 200 GB e adicionei uma partição de 100 GB, na qual instalei o Ubuntu.
Desde então, não consigo inicializar o Windows.
Ao entrar no gerenciador de inicialização do Windows, ainda sou solicitada a senha, mas depois disso, recebo uma tela dizendo
Seu PC/dispositivo precisa ser reparado
Ocorreu um erro inesperado.
Código de erro: 0xc000000e
Em seguida, inseri minha unidade de instalação do Windows 10 e fui inspecionar a partição na linha de comando ( ShiftF10).
Mas diskpartnão foi possível montar a partição, pois aparentemente ela funciona no MBR.
(Certifiquei-me de inicializar a unidade de instalação no modo EFI (por meio de uma sub-rotina de inicialização manual no rEFInd) e, portanto, esperava diskpartoperar no GPT, mas tudo bem...)
O MBR originalmente continha quatro partições:
- PES
- MacintoshHD
- Recuperação HD
- BOOTCAMP
O GPT também continha uma partição de recuperação do BitLocker após o BOOTCAMP.
Descobriu-se que a adição da partição Linux mudou e tirou o BOOTCAMP da lista e tornou "Linux HD" a quarta partição.
Simplesmente ajustei o MBR para ter o último ponto de entrada para o BOOTCAMP novamente, “pulando” assim a partição Linux.
Depois disso, ainda consegui inicializar o OS X e o Ubuntu, e agora também consegui montar a partição do Windows a partir do diskpart.
E consegui desbloquear a partição com
manage-bde -unlock W: -Password
provando que 1) não baguncei o MBR e 2) a partição ainda estava intacta.
Diante disso, tenho certeza de que o problema está no BCR.
Por razões ainda não claras para mim, não consigo montar o ESP a partir da unidade de instalação - tentar atribuir uma letra de unidade à primeira partição do disco 0 me diz que "Não há volume especificado", mas list volumeapenas lista tudo o que já está montado.
bootrec /rebuildbcdtambém falha horrivelmente, removendo o arquivo BCDda unidade de instalação.
No entanto, posso simplesmente copiar o BCD para a unidade de instalação e usá bcdedit-lo.
bcedit /store BCDimpressões:
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
Agora, isso unknownnão parecia tão bom para mim, então mudei para partition=W:usar
bcdedit /store BCD /set {default} device partition=W:
bcdedit /store BCD /set {default} osdevice partition=W:
E verifiquei o 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
Mas depois de enviar o arquivo BCD de volta para o meu ESP, o gerenciador de inicialização do Windows nem mesmo solicita mais uma senha, mas imediatamente exibe um erro diferente, dizendo
Seu PC/dispositivo precisa ser reparado.
Não foi possível carregar o aplicativo ou sistema operacional porque um arquivo necessário está faltando ou contém erros.
Arquivo: \Windows\system32\winload.efi Código de erro: 0xc0000225
Tentei configurar deviceantes osdevicee depois de descriptografar a W:unidade, com o mesmo resultado.
Definir devicepara {bootmgr}também não fez diferença. Agora tenho certeza que isso foi um retrocesso, pois ele nem pede mais minha senha.
Notei também que mesmo a execução bcdedit /store BCDfez muitas alterações no arquivo, visto que não houve alterações nos dados.
Entre outras coisas, o arquivo aparentemente conteria seu próprio caminho, sendo Volume1\EFI\Microsoft\Boot\BCDpara o arquivo BCD original e ??\C:\BCDpara o meu arquivo modificado.
A princípio fiquei preocupado que isso pudesse de alguma forma "impurificar" o arquivo, mas fiz um teste, mudando descriptionde {default}para Windows 42, o que, novamente, causou muitas alterações no arquivo, mas o gerenciador de inicialização do Windows ainda me pediu para uma senha ao usar esse arquivo, portanto, um local de arquivo personalizado não "impurifica" o arquivo, nem o que bcdeditestou usando está quebrado.
Agora, finalmente minha pergunta:
Como posso reparar meu BCD?
Ou se esse não for o problema, então o que é e como posso corrigi-lo?
Informação 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
O gerenciador de inicialização do Windows com o BCD original:
O gerenciador de inicialização do Windows com o BCD original após inserir minha senha:
O gerenciador de inicialização do Windows com um BCD modificado:
Atualização 1:
Tentei marcar o BOOTCAMP como "inicializável" no MBR, sem nenhuma alteração.
Responder1
O BCD estava realmente bom, era o MBR que estava causando todos os problemas.
Eu já havia descriptografado minha unidade [1] e estava tentando reinstalar o Windows, mas ao selecionar a unidade, apareceu um pop-up dizendo algo como "este disco rígido usa MBR, mas sistemas baseados em EFI só podem ser instalados em unidades GPT".
Aparentemente, no Windows, o MBR tem precedência sobre o GPT.
Fui em frente e substituí meu MBR por um "protetor", 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)
(No Linux, gdiskdeve ser instalado por padrão (caso contrário, tente sudo apt-get install gdisk), no Mac você pode obtê-lo emaqui.)
Isso finalmente resolveu meu problema.
[1] Parece que não é realmente necessário, mas para registro: supondo que sua unidade criptografada esteja rotulada W:, primeiro desbloqueie-a na linha de comando da unidade de instalação, depois execute manage-bde -off W:, verifique o progresso de vez em quando com manage-bde -status W:e reinicie uma vez criptografada atinge 0%.