Microsoft hat mit dem Juni 2025 Patch-Tuesday Update KB5060533 für Windows 10 offenkundig wieder einmal neue Secure Boot DBX (Forbidden Signature Database) Updates verteilt. Diese werden einen Boot nachdem das Windows-Update vollständig installiert wurde dann beim nächsten darauffolgenden Reboot ins UEFI geladen und aktiv. Also nicht gleich am Windows-Update-Abend, sondern quasi 1-2 Tage (1-2 weitere Boots) danach.
Dieses DBX-Update hat meinen PC mit Fujitsu D3410-B Mainboard de-fakto gebricked. Mit gebrickt meine ich: Nach dem Einschalten erscheint noch das „Fujitsu“ UEFI-Logo, dieses hängt dann jedoch ohne jegliche Reaktion, kein SSD-Zugriff mehr (erkennbar an der LED welche dunkel bleibt), keinerlei Versuch zu booten, keine Möglichkeit von USB-Stick zu booten, nichts. Auch keine Möglichkeit noch ins BIOS (z.B. mit F2) einzusteigen – reagiert nicht mehr. Die Tastatur ist ebenfalls eingefroren, Num-Lock Key leuchtet und reagiert nicht mehr.
Warum weiß ich (jetzt nachdem mein PC wieder läuft), dass ein DBX-Update stattgefunden hat? Das findet man im System-Eventlog wie folgt: Filtern auf Quelle „TPM-WMI“, Event-ID +1034:
Tja, also Pech gehabt, PC gebricked – was tun?
Fujitsu hat eine Firmware BIOS/UEFI Recovery Möglichkeit vorgesehen, die ganz ohne Betriebssystem bzw. Bootmedium auskommt. Um dieses Recovery zu aktivieren muss man erst mal den hierfür nötigen Jumper suchen und finden:
Achtung, die Abbildung ist verkehrt herum. Wenn man das Mainboard vor sich liegen hat so ist die Mainboard-Kante nicht unten, sondern oben. Die Identifikation gelingt über den 4-poligen Speaker-Anschluss, darüber ist ein Recovery-Jumper der in der „Normal-Position“ wie grau angedeutet auf dem zweiten+dritten Pin angebracht ist. Diesen muss man auf den ersten+zweiten PIN versetzen, so wie das die Skizze mit dem Schriftzug „Recovery“ darstellt. Hier ein Foto auf dem ich die Position des Jumpers eingezeichnet habe:
Einen USB-Stick mit den BIOS-Files darauf an eine der direkt auf der Rückseite des Mainboards befindlichen USB-Buchsen anschließen (keine Front-USB-Ports oder USB-Hubs nutzen!) und im Recovery-Modus das Gerät nun einschalten. Es wird nach einigen Sekunden ein Piepton ausgegeben, und wenn die Files am USB-Stick gefunden werden gibt es dann auch noch „Fortschritts-Töne“ die einem mitteilen, dass sich noch was tut. Der Bildschirm bleibt hierbei die ganze Zeit über dunkel! Der Vorgang dauert gefühlt 2-3 Minuten. Wenn das Gerät fertig ist startet es neu, und – Hurra – ein BIOS-Screen der einem die Anweisung gibt nun auszuschalten, den Jumper wieder in Normalposition zu versetzen und den USB-Stick abzuziehen erscheint.
So, die spannende Frage ist noch, was muss auf dem USB-Stick drauf sein. Ich habe zu meinem Board leider keine Recovery-Anleitung gefunden. Einzig die oben abgebildete Skizze aus dem Handbuch, die einen zarten Hinweis auf das Vorhandensein des „Recovery“ Jumper gab (gänzlich ohne Erklärung im Handbuch) hat mich hoffen lassen, dass andere gefundene Anleitungen für andere Fujitsu Esprimo PCs möglicherweise ähnlich funktionieren. Jedenfalls habe ich schlussendlich folgende funktionierende Bestückung des USB-Sticks aus diversen Beschreibungen abgeleitet und positiv getestet:
- USB Stick (8GB) mit RUFUS FAT32 + FreeDos bootfähig formatieren
- Aus dem „Fsas_D3410B1xAdminpackageCompressedFlashFiles_V50011R1290_1232234.ZIP“ (das ich von https://support.ts.fujitsu.com/ heruntergeladen habe) folgende Files extrahieren und am USB-Stick ablegen:
- D3410-B1.rom
- D3410-B1.UPC
- D3410-B1.UPD
- DosFlash.BAT
- EfiFlash.exe
Ich vermute, dass der Stick für den Vorgang gar nicht FreeDos-bootfähig sein müsste, und ich vermute auch, dass die BAT und EXE-Datei nicht benötigt wird, aber in der oben skizzierten USB-Stick-Befüllung habe ich den Vorgang erfolgreich durchgeführt. Nachtrag vom 16.06.2025: Der Kommentar von Andreas vom 15.06.2025 unten bestätigt diesen Verdacht, er konnte den Flash-Vorgang allein mit der D34xxx.rom Datei am USB-Stick durchführen.
Bei anderen Mainboards heißen die Files geringfügig anders, z.B. beim Fujitsu D3441-S1x heißen die Files D3441-S1.rom + D3441-S1.UPC + D3441-S1.UPD … wenn man das AdminPackage für sein Board auf der Fujitsu-Website lokalisiert hat findet man die Files darin direkt im Wurzelverzeichnis + im DOS Verzeichnis.
Freilich muss man anschließend seinen Bitlocker-Recovery-Key zur Hand haben, um nach dieser Aktion wieder Windows 10 booten zu können … aber den hat man ja als geübter Admin ohnehin stets griffbereit.
Notiz an mich selbst: Der fertig vorbereitete USB-Stick ist (fürs nächste mal) im „Milka Naps Metall-Krimskrams-Kisterl“ verwahrt 😉
Updates zur Thematik und Reaktionen
Was wurde von Microsoft denn konkret verteilt?
Die Antwort findet sich in dieser Inhalts-Liste zum Cumulative Update KB5060533:
Windows 10 version 21H2 22H2 LCU x64-based
...
BioIso.exe,"10.0.19041.5794","03-Jun-2025","10:16","744,480"
dbupdate.bin,"Not versioned","03-Jun-2025","10:15","3"
dbxupdate.bin,"Not versioned","03-Jun-2025","10:15","24,005"
dbupdate2024.bin,"Not versioned","03-Jun-2025","10:15","4,832"
DBUpdateOROM2023.bin,"Not versioned","03-Jun-2025","10:15","4,840"
DBUpdate3P2023.bin,"Not versioned","03-Jun-2025","10:15","4,829"
DBXUpdate2024.bin,"Not versioned","03-Jun-2025","10:15","5,052"
KEKUpdateCombined.bin,"Not versioned","03-Jun-2025","10:15","716,120"
DBXUpdateSVN.bin,"Not versioned","03-Jun-2025","10:15","3,509"
SbatLevel.txt,"Not versioned","03-Jun-2025","10:15","45"
SbatLevel.cat,"Not versioned","03-Jun-2025","10:15","10,014"
...
Diese Files liegen am installierten System hier:
Verzeichnis von C:\Windows\System32\SecureBootUpdates
07.12.2019 11:09 3 dbupdate.bin
24.01.2024 12:17 4 832 dbupdate2024.bin
22.04.2025 19:56 4 829 DBUpdate3P2023.bin
22.04.2025 19:56 4 840 DBUpdateOROM2023.bin
10.06.2025 20:26 24 005 dbxupdate.bin <<< Aktualisiert!
10.04.2024 20:29 5 052 DBXUpdate2024.bin
14.01.2025 22:17 3 509 DBXUpdateSVN.bin
22.04.2025 19:56 716 120 KEKUpdateCombined.bin
15.08.2024 22:13 45 SbatLevel.txt
10.04.2025 20:28 70 474 SKUSiPolicy.P7b
10.04.2025 20:28 67 120 VbsSI_Audit.P7b
11 Datei(en), 900 829 Bytes
Die Historie des dbxupdate.bin Files kann man sich in diesem GitHub-Repo ansehen, mit dem Juni-Update ist das File von zuvor 8kByte auf 24kByte angewachsen. Das Überschreitet möglicherweise den Speicherplatz, den das Fujitsu-Bios hierfür vorgesehen hat. Man hatte vor einigen Jahren schlicht nie damit gerechnet, dass hier nicht nur ein paar dutzend sondern viele hundert Hashes und Zertifikate zu verzeichnen sein könnten.
Verhindern, dass Windows erneut SecureBoot DB/DBX Updates appliziert
Informationen seitens Microsoft findet man hierzu nur betreffend dem Aktivieren/Enforcen der DB-Updates, aber diese Informationen sind auch nützlich um die nötigen Stellschrauben zu finden, um das Update zu deaktivieren.
Da wäre zum einen dieser Registry-Key welcher bei mir wie folgt konfiguriert war:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000400
=> Den Wert auf 0 ändern.
Zum zweiten ist da folgender Taskplaner-Job, der das Update bei jedem Systemstart prüft und durchführt:
Aufgabenplanung => Microsoft\Windows\PI => Secure-Boot-Update => diesen auf „Deaktiviert“ konfigurieren:
ACHTUNG: Dieser Tipp ist nach bestem Wissen und Gewissen verfasst. Was ich geprüft habe: Mein System versucht danach kein SecureBoot-Update mehr durchzuführen (System-Eventlog, Ereignisquelle TPM-WMI ausgewertet). ABER siehe Kommentar von Marco unten, bei ihm wurde das Update beim zweiten Boot nach dem Windows-Update dennoch durchgeführt, eventuell wird das Update also auch noch durch einen anderen Vorgang getriggert!
13.06.2025 – Zahlreiche Berichte über andere Fujitsu D34xx Mainboards & PCs
Mittlerweile findet man im Netz in zahlreichen Foren oder z.B. auf Reddit Rückmeldungen, dass auch viele andere Fujitsu-Geräte von diesem Problem betroffen sein dürften:
- Fujitsu Esprimo P556
- Fujitsu Esprimo P956 Series, Fujitsu D3402 Mainboard
- Fujitsu Esprimo Q956 Series, Fujitsu D3413-A1 Mainboard
- Fujitsu Esprimo Q556, Fujitsu D3403-A1x Mainboard
- Fujitsu Esprimo X956/T, Fujitsu D3444-A11 GS 1 Mainboard
- Fujitsu D3400-A1x Mainboard
- Fujitsu D3402-A11 Mainboard -> BIOS für Restore
- Fujitsu D3430-A1 Mainboard -> BIOS für Restore
- Fujitsu D3441-S1 Mainboard -> BIOS für Restore
Download des BIOS ist entweder von der Fujitsu Website https://support.ts.fujitsu.com/ oder von der Kontron Website https://ftp.kontron.com/ (Benutzername ist „anonymous“, kein Passwort) meist auffindbar. Ergänzung 16.06.2025: Kontron ersucht diese URL für den Download zu nutzen, da deren FTP-Server derzeit überlastet ist.
14.06.2025 – Günter Born auf borncity.com zitiert / referenziert mich
Auch der bekannte IT-Blogger Günter Born hat sich dem Thema „gebrickte Fujitsu-Rechner“ nun in einem Blog-Beitrag auseinandergesetzt, seine Aussagen stützen sich weitgehend auf meinen (diesen) hier am 12.06.2025 bereits geposteten Blog-Beitrag. Eventuell folgen aber in dessen stark frequentiertem Blog noch interessante Kommentare anderer Betroffener, daher verlinke ich seinen Beitrag mal.
Spekulationen betreffend Schuldzuweisungen (Microsoft / Fujitsu)
In den Foren (vor allem borncity.com) lese ich nun vermehrt auch Spekulationen darüber, ob Microsoft denn „schadenersatzpflichtig“ sei, wenn es die Fujitsu-PCs mittels Windows-Updates zerstört. Es stellt sich also die Frage: Wer ist an dieser Misere schuld?
Streng genommen ist (möglicherweise) keiner der beiden Schuld. Weder hat Microsoft hier etwas fehlerhaftes fahrlässig verteilt (das DBX-File ist ja in Ordnung, es ist vermutlich nur zu groß). Noch hat Fujitsu bei seinem UEFI eine besonders „nicht dem Stand der damaligen Technik“ entsprechende Umsetzung vorgenommen.
Die UEFI-Spezifikation hat schlicht keine Angaben dazu gemacht, wie groß diese DBX Update Files werden dürften bzw. wie viele Einträge sie enthalten dürfen. Man hat wohl angenommen, dass ein solches Blacklisting eher die Ausnahme und für Einzelfälle relevant werden würde. Viele Jahre lang enthielt die Liste gar keine bzw. ein paar Dutzend Einträge. Erst in den letzten Jahren ist die Liste an angreifbaren und vormals aber gültig SecureBoot-signierten Bootloadern quasi „explosionsartig angewachsen“. Heute finden sich darauf hunderte Einträge (sowohl Hashes als auch Zertifikate).
Die Referenz UEFI-Implementierungen haben hier auch keine „Prüfung/Schutz“ beinhaltet. Die Hersteller hatten es also selbst in der Hand, wie viel Speicherplatz sie im UEFI hierfür vorsehen, und ob eine Prüfung ob die Grenzen des verfügbaren Speichers dabei nicht überschritten werden gesprengt werden. Wer z.B. „nur“ 32kB für SecureBoot-Keys/DB/DBX vorgesehen hat ist mittlerweile über dem Limit.
14.06.2025 15:45 – winfuture.com zitiert / referenziert mich
Auch winfuture.com hat das Thema nun aufgegriffen und zitiert / referenziert meinen Blog. Eventuell finden sich also auch dort im winfuture.com Beitrag demnächst noch sachdienliche weitere Leser-Kommentare.
hallo,
kllappt leider nicht, wir haben jumper umgestellt – und kommen trotzdem nicht ins recovery.
auch ps2 maus/keyboard wurden getestet.
wie viele tausende pcs wurden gebrickt, werden wir am montag erfahren…
BG
AB++
Auch bei mir sind mindestens 3 PCs von Kunden nach dem Update gebrickt!
Hallo Gunnar,
danke für die Zusammenstellung. Habe ich es richtig verstanden, dass mit „AvailableUpdates“=dword:00000000 und der Deaktivierung des Tasks Secure-Boot-Update das kumulative Juni-Update eingespielt werden kann oder sind noch weitere Schritte notwendig? Wir haben einige Esprimos P556 und Q556 in Einsatz, haben die Updates jedoch noch nicht freigegeben.
Gruß,
Silesius
Ich habe nur ein Gerät privat, beruflich nutzen wir andere Marken. Es besteht ein gewisses Rest-Risiko, dass das Windows-Update den Registry-Key wieder setzt und den Taskplaner-Job reaktiviert. Ich würde daher nach der Update Installation noch vor dem Reboot, sowie beim zweiten Reboot danach jedenfalls den Taskplaner-Job nochmals prüfen.
Danke für deine Antwort. Ich habe mitbekommen, dass offensichtlich doch einige Q556 das Update schon installiert haben. Hat man vor dem „letzten“ Reboot noch eine Möglichkeit den Brick zu verhindern?
Wie gesagt, technisch gesehen spielt der Taskplaner-Job das DB/DBX-Update ein. Wann der zuletzt gelaufen ist lässt sich in der Aufgabenplanung in der Spalte „Letzte Laufzeit“ prüfen. Ob die neuen Files schon im Verzeichnis C:\Windows\System32\SecureBootUpdates liegen oder erst nach den Neustart dort hineinextrahiert werden lässt sich auch prüfen.
Ach ja – und natürlich lässt sich prüfen ob was gelaufen ist, indem man wie von mir oben gezeigt im Eventlog\System nach Quelle TPM-WMI filtert. Die Ereignis-ID #1034 ist jene, die das Einspielen protokolliert. Sobald das Update appliziert ist, wird das BIOS es beim nächsten Reboot (oder Boot) verarbeiten.
Hilft es ggf, im BIOS/UEFI das Firmwareupdate von Windows zu unterbinden? Ggf. mit Einstellung „Restriceded“?
Ich kenne keine Einstellung im BIOS/UEFI die das Update von SecureBoot DBX (Forbidden Signature Database) Updates unterbindet. Mit einem Firmware-Update hat das nichts zu tun, es wird hier keine neue Firmware installiert.
Zumindest ist auch das Board D-3441-S1 betroffen unter Windows 11 betroffen.
Vor dem Update den Task zu disablen hilft nicht.
Vor dem Reboot zum Update war im Windowsordner noch immer die alte Datei drin, der Task disabled und der Registryeintrag auf 0.
Nach dem Reboot war die neue Datei im Ordner, der Task noch immer disabled und der Registryeintrag auf 0.
Dennoch blieb der Rechner ab dem nächsten Neustart hängen, ohne dass man ins BIOS einsteigen kann.
Da mein Mainboard aber auch vorher schon kein BIOS-Update hinbekam, wird es jetzt kritisch. Komischerweise Bootete der Rechner nie neu, wenn man im BIOS „Save and Restart“ sagte, sondern speicherte und schaltete sich ab. So schaltete er sich auch immer ab, wenn man von Windows oder Bootstick ein BIOS-Update durchführen wollte, statt das BIOS-Update durchzuführen. Hängt vermutlich miteinander zusammen.
Danke für die Rückmeldung, ich habe Deine Info oben im Artikel ergänzt.
Zumindest gibts für Dein Board D-3441-S1 das für den Recovery-Flash benötigte AdminPack, ich habe es oben mal in der Tabelle verlinkt. Müsste sich also damit recovern lassen.
Selbiges Problem bei Esprimo P956 – Mainboard D3402.
Hat mit dieser Anleitung wunderbar funktioniert. Die Fehlerbehebung hat – dank der ausführlichen Erklärung – keine 10 Minuten gedauert. Vielen Dank hierfür!
Hallo zusammen,
hat schon jemand einen Q556 mit D3403.A1 „wiederbelebt“?
Ich kann leider nirgends die benötigten BIOS-Files noch eine Dokumentation über die Jumperleiste finden.
Ich habe hier ca. 10 Q556 die die Grätsche gemacht haben.
Wäre super, wenn ich die wieder flott kriegen könnte.
Hier kannst du den Pfad auf dem Kontron-Server nachvollziehen:
https://learn.microsoft.com/it-it/answers/questions/2283219/problema-pc-fujitsu-esprimo-p556-e85-dopo-aggiorna?page=1
Für den Q556, bzw. das Board D3403.A1 gibt’s weder bei Fujitsu noch bei Kontron ein Bios zum runterladen. Auch für das Board gibt es keine Dokumentation.
Hab’s aber mit viel suchen und kombinieren hinbekommen.
Um an das ROM-File zu kommen hat mir diese Anleitung geholfen: https://askubuntu.com/questions/1538941/please-remove-the-installation-medium-then-dead
Die Anleitung hilft aber nur wenn man noch zu mindestens einem Rechner Zugang hat um in den Gerätemanager zu kommen und die HardwareID der Systemfirmware auszulesen, was bei mir zum Glück der Fall war. Für den Q556 mit dem D3403.A1 lautet diese: UEFI\RES_{def41966-5b56-4205-af27-333430334131}
Das ROM-File muss anscheinend exakt „D3403.A1.rom“ heißen damit es erkannt wird.
Auf dem Board gibt es eine PIN-Leiste mit sechs PINs. Der Jumper ist im Normalbetrieb auf 2-3 (von der Frontseite her gezählt). Für den Recovery-Vorgang muss er auf 1-2 gesetzt werden.
Für das Recovery habe ich wie oben beschrieben mit Rufus einen FreeDOS Boot-Stick generiert und das ROM-File darauf abgelegt.
Den habe ich an den rückseitigen, boardnäheren USB2-Port (schwarz) gesteckt und den Monitor angeschlossen, sonst nichts (auch keine Tastatur).
Dann den Jumper auf 1-2 gesetzt und das Netzkabel eingesteckt.
Nach einer weile piept es zweimal laut, danach ertönt dann eine ganze Zeit lang ein Geräusch das an das ticken einer Uhr erinnert.
Danach schaltet sich der PC kurz aus und geht wieder an.
Dann piept es wieder zweimal laut und ein paar Sekunden später erscheint dann auf dem Monitor eine Erfolgsmeldung mit den Anweisungen, abzuschalten, Stromkabel entfernen, Jumper zurücksetzen und USB-Stick entfernen.
Beim ersten Start dreht der Lüfter mal kurz hoch.
Danach liefen die Rechner (bis jetzt) wieder problemlos.
D3400-A11 – selbes Problem. Leerer Stick mit dem *.rom reicht; bei Kontron unter Services ist ein Dokument dass den Recovery-Flash beschreibt.
Danke für den Hinweis, dass die ROM-Datei ausreicht. Ich habe diesen oben im Blog-Post ergänzt.
Danke für den Artikel; bei mir hat es den Rechner entbrickt…
Weiß jemand ob das evtl. mit zukünftigen Updates von MS gefixt wird? Dann lass ich einfach das KB5060533 bzw. 06er Update aus. Oder gibts evtl. ein Fix von Fujitsu über Deskupdate / neues UEFI?
Ich hab hier sehr viele dieser Rechner – sind für den Austausch vorgemerkt, aber ich brauch noch bis Ende Jahr dafür und keine Updates bis Ende Jahr klingt auch nicht so toll…
Wie ist das mit Win11 Updates? Verursachen die auch die Probleme?
Ich weiß, nicht supportet auf der Hardware, aber geht hald trotzdem…
Übrigens, einen PC hats uns zerlegt in dem wir ein Ubuntu Live ISO gestartet haben.
Wenn meine These zutrifft, dass im Fujitsu-UEFI die Anzahl der DBX-Einträge bzw. der dafür benötigte Speicherbereich nicht ausreicht, dann gibt es von Microsoft hierfür keinen FIX. Die Behebung müsste Fujitsu mittels Aktualisierung des BIOS/UEFI bereitstellen, die betreffenden Modelle erhalten aber schon längere Zeit keine Firmware-Updates mehr, insofern ist hier nicht mit einer Behebung zu rechnen. Ich hoffe, dass meine im Blog-Post skizzierte Deaktivierung des TaskPlaner-Jobs betreffend SecureBoot-Update ausreicht, um nicht beim nächsten Update wieder betroffen zu sein. Und ich habe meinen Firmware-Recovery-USB-Stick nun griffbereit, falls ich doch mit einem zukünftigen Update wieder betroffen bin.
Alles klar, danke dir und auch für die tollen Tipps! – Roll ich mal sicherheitshalber zum Test auf 1-2 Rechner aus und teste das mal 🙂 LG
Hello, another option to avoid this horrid bug could be to simply de-activate SecureBoot in the BIOS, for this Fujitsu machines?
If this helps (I saw comments about this, but not tried myself) you would have to disable SecureBoot BEFORE the DBX-Update gets installed, otherwise it’s too late. And be aware you cannot use BitLocker with TPM if you disable SecureBoot – so if you use BitLocker with TPM you need to disable it.
Yes, I just have tested twenty D556 machines, disabled SecureBoot in the BIOS, just before the KB5060533 was installed (on Win10 22H2) ,and rebooted them a few times, none of them was bricked (look like that was just in time!). We don’t use Bitlocker at all.
And thank you for your article!
Thanks for this additional Information and testing out. I guess Windows does not apply DBX Updates when SecureBoot is turned off, as far as I remember the Powershell-WMI CmdLets for accessing those SecureBoot Variables and information are disabled without having SecureBoot enabled too.
Hallo,
irgendwie ist das Thema an mir vorbei gegangen.
Frage: Gilt das nur für die Desktop-PCs, oder auch für Notebooks, zum Beispiel Fujtsu Ceslsius H780 mit Intel Core i7-8750H, 2,20 GHz 6 Kerne , 12 logische CPUs
Wie kann ich bei dem Notebook rausfinden, welche Mainboard verbaut ist?
OS: Windows 11 Pro
Danke für die Beantwortung meiner Frage.
Mainboard findest du in den DMI Daten, am Besten mit dem Tool HWiNFO ermitteln.
Die von dir genannten CPUs sind Generation 8 Coffee Lake. Die oben genannten PCs und Mainboards sind Generation 6 SkyLake und teils Generation 7. Mir sind noch keine Meldungen über betroffene Generation 8 CPU basierte Geräte bekannt.
Okay, vielen Dank für die Rückmeldng.
Das heißt ich könnte Glück haben und ohne Probleme durchkommen. Ich betreue ein paar private Personen, welche sich refurbished Fujitsu Celsius H780 gekauft haben.
Bei diesen Rechnern habe ich das Windows Update erstmal bis 24.06.2025 ausgesetzt.
Gruss Edgar
Hallo,
anscheinend sind nicht nur Fujitsu-Mainboards betroffen sondern möglicherweise auch eine Reihe anderer Geräte. Das Problem tritt in ähnlicher Weise auch bei meinem Gigabyte G5 auf. Im Grunde gleiches Update (nur auf Win 11) und auch hier tut sich nach dem Gigabyte Logo nichts mehr. Und Reddit nach zu urteilen bin ich damit nicht allein: https://www.reddit.com/r/gigabyte/comments/1ladf27/gigabyte_g5_kf5_stuck_on_startup_screen/
Ich vermute das BIOS kann auch hier mit den 24KB nicht umgehen, auch wenn das Mainboard ein gutes Stück aktueller sein sollte. Nur scheint es bei dem Fall keine einfache Lösung zu geben. Da Laptop gibt es (soweit ich weiß) keine Jumper zum Umstecken und BIOS gibt es bei Gigabyte soweit ich sehe nur zur Installation über Windows. Da ich da offensichtlich nicht mehr reinkomme wird das so nichts mit der Aktualisierung. Wenigstens kommt man hier noch ins BIOS, aber das bringt offenkundig nicht viel.
Hi, für die Dual Boot User (also VernünftigesOS (Unixoid) & Wintendo) hat MS einen schönen workaround implementiert:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD
Dann muss man sich aber fürdehin selbst um die Updates kümmern bzw. diese Konfiguration wieder zurücknehmen, wenn man soweit ist.
Gefunden u.a. hier: https://linuxsecurity.com/news/vendors-products/windows-update-fixes-linux-dual-boot-boot-issues
Vielleicht hilft es ja dem einen oder anderen Admin – Use at your Own Risk und YMMV,
Jan
Danke für Deinen Hinweis auf SBAT Updates für Linux SHIM Boot Loader.
Allerdings sind SBAT und DBX Updates technisch gesehen zwei verschiedene Mechanismen, ich denke daher nicht, dass diese hier genannte SBAT Update Sperre irgend etwas an DBX Updates ändert bzw. diese hier in meinem Blog-Post erläuterte Thematik adressiert.
PCs der Wortmann AG mit Mainboard D3400-B22 scheinen auch betroffen zu sein, z. B. TERRA PC-BUSINESS 5060 (Art. 1009582) – interessanterweise aber offenbar nur sporadisch. Wir haben etliche solche Systeme bei Kunden stehen und bislang „nur“ zwei Totalausfälle.
Die entsprechende Vergrößerung des Speicherplatzes im BIOS fand bereits vor *vielen* Jahren statt.
Jedes BIOS, das die Fixes für Spectre/Meltdown (entdeckt 2017) beinhaltet, „sollte“ hier keine Probleme mehr haben.
Unser Kontron Server ist durch die vielen Anonymous FTP Login Versuche überlastet.
Bitte stattdessen https://ftp.kontron.com/main.html?download&weblink=3cb83a90a99c51160d2aa1f1f34cc340&subfolder=Products/Motherboards verwenden.
Danke für die Info. Ich habe den bereitgestellten Link oben im Blog-Post soeben ergänzt.
Was das Thema Spectre/Meltdown Microcode Updates betrifft: Ursächlich besteht da kein Zusammenhang, ob die betreffenden Fujitsu Boards diese Updates im Wege neuer Firmware jemals erhalten haben ist mittlerweile auch nicht mehr sonderlich relevant, da Microsoft seit April 2018 die Intel Microcode Updates auch über Windows Updates bereitstellt. Mein betroffenen BIOS war jedenfalls das letzte von Fujitsu verfügbar gemachte aus dem Jahr 2020.
Ich habe bei einem kleinen Kunden alte Fujitsu Esprimo P9900 stehen, die noch gut laufen und funktionieren. Dankenswerterweise habe ich bevor Updates installiert wurden, diese Beiträge gesehen und habe die Updatefreigabe noch am Wochenende zurückgezogen. Auf einem alten NUC und auf dem HPE DL350 G10 lief alles problemlos.
Auf diesen PCs läuft überall Windows 10 1809 LTSC. Es ist auch Secure Boot und Credential Guard aktiviert. Kann ich jetzt bis zum Lebensende der PCs keine Updates mehr freigeben? So töricht sein und ausprobieren, ob diese auch betroffen sein werden, wollte ich nicht.
Mein Hinweis auf Specte/Meltdown diente nur zu *groben* Abgrenzung des Zeitbereichs, ab dem releaste BIOS Versionen mehr Platz reserviert haben.
Bei mir war es ein Fujitsu Celsius W550 (D3417-A21 Mainboard)
Mit deinen Tipps läuft er wieder, Danke!
Hier noch der Link zum BIOS Download:
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=1BDE9EC5-0CFD-4800-BB8C-8D1FD27064D1
hi, anyone with a solution for fujitsu esprimo x956t
Turn off the PC and remove power cord. Hold the power button a few seconds. Connect power cord and start PC and press F2 immediately to enter BIOS setup. If you don’t see the BIOS setup retry procedure again.
In BIOS setup turn off TPM, save settings and restart.
If steps described before fail, remove bios battery and re-insert it again. Then proceed as described above by turning on power and press F2 …
This answer seems just a generic (maybe even AI generated) answer without a connection to this discussed issue. DBX Updates are not stored in CMOS and cannot be deleted or undone by resetting CMOS.
So just follow my posted guide to restore original Firmware.rom, that’s the only currently known working way to recover from this issue.
Ich habe einen Esprimo Q956 mit dem D3413‑A1 Mainboard. Da Fujitso und Kontron dafür nicht die passende zip zum download haben. Habe ich kurz bei ChatGPT nachgefragt und mir wurde empfohlen die ZIP vom D3417 zu downloaden und die .rom Datei entsprechend auf D3413-A1.rom umzubennen. Danach die Steps befolgt und zack funktioniert der Eimer wieder. Danke für den Work-a-round!
Hi Vaagar,
das klingt ja spitze! Ich habe genau das gleiche Problem…
Welche Datei hast du denn wo herunter geladen? Kannst du bitte den Link reinstellen?
Besten Dank!
Hallo, meinen Q956 Board D3413-A13 hat es auch getroffen. Finde aber leider nirgends das passende BIOS dazu. Weder bei Fujitsu noch bei Kontron. Hat vielleicht jemand eine Idee wo ich das „Admin Package“ sonst noch herunterladen könnte?