News KB5034441: Windows-10-Update bricht mit Fehlercode 0x80070643 ab

[iron_monkey]

Ein ähnliches Problem gibt es immer mal wieder mit zu kleinen /boot Partitionen unter Linux, aber Linux ist ja heilig, da motzt man nicht drüber.

Einem geschenkten Gaul schaut man nicht ins Maul!

 

[Krik]

In /boot landet bei mir immer ein neuer Kernel, deshalb hab ich da gleich 1,5 GiB reserviert.
Oder sollte der dann auch in /efi liegen? 🫣 Da würde ich aber mit 500MB nicht weit kommen.

Der Kernel muss weiterhin in /boot liegen, wenn du dich nicht totkonfigurieren willst. Ich sehe aber persönlich keinen Grund mehr, /boot in eine extra Partition zu legen.

Systemd bevorzugt es, wenn das efi-Verzeichnis unter /efi statt /boot/efi liegt. Es kommt aber mit letzterem auch klar. Falls für den Boot-Vorgang Treiber notwendig sind, müssen die in /esp liegen. Daher lohnt es, das auch in eine extra Partition zu packen.

 

[Renegade334]

Wird sie doch... Nur eben mit den bekannten Größen/Notwendigkeiten, welche seinerzeit bei Herrausgabe des Installationsmediums notwendig waren und nicht das, was Jahre später mal benötigt wird.
Bitte erstmal das Thema ansehen anstatt direkt los zu schimpfen!

Das kann man so aber auch zurückgeben.
Vorgestern ein frisches Server 2022 installiert und direkt nach dem CU 01/24 kam der Sicherheitspatch und schlug fehl.
Bei komplett umgeänderten Standardgrößen.

Allerdings sehe ich das eher als nervig und nicht als großes Problem. Das Update steht dann halt jetzt ein paar Tage in der Liste und alle Monitoring Tools drehen am Rad, aber da kommt garantiert zeitnah eine Korrektur.
Ich ärgere mich eher über die 10 Minuten vergeudete Arbeitszeit, bis ich das Problem eingegrenzt hatte. Vorgestern war der Fehler halt noch "neu" und trat plötzlich auf allen Systemen auf.

 

[mibbio]

Geil, ein enger Freund hat mit einem Partition-Tool rumgespielt, um den Fehler zu beheben und hat dabei sein System zerschossen (lässt sich zumindest nicht mehr booten ).

Bringt er morgen vorbei - mal sehen, was er verbockt hat.

Mal so ein Schuss ins Blaue, er hat bestimmt versehentlich was an der EFI-Partition verändert, wo ja der Bootloader vom OS liegt.

 

[Carrera124]

Einmal mehr fragt man sich, warum so etwas nicht vorab bei irgendwelchen Tests auffällt? Die Standardausrede, dass es zu viele Hardware-Software-Treiber-Kombinationen gibt, kann hier ja nicht gelten, wenn das Problem sogar bei einem frisch und clean installierten Win10 auftritt.

 

[jimmy13]

@Carrera124 Hatte mal ein Video gesehen, in dem gesagt wurde, dass sich MS inzwischen viele Tests einfach spart. Ob das wirklich so ist, kann ich natürlich nicht bestätigen, aber zutrauen würde ich es.

 

[qu1gon]

Es gibt doch kein Windows-Update, welches fehlerfrei ist oder keine Probleme macht oder?
Quasi bzw. gefühlt nach jedem Update gibts Probleme... ^^

 

[Fabian_otto]

Die Wiederherstellungspartition kann man dort (leider) nicht verändern - die schon weiter vorn im Thread verlinkte Anleitung von Microsoft (Link) funktioniert aber.

Wie bei anderen hier lief bei mir nach Neuanlegen mit mehr Kapazität (knapp 3GB) dann auch das Update ohne Probleme durch.

Das bekommt MS doch sicher als automatisiertes Update selbst hin. Ich fummel mich da jetzt nicht durch 23 schrittige Anleitungen durch.

 

