[English]Ich ziehe mal ein Thema in einen Blog-Beitrag, welches sich in Kommentaren abzeichnet. Besitzer von Fujitsu-Rechnern laufen Gefahr, dass die Geräte durch die Juni 2025-Sicherheitsupdates für Windows komplett gebrickt werden. Die starten nicht mal mehr ins BIOS/UEFI. Ursache ist wohl eine Aktualisierung der DBX-Records für den Secure Boot durch die Windows Updates. Lässt sich nur mit Tricks wieder korrigieren.
Fujitsu Esprimo P556
Ich habe mal auf die Schnelle geschaut, was es zum Fujitsu Esprimo P556 zu im Internet gibt. Es ist ein Desktop-System, welches gebraucht auf vielen Plattformen im Handel ist und wohl auf Windows 10 – oder mit Tricks auf Windows 11 – gehoben werden kann.
Laut Datenblatt kamen die für den Bürobereich gedachten Rechner mit Intel iCore i3-i7-CPUs und Windows 7 bis Windows 10, wird aber als openSUSE Linux-kompatibel ausgewiesen.
Nutzerberichte über gebrickte Geräte
Im Umfeld des Juni 2025-Patchday bei Microsoft haben sich Nutzer mit Problemberichten zu gebrickten Geräten hier im Blog in Kommentaren zum Beitrag Patchday: Windows 10/11 Updates (10. Juni 2025) gemeldet.
Nico eröffnete die Runde in diesem Kommentar mit dem Hinweis, dass die Windows-Update-Runde von Juni 2025 mehr als 20 Rechner vom Typ Fujitsu Esprimo P556 außer Betrieb gesetzt habe. Das Fehlerbild: Nach dem obligatorischen Neustart friert der Rechner sofort ein, und es wird nur noch das Fujitsu-Logo angezeigt. Man kommt auch nicht mehr ins BIOS bzw. UEFI. Ist für mich das Synonym für einen gebrickten Rechner.
Reset des BIOS und dann TPM deaktivieren kann helfen
Peter meldete sich in diesem Kommentar, weil er einen P556 mit Windows 11 betreibt. Er schreibt, dass er etwas experimentiert habe, und das BIOS (gemeint sind wohl die gespeicherten CMOS-Daten) resetten konnte. Dazu hat er die Knopfzelle auf dem Mainboard für einige Minuten raus genommen und das Gerät auch vom Strom getrennt (so dass alle Kondensatoren entladen wurden).
Seine Aussage war, dass das Problem mit dem im Hersteller-Logo hängenden Rechner sofort wieder auftritt, wenn das TPM-Modul im BIOS/UEFI aktiviert (enabled) wird. Ohne aktiviertes TPM startet der Rechner wieder. Er schließt daraus, dass irgend etwas beim letzten Update (oder schon vorher) etwas enthalten sei, was das TPM gecrasht habe. Ein testweiser Tausch von CPU und RAM habe nicht geholfen.
Bericht über Probleme bei Wortmann-Systemen
Auch im Beitrag Windows 11 24H2: Out-of-Band-Update KB5063060 startet ein Kommentar-Thread zu gebrickten Wortmann-Rechnern mit Fujitsu-Boards. Die kommen ggf. über OEMs aus Taiwan (siehe weiter unten zu Clevo). Leon gibt in diesem Kommentar einige Hinweise zur Vorgehensweise, um das Gerät per BIOS-Recovery wieder zum Laufen zu bringen.
Ein weiterer Bericht: DBX-Update verteilt
Gunnar Haslinger bestätigt in diesem Kommentar (danke für den Hinweis) ebenfalls das Problem und verwies auf seinen deutschsprachigen Artikel Fujitsu D3410-B Mainboard Recovery UEFI/BIOS-Flash nach SecureBoot DBX WindowsUpdate. Dort bestätigt er, dass die DBX-Datei für den Secure Boot von Windows durch das Update manipuliert wird, und das schief geht.
Er schreibt, dass die SBAT nach seiner Analyse zufolge nicht erneuert wurde. Allerdings sei die DBX von 8KB auf 24KB angewachsen. Daher vermutet er, dass der zur Verarbeitung / Ablage vorgesehenen Speicherplatz gesprengt wird und dann die Aktualisierung schief geht.
Gunnar skizziert für seinen Fujitsu D3410-B, wie er durch Recovern des BIOS aus dem Schlamassel heraus kam und die erneute Installation der Änderungen verhindert. Problem wird sein, ein passendes BIOS zu finden. In diesem Kommentar erwähnt Nico, dass er BIOS-Versionen bei Kontron in Augsburg gefunden habe. Ein anonymer Leser schreibt in diesem Kommentar, dass die Dateien für das P556/557 -BIOS noch auf den Fujitsu-Servern liegen. Er benutzte eine Suche mit einem Muster wie:
https://support.ts.fujitsu.com/ D3410
wobei D3410 die Modellnummer des Geräts ist, und erhielt Suchergebnisse mit Download-URLs von BIOS-Updates erhalten. Vielleicht hilft das ja weiter.
Meldungen auf reddit.com
Gunnar verweist in seinem Artikel auch auf den reddit.com-Beitrag Dozens of P556 with corrupted BIOS after update wo Dutzende an kaputten Fujitsu Esprimo P556 beklagt werden. Dort beschreibt ein Nutzer seinen Weg, um einen Fujitsu D3410-B wieder zum Leben zu erwecken. Ich empfehle auf jeden Fall den Artikel von Gunnar und auf reddit.com durchzugehen.
Meldung im Microsoft Answers-Forum
Leser Paul weist in diesem Kommentar auf den Beitrag After installing update KB5060533 I believe on 2 pc neither will now start im Microsoft Answers-Forum hin. Dort beschreibt jemand sein Problem mit Fujitsu-Rechnern und dokumentiert die hängenden Start-Bildschirme mit Fotos.
Eine Suche nach "kb5060533 fujitsu bricked" liefert weitere Treffer (auch einige italienischsprachige Ergebnisse), wo Esprimo P556 betroffen sind (siehe diesen Treffer).
Auch Systeme von Clevo betroffen
Nachtrag: Es weitet sich wohl bezüglich der betroffenen Rechner aus. Beachtet auch diesen Kommentar zum Artikel Windows 10: Juni 2025-Update KB5060533 verursacht Surface Hub v1-Bootfehler, der sich auf Rechner des taiwanesischen OEM-Herstellers Clevo (werden von Wortmann vertrieben) bezieht. Betroffen sind Maschinen mit Windows 10 und Windows 11. Speziell Nutzer, die Bitlocker einsetzen, dürften in zusätzliche Probleme laufen.
Ähnliche Artikel:
Microsoft Security Update Summary (10. Juni 2025)
Patchday: Windows 10/11 Updates (10. Juni 2025)
Patchday: Windows Server-Updates (10. Juni 2025)
Patchday: Microsoft Office Updates (10. Juni 2025)
Windows 11 24H2: Out-of-Band-Update KB5063060
Windows 10/11: Preview Updates 27. /28. Mai 2025
Juni 2025-Patchday soll Schwachstelle CVE-2025-33073 in Windows schließen
Windows Netzwerkschwachstelle CVE-2025-33073 (Reflective Kerberos Relay Attack)
Windows 10: Juni 2025-Update KB5060533 verursacht Surface Hub v1-Bootfehler
MVP: 2013 – 2016
Deswegen muss es eine strenge Trennung zwischen OS und HW/FW geben, windows darf ohne explizite Zustimmung keine permanente Änderungen an der firmware vornehmen.
Einem was in die DBX ohne Einwilligung zu schreiben ist Computersabotage.
Musst es ja nicht einspielen
Seit Windows 10: doch, muss ich
Nein must du nicht! W10 lässt sich noch so einstellen das da nix automatisch passiert! Wie das unter W11 aussieht weiss ich nicht, da mit das nicht auf mein Rig kommt.
Du bist keiner, der Ahnung hat, oder bist du noch mit Windows 7 unterwegs.
Unsinn.
Wird Zeit, das Hersteller wie MS hier Schadensersatzpflichtig werden. Dann würde die dreimal überlegen ob das richtig ist was die da einfach ausrollen.
Wie idealistisch kann man veranlagt sein? Ja! 😂
> Wie idealistisch kann man veranlagt sein? Ja!
Weniger labern, mehr lesen.
Wie leben im KI-Zeitalter; aber Nerds, die sich nur in Computerforen tummeln, sind unfähig, althergebrachte Suchmaschinen zu bemühen.: https://www.it-recht-kanzlei.de/vertraege-digitale-produkte-maengelhaftung-gewaehrleistung.html#abschnitt_79
Mich kannste damit nicht meinen – ich nutze so überhaupt keine AI/KI, außer die mittlerweile bereits standardmäßig in den Suchdiensten Integrierten! 😜
"Weniger labern, mehr lesen."
Kannste Dir schenken, Du Fraggle.
Als hätte der von i-einer RA-Kanzlei interpretierte "Mist" Anspruch auf Allgemeingültigkeit, insbesondere für Nicht-EU-Unternehmen – oder als würd's die scheren! 🤦♂️
> Als hätte der von i-einer RA-Kanzlei interpretierte "Mist"
das kannst Du Frau Keller-Stoltenhoff gerne persönlich schreiben, falls Du das Impressum findest. Für Korrekturhinweise ist man dort immer dankbar.
Wenn Dein Taschengeld schon reicht, empfehle ich dringend den einschlägigen Bd. 3 des Müko BGB (https://www.beck-shop.de/schuldrecht-allgemeiner-teil-ii-311-432/product/35739862).
> … ich nutze … in den Suchdiensten …
Du und Suchdienste nutzen – was dabei herauskommt, sieht man ja an deinen schnoddrig-uninformierten Einlassungen.
😂🤣
Also die Computersabotage § haben sehr wohl Gültigkeit…
nur musst du eben klagen um dein Recht auch zu bekommen, das fliegt dir nicht so einfach zu!
Und was das gegen Microsoft bedeutet kannst dir ja selbst ausrechnen… hoffe du hat ne richtig richtig potente Kriegskasse!
Recht haben und recht bekommen sind eben zwei paar Schuhe! Nur wer richtig fett Asche hat bekommt auch sein Recht!
Und dann bekommst Du am St. Nimmerleinstag ein Gerichtsurteil und bis dahin bist Du mit Deiner Firma nicht handlungsfähig und doppelt und dreifach pleite…
was ist wenn es kein Windows Fehler, sondern ein Fujitsu Fehler?
Wie kommt man darauf, dass hier Microsoft schuld ist?
Gerade bei DBX/SBAT Zeugs, sieht man wieder welcher Hersteller besondern sparsam mit Speicherplatz war.
Microsoft rollt etwas aus, was funktionierende Geräte soft-bricked. Du darfst aber gern qualifizierte Argumente bringen, warum der Speicher für damals zu knapp war und wo definiert ist, welcher Speicher erforderlich war. Und warum ein Software-Hersteller ungefragt – also ohne, dass man da überhaupt was tun kann – die Hardware manipuliert. Würde ich das mit einem Tool bei deinem PC machen, würde das sicher unter Computersabotage fallen. Microsoft darf das aber?
Denkst Du es ist "Zufall" dass Windows auf einem PC läuft?
Dass ein Hersteller schreibt "kompatibel mit Windows 10"?
Microsoft hat ein Programm schon seit Uhrzeiten.. dem können Hardware Hersteller beitreten, und dürfen einen Sticker drauf machen "designed for Microsoft Windows".
Es gibt hier sehr genaue vorgaben, was ein PC leisten muss. Was der Hersteller leisten muss, usw.
Normal wäre .. dass der Hersteller hier ein Update liefern muss. Nur Fujitsu ist anders.. denn die haben den PC Markt aufgegeben.
zum Lesen zum Thema:
das Problem ist simple, jeder der Beteiligten hat unterschätzt wie groß die DBX bei UEFI werden kann, deshalb braucht es das Update.
Man könnte also Spitz formulieren, Linux ist schuld, dass nun die Fujitsu Rechner sterben.
https://mjg59.dreamwidth.org/70348.html
https://neodyme.io/en/blog/bitlocker_why_no_fix/#the-linux-side-of-things-sbat
Microsoft darf das, weil Fujitsu den Microsoft KEK Schlüssel in der Firmware getestet hat. Du kannst im UEFI die hinterlegten Keys löschen und deine eigenen hinterlegen, Microsoft also aussperren. Musst dich dann aber um die Signatur der BootLoader selbst kümmern.
Microsoft rollt etwas aus, das eine Sicherheitslücke schließt und was korrekt implementiert einen Fehler, in dem Fall den 'EFI_STATUS Fehler – Code 9: EFI_OUT_OF_RESOURCES' zurückgebe sollte, was sich zusätzlich im Windows Ereignisprotokoll unter der ID 1795 niederschlägt. Abgesehen davon passiert nichts weiter außer, dass bei jedem Neustart versucht wird, dass Update doch noch zu installieren, falls der Fehler behoben wurde. Und selbst wenn kein Code zurückgegeben wird oder das Update ohne entsprechende Prüfung geschrieben wird dürfte maximal das Betriebssytem nicht mehr starten, denn das alles ist noch immer kein Grund dafür, dass das System nichtmal mehr grundlegend startet! Da hat Fujitsu offenbar mehrere Sachen verbockt und ist auch gemäß Spezifikation für ein Update zur Beseitigung des Problems verantwortlich!
Der Meinung bin ich immer schon gewesen. Wenn es möglich ist, von der Betriebssystem-Ebene aus das Secure Boot zu manipulieren, dann ist das ganze Konzept für'n A….
Q.e.d.
Jop… alles aus der Hölle der Bequemlichkeit.
100% korrekt.
Das Update muss mit dem im KEK des UEFI hinterlegten Zertifikat signiert sein. Das Konzept ist daher freilich in Ordnung. Man hat nur zu Beginn eben verabsäumt Maximalgrößen und eine Prüfung derer in die Referenzimplementierung aufzunehmen.
Und die Erfahrung zeigt, wenn an einer Stelle eine Grössenprüfung fehlt, dann fehlt sie auch anderswo und nette Buffer Overflow Exploits warten darauf, gefunden zu werden…
genau so ist es..
Es ist ja auch völlig ausgeschlossen, dass Zertifikate „verlorengehen". Ganz besonders bei Microsoft.
/Ironie aus
Kann man so sehen. Dann muss man aber nicht nur auf entsprechende Sicherheits- und ggf. weitere Funktionen verzichten, sondern hat auch keine Möglichkeit zum Massenrollout in großeren Firmen oder wenn die Mitarbeiter stark verteilt bzw. im Außendienst sind. Mal davon abgesehen, dass man sich drüber streiten kann, ob solche (erweiterten) Funktionen tatsächlich zur eigentlichen Firmware gehören.
Die DBX zu schreiben ist mehr oder weniger ein ganz normales Sicherheitsupdate für Secureboot, welches ein (zusätzliches) Zertifikat in die Variable DBX.db schreibt und das auch nur wenn der Bootloader des OS kompatibel ist, ähnlich, wie wenn der Systemeigene Zertifikatsspeicher aktualisiert wird nur, dass es entsprechend für den Bootvorgang gilt und dort ein Sicherheitsproblem beseitigt. Unbedarfte Anwender bekommen das automatisch, Profis könnten sowas mit entsprechenden Einstellungen verhindern!
Ich empfehle den Artikel von Gunnar Haslinger:
https://hitco.at/blog/fujitsu-d3410-b-mainboard-recovery-uefi-bios-flash-nach-secureboot-dbx-windowsupdate/
Dort ist beschrieben, wie man Win Updates "verbieten" kann, die SecureBoot-dbx-Dateien zu aktualisieren.
Fujitsus sind eol und Out of Support,
Einsatz auf eigene Verantwortung .
wer ist verantwortlich? wer ist für die Ausstattung von Arbeitsplätzen zuständig?
am Thema vorbei, gibt Privatleute mit solchen Rechnern, und wir werden uns aus Ressourcen- und Umweltgründen solche Ex und Hop-Strategie bald nicht mehr leisten können.
Und was wäre, wenn die Systeme noch im Support wären? Warten, bis der Hersteller reagiert?
Ich weiss, es ist schwer zu Akzeptieren, vor allem wenn man noch die Zeiten vor Windows 95 kennt.
Aber ein PC ohne Updates, also ohne Support ist Heutzutage nicht mehr verwendbar. Das betrifft nicht nur das OS, sondern natürlich den ganzen Stack. (was bringt es wenn das OS aktuell ist, aber eine gravierende Lücke in der Hardware oder Treiber?)
Das ganze .. ich verwende den aber nur noch Privat. Ist halt auch Schrott. Man nimmt also billigend in Kauf, dass jemand aus dem Rechner einer Zombie macht und andere schädigt. Quasi wie betrunken Autofahren, oder Autofahren mit kaputten Bremsen.
(ausgenommen sind Rechner ohne Internet)
Das ist ja auch der Grund schlechthin weshalb Microsoft bei Windows 11 so HW Anforderungen macht.
Wenn der Support von Intel/AMD für CPU Chips ausläuft, stellt auch Microsoft den Support ein. Das war früher anders.
Im Grunde färbt hier das Android Eco-System auf das WIntel Universum ab, bei Android ist es schon immer so gewesen.. dass der Plattformhersteller, oft Qualcomm, entscheidet wie lange es Updates gibt.
In dem Sinne, sind modernere Abrechnungskonzepte einfach ehrlicher. Wer ein Abo von Office oder Windows hat, kann sicher sein, dass er die Software auf moderner Hardware immer nutzen kann.
Wer eine klassische einmal Kauf-Lizenz erwirbt, hat oft keine Ahnung wie viel Nutzungszeit er wirklich bekommt.
Der Ruf nach "besserer" Software Qualität, würde das ganze verbessern, aber nicht lösen.
Ich nutze meine Privaten PCs so lange wie ich da ein aktuelles Windows drauf bekomme. Da Microsoft gegen Privates basteln nichts hat, kann es irgendwie nicht so wichtig sein. Ein paar Registry Einträge nach dem Start des Setups setzen, kann bei passender Anleitung jeder der es möchte.
Daraus ergibt sich das mein AMD Phenom II X4 965 basierter PC demnächst mal ausgetauscht wird. Da die CPU kein SSE4.2 unterstützt läuft 24H2 nicht mehr drauf.
Auf einem alten Laptop mit AMD A6 5200 APU und einer Radeon 8400 läuft hingegen Windows 11 24H2. Das funktioniert sogar besser als 23H2 was zuvor installiert war. Unter Windows 11 24H2 gibt es keine Bildruckler mehr, bei der TV Wiedergabe aus der ARD Mediathek. Sky GO funktioniert auch.
Auch wenn ein Rechner EOL ist, sollte ein wichtiges Update prüfen, ob die Voraussetzungen gegeben sind und nicht einfach die Hardware abschießen, sondern zumindest warnen, dass was schiefgehen könnte …
Jetzt hoffe ich, dass mein HP ProDesk nicht das gleiche Problem bekommt, der ist auch schon 10 Jahre alt.
Etwas OT:
Ich habe lange Zeit ein Systemtool genutzt, dass mit Admin-Rechten portable gestartet wurde, aber nur der Information diente.
Eines Tages hat es beim Start ungefragt, ohne dass ich es verhindern konnte, die Installationsversion draufgebügelt. Fand ich auch nicht prickelnd.
gute Forderung,
wie soll das gehen?
Das Update hinterlegt im Bereich den Windows beschreiben darf im BIOS, eine Datei.
Das BIOS stolpert beim Boot.
Wie soll das Update sowas prüfen?
Falls es technisch möglich ist: Größe des Speichers abfragen oder den User darauf hinweisen, das zu tun, bevor das Update eingespielt wird.
Stimmt, und die Voraussetzungen (kompatibler Bootloader) wurden auch geprüft, sonst hätte die Installation des eigentlichen Updates garnicht erst gestartet. Für sämtliche Prüfungen und den korrekten 'Einbau' des im Update enthaltenen Zertifikats ist allerdings das EFI bzw. Fujitsu verantwortlich und selbst wenn die das verbockt hätten dürfte der Rechner dadurch nicht komplett stillgelegt werden!
Das ein anderer Hersteller dieselbe Kombination von Fehler hätte ist eher unwahrscheinlich!
Bei uns laufen die PCs bis die User schreien oder sie auseinanderfallen – so haben wir aktuell 40% nicht W11 kompatible PC angesammelt :-)
die bis April 2024 neu gekauften Geräte sind noch ganz normal im Support.
Oder hast du die vor der Schließungs -Ankündigung im September 2023 gekauften Geräte alle sofort ersetzt?
Du musst auch kein Windows 10 verwenden.
Das ist nicht hilfreich!
Geh mal aus der Sonne!
Muß auch nicht hilfreich sein, behält aber trotzdem grundsätzliche Gültigkeit! 😉
Ich hab ein paar Kunden die auf Win10 sind und nicht migrieren können, und Fujitsu Rechner haben..
Die Frage bei so Fehlern ist immer .. gibt es ein BIOS Update ? Oder ist das ein Windows Fehler. Aber eher ist es ein BIOS Fehler, sonst wären andere Hersteller auch betroffen.
Die Kunden verdienen mit Hilfe dieser PCs viel Geld. Da wird genug sein, um alle paar Jahre die PCs mal zu ersetzen. 1-2 Tage Nutzungsausfall ist teurer als neue PCs. Diese Büchsen sind schon rund 10 Jahre alt.
Hast du schonmal von Privat-PC gehört? Schreib dich nicht ab…
in der Sache hast du vollkommen recht.
man darf das aber nicht schreiben.
Wir leben nunmal im Zeitalter der Nachhaltigkeit und Ressourcen- und CO2-Sparsamkeit, zumindest wird das von Politik und Medien tagein tagaus so vermittelt. Dazu passt nicht mehr das einfache Wegwerfen von eigentlich einwandfrei funktionierender Technik alle paar Jahre.
Die Zeiten, in denen es für Privat- und Büro-Anwender noch einen nennenswerten Fortschritt bei PCs gab, sind seit mindestens 10 Jahren vorbei. Es ist für die Masse der Nutzer heute weder nötig noch sinnvoll, PCs alle paar Jahre zu ersetzen.
Nicht korrekt. Hier werde keine monetären Gewinne erwirtschaftet. Die Ausfallzeiten für die Mitarbeiter waren auch deutlich geringer, meist um die 2 Stunden. Außerdem gibt es hier noch andere Aufgaben, als den ganzen Arbeitstag in den Bildschirm zu glotzen…
Während der Garantiezeit wäre solch ein Ausfall sogar noch schlimmer gelaufen, da hier der erste Reparaturversuch frühestens am nächsten Werktag stattgefunden hätte und sehr wahrscheinlich das Servicenetz in die Sättigung getrieben hätte. Damals hatten allein wir hier etwa 150 solcher Rechner im Einsatz, zusätzlich war Fujitsu hier in der Region sehr weit verbreitet.
Weil wir aber seit letzten Jahr genau diesen Rechnertyp nach und nach ersetzen, hatten wir sogar genug Ersatzgeräte zur Hand. Die größte Hürde war tatsächlich, dass Fujitsu den Zugang zu einem funktionierenden BIOS gekappt hat und wir uns anderweitig umsehen mussten.
Aber Hauptsache erstmal rumgepoltert…
Ich habe mir angewöhnt, mindesten die Vorgängerversion von Treiber- oder BIOS-Installationsdateien lokal zu archivieren, da der Herstellersupport gerne mal zu früh wegfällt.
Wie so oft hängt da halt andere Hardware dran, die sehr teuer ist, dessen Hersteller nicht mehr existiert.
Da hier einige spekulieren wer denn nun genau schuld sei, Fujitsu (das Bios) oder Microsoft (das Windows-Upate):
Streng genommen ist keiner der beiden Schuld.
Die UEFI-Spezifikation hat keine Angaben dazu gemacht, wie groß diese DBX Update Files werden dürften bzw. wie viele Einträge sie enthalten dürfen.
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.
danke für die Ergänzung
Grundsätzlich sollte aber Microsoft solche tiefergreifenden Änderungen nicht einfach von sich aus machen, sondern kommunizieren oder besser noch bestätigen lassen. Dass Microsoft sowieso ein Update-Problem hat, ist aber unbestreitbar.
Die Thematik tritt auch mit Linux-Betriebssystemen die UEFI SecureBoot DBX-Updates ausliefern auf. Es wird schlicht die neueste SecureBoot Forbidden Signature Database als Microsoft-KEK signierte DBX-Datei ausgeliefert, dazu gibt es einen im UEFI-Standard vorgesehenen Mechanismus, der dazu unabhängig welches Betriebssystem verwendet wird bzw. welches Mainboard/UEFI im Einsatz ist genutzt werden kann. Das DBX-File wird hierzu hinterlegt und beim nächsten Reboot dann vom UEFI verarbeitet. Wenn das UEFI daran "verstirbt" ist das grundstätzlich out-of-scope des OS, das hat dem UEFI das File lediglich bereitgestellt.
Wenn man es zeitlich etwas aufschlüsselt, dann dürfte das hier behandelte Update, ausschließlich auf Linux abzielen, um eine Schwachstelle im entsprechenden Bootvorgang mit aktiviertem SecureBoot effektiv auszuschalten.
[ https://www.borncity.com/blog/2025/05/17/microsoft-fixt-mit-mai-2025-update-den-linux-dual-boot-fehler-von-august-2024/ ]
Streng genommen existiert der Rückgabecode 'EFI_OUT_OF_RESOURCES' (A resource has run out. | Not enough storage is available to hold the data.) seit mindestens 'UEFI Specification Version 2.0 (released January 2006)' – Ältere habe ich nicht gefunden – und ein Fehler beim Update der 'DBX.db' dürfte in keinem Fall zu so einem Fehler führen!
[ https://uefi.org/specifications ]
Bei uns wurden einige Terra 1778R Laptops gebricked. Es lässt sich beinahe nichts mehr booten. Der Support hat nun BIOS Updates per Mail verschickt.
"…Dazu hat er die Knopfzelle auf dem Mainboard für einige Minuten raus genommen und das Gerät auch vom Strom getrennt (so dass alle Kondensatoren entladen wurden)…"
Was man auch versuchen könnte: Knopfzelle mal drin lassen, vom Netz trennen, und dann den Ein-/Aus-Schalter mehrere Male drücken, evt. gedrückt halten. So wird die Restspannung auf dem Motherboard aufgebraucht.
Hat bei mir schon geholfen.
Tritt das Problem immer noch auf, dasselbe Spiel aber mit entfernter Knopzelle.
Nutzt nichts, das DBX liegt nicht im flüchtigen CMOS. Was möglich ist: dass damit die Defaultsettings hergestellt wurden die auf dem betreffenden BIOS eventuell ohne aktiviertem TPM und SecureBoot vor konfiguriert sind.
In diesem Fall nützt es vielleicht nichts.
Mir hat es schon ein paarmal geholfen.
Z.B. mit dieser Müllhalde hier vor ein paar Wochen:
Gerätename Elite-800-G9
Prozessor Intel(R) Core(TM) i7-14700 2.10 GHz
Installierter RAM 32.0 GB (31.7 GB verwendbar)
Geräte-ID
Produkt-ID
Systemtyp 64-Bit-Betriebssystem, x64-basierter Prozessor
Stift- und Toucheingabe Für diese Anzeige ist keine Stift- oder Toucheingabe verfügbar.
Der Müll ist plötzlich nicht mehr gestartet, und ein weisses Fenster mit einer Meldung ist erschienen, dass der Netzteil-Lüfter nicht mehr erkannt würde.
Ich habe dann den PC ausgesteckt, mit Drücken des Netzschalters die Rest-Spannung verbraten, und seit dann läuft die Müllhalde wieder.
Erinnert mich an
https://www.borncity.com/blog/2024/06/11/bios-update-01-17-00-macht-hp-probooks-445-g7-und-455-g7-komplett-unbrauchbar/
ist das nicht lustig… da hat mich letztens einer hier angemacht, dass Open Source Software (war Firefox) und Systeme nicht in Konzernen eingesetzt werden könnten, weil es keinen Support gäbe.
Ich sehe mir diesen "Support" von Microsoft mit seinen Updates an und denke mir: Richtig so! Diese Probleme will ich auch nicht haben".
Der Support für Windows 10 läuft im Oktober aus und Windows 11 lässt sich nur mit unsupporteten Tricks auf solch alter Hardware installieren, was jedoch die Schleusen zu weiteren erwartbaren Problemen öffnet. Linux braucht kein TPM/Secureboot und dessen Designprobleme sind längst bekannt. War ja ähnlich dem Problem mit KB5034441, wo die RE-Partition zu klein war. Neue Betriebssystemfeatures setzen nun manchmal andere Hardware voraus und dann muss der Geizkragen eben in den sauren Apple beißen.
Was soll der Unsinn mit der Attributierung "dann muss der Geizkragen eben in den sauren Apple beißen."?
Wortspiel:
$hardware_taugt_nichts = true; // oder false, je nach Gusto
$windows_ist_doof = true; // je nach Erfahrung
$anschaffungskosten_apple = 2000; // Beispielpreis
$geizkragen = true; // wir sparen gerne
if ($hardware_taugt_nichts && $windows_ist_doof) {
if ($anschaffungskosten_apple > 1500 && $geizkragen) {
echo "Der Biss in den Apfel wäre jetzt wirklich sauer…";
echo "Aber manchmal ist ein Tapetenwechsel nötig.";
echo "Vielleicht lohnt sich doch der Griff zu einem Apfelgerät, auch wenn das Portemonnaie dabei weint.";
} else {
echo "Ein Apfelgerät könnte jetzt tatsächlich sinnvoll sein!";
}
} else {
echo "Alles gut, bleib erstmal bei deiner aktuellen Plattform. Spare das Geld für wichtigere Dinge.";
}
Standard Antwort: Mit Linux und OSS wäre das nicht nötig geworden. Und: Es gibt wichtigeres im Leben als die von dir erwähnten Produkte. Wenn die gesellschaftliche Entwicklung so wie die letzten Monate weiter geht, wird ein Apple-Produkt kaufen wollen, unser geringstes Problem sein. Stichwort: Gerade die Kündigung meiner Hausversicherung 'wegen steigender Kosten für Umweltschäden' bekommen. Die Preise für einen Nachfolgevertrag ohne Elementarschadenversicherung decken jährlich eine schönen refurbished PC, und hier schreibt jemand etwas von Geizkragen.
Ich hatte ja vorhin bereits geschrieben „Linux braucht kein TPM/Secureboot und dessen Designprobleme sind längst bekannt.". Ich nutze selbst derzeit nur Ubuntu und macOS wäre eine weitere Alternative zu Windows, damit so etwas nicht passieren muss.
Ich stand vor 15 Jahren fast vor dem Kauf eines Mac Mini. Mein Fehler war, dass ich bei Gravis vorbei ging und sah, wie das Teil verarbeitet war. Seid der Zeit habe ich in VMs mit macOS experimentiert, gefiel mehr zwar gut, aber Apples goldener Käfig. Seid dem iPad 1 mit UMTS und einem refurbished iPad 3 ist hier Apple freie Zone. Linux Mint tut es gut auf alten Dells.
Auf jeden Fall, wenn ich etwas bereut habe, dann das ich zu spät komplett auf den Pinguin umgestiegen bin. Windows habe ich jetzt im Privaten tatsächlich nur noch auf dem Rechner, um meiner Gattin jedesmal die Nachteile vorbeten zu können, wenn Sie wieder Ihre Klickibunti Windows-Sehnsucht bekommt, weil das ja so viel Schöner und einfacher als Linux ist (Anmerkung: Sie meint Windows wäre gar nicht auf dem PC, weil immer Ubuntu automatisch startet. Ihr zu erklären, das die beiden Systeme im Dual-Boot auf der Platte sitzen ist bis dato ein schier unerreichtes Ziel geblieben). Ansonsten kenne ich einige Entwickler, die unter Anderem wegen der guten Tastatur und des Displays ein MacBook Pro zum coden bevorzugen, aber natürlich kommt aus dieser Ecke ebenfalls Kritik an den exorbitanten Preisen von Apple. Leider ist es aber die einzige Alternative zu Linux wenn der Preis keine Rolle spielt und Windows nicht in Frage kommt, bzw. Man sich von den Strategen aus Redmond verabschieden möchte.
TPM und SecureBoot haben erstmal nichts miteinander zu tun.
Apple verwendet SB schon seit Jahren, allerdings nicht die offene UEFI Spezifikation sondern wohl eine Proprietäre und waren afair sogar die Ersten, die das über die komplette Produktpalette standardmäßig aktiv hatten. Intel Macs machen im Prinzip mehr oder weniger eine Kombination von SecureBoot und TPM während die Arm Geräte noch strenger sind was eher MS Pluton entspricht.
Ubuntu verwendet signierte Bootloader, solange SecureBoot während der Installation erkannt wird, wobei es i.d.R. auch keinen Grund gibt das zu deaktivieren.
Das stimmt halt nicht.
Linux könnte Secure-Boot sehr gut gebrauchen. Ohne Secure Boot ist die Disk-Encryption von Linux schrecklich anfällig.
Ohne ist nicht zu erkennen, ob jemand die Book-Disk von Linux manipuliert hat.
Aber es liegt auch am aktuellen Aufbau von Linux Distributionen dass es schwer bis unmöglich ist hier einen sinnvollen Support einzubauen.
Welchen Support meinst du genau?
SecureBoot wird von allen relevanten Distributionen seit Jahren unterstützt und zur Erhöhung der Sicherheit sogar empfohlen! Solange SB während der Installation aktiv ist passiert das alles automatisch, ohne dass der Benutzer davon etwas mitbekommt.
Linux unterstützt Secure Boot nicht, es umgeht ihn. Der SHIM ist nichts anderes.
Somit kann jeder mit Hardware Zugriff das Boot-Enviroment von Linux manipulieren, also das initramfs neu erstellen, dort Kernel module einschmuggeln, was auch immer.
Musstest du dich,wenn du ein recovery von USB startest, jemals für Linux authentifizieren? Warum nicht? -> weil es keinen Support für SB gibt der über den SHIM hinaus geht.
Jein, du scheinst auf einem älteren Stand zu sein bzw. das ist Distributionsabhängig.
SecureBoot lädt 'Shim', der sich selbst nochmals gegen die 'DBX' prüft und dann mit einem eingebetteten Schlüssel den nachfolgenden, auch signierten 'Grub' prüft, der dann, je nach Einrichtung, entweder gegen 'Shim' oder das 'UEFI' den signierten Kernel prüft – im Optimalfall zumindest (scheint beispielsweise bei 'RedHat' so zu sein)
Neuere 'Shims' erlauben nur, dass vollständige und komplett eigenständige ("standalone") und signierte 'Grubs' geladen werden, welche das dynamische Nachladen von Modulen (durch 'Shim-Lock') nicht erlauben. Diese müssen zusätzlich gegen die 'SBAT-Einträge' in der 'DBX' geprüft werden und es kann dadurch dann, trotz korrekter Signierung der Start verweigert werden z.B. falls diese bekanntermaßen anfällig sind oder veraltet und o.g. Nachladen zulassen.
Wenn das System verschlüsselt ist – bevorzugt mit Hilfe eines 'TPMs' oder neueren/besseren Sicherheitschips, die auch nochmals die unveränderte 'Boot-Kette' prüfen, ist der Hardwarezugriff egal; die Aufgabe von 'SB' ist es ausschließlich, den Bootprozess abzusichern und dann ist auch nix mit Manipulation! Nach der Entschlüsselung kann 'Grub' jede 'grub.conf' nachladen, die er will und damit auch neue Module. Wenn dein System unverschlüsselt ist, hast du aber sowieso ganz andere Probleme, wenn dir jemand was will!
Für den "Standalone" 'Grub' is der Distributor verantwortlich. Dieser sollte den 'Grub' natürlich ohne deaktivierten 'Shim-Lock' bauen (wird wohl neuerdings auch von 'Shim' geprüft!?) und den Pfad zur nachfolgenden 'grub.conf' ins verschlüsselte Dateisysytem setzen – diese wird dann nach Entschlüsselung verarbeitet. Ab hier könnte tatsächlich eine Lücke entstehen wobei man wohl die 'grub.conf' und die 'initrd' signieren und von 'Grub' prüfen lassen könnte und es wohl neuerdings auch eigenständige ("standalone") und signierte 'Kernel/initrd/usw.'-Images gibt, die direkt vom UEFI geprüft werden können – aber soweit bin ich noch nicht ;)
PS Recovery (von USB) musste ich schon ewig nicht mehr machen; aber auf meinem Hauptsystem läuft ja auch Windows 11 und außerdem bin ich, abgesehen von einem kleinen "Headless" 'Debian' für 'Pi-Hole' – in der Vergangenheit lief das auf 'CentOS' – und einem kürzlich installierten 'Sparky' (mit SecureBoot! – hehe) – möglicherweise kommen demnächst noch ein 'ClearOS', 'Tuxedo', 'Fedora' oder 'EndeavourOS' hinzu – ein ziemlicher Linux-Noob :P
Man kann z.B. eine manuelle Integritätsprüfung mittels Hashberechnung der /Boot Dateien per Script von Kernel, initramfs und Grub vor jedem Shutdown oder Neustart des Systems extern auf z.B. einem Hardware-Token speichern und vor jedem Boot abgleichen. Weiterhin gibt es Tools zum Auswerten von PCR-Werten und in Kombination mit systemd-measure kann man so prüfen, ob der Bootloader/Kern verändert wurde. So kann sichergestellt werden, dass die Hashes valide sind. Natürlich muss das zuerst auf einem cleanen System implementiert werden, ohne manipulierten Bootloader. Desweiteren können weitere Sicherheitsfaktoren wie Grub-Passwort, Netzwerkboot mit verifizierten Images (okay für Privatanwender eher nicht umsetzbar). Es gibt also Alternativen mit Measured Boot/TPM/automatisierte Policys, so machen es auch einige Spezialdistros.
Gnade uns g*tt
na was meint ihr,wie viele Firmen und Behörden sind am Montag nicht handlungsfähig? wo bekommt man eigentlich so viel Ersatzgeräte her?
Die Sache zeigt ganz deutlich wie defect by design das ganze PC Ecosystem ist. UEFI ist eine undurchdachte Ausgeburt. Für ein sicheres System besitzt nur der Nutzer kryptografische Schlüssel. Daher müßte der Bootlader grundsätzlich vom Nutzer signiert sein. Das kann schließlich auch problemlos bei der Erstinstallation erfolgen. Anzeigen des ursprünglichen zertifikats und dessen Verfifizierung und dann mit einem alterntiven Key signieren und hinterher den ursprünglichen Key deaktivieren. Technisch ist das alles kein Problem, nur daß eben M$ und die Hardwarehersteller nicht mehr machen können, was sie wollen.
Geht alles was du schreibst – zumindest im Normalfall. SecureBoot soll auch nicht für ein sicheres System sorgen, sondern ausschließlich dafür, dass beim Bootvorgang keine anfälligen Komponenten geladen werden!
Hallo, irgendwie ist der Beitrag 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
OS: Windows 11 Pro
Danke für die Beantwortung meiner Frage.
Wenn du SecureBoot aktiv hast, das Windows Update vom letzten Dienstag, 10.06 durchgelaufen ist und der Rechner danach problemlos neu gestartet hat, sollte nichts mehr passieren.
Bei Gunnar (Link oben im Beitrag) sind betroffene Geräte bzw. Mainboards aufgeführt.
Ob SecureBoot aktiv ist kannst du in einer Admin(!)-PowerShell mit 'Confirm-SecureBootUEFI' prüfen.
@TAFKAegal
Vielen Dank. Das schaue ich mir an.
hi, für mich als it-fachkraft mit >20 jahren berufserfahrung, heißt das Ganze nur eins:
– jede ms kb kann ab sofort auch die letzte sein – ob beruflich oder privat spielt nicht wirklich eine rolle, in beiden fällen ist unter umständen die Existenz in realer gefahr. daraus lassen sich weitere maßnahmen ableiten.
welche genau muss zum glück der sachbearbeiter nicht entscheiden.
ich sehe das ganze als testlauf, kommt ms damit durch – und das tun sie offensichtlich, muss man damit rechnen dass noch mehr aktiv genutzte, produktive hardware ins museum wandert …
Kann es sein, dass das Problem nicht erst mit den Juni-Updates auftritt sondern bereits vorher?
Hintergrund: Mir ist am 30. Mai beim Einspielen von Win10-Updates auf einem kleinen Shuttle-PC ebenfalls der Rechner nach dem Reboot ausgefallen. Das gesamte Szenario passt irgendwie auf die Situation. Der Shuttle ließ sich ebenso nicht wiederbeleben und wurde leider mittlerweile entsorgt. Das Entfernen der CMOS-Batterie hatte als letzte Möglichkeit nämlich auch keinerlei Wirkung entfaltet (RAM und SSD waren allerdings noch intakt).
Da der PC lange Zeit im 24/7 Betrieb war, hatte ich auf einen schleichenden Hardwaredefekt getippt — und würde den auch nach wie vor nicht zu 100% ausschließen — aber die Art des Schadensfalls und die zeitliche Nähe zu dieser Meldung lassen jetzt auch einen anderen Schluss zu.
Das wäre verdammt ärgerlich.
Bei einem Esprimo P556 mit Mainboard D3400-U1 gab es bei uns keine Probleme mit Windows 11 zumindest.
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,
(Funzt auch auf Non-Dual Boot Systemen)
Ja hilft. Zwar nicht, wenn wie hier die DBX.db ein Update bekommt oder ein Hardwarehersteller wie z.B. Fujitsu kräftig Mist gebaut hat, aber wenigstens, wenn ein Linux Distributor es bis zum heutigen Tag nicht geschafft hat einen anfälligen Bootloader durch eine neue, seit knapp 1,5 Jahren verfügbare Version zu tauschen. Steht übrigens oben!
Was soll eigentlich "Wintendo" sein? Achso… naja, wenn Lesen schon überfordert, dann klappt es mit dem korrekten Schreiben wahrscheinlich auch nicht!
die woche (und der hin***ern) ist gerettet
uns ist es gelungen die clients wieder zu erwecken – nach dieser anleitung (ich hoffe ich darf das hier posten)
Fujitsu D3410-B Mainboard Recovery UEFI/BIOS-Flash nach SecureBoot DBX WindowsUpdate
Mfg
AB++
Wir haben inzwischen eine GPO für diese Einstellungen gesetzt.
Zwar sind hier keine D34xx-Boards mehr aktiv, aber viel D35xx und Laptops aus dieser Generation.
Klar kannst Du die Anleitung von Gunnar Haslinger hier posten – der Beitrag ist aber prominent oben im Text verlinkt ;-).
Günter, ich habe dank deines Beitrags beim Kunden diese Katastrophe abwenden können. Dort habe ich nämlich Fujistu P920 und P9900 im Einsatz (D2912 und D3222). Ich weiß zwar nicht, ob die kaputt gegangen wären, will es aber auch nicht ausprobieren. Auf den Systemen läuft 1809 LTSC stabil; Credential Guard und Secure Boot sind aktiv. Ändern möchte ich das auch nicht unbedingt.
Kann ich mit dem Setzen des Registrywertes ein "Brick" im Juli verhindern?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000000
Denn man muss sich im Klaren sein: Dieser Dreck ist kommulativ!
Dann würde ich nämlich per GPO den Task "\Microsoft\Windows\PI\Secure-Boot-Update" deaktivieren und "AvailableUpdates" auf 0 setzen. Aber ich würde schon gerne vorher wissen, ob es erfolgreich ist. :)
Hallo,
das hatte ich in Windows 11 gemacht, bevor ich das Update einspielen ließ. Das brachte nichts. Nach dem Update waren die Werte zwar noch immer wie ich sie eingestellt hatte. Während des Updates wurde der Prozess wohl trotzdem durchgeführt.
Diese Werte scheinen nur zu helfen, dass diese Dbx nicht täglich erneut übertragen werden, wenn man eigentlich kein Update durchführt.
Danke für den interessanten Beitrag. Hattest du auch den Task abgeschaltet?
Dann frage ich mich, wie ich sicher die Updates deaktivieren kann, ohne Secure Boot zu deaktivieren? So kann ich auf jeden Fall erst einmal keine weiteren Updates freigeben. Das versetzt mich nicht direkt in Unruhe, würde ich aber gerne auch lösen. Zumal ich für das Abschalten von Secure Boot vor Ort sein müsste.
Dass der AvailableUpdates nichts bringt, klingt nachvollziehbar, es ist ja keine Richtlinie.
Hallo zusammen!
Kann mir mal jemand "auf´s Pferd" helfen?
Tritt das Problem nur unter W10 (KB5060533) auf oder auch unter Windows 11 (KB5060842 bzw OOB KB5063060) auf?
Wenn die Ursache ein DBX-Update/eine DBX-Vergrößerung ist, wäre das BS ja eigentlich egal… ?!
Und sehe ich es richtig, das scheinbar nur ältere Fujitsu-Systeme (oder Systeme mit älteren Fujitsu-Boards) betroffen sind, aktuellere Systeme bzw. Boards aber nicht?
Und vlt. auch deshalb scheinbar hauptsächlich Systeme unter W10 betroffen, da auf neueren Systemen, die das Problem gar nicht haben/hätten, eh schon W11 läuft?
(Bis auf 5 Ausnahmen sind die ältesten meiner ~250 Systeme aus 2019 (Esprimo P558, Board D3600), derzeit alle NOCH W10. Sind die wohl schon jung genug?)
DANKE!
TJ
Die Updates für Windows 11 (KB5060842 und KB5063060) enthalten auch eine neue Datei dbxupdate.bin, allerdings mit einer Größe von nur 4.418 Bytes.
Bei KB5060533 für Windows 10 beträgt die Dateigröße der dbxupdate.bin 24.005 Bytes (zu groß für Fujitsu-Mainboards).
Die Dateigröße 24.005 Bytes stimmt mit der Datei bei Github überein (RAW):
github. com/microsoft/secureboot_objects/tree/main/PostSignedObjects/DBX/amd64/dbxupdate.bin
Warum diese Datei bei Windows 11 kleiner ist weiß ich nicht.
Fehlen bei Windows 11 da nicht einige Einträge oder welcher Trick ist da benutzt worden?
Warum kann Microsoft die kleinere Datei nicht auch bei Windows 10 einbauen?
Die Angaben zur Dateigröße stammen aus den File Information csv am Ende der jeweiligen KB-Artikel.
Okay, DANKE für die Erläuterung!
Dann kann es , zumindest theoretisch, also sein, dass das Juni-Update ein Fujitsu-System mit W10 zum "Brick" macht, ein baugleiches System mit W111 aber weiter leben läßt, weil dei DBX-Tabelle für W10 größer ist als die für W11?
Hallo,
das kumulative Update 6'25 von Windows 11 enthält auch eine 24k Dbx und schießt das Mainboard genauso ins Nirvana. Ich musste das BIOS genauso wieder neu aufspielen und erwarte, dass ich diese Prozedur jetzt wohl bei jedem Update wiederholen muss.
Die DBX Geschichte geht noch ein bisschen weiter. https://arstechnica.com/security/2025/06/unearthed-in-the-wild-2-secure-boot-exploits-microsoft-patches-only-1-of-them/
Tja, da wird die eine Lücke wohl auch von "den Guten" genutzt, daher darf/muss sie noch bleiben?
Moin,
es sind auch "FUJITSU CELSIUS W550 power" mit "Mainboard D3417-B µATX"
und "Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz" betroffen … :-(
Nach Neustart bleiben sie beim BIOS Bildschirm hängen und nichts geht mehr :-(
Lösung die bei mir Funktionierte:
Workstation ausschalten, Netzkabel ziehen, Gehäuse öffnen, Batterie entfernen…
Ich habe ca 5 min gewartet…
Batterie wieder eingestezt, Netzkabel anstecken, Einschalten :-(
BIOS Bilschirm ist wieder da, Einstellungen überprüft/korregiert, Neustart und Windows 10 startet wieder und funktioniert wieder… :-)
Aber:
Viele Windows Funktionen wie Updateverlauf ansehen usw. funktionieren nicht mehr…
Natürlich hat das MS-Update alle Systemwiederherstellungpunkte gelöscht… :-(
Kein aktuelles Voll-Backup von C: vorhanden…?
Da hat man dann doch noch eine ganze Menge zu tun…
Ich frage mich dabei: Wieso funktioniert das Herausnehmen der Batterie eigentlich?
Ich hatte erwartet, dass das UEFI auf Grund einer nicht korrekten Implementierung kaputt geschrieben ist. Durch die Batterie sind ja nur die Einstellungen „verloren".
Ist Secure Boot durch das Zurücksetzen der Einstellungen nun ausgeschaltet, dass es wieder hochfährt?
Wenn du ein Update deinstallieren möchtest, kannst du das über die Konsole machen. Öffne dazu die cmd.exe als Administrator und
1) dism.exe /Online /Get-Packges
Dort kannst du am Besten über die Version des Updates den exakten Namen finden. Bei mir (10 21H2 LTSC) ist das für Juni: "Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.5965.1.5"
Diese Versionsnummer kannst du im Changelog des monatlichen Updates finden: https://support.microsoft.com/en-us/topic/june-10-2025-kb5060533-os-builds-19044-5965-and-19045-5965-eeae388c-ca1c-4569-95d7-3d7be2e0b8ba
2) dism.exe /Online /Remove-Package /PackageName:
Das Herausnehmen könnte deshalb funktionieren, wenn bei dem entsprechenden System/UEFI die kaputten Teile nicht persistent geschrieben wurden und somit mehr zurückgesetzt wird oder es dadurch sogar zu einem vollständigen Rücksetzen auf Werkeinstellungen kommt. Oder möglicherweise hat Fujitsu bei dem 'Xeon-Workstation-System' etwas sorgfältiger gearbeitet!?
Ich habe dazu seit Tagen einen unfertigen Kommentar dazu rumliegen bei dem ich aber bisher keine Lust hatte mich dranzusetzen.
PS Mich wundern die Aussagen mit den "Windows Funktionen" und den "Wiederherstellungspunkten" deutlich mehr!
Das Herausnehmen könnte deshalb funktionieren, wenn bei dem entsprechenden System/UEFI die kaputten Teile nicht persistent geschrieben wurden und somit mehr zurückgesetzt wird oder es dadurch sogar zu einem vollständigen Rücksetzen auf Werkeinstellungen kommt. Oder möglicherweise hat Fujitsu bei dem 'Xeon-Workstation-System' etwas sorgfältiger gearbeitet!?
Ich habe dazu seit Tagen einen unfertigen Kommentar dazu rumliegen bei dem ich aber bisher keine Lust hatte mich dranzusetzen.
PS Mich wundern die Aussagen mit den "Windows Funktionen" und den "Wiederherstellungspunkten" deutlich mehr!
Falls das jemandem hilft:
Ich hatte Kontakt zu Fujitsu. Nach deren Kenntnisstand sind "lediglich" folgende Modelle betroffen: (PC-Model, Mainboard, Bios-Update geplant ja/nein)
CELSIUS J550
D3427-A1
nein
CELSIUS W550
D3417-A1
D3417-A2
ja
CELSIUS W550 Power-L
D3417-A1
D3417-A2
ja
ESPRIMO D556
D3430-A1
nein
ESPRIMO D556/E94+ PPC
D3420-C1
D3420-D1
ja
ESPRIMO D756
D3431-A1
nein
ESPRIMO D956
D3432-A1
nein
ESPRIMO P556/ ESPRIMO PH556
D3400-A1
nein
ESPRIMO P756
D3401-A1
nein
ESPRIMO P956
D3402-A1
nein
ESPRIMO Q556
D3403-A1
nein
ESPRIMO Q556/D
D3403-B1
nein
ESPRIMO Q956
D3413-A1
nein
ESPRIMO X956 / ESPRIMO X956/T
D3444-A1
nein
Das deckt sich mit meinen Tests. Meine ältesten Fujitsu-Systeme stammen aus dem Jahr 2013 und vertragen das Win-Update problemlos. Es ist also nicht nur eine Frage des Alters der Geräte.
Mir hat es der Fujitsu-Support anders erklärt. Wenn ich mich nicht täusche, zitierst du hier das PDF, welches mitunter vom Support verschickt wurde und über der Tabelle steht betroffene Systeme. Somit sollten alle gelisteten Modelle betroffen sein. Das Ja/Nein bezieht sich darauf, ob ein Bios-Update rauskommt. Mitgeschickt wurden sämtliche ROM-Dateien für die Problembehebung. Der Support hat mir in meiner E-Mail explizit geschrieben, dass P556 und Q556 betroffen sind.
Danke für die Liste. Wir haben auch noch einige "D756" im Einsatz (mit Windows 10), die jetzt auch das Problem haben. Die sollten natürlich prinzipiell noch bis Oktober ausgetauscht werden, aber nun müssen wir schauen, wie wir die Uer wieder arbeitsfähig bekommen.
Der Support hat mir heute noch dies geschrieben. Sollte das Problem bei den betroffenen Systemen noch nicht aufgetreten sein, genügt es in der Regel im BIOS-Setup folgende Option zu setzen:
Security -> Secure Boot Configuration -> Secure Boot Control: Disabled
Ein BIOS-Update ist hierfür grundsätzlich nicht nötig.
Das Mainboard D3441-S1x ist definitiv auch betroffen, kann aber per Jumper in Recoverystellung und BIOS-Flashstick gerettet werden. Es empfiehlt sich also so einen Stick vorbereitet parat liegen zu haben.
Vermutlich wird auch das Abschalten des SecuredBoot helfen. Nur Vorsicht: Ich hatte ein Mainboard – als ich SecuredBoot abgeschaltet hatte, konnte das Bitlocker verschlüsselte Laufwerk nicht mehr gelesen werden, obwohl TPM aktiviert blieb. Besser vorher entschlüsseln.
Ach, mein Fehler. Wir meinen beide dasselbe.
Ich hatte ein relativ neues WORTMANN TERRA MOBILE 1516U Model 1220791 mit den oben beschriebenen Symptomen auf dem OP Tisch. Windows11 Home, trotz lokalem Benutzerkonto war die Festplatte verschlüsselt wovon der Eigentümer nichts wusste.
Das Gerät konnte durch neuflashen des BIOS über die glücklicherweise noch zugängliche UEFI Shell gerettet werden.
Ich hab hier zwei Gigabyte Notebooks Typ G6 MF und G6 KF deren Unterbau von CLEVO stammt. Diese sind auch an diesem Problem eingegangen. Nichts bootet mehr. Leider steht dann Online bei Gigabyte auch noch ein falsches Bios das nicht flashbar ist. Vom Gigabyte Support hab ich jetzt das passende Bios erhalten und war mit der UEFI Shell vom Stick aus in der lage die beiden Geräte neu zu flashen und jetzt laufen sie wieder. Andere Maßnahmen wie Secure Boot aus usw. haben nichts gebracht.
Hallo,
ich möchte die Party hier nur ungern stören, aber ist es schon mal aufgefallen, dass Geräte der Serie Fujitsu Lifebook U7511 unter Win11 23h2 schon seit 2025-05 die Updates nicht mehr korrekt installieren können?
Wir haben mittlerweile 8 Geräte, die bei den Updates im Fehlerstatus bleiben (wahrscheinlich mehr), wird eine Windows Neu-Installation versucht, bleiben die Geräte bei 2025-06 hängen (Schwarzer Bildschrim mit Mauszeiger=Textmarkierungsmodus, Strg+alt+entf keine Reaktion), nach einem harten Neustart wird das Update entfernt.
Kündigt sich hier das selbe Problem für den/die nächsten Monat(e) an?
Hat jemand einen Tip zur Problemlösung? Ich Suche jetzt seit Wochen…
Wir haben hier mittlerweile 8 Geräte zu stehen
Funktioniert die Installation des Updates mittels dism auch nicht?
1.
Update.msu auspacken zu Update.cab (Name und Pfad natürlich anpasssen):
expand -F:* c:\Updates\Update..msu c:\Updates\Update.cab
2.
Dism.exe /online /add-package /PackagePath:c:\Updates\Update.cab
3.
Falls das nicht funktioniert, dann mal im c:\Windows\logs\DISM\dism.logs nachschauen, was da drin steht als Fehlerbegründung.
Bei uns sind mittlerweile folgende Fujitsu-Rechner betroffen:
Q558 = 11 Stück in Verwendung (1 Problemfall bekannt)
Q7010 = 51 Stück in Verwendung (7 Problemfälle aufgetaucht)
Q5010 = 24 Stück in Verwendung (1 Problemfall bekannt)
Gibt es zu dem Case einen aktuellen Stand?
Ich habe nichts mehr gehört – verfolge das aber auch nicht