Wenn da Poti regelmäßig benutzt wurde, dürfte die Schicht, welche den Widerstand bildet, oder der Stift (je nach Bauweise) abgenutzt sein oder beides. Kontaktspray oder irgendwelche Öle helfen da auch nur kurzfristig. Das Poti muss ersetzt werden. Aber ob das bei PC-Lautsprechern Sinn macht, sei mal ...

Habe das jetzt mal getestet:

28120.2302.260608-1818.BR_PRERELEASE_IM_CLIENTMULTI_X64FRE_DE-DE.ISO

Klappt nicht zu 100%. Das meiste passt zwar, aber es wird leider die alte efisys.bin verwendet (CA 2011/SVN 1.0). Das hat natürlich zur Folge, wenn in der VM bereits SVN 3.0 für cdboot eingetragen ist ...

UUPDUMP "verbaut" immer noch die bootx64.efi mit 2011er Zertifikat.
In der "ConvertConfig.ini" die Option "UpdtBootFiles=1" setzen:

:: Change to 1 to update ISO boot files bootmgr/memtest/efisys.bin from Cumulative Update
:: this also update new UEFI CA 2023 boot files if detected

Ob das aber ...

Und bei der 29610.1000 das Setup manuell in der Konsole starten. Oder halt vorher die Boot.wim fixen.

Oder im Moment einfach ignorieren. Muss seitens Microsofts ein neues Update erscheinen, welches das Problem behebt.

Ja, kommt bestimmt noch was. Und eventuell auch ein neuer Converter Skript, dammit das Booten in das Setup mit der 29610 wieder funktioniert.

@ Harry S:

Stimmt. Wenn man die boot.wim austauscht, klappt das nicht. Da endet das mit dem fehlenden Medeintreiber. Interessant. Aber die install.wim in das Image der 26200.8655 kopieren, scheint zu funktionieren. Frickelei. Naja, egal erst einmal. Das Update ist ja noch nicht fertig. Mal schauen ...

Klingt nach Problem mit der install.wim. Dann kommt der gerne mit dem fehlenden Medientreiber.

Und was hast Du jetzt an der 26200.8728 korrigiert? Die boot.wim ausgetauscht?

Das Problem mit der 26200.8726 betrifft alle ISOs. Hier gibt es ein Problem mit dem Setup aus der Boot.wim. Das beendet sich, weil irgendeine Prozedur nicht gefunden wird. Das endet im Bootloop. Das aber speziell jetzt die Build und Revision. Die 26200.8655 bootete einwandfrei in das Setup. Das SVN ...

Das dürfte dabei bleiben, Solange das CA 2011 nicht widerrufen wurde, macht das eigentlich nichts. Problem ist halt nur, wenn SVN 3.0 für cdboot im UEFI steht. Dann muss man zur Erstellung der ISO die passende efisys_ex.bin verwenden, egal ob CA 2011 oder CA 2023.

Sofern SVN 3.0 für cdboot im UEFI eingetragen ist, dann wohl ja. Der Coverter verwendet da wohl die alte efisys.bin. Von Stick gebootet ist SVN 9.0 relevant sofern das CA 2023 verwendet wird (efisys.bin ist hier uninteressant). Hängt aber auch alles davon ab, was im UEFI für Secureboot eingetragen ...

@g-force; Ja, das liegt an der boot.wim der 8278. Mit der passt was nicht. Das Setup beendet sich mit "The specified procedure could not be found.", was an der Stelle zur Folge hat, dass neu gestartet wird. Aber welche Prozedur da nicht gefunden wird, keine Ahnung. Als Workaround könnte man jetzt ...

g-force hat geschrieben: 14.06.2026, 08:42 Alle ISO ab 26200.8728 machen bei Installation in der VM nur noch einen kurzen Boot-Loop.

Bei mir gerade auch so. 26200.8655 bootet normal, 26200.8728 nur Boot-Loop, unabhängig von den Zertifikaten oder der SVN oder wer die ISO erstellt hat. Im Moment keine Ahnung, woran das liegen könnte.

Das hängt jetzt wohl irgendwie mit der boot.sdl zusammen. Aber wieso und warum, da bin ich noch nicht ganz durchgestiegen, wie Microsoft das genau meint;

If you deploy dynamic updates such as this update to an existing Windows image, ensure the boot.stl file is included as part of the installation ...

Die komplette ISO muss neu erstellt werden. Die efisys.bin ist der Bootsektor für die ISO. Und hier muss die bootx64.efi mit CA 2023/SVN 3.0 enthalten sein. Die bootx64.efi in EFI-Order auf der ISO wird für das Booten hier nicht verwendet. Die ist nur für HDD/SDD/Stick gedacht. Wie gesagt, verwende ...