[English]Stimmt das Datenträgerlayout bei Windows-Maschinen nicht mit den Microsoft-Vorgaben überein, kann das schnell Ärger geben. Bei der Update-Installation kommt es zu Rollbacks und die Installation der Feature-Updates scheitert an einer Fehlermeldung. Hier eine Zusammenfassung, was man beachten und wissen sollte.
Anzeige
Blog-Leser Martin Feuerstein hat mich Mitte November 2020 per Mail kontaktiert und über zwei Problemfälle bei der Installation von Updates und Funktionsupdates berichtet. Beide ließen sich auf das Partitionslayout (verursacht beim Wechsel vom BIOS- zum UEFI-Boot) zurückführen.
- Beim ersten Fall schrieb Martin: hab die Tage einen Fall bearbeitet, bei dem ein älterer Laptop (offiziell nicht mal für Win10 unterstützt) Probleme beim Feature-Update von 1809 auf 1909 hatte. Ursache: Partitionslayout (installiert für MBR – aber das BIOS unterstützt doch UEFI).
- Zwei Tage danach ein schon länger schwelendes Problem mit regulären Windows-Updates an zwei Servern (2012 R2 und 2016) gelöst. Ursache: Partitionslayout (UEFI). Die Server wurden vorher von ESX auf Hyper-V migriert.
Also unterschiedliche Probleme, aber gleiche Ursache. Lösung ist eigentlich „nur" die Umsetzung von einem – immerhin bootfähigen – MBR-Layout zu einem UEFI-konformen Layout. In der Theorie gibt's da schon Werkzeuge (MBR2GPT, GPTGen) für eine geschmeidige Umsetzung, in der Praxis hat aber nur die Keule (Backup + Partitionen löschen + Wiederherstellen) funktioniert.
Fall 1: Das Setup steigt beim Upgrade aus
Beim ersten Fall sollte ein Notebook von Windows 10 Version 1809 auf eine neuere Windows 10-Build aktualisiert werden. Das Notebook ist ein Fujitsu Lifebook E752, ist ca. 8 Jahre alt. Im BIOS/UEFI gibt es keine Einstellmöglichkeiten bzgl. Secure Boot oder CSM (Compatibility Support Module). Beim Windows-Start wird, wie bei anderen Nicht-UEFI-Geräten, die Windows-Flagge eingeblendet und kein Hersteller-Logo, wie es bei UEFI üblich wäre. Kein Hinweis auf UEFI.
Problem bei diesem Gerät ist, dass das Setup bereits beim Start den Fehler Windows kann nicht installiert werden, weil dieser PC ein nicht unterstütztes Datenträgerlayout für die UEFI-Firmware aufweist meldet.
Anzeige
Was ist die Ursache? Das Partitionslayout ist nicht wie aus dem Microsoft-Handbuch angelegt. Hier die Auflistung der Daten in der Eingabeaufforderung.
Ein eigentlich offensichtliches Problem aber ärgerlich, weil dort ja ein Windows 10 läuft und nur ein Upgrade ausgeführt werden soll. Die Lösung: Das Layout der Festplatte auf die Anforderungen Microsofts umstellen und dann installieren.
Fall 2: Windows-Server rollen Updates zurück
Der zweite Fall betraf zwei Windows-Server, eine VM mit Server 2012 R2, eine VM mit Server 2016. Diese rollen nach der Installation die kumulativen Updates in der Boot-Phase zurück, während andere Updates (z. B. Office) ohne Fehlermeldung installiert werden. Die VMs wurden zuvor von VMWare ESX zu Hyper-V migriert. Andere Server in derselben Domäne zeigen keine Auffälligkeiten, bis vor der Migration gab es auch mit den Updates keine Probleme.
Im Eventlog kein Hinweis auf einen Fehler, abgesehen davon, dass die Updates nicht installiert werden können. Ein Fehler zeigt sich aber in den CBS-Logs (Component-Based Servicing) in c:\Windows\Logs\CBS, dass die Boot-Partition nicht gefunden wurde:
(CBS-Log, Zum Vergrößern klicken)
In der Log-Datei finden sich Einträge der Art:
Microsoft-Windows-BootEnvironment-Core-BootManager-PCAT
Installer name: 'Boot File Servicing (BFSVC) Installer'
BFSVC: 'Failed to get system partition! Last Error = 0x3bc3'
Boot File Servicing (BFSVC) Installer ({c5f0e9d7-e844-4507-89e4-701b5a747221}) with HRESULT HRESULT_FROM_WIN32(15299)
Damit war klar, dass auch hier das Partitionslayout mit reinspielt. Martin schreibt:
Die VMs wurden vorher vorher als BIOS-Maschine mit MBR-Layout betrieben, nach der Konvertierung aber als Gen2/UEFI-VM unter Hyper-V. Der Einfachheit halber wurde auf einen MBR-Datenträger eine FAT32-Partition für den Bootloader geschrieben und das Betriebssystem auf eine NTFS-Partition.
Hintergrundwissen zum Partitionslayout
Früher wurde das MBR-Layout als Standard für Festplatten definiert – d.h. auf einem Datenträger können bis zu vier primäre Partitionen angelegt werden, die Boot-Partition (die Partition mit dem Boot-Manager) wird „aktiv" gesetzt. Funktioniert so seit der Markteinführung von MS-DOS. Um mehr als die vorgesehenen vier Partitionen pro Datenträger anzulegen, kann eine erweiterte Partition eingerichtet werden, die ihrerseits logische Partition enthält.
- Klassische BIOS-Installation mit Windows Vista aufwärts mit MBR-Datenträger-Layout sehen so aus: Es wird eine Partition für den Boot-Manager angelegt, diese wird aktiv gesetzt, das Betriebssystem wird auf eine separate Partition installiert. Bei BIOS-Installationen kann die Boot-Partition wahlweise mit FAT32 oder NTFS formatiert sein, dem BIOS ist das egal. Die Windows-Partition muss mit NTFS formatiert sein (ob durch die Vista/7-Installation nun eine NTFS- oder FAT32-Partition angelegt wurde weiß ich heute auch nicht mehr).
- UEFI-Installation: Es wird eine Partition für den Boot-Manager angelegt, diese *muss* mit FAT32 formatiert sein, sonst kann das UEFI den Boot-Manager nicht starten. Die Betriebssystem-Partition ist wie für Windows üblich mit NTFS formatiert. UEFI ist dabei für die Verwendung mit einem GPT-Datenträger-Layout vorgesehen, das keine aktiv gesetzte Partition kennt – Im UEFI wird durch das Betriebssystem der Pfad zum Boot-Manager auf einer FAT32-Partition eingetragen. Das Auslesen des Boot-Managers aus der ersten FAT32-Partition ist m.M.n eher als Fallback-Lösung zu betrachten.
Windows startet, unabhängig ob nun ein BIOS oder UEFI (mit oder ohne CSM) vorliegt, sofern der Boot-Manager von einer Partition gelesen werden kann. Für das BIOS (MBR-Layout) ist die aktive gesetzte Partition maßgeblich, für UEFI der eingetragene Pfad zum Boot-Manager. Alternativ lädt UEFI auch Boot-Loader von einer FAT32-Partition, ohne dass diese im UEFI eingetragen ist.
Mit einem MBR-Layout, der FAT32-Boot-Partition (für MBR aktiv gesetzt) und der Betriebssystem-Partition haben wir nun also einen Datenträger, der prinzipiell auf einem BIOS-Computer und einem UEFI-Computer starten kann. Also alles bestens, oder nicht?
BCD-Einträge mit bcdboot reparieren, Zum Vergrößern klicken
Hinweis: Bei der Einrichtung des Boot-Managers mittels BCDBoot kann angegeben werden, welche Boot-Methode eingerichtet werden soll: entweder BIOS (/f BIOS), UEFI (/f UEFI) oder ein Hybrid (/f ALL), der beides kann.
Ausweg für die Update- und Feature-Update-Installation
Martin schrieb mir dazu: Grundlegend muss das Datenträgerlayout für den UEFI-Boot auf GPT umgestellt werden und ein entsprechender Boot-Manager geschrieben werden. Die Windows-Datenträgerverwaltung lässt die nachträgliche Konvertierung des Systemdatenträgers nicht zu, der Datenträger müsste also erst mit dem GPT-Layout neu initalisiert und das Betriebssystem neu installiert werden.
Für die Konvertierung gibt es aber z. B. das Bordmittel MBR2GPT (hat bei mir nicht funktioniert) oder GPTGen (hat auch nicht funktioniert, oder ich habe nicht die richtigen Parameter verwendet). Andere Partitionierungsprogramme (meist kostenpflichtig, zumindest für Geschäftskunden) mögen die MBR-GPT-Partitionierung beherrschen, diese habe ich aber nicht ausprobiert.
Martin hat dann folgende Lösungsschritte ausgeführt:
1. Betriebssystempartition sichern
Dies kann zum Beispiel mit DISM, also einem Bordmittel von Microsoft, in einer Wiederherstellungsumgebung geschehen
DISM /Capture-Image /CaptureDir:"c:\" /ImageFile:"d:\os.wim" /Name:"Betriebssystem"
Für zusätzliche Partitionen auf dem Datenträger muss DISM entsprechend nochmal ausgeführt werden
2. Datenträger neu initialisieren
Der Datenträger wird entsprechend diesem MS-Dokument neu initialisiert: Im Folgenden wird von diesen Laufwerksbuchstaben ausgegangen:
c:\ – Betriebssystem-Partition
d:\ – Datenträger, der die Sicherung des Betriebssystems enthält
z:\ – Boot-Partition
3. Betriebssystem wiederherstellen und Boot-Manager erstellen
Das Betriebssystem wird auf die neu eingerichtete Partition wiederhergestellt
DISM /Apply-Image /ImageFile:"d:\os.wim" /Index:1 /ApplyDir:c:\
Anschließend wird der Boot-Manager auf den neu initialisierten Datenträger geschrieben, um das Betriebssystem bootfähig zu machen:
BCDBoot c:\windows /l de-de /s z:\ /f UEFI
Nach diesen Schritten sollte das System dann wieder wie gewohnt Updates oder Funktionsupdates installieren können. Danke an Martin für die Aufbereitung dieses Sachverhalts. Vielleicht hilft es mal jemanden weiter.
Anzeige
Das es solche Probleme gibt wurde ja schon vor Jahren bei einigen Updates unter Windows 7 offenbar. Dort betraf es aber dann das Layout im Multibootbetrieb mit Linux. Inzwischen habe ich dafür einfach zwei SSD/NVME im Rechner und starte den linuxloader von der "nur-Linux"-Platte, der dann ggf. Windows von der zweiten Platte nachlädt. So das die Windowsplatte komplett auch Solo betrieben werden könnte und die dortigen Probleme sind für mich auch Geschichte. Mit den og. Updates gäbe es sicher sonst wieder die gleichen Probleme. Schade ist, das es keine Win10-internen Routinen gibt, die den unbedarften Anwender auf soetwas hinweisen…
Ich habe kürzlich mit MBR2GPT von MBR erfolgreich auf GPT umgestellt.
Dabei bin ich im Prinzip nur dieser Anleitung gefolgt:
https://www.deskmodder.de/wiki/index.php?title=MBR_zu_GPT_%C3%A4ndern_Festplatte_konvertieren_Windows_10
Allerdings gefror mir beim Umstellen im BIOS-Setup von Legacy auf UEFI das Blut in den Adern, die Kiste fand kein Bootlaufwerk mehr! Ich fühlte mich ziemlich aufgeschmissen, eine händische Neuinstallation mit all den Anwendungen würde Tage dauern! Dazu hatte nun weder Lust noch Zeit. Und es wurde noch schlimmer, als ich die Sata-SSD per USB.Adapter an meinen Notebook hing, sah der da nur eine riesige reservierte Partiton, die nicht auf eine Windows-Installation hin deutete. Alles weg!?!?
In meiner Verzweifulung habe ich dann die SSD zurück gebaut und den PC von einer 2004 DVD booten lassen, um mal in der Reparaturkonsole nachzusehen. Per Diskpart habe ich dann gesehen, dass alle Partitionen aber noch auf der SSD da waren, und ich konnte aus der Eingabeaufforderung auch darauf zugreifen. Kurzerhand habe ich dann die Reparaturfunktion von der 2004 DVD gestartet. Dabei ist anzumerken, auf der SSD ist bereits 20H2 drauf, das hätte auch schief gehen können. Aber es hat geklappt, die SSD wurde ein paar Minuten analysiert, dann wurde was gemacht, und dann wurde der PC neu gestartet, und bootete wieder! Jetzt als UEFI/GPT-System.
Danke Günter und allen anderen (Martin), für das Spezialthema.
Immer bei einer neuen Festplatte, fange ich wieder an zu grübeln. Bei Größen über 2 TB wird es spannend.
Bei neuen Systemfestplatten erst recht.
Bei @moinmoin von Deskmodder bin ich dann auch fündig geworden.
Danke für diesen interessanten Artikel. Kommt mit in meine Lesezeichen. Ich habe schon viele Systeme erfolgreich per mbr2gpt umstellen können. Bis jetzt hat immer alles einwandfrei funktioniert. Aber gut zu wissen, wo man hin greifen kann, wenn es mal knallt.
MBR2GPT habe ich selber schon mal erfolgreich getestet.
Und für den nicht ganz so technisch versierten kann es eine Möglichkeit sein auf GPT umzustellen, sofern es funktioniert. Meine Erfahrung bei anderen Computern hat bisher gezeigt, das es selten funktioniert.
Was mich am MBR2GPT Tool stört, ist die Tatsache, das eine neue zusätzliche Partition erstellt wird und somit nicht die alte vorhandene System-reservierte Partition genutzt wird. Wenn ich selber irgendwo es umstellen müsste, würde ich mit einem Partitionstool die Platte auf GPT ändern und die System-reservierte auf eine EFI Partition umstellen und die Boot Configurations Speicher neu erstellen.
Ich hab es probiert mit MBR2GPT und GPT2Gen, auf endlose Versuche hatte ich aber auch keine Lust. Sichern+Wiederherstellen ging dann einfach schneller.
@Martin
Kann ich verstehen und nachvollziehen.
Wie ich bereits geschrieben habe, halte ich auch nicht viel vom MBR2GPT Tool aus den bereits von mir geschriebenen Gründen: Unzuverlässigkeit und der zusätzlichen Partition die erstellt wird.
MfG
Matthias
Ich habe meinen Rechner vor einiger Zeit mit MBR2GPT auf UEFI umgestellt. Wenn ich das jetzt lese, bin ich doch froh, dass es damals problemlos geklappt hat.
Aktuell ist gerade ein Beitrag "Virtuelle Maschinen unter Hyper-V von Generation 1 auf 2 konvertieren" auf WindowsPro erschienen. Dabei wird auch die Änderung des Disk-Layouts mit MBR2GPT kurz angesprochen.
Wo ich das gerade sehe, ich empfinde diese "Neuerung" seit Win 2004 als Designfehler.
Im UEFI/GPT wird seitdem bei Neuinstallationen eben genau dieses im MS Handbuch beschriebene Layout angelegt:
– eine Systempartition
– eine MSR
– eine Windows-Partition
und im Nachgang, nicht bei der Installationspartitionierung sichtbar:
– eine Partition für Wiederherstellungstools
Dies gab es meine ich in 1903 schon mal als Fehler in einem Build wurde dann aber wieder abgestellt, also der damalige Standard:
– Systempartition
– MSR
– Recovery
– Windows
Nun kommt es doch ab und an mal vor, dass man die Festplatte tauscht und dann ein größeres Modell hat, konnte man früher einfach die Windowspartition erweitern ist dies nun durch die Recovery am Ende des Partitionslayouts nicht mehr einfach möglich.
Ich habe Windows 11 über den Windows Insider Ring installiert und bin auch sehr zufrieden damit. Allerdings stellt sich wie von Geisterhand immer mal wieder das CSM im UEFI BIOS ein und dann bekomme ich die Meldung "MBR Failure" – dabei ist gar kein MBR nötig, da ich die Platte zuvor auf GPT konvertiert habe.
Sobald ich CSM wieder ausschalte, bootet der PC wie gewünscht.
Hat jemand eine Ahnung warum das passiert und wie ich mir den Spaß ersparen kann?
Der Befehl zum Sichern der Partition muss so aussehen:
DISM /Capture-Image /ImageFile:"d:\os.wim" /Name:"Betriebssystem" /CaptureDir:"c:"
Reihenfolge ist nicht unwichtig. Auch der Backslash im Capturedir ist überflüssig.