[SOLVED] [Gelöst] Windows 11 Gast bootet nicht mehr nach Inplace-Upgrade von 23H2 auf 24H2

[Peter Altherr]

Ich habe bei einem Windows 11 Gast ein Inplace-Upgrade von 23H2 auf 24H2 durchgeführt. Nachdem der blaue Bildschirm mit dem Installationsfortschritt in % und der Info, dass es zu mehreren Reboots kommen kann angezeigt wurde, habe ich die RDP-Sitzung getrennt. Vorhin wollte ich nachschauen, wie weit die Installation ist und es kam keine RDP-Sitzung mehr zustande. In der Konsole wird mir dafür folgendes angezeigt:



Nach ein paar Sekunden wird der Boot erneut versucht und endet in der gleichen Meldung, eine Endlosschleife. Die VM hat folgende Einstellungen:


Wenn jemand einen Tip hat, wo ich hier ansetzen kann, wäre ich sehr dankbar

 

[ThoSo]

Das Problem habei ich aktuelle auch.Die Vm bleibt beim Starrten hängen - dann ein Hard-Reset und es läuft!
Kannst mal Probieren.

Einziger Unterschied bei mir, ich habe noch den Maschinen Typ "pc-q35-8.1" Speicher und Core -Zahl habe ich weniger, aber das ist sekundär.
Bootreihenfolge, scsi0, ide0, net0

 

[ThoSo]

sehe gerade das es neuere Treiber für VirtioIO gibt:
https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.262-2/
sind vielleicht 24H2 ready - muss ich mal testen!

 

[Peter Altherr]

Danke für deinen Tip. Bleibt bei mir leider ohne Erfolg. Die Fehlermeldung kommt immer wieder. Aber die aktualisierten VirtIO-Treiber werd ich mir besorgen. Ich hab noch die 0.1.240-0 im Einsatz.

 

[ThoSo]

Die Zeile mit BdsDxe load / start habe ich immer. Zusätzlich steht mittendrin noch Proxmox und die Sterne drehen sich.
Das ist soweit normal. Nur muss er dann weiter hochkommen!
Geht doch mal auf die Hardware Version 8.1 - vielleicht liegt es an der Version 9 - nur so eine Idee!
Hier läuft das teil nach dem Update auf die neuen Virtion-win-01.262-2 und den Preview Update 8/2024 rauf und runter. Mal sehen ob das demnächst auch noch so ist.

 

[Peter Altherr]

Ich hab den Knoten nochmal durchgestartet und auch die Hardware-Versionen 8.1, 8.2 und 9 für die VM getestet. Leider keine Änderung, ich bekomme immer die Meldung aus dem ersten Post.

 

[ThoSo]

Abgesichert starten klappt auch nicht, so das Windows den Reparaturmodus ausführt?

 

[ThoSo]

Also bei mir ist das Bootproblem jetzt weg.
Kannst die Machine zurückstellen (Backup ?) und die VirtIO Updaten und das noch mal testen?

 

[raddirad]

Hallo @ThoSo

Was hast du denn gemacht damit das Bootproblem weg ist?

Gruß
Mathias

 

[ThoSo]

Hallo @ThoSo

Was hast du denn gemacht damit das Bootproblem weg ist?

Gruß
Mathias

Die neuen Treiber und die Preview Update 08/2024 installiert!
https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.262-2/

Wobei ich das bootproblem bei einer sauber installierten 24h2 hatte und nicht bei einem "upgrade" !


Gruß
Thomas

 

[Peter Altherr]

Problem bei mir besteht immer noch. Leider ist das Backup, das ich habe zu alt um darauf zurückzugreifen, mein Fehler. Ich hab die Lösungsansätze aus diesem Thread https://forum.proxmox.com/threads/help-failed-to-start-boot0001-uefi-qemu-dvd-rom-time-out.83521/ abgearbeitet, aber keiner greift. Hat das Problem vielleicht etwas damit https://www.deskmodder.de/blog/2024...lisiert-werden-wegen-secure-boot-aenderungen/ zu tun?

 

