Notiz:Ich hatte ursprünglich geglaubt, dass das BCD das Problem sei, was sich aber als falsch herausstellte.
Ursprünglich hatte ich meinen Laptop wie folgt eingerichtet:
- Eine 300 GB große Partition mit OS X 10.10 und nativer Volllaufwerksverschlüsselung (FileVault).
- Eine 200 GB große Partition mit Windows 10 und nativer Volllaufwerksverschlüsselung (BitLocker).
- Ein rEFInd-Bootmanager ist auf dem ESP in installiert
/EFI/boot. - Ein Microsoft-Bootmanager ist auf dem ESP in installiert
/EFI/Microsoft/Boot.
Vor zwei Tagen habe ich die OS X-Partition auf 200 GB verkleinert und dazwischen eine 100 GB große Partition hinzugefügt, auf der ich Ubuntu installiert habe.
Seitdem kann ich Windows nicht mehr starten.
Beim Aufrufen des Windows-Bootmanagers werde ich zwar immer noch nach dem Passwort gefragt, aber danach erhalte ich einen Bildschirm mit der Meldung
Ihr PC/Gerät muss repariert werden
Ein unerwarteter Fehler ist aufgetreten.
Fehlercode: 0xc000000e
Dann habe ich mein Windows 10-Installationslaufwerk eingelegt und die Partition über die Befehlszeile ( ) überprüft ShiftF10. Es stellte sich
jedoch heraus, dass ich die Partition nicht mounten konnte, da sie anscheinend auf dem MBR ausgeführt wird. (Ich habe sichergestellt, dass ich das Installationslaufwerk im EFI-Modus gestartet habe (über eine manuelle Startstrophe in rEFInd), und habe daher erwartet, dass es auf dem GPT ausgeführt wird, aber na ja ...)diskpartdiskpart
Der MBR enthält ursprünglich vier Partitionen:
- ESP
- Macintosh HD
- Wiederherstellungs-HD
- BOOT CAMP
Die GPT enthielt zusätzlich eine BitLocker-Wiederherstellungspartition nach BOOTCAMP.
Es stellte sich heraus, dass das Hinzufügen der Linux-Partition BOOTCAMP aus der Liste verdrängt hatte und „Linux HD“ zur vierten Partition machte.
Ich habe einfach den MBR angepasst, um wieder den letzten Einstiegspunkt zu BOOTCAMP zu haben und so die Linux-Partition „übersprungen“.
Danach konnte ich OS X und Ubuntu immer noch booten und ich konnte jetzt auch die Windows-Partition von mounten diskpart.
Und ich konnte die Partition entsperren mit
manage-bde -unlock W: -Password
Dies beweist, dass 1) ich den MBR nicht durcheinander gebracht habe und 2) die Partition noch intakt war.
Vor diesem Hintergrund bin ich mir ziemlich sicher, dass das Problem am BCR liegt.
Aus mir noch immer unklaren Gründen kann ich das ESP nicht vom Installationslaufwerk mounten - der Versuch, der ersten Partition von Datenträger 0 einen Laufwerksbuchstaben zuzuweisen, zeigt mir „Es wurde kein Volume angegeben“, list volumelistet aber nur alles auf, was bereits gemountet ist.
bootrec /rebuildbcdschlägt ebenfalls schrecklich fehl, das Entfernen der BCD-Dateivom Installationslaufwerk.
Ich kann die BCD jedoch einfach auf das Installationslaufwerk kopieren und bcdeditdarauf verwenden.
bcedit /store BCDDrucke:
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
Nun, diese unknownsahen für mich nicht so gut aus, also änderte ich sie partition=W:in
bcdedit /store BCD /set {default} device partition=W:
bcdedit /store BCD /set {default} osdevice partition=W:
Und ich habe das Ergebnis überprüft:
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
Aber nachdem ich die BCD-Datei wieder auf meinen ESP übertragen habe, fordert mich der Windows-Bootmanager nicht einmal mehr zur Eingabe eines Kennworts auf, sondern zeigt mir sofort einen anderen Fehler an, der besagt:
Ihr PC/Gerät muss repariert werden.
Die Anwendung oder das Betriebssystem konnte nicht geladen werden, da eine erforderliche Datei fehlt oder Fehler enthält.
Datei: \Windows\system32\winload.efi Fehlercode: 0xc0000225
Ich habe versucht , vor und nach dem Entschlüsseln des Laufwerks deviceund die Einstellungen vorzunehmen , mit demselben Ergebnis. Auch die Einstellung für hat keinen Unterschied gemacht. Jetzt bin ich mir ziemlich sicher, dass dies ein Rückschritt war, da es nicht einmal mehr nach meinem Passwort fragt.osdeviceW:device{bootmgr}
Mir fiel auch auf, dass selbst das Ausführen bcdedit /store BCDziemlich viele Änderungen an der Datei vorgenommen hat, obwohl es keine Datenänderungen gab.
Unter anderem enthielt die Datei anscheinend ihren eigenen Pfad, nämlich den Volume1\EFI\Microsoft\Boot\BCDfür die ursprüngliche BCD-Datei und ??\C:\BCDden für meine geänderte Datei.
Ich war zunächst besorgt, dass dies die Datei irgendwie „verunreinigen“ würde, aber ich führte einen Test durch, bei dem ich descriptionvon {default}in geändert Windows 42habe, was wiederum ziemlich viele Änderungen an der Datei verursachte, aber der Windows-Bootmanager fragte mich bei Verwendung dieser Datei immer noch nach einem Kennwort, also „verunreinigt“ weder ein benutzerdefinierter Dateispeicherort die Datei, noch ist das von bcdeditmir verwendete defekt.
Nun zum Schluss meine Frage:
Wie kann ich mein BCD reparieren?
Oder wenn das nicht das Problem ist, was ist es dann und wie kann ich es beheben?
Zusätzliche Information:
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
Der Windows Bootmanager mit dem originalen BCD:
Der Windows Bootmanager mit dem originalen BCD nach Eingabe meines Passwortes:
Der Windows Bootmanager mit geändertem BCD:
Aktualisierung 1:
Ich habe versucht, BOOTCAMP im MBR als „bootfähig“ zu markieren, ohne dass sich etwas geändert hätte.
Antwort1
Mit dem BCD war eigentlich alles in Ordnung, die Probleme wurden jedoch vom MBR verursacht.
Ich hatte mein Laufwerk bereits entschlüsselt [1] und versuchte, Windows neu zu installieren. Als ich das Laufwerk auswählte, erschien jedoch ein Popup mit der Meldung „Diese Festplatte verwendet MBR, aber EFI-basierte Systeme können nur auf GPT-Laufwerken installiert werden“.
Unter Windows hat MBR also offenbar Vorrang vor GPT.
Ich habe meinen MBR durch einen "schützenden" ersetzt, mit
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)
(Unter Linux gdisksollte es standardmäßig installiert sein (sonst versuchen Sie es sudo apt-get install gdisk), auf dem Mac können Sie es vonHier.)
Dadurch wurde mein Problem endlich gelöst.
[1] Es scheint, als wäre das nicht wirklich notwendig, aber zur Info: Vorausgesetzt, Ihr verschlüsseltes Laufwerk ist mit gekennzeichnet W:, entsperren Sie es zunächst über die Befehlszeile zur Installation des Laufwerks, führen Sie dann aus manage-bde -off W:, überprüfen Sie von Zeit zu Zeit den Fortschritt mit manage-bde -status W:und starten Sie neu, sobald die Verschlüsselung 0 % erreicht.