[fdsonne]

Das kann man so aber auch zurückgeben.
Vorgestern ein frisches Server 2022 installiert und direkt nach dem CU 01/24 kam der Sicherheitspatch und schlug fehl.
Bei komplett umgeänderten Standardgrößen.

Ja und? Das Installationsmedium ist jetzt von welchem Datum? Gestern gab es nur 12/2023 zum Download. Also älter als die Patches.
Btw. ist bei einem 2022 Server gar keine Recovery Partition aktiv. Zumindest nicht mit einem regulären ISO aus dem VLSC.
Du müsstest jetzt für die aktuelle Erkennis ein 01/2024er Medium abwarten. Bei einem Win10 22H2 mit 12/2023 Stand des ISOs aus dem MSDN Portal funktioniert die Installation ohne Fehler.

Allerdings sehe ich das eher als nervig und nicht als großes Problem. Das Update steht dann halt jetzt ein paar Tage in der Liste und alle Monitoring Tools drehen am Rad, aber da kommt garantiert zeitnah eine Korrektur.

Und du lässt Updates bei Microsoft ungefragt, ungeprüft und ungetestet einfach auf Server ausrollern?
-> Mit WSUS oder SCCM dazwischen bekommst du das Update btw. gar nicht angezeigt. JFYI. Klingt irgendwie nach ner komischen Geschichte.

Ergänzung (12. Januar 2024)

Das ist alles keine Entschuldigung. Das System muss erkennen, dass das Update einfach nicht funktioniert und nach einer angemessenen Anzahl Versuche jene einstellen. Alles andere ist Mist und die Verschwendung von Resourcen.

Dabei stimme ich dir zu. Aber da MS das so nicht vorsieht, kannste drüber schimpfen ohne dass sich was ändert oder damit leben. Btw. ist das wie gesagt keine Erfindung von Microsoft und ist in anderen Umfeldern exakt identisch. Linux per Autoinstall bügelt dir das auch jeden Tag wieder neu drauf. Da wird auch nix erkannt oder sonstwas. Updates ausm Store (egal ob Apfel, MS, Android, ...) tätigen das so. Auto Updates bei Software im Windows Umfeld fabrizieren das ähnlich usw. usf.
Der Kritikpunkt ist ja gut und schön, aber das kann man jetzt schwer MS alleinig vorwerfen, wenn das irgendwie alle größen am Markt so tätigen.

 

[Weby]

Gibt es nicht mittlerweile eine automatisierte Lösung? Wie soll man bei einer hohen Anzahl an Computern überall die Partition vergrößern.....und was Microsoft da geliefert hat um das Update zu installieren ist ja auch keine finale Lösung für die kleine Partition.

 

[Terrier]

Einfach abwarten und die Finger still halten.
Normal kann Microsoft die Partition automatisch vergrößer oder auch eine neue Wiederherstellungspartition anlegen.
Wurde ja alles hier im Thread schon oft gesagt und Links von Microsoft, was da normal bei der Partition gemacht wird, wurden ja auch schon gebracht.
Nächstes Patchday ist in 4 Wochen.
Alte kumulative Updates sind dann eh immer enthalten

Das ist alles keine Entschuldigung. Das System muss erkennen, dass das Update einfach nicht funktioniert und nach einer angemessenen Anzahl Versuche jene einstellen. Alles andere ist Mist und die Verschwendung von Resourcen.

Bei mir gibt es keine automatische Wiederholung (Endlosschleife.)
Wenn, dann muss ich das Update jedes Mal wieder anklicken. "Wiederholen"
Konnte man das nicht irgendwo einstellen?
Updates suchen, benachrichtigen, aber selbst downloaden und installieren?
Irgendwas habe ich da doch mal gemacht.

 

[dvor]

Wenn, dann muss ich das Update jedes Mal wieder anklicken. "Wiederholen"

Nach dem nächsten Neustart wird es erneut automatisch (nicht) installiert. -> Endlosschleife.