[ThoSo]

Also "alt" ist relativ.
Was du jetzt machen könntest, wäre auf der Proxmoxkonsole die VM-Disk umbenennen und einen VM-Restore starten. In die wiederhergestellte VM die umbenannten Disk zusätzlich mit einbauen um zu Retten was gerettet werden muss.

Du hast ein aktuelles ISO der 24h2?
Deskmoder-Quelle : https://www.deskmodder.de/blog/2024/04/27/windows-11-24h2-26100-iso-esd-deutsch-english/

Evtl könntest du auch mit dem ISO booten, mit Shift+F10 die Console startet und die Festplatte der VM chkdsk /f prüfen - ist vielleicht ein Macken drauf. Und vor allem könntest prüfen ob die vielleicht voll ist - wer weiss das schon?
Evtl. kannst du dann auch in den Reparaturmodus gehen.
Man behauptet auch das F8 drücken beim starten immer noch gehen soll - mir aber bisher nie gelungen!

Tausch mal UEFI gegen BIOS, oder wechsele die Grafikkarte, vielleicht merkt Windows das die Geräte neu erkannt werden müssen.
Das mit dem SecureBoot-Beitrag bezieht sich auf Installationsmedien, nicht auf installierte Systeme.

Hast Du da eventuell einen Virenscanner drauf der sich mit der Upgradeaktion nicht verträgt?

 

[Falk R.]

Tausch mal UEFI gegen BIOS,

Das ist keine Sinnvolle Idee. Das kann per Design gar nicht funktionieren. BIOS benötigt MBR Disks und UEFI arbeitet nur mit GPT Disks. Es gibt OS, welche einen solchen Wechsel unterstützen (z.B. ESXi) bei Windows funktioniert das garantiert nicht.

 

[ThoSo]

Das ist keine Sinnvolle Idee. Das kann per Design gar nicht funktionieren. BIOS benötigt MBR Disks und UEFI arbeitet nur mit GPT Disks. Es gibt OS, welche einen solchen Wechsel unterstützen (z.B. ESXi) bei Windows funktioniert das garantiert nicht.

War auch nur als "Ärgere das Böse Windows" gedacht, damit es in den Reparatur bzw. OOBE Modus knallt.
Aber warten wir mal was Peter Altherr uns demnächst an Input zurückgibt.

 

[Peter Altherr]

Wenn ich im UEFI (Esc im ProxMox Splashscreen) Secure Boot deaktiviere und einen Hard Reset mache, dann bootet die VM und will einen Bitlocker Wiederherstellungsschlüssel. Ich denke, das Verhalten ist normal nach einem Wechsel des Secure Boot Status. Ich werd jetzt mal den Wiederherstellungsschlüssel hervorkramen und eingeben und dann weiter berichten.

Nachtrag: Wiederherstellungsschlüssel gefunden und eingegeben. Bringt leider nix, es kommt nach kurzer Pause wieder der Proxmox Splashscreen und das Spiel geht von vorne los. UEFI wieder auf Secure Boot umgestellt und es kommt die bdsdxe-Meldung aus meinem ersten Post.

 

[ThoSo]

Es gab mit Bitlocker Stress nach einem Juli Update durch Microsoft verursacht:
https://www.borncity.com/blog/2024/...ker-abfragen-durch-windows-juli-2024-updates/

Hast mal von einem ISO die Reparatur probiert?
Was ist den der letzte Stand der Dinge, was schon probiert wurde (siehe #12)?

 

[Peter Altherr]

Danke, das ist der nächste Schritt, den ich machen werde. Die üblichen Schritte zur Startreparatur wenn von einem anderen Medium gebootet wurde. Ich werde berichten.

 

[Peter Altherr]

Booten von einer Windows 11 ISO führt zum gleichen Verhalten. Es kommt kurz die Meldung "Bitte eine Taste drücken um von CD oder DVD zu booten" und egal, ob ich das mache oder nicht bootet die VM nicht von der ISO. Ich denke ich werde eine neue aufsetzen und das HDD-Image der alten mounten und rüberschieben, was geht.

 

[ThoSo]

Booten von einer Windows 11 ISO führt zum gleichen Verhalten. Es kommt kurz die Meldung "Bitte eine Taste drücken um von CD oder DVD zu booten" und egal, ob ich das mache oder nicht bootet die VM nicht von der ISO. Ich denke ich werde eine neue aufsetzen und das HDD-Image der alten mounten und rüberschieben, was geht.

Seltsam - vielleicht liegt es ja nur an der VM selbst (Config - TPM).

 

[Peter Altherr]

Mittlerweile bin ich etwas schlauer. Die Meldungen aus dem 1. Screenshot sind keine Fehler- sondern ganz normale Statusmeldungen. Das Problem hängt ursächlich mit dem Update auf von Win11 23H2 auf 24H2 zusammen. Nachdem ich den CPU-Typ von Standard kvm64 auf x86_64-v2-AES geändert und einen Hard Reset der VM gemacht habe, bootet sie jetzt wieder ins Windows. Es kam sofort die Meldung, dass alle Änderungen rückgängig gemacht werden. Ein weiterer Reboot läuft dann durch bis zum Windows-Login.

Bevor ich den nächsten Anlauf zum Update auf 24H2 mache, werde ich das hier machen:

https://blog.gareth.com/index.php/2024/03/03/windows-11-24h2-proxmox-popcnt/

Und diesmal natürlich einen Snapshot der VM, bevor ich loslege

Nachtrag: Hat nichts gebracht. Folgendes hab ich gemacht, damit's läuft:

1. Wie im o.g. Blogeintrag beschrieben auf dem Node eine Custom-CPU mit POPCNT-Flag erstellt (die physische CPU des Nodes (Intel Xeon E3-1241v3 unterstützt POPCNT).
2. In der heruntergefahrenen VM die CPU von Standardeinstellung auf die von mir angelegte qemu64-popcnt umgestellt.
3. VM hochgefahren und versucht mit einer Win11-24H2-ISO zu booten. Ausser dem Prompt eine Taste zu drücken um von CD oder DVD zu starten passiert gar nix. Er bleibt in der Bootloop stecken.
4. Zurückgestellt auf die x86_64-v2-AES CPU und die ISO bootet.

Jetzt freu ich mich, dass die VM wieder startet und ich endlich das Inplace-Upgrade auf die 24H2 durchziehen kann.

Es bleibt die Frage, welche CPU-Einstellung in diesem Szenario aus Performancesicht die Optimale wäre...

Nachtrag2: qemu64 wie in diesem Thread empfohlen, hilft auch nicht, aber interessanterweise CPU-Typ host geht. Ist nur leider suboptimal, wenn die VM leicht migrierbar sein soll (nicht vom CPU-Typ des neuen Zielsystems abhängig).

Ich werd jetzt erstmal die Custom-CPU wieder entfernen und den CPU-Typ auf host lassen.

Wenn jemand einen Vorschlag hat, wie man ein Win11 24H2 dazu bekommt auf einer kvm64-/qemu64-CPU zu booten bzw. wie der CPU-Typ konfiguriert sein muss, dann gerne her damit

Nachtrag3: Nach etwas Stöbern im Netz hab ich jetzt die x86_64-v3 als CPU für die Win11 24H2 festgelegt. Die kommt, was die Unterstützung erweiterter Befehlssätze angeht, am nächsten an die im Node verbaute Intel Xeon E3-1241v3 ran und damit lasse ich es erstmal gut sein und kümmere mich um mein zweites Proxomox Sorgenkind.