Updates suchen, benachrichtigen, aber selbst downloaden und installieren?

Das war mal.

 

[col]

Gibt es nicht mittlerweile eine automatisierte Lösung? Wie soll man bei einer hohen Anzahl an Computern überall die Partition vergrößern.....und was Microsoft da geliefert hat um das Update zu installieren ist ja auch keine finale Lösung für

Microsoft shares script to update Windows 10 WinRE with BitLocker fixes

https://www.bleepingcomputer.com/ne...update-windows-10-winre-with-bitlocker-fixes/

Ich halte es aber genauso wie zahlreiche andere und warte auf das nächste Windows Update, insbesondere da ich sowieso keine bitgelockte SSD/Festplatte verwende.

 

[Fabian_otto]

MS arbeitet wohl mit Hochdruck daran:

https://support.microsoft.com/en-us...24-20666-0190331b-1ca3-42d8-8a55-7fc406910c10

Wenn ich das richtig verstanden habe, reicht eine Ausführung des Scripts und die WinRE Partition ist auf dem neuesten Stand und somit kein Update mehr nötig. Nun muss MS es nur noch aus dem Windows Updater rausnehmen und durch das Skript ersetzen.

 

[SPB]

Man muß ja schon froh sein, daß dieses versaubeutelte Update separat kam und nicht im großen monatlichen Sicherheitsupdate mit drin war. Hoffentlich kommen die da nicht noch auf dumme Ideen.
Ich habe seit über drei Jahren weder eine Recoverypartition, noch eine WimRE.wim in meiner Systempartition.
Mit W10 Home auch kein Bitlocker.
Im Problemfall wird das letzte Image zurückgespielt (ca 5 Minuten Aufwand) und fertisch.

 

[Lora]

MS arbeitet wohl mit Hochdruck daran

Das ist doch schon die Lösung, besser wie es selbst zu machen, wenn ich schon lese:

Und am Ende halt in der PS ausführen:

.\PatchWinREScript_2004plus.ps1 -packagePath "\\server\share\windows10.0-kb5021043-x64_efa19d2d431c5e782a59daaf2d.cab"

 

[Postman]

Ein ähnliches Problem gibt es immer mal wieder mit zu kleinen /boot Partitionen unter Linux, aber Linux ist ja heilig, da motzt man nicht drüber.

Weil es nur wenige privat nutzen und das sind oft freakige Fanboys.
Sollen doch manche wechseln, das interessiert so viel als wenn man weiß wer eine Unterhose trägt oder nicht.
Die wenigen Promil mehr kratzen keinen und den leichten Anstieg haben Linux höchstens dem Steam Deck zu verdanken.

 

[Lora]

Ein ähnliches Problem gibt es immer mal wieder mit zu kleinen /boot Partitionen unter Linux, aber Linux ist ja heilig, da motzt man nicht drüber.

Wer braucht schon ausreichend Platz für den Kernel, wenn man stattdessen einfach täglich ein Loblied auf Linus Torvalds singen kann? Schließlich sind zu kleine /boot Partitionen ein geheimer Test, um sicherzustellen, dass nur die wahren Gläubigen den heiligen Linux Weg beschreiten dürfen. Praise the penguin! 🐧

Spaß beiseite, als normaler Nutzer reicht die Standard Vorgabe, wer mehr braucht sollte das halt wissen.
Hier im Thread lese ich aber von vielen das sie nichts von dieser RE Partition wussten. Und wer weiß,
vielleicht kommen ja Drittanbieter Skripte die das System zerschießen oder schlimmeres.

 

[nobby_a]

Resümierend ist festzustellen: Wer Win 10 Home hat oder BitLocker nicht verwendet, braucht dieses Update eigentlich gar nicht.

 

[Volume Z]

Normal kann Microsoft die Partition automatisch vergrößer oder auch eine neue Wiederherstellungspartition anlegen.

NORMAAAL

Das scheint für Dich logisch aus der Tatsache zu folgen, dass KB5034441 genau das nicht tut.