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

Unter Linux kann es auch ein Problem sein.
Doch je nach Konfiguration liegt "/boot" mit auf "/" und ob von der 1TB SSD paar MB mehr belegt werden
interessiert dabei gar nicht.
Ich kenne auch die Idee "/boot" auf eine eigene Partition zu schieben, doch die sollte 1-2GB groß sein.
Da hat man dann etwas Platz für Notfall-Kernel usw.

Finde es auch schräg, dass die Partitionen so "auf Kante genäht sind".
Da nehmen sich die OEMs auch gerne mal 10GB+ für ihre "RecoveryPartition", aber bei den wichtigen
Partitionen wird geknausert.
 
Zuletzt bearbeitet:
Caramon2 schrieb:
Wichtiger Hinweis.

Ich würde LinuxMint Debian Edition nehmen/empfehlen (s. Anhang), das soll angeblich SecureBoot unterstützen: Ich nutze das nicht und bevorzuge generell den BIOS/CSM-Modus.

UEFI ist mir zu umständlich und fehleranfällig. - Insbesonders wenn ich eine Installation von USB booten will: Ich meine eine richtige Installation, kein Livesystem.
Mit aktivem SecureBoot sollte normalerweise außer das installierte OS gar kein Boot möglich sein außer von der internen Disk mit dem intern installierten Windows bzw. Betriebssystem. (theoretisch) -> weil sonst führt es ja das SecureBoot Feature ad absurdum. Würde man irgend externes OS einfach so booten können, dann wäre ja die Sicherheit nicht mehr gegeben, da dem OC Eigentümer/Besitzer ja die Hände gebunden sind, dass in diesem externen System nicht wer Root Rechte mitbringt und damit dann das System beliebig verwaltet. Mal von der Disk Vollverschlüsslung abgesehen.
Donnerkind schrieb:
Das halte ich für ein Gerücht, bei mir ist sie nämlich hinten. Vorne habe ich nur die EFI-Partition mit 100 MB.
Ursprünglich war die Partition in der Tat mal vorn. Bei Win10 21H2 und 22H2 hingegen ist sie hinten. Wann sie das geändert haben, keine Ahnung. Mit 2004 oder davor wahrscheinlich. Bei Win11 wohl auch. Zumindest was ich strichprobenartig geprüft habe.
Donnerkind schrieb:
Hab dann natürlich trotzdem ausgeschaltet.
Naja, brauchste dich halt nicht wundern wenn dann komische Sachen passieren. Kein Plan wie die Leute das immer hinbekommen, sich via Updates den PC zu zerrupfen... Macht man es nicht kaputt, braucht man auch keine so (mMn) windige Befehle wie sfc mit halbgaren Reparatur Optionen.
IsaacClarke schrieb:
Selbst jeder drittklassige Softwarehersteller kommt auf die Idee, ein Update zurückzuziehen bis es repariert ist, aber für Microsoft ist dieser Schritt scheinbar zu Kundenfreundlich.
Was sollen sie zurück ziehen wo es doch nicht kaputt ist?
Meine Frisch installierte Test VM läuft btw. durch. Das ist demnach kein allgemeines Problem sondern trifft unter bestimmten Ursachen auf. Welche genau dazu führen, dass die Partition zu klein ist, kein Plan, hab ich nicht untersucht.

Btw. wird das Update nur via Windows Update released. Sprich das wird keine per WSUS/SCCM gemanagede Enterprise Umgebung jemals zu Gesicht bekommen. Betrifft primär privat Personen.
Ergänzung ()

GTrash81 schrieb:
Ich kenne auch die Idee "/boot" auf eine eigene Partition zu schieben, doch die sollte 1-2GB groß sein.
Da hat man dann etwas Platz für Notfall-Kernel usw.
Das stammt eher aus Zeiten vor (U)EFI Boot. So hat man den Bootkram eben für alte Systeme zugänglich gemacht.
GTrash81 schrieb:
Da nehmen sich die OEMs auch gerne mal 10GB+ für ihre "RecoveryPartition", aber bei den wichtigen
Partitionen wird geknausert.
Wobei das teils auch andere Partitionen sind. Also nicht die WinRE Umgebung, um die es hier geht. In den Recovery Partitionen die du meinst liegt das OS Image zum vollständigen Restore. Das WinRE Environment um was es hier im Problemfall geht beinhaltet lediglich eine winzig abgespeckte Umgebung mit ein paar Recovery Tools. Das ist nur paar wenige hundert MB Groß. Entgegen so einem kompletten System Image inkl. Treiber, Software und Patches, was in zwei Stellige GB Bereiche rauf geht/gehen kann.
 
Zuletzt bearbeitet:
GTrash81 schrieb:
Doch je nach Konfiguration liegt "/boot" mit auf "/" und ob von der 1TB SSD paar MB mehr belegt werden
interessiert dabei gar nicht.
Exakt, so ist das auch bei mir. Ich wüßte gar nicht, warum ich für /boot ne extra Partition machen sollte.
 
GTrash81 schrieb:
Finde es auch schräg, dass die Partitionen so "auf Kante genäht sind".
Da nehmen sich die OEMs auch gerne mal 10GB+ für ihre "RecoveryPartition", aber bei den wichtigen
Partitionen wird geknausert.
Microsoft sieht halt nicht vor, dass man sich parallel zu Windows noch ein weiteres Betriebssystem installiert nebst eventuell dafür notwendige Daten in den speziellen Partitionen. Guck einfach mal, wie groß aktuell so ein gängiges Initfamfs oder Kernelimage ist und mit welcher Größe Windows die EFI-Partition erstellt.
Ergänzung ()

Kuristina schrieb:
warum ich für /boot ne extra Partition machen sollte.
Verschlüsselte Rootpartition wäre so ein Anwendungsfall. Wenn /boot Teil der verschlüsselten Partition ist, kann der Bootloader eher schlecht das Initramfs und den Kernel laden.
 
  • Gefällt mir
Reaktionen: aragorn92

Wiederherstellungspartition ist gelöscht, aber WinRE-Status: Disabled
Trotzdem läuft update in den Fehler:
1704990109239.png

Werde bei Gelegenheit entspannt hier durchlesen und erst mal abwarten ob MS reagiert.
 
Genau das will ich noch rausfinden, ob nur die Partitionsfummler den Fehler beschert bekommen.
 
  • Gefällt mir
Reaktionen: Engaged
Teckler schrieb:
ob nur die Partitionsfummler den Fehler beschert bekommen.
Nein. Standardinstallation auf leere (nicht partitionierte) SSD und ein paar Funktionsupdates. Nie Partitionen verändert. Der Fehler ist da.

fdsonne schrieb:
Nö, es läuft hier in meiner Test VM ohne mucken oder Kopfstände durch.
Hier ist es eine Endlosschleife. Made by Microsoft.

Dass es auf manchen Systemen funktioniert und auf anderen nicht ändert nichts: Microsoft hat es verbockt. Das Update funktioniert nicht wie es soll.
 
  • Gefällt mir
Reaktionen: iron_monkey, -=:Cpt.Nemo:=- und Teckler
Kuristina schrieb:
Exakt, so ist das auch bei mir. Ich wüßte gar nicht, warum ich für /boot ne extra Partition machen sollte.
Früher - vor anständigem Support seitens EFI bzw. mit exotischem Filesystem hast du da halt den Bootkram rein gekippt, wenn die MBR Größe nicht gereicht hatte. Bspw. ne per EXT2 formatierte /boot und ne was auch immer / Partition. Oder wenn du wilde Container Verschachtelung für Root gemacht (Encryption, LVM, Dedup Krams, ...) hast und das einfach nicht bootfähig war.

Das ist aber gut und gerne 10+ Jahre her.
Teckler schrieb:
Genau das will ich noch rausfinden, ob nur die Partitionsfummler den Fehler beschert bekommen.
Ich kann es mit einer Win10 x64 Enterprise - installiert als 21H2 aus 01/2022 -> gepatcht direkt nach Install auf 01/2024, gefolgt vom Enablement Patch auf 22H2 nachstellen.
Während aber eine 22H2 Install (Win10 x64 Enterprise aus 12/2023) frisch von der ISO ohne Probleme durch läuft.

btw. die gepatchte WIM nach dem Update hat bei letzterer Testkiste ~460MB. Das wird also knapp je nach Menge der Kompression das in die 546MB Recovery Partition zu bekommen. Aber scheint zu passen. Ich schau gerade ob ich rausbekomm, was da schief läuft bei der anderen Test Kiste, dessen WinRE noch 10.0.19041.1 hat vor dem Update.
Der Patch ist btw. lediglich 22MB groß, wenn ich das richtig sehe. Vielleicht fehlt dem Ding auch einfach ein Kompressions Kommando. Bzw. das Ausmiste Kommando, was man da via manuellem dism setzen kann...

dvor schrieb:
Hier ist es eine Endlosschleife. Made by Microsoft.
Ja logisch, es gibt halt Fälle wo es nicht tut. Leider ist der Infostrom relativ spärlich unter welchen Bedinungen das jetzt auftritt und wo nicht.
Fakt ist aber, es tritt nicht perse und immer auf.
dvor schrieb:
Dass es auf manchen Systemen funktioniert und auf anderen nicht ändert nichts: Microsoft hat es verbockt. Das Update funktioniert nicht wie es soll.
Wie hoch der relative Anteil der funktionierenden und nicht funktionierenden Installationen ist, ist nicht klar atm. Wenn es nach dem Maßstab geht, reicht dir ja schon ein Fehler und "Microsoft hat es verbockt" -> nur ist das reichlich realitätsfern so eine Ansicht zu haben, da eine Microsoft eben nicht für jede erdenkliche Konstellation eine Funktionsgarantie übernimmt.
Wenn du das willst, such dir nen Dienstleister der dir dafür Support gibt. Kostet halt... Aber dann bist du geschützt. Btw. bist du es auch wenn du die Updates über nen WSUS freigibst -> denn dann kommt das Update gar nicht ;)
 
  • Gefällt mir
Reaktionen: aragorn92, Teckler und Kuristina
fdsonne schrieb:
Was sollen sie zurück ziehen wo es doch nicht kaputt ist?
Meine Frisch installierte Test VM läuft btw. durch. Das ist demnach kein allgemeines Problem sondern trifft unter bestimmten Ursachen auf. Welche genau dazu führen, dass die Partition zu klein ist, kein Plan, hab ich nicht untersucht.

Btw. wird das Update nur via Windows Update released. Sprich das wird keine per WSUS/SCCM gemanagede Enterprise Umgebung jemals zu Gesicht bekommen. Betrifft primär privat Personen.
Wenn nichts kaputt sein soll, warum bieten sie dann eine Anleitung zur Fehlerbehebung an, ergibt keinen Sinn wenn es so sein sollte wie du sagst. Wenn es nichts mit Microsoft zu tun hätte, würde ich an Microsofts stelle gar nichts dazu schreiben, denn es wäre ja nicht deren schuld, wäre ja blöd Aufmerksamkeit auf sich zu ziehen und zu suggerieren einen Fehler begangen zu haben.

Ich habe keine Ahnung ob ich betroffen bin, ich bin noch nicht zu hause, ich habe meine Windows-Updates in den Gruppenrichtlinien 30 Tage aufgeschoben sie zu laden, ich bin nicht betroffen, zumindest noch nicht.

Ich habe auch nichts aktiv getan um diese Partition zu verkleinern, falls sie kleiner sein sollte, ich habe keine Ahnung warum man dies überhaupt zu sollte.

Genau, es betrifft Privatpersonen, die Anleitung die MS da zur Verfügung stellt wird die meisten dieser Leute überfordern, falls sie sie überhaupt finden, was ich auch bezweifle.

Tut mir leid, aber dieses "Der Nutzer ist an allem schuld" geht mir am Heckausgang vorbei, immer diese Unterstellungen und versuchten Relativierungen das MS ja gar nicht schuld sein könne, weil es bei ihnen ja nicht vorgekommen sei... einfach nur Kopfschüttel
 
  • Gefällt mir
Reaktionen: iron_monkey und piepenkorn
fdsonne schrieb:
reicht dir ja schon ein Fehler und "Microsoft hat es verbockt"
Fast. Eine Endlosschleife ist eine der schlimmsten Sachen die ein Programmierer erstellen kann. Da muss wenigstens eine vernünftige Abbruchbedingung hinein. Die fehlt ganz offensichtlich.

Dass das Update nicht funktioniert ist eine Sache. Dass der sinnfreie Installationsversuch immer wieder neu gestartet wird eine andere.
 
Hoffentlich passiert das meiner Gaming-VM nicht. Ich weiß nicht einmal, was eine RE-Partition ist. Also jetzt weiß ich's durch die Kommentare, aber vorher nicht. Sehr nutzerfreundlich!
Ergänzung ()

amorosa schrieb:
Als ich davon gelesen habe, hab ich erstmal Windows Update für 4 oder 5 Wochen pausiert.
Gute Idee, die Gaming-VM sollte das aushalten. Da bin ich nicht einmal bei CB eingeloggt. Trotzdem nicht optimal.
Ergänzung ()

xexex schrieb:
obwohl gerade die Macs und die iPhones sich einen Dreck um Standards kümmern und oft eine Sonderwurst benötigen
Windows als einziges verbreitetes nicht-unixoides OS steht da aber auch nicht so gut da.
 
IsaacClarke schrieb:
Tut mir leid, aber dieses "Der Nutzer ist an allem schuld" geht mir am Heckausgang vorbei, immer diese Unterstellungen und versuchten Relativierungen das MS ja gar nicht schuld sein könne, weil es bei ihnen ja nicht vorgekommen sei... einfach nur Kopfschüttel
Komm mal runter ;)
Es ist nunmal ein Unterschied pauschal ne Unfähigkeit zu unterstellen, wo es eben auch konstellationen gibt, wo es passt. -> das kannst du auch selbst nach stellen, wenn du dir mal die Arbeit machst.

Btw. geht es dabei auch gar nicht um Schuld Zuweisungen oder um Unterstellungen, wer jetzt was gemacht hat um Schuld zu schein, dass es nicht geht.
Ein Unternehmen kann in der Form keine 100% Garantie geben. Ist so. Hier rennen primär Hobby ITler und möchte Gern Profis in den Foren rum, die durch Frickellei sich den Käse manchmal!! selbst verbauen. Da reicht es nur mal in die Threads zu schauen, wo es daraum geht irgendwas zu erzwingen, was so nicht (mehr) vorgesehen ist. Startmenü, Cortana, irgendwelche UI Sachen, whatever.

Das ist kein Relativieren von dem Thema, MS hat hier offenbar nicht genug vorab getestet, dann wäre das aufgefallen -> zudem ja beim Upgrade von 10 auf 11 schon eine Lösung für exakt das selbe Problem existiert -> es wird ne neue WinRE Umgebung erzeugt. Das hätte man hier auch tun können. Haben sie aber nicht. Warum? Weis nur Microsoft...

IsaacClarke schrieb:
Wenn nichts kaputt sein soll, warum bieten sie dann eine Anleitung zur Fehlerbehebung an, ergibt keinen Sinn wenn es so sein sollte wie du sagst.
Doch natürlich ergibt das Sinn. Weil der Fehler ja auftreten KANN. Und um ihn zu lösen, gibts es einfach eine Anleitung.

Es ist übrigens weniger heiß gegessen als es gekocht wird. Der Fehler tritt nicht während des Updates auf, sondern weil das was das Update gemacht hat, am Ende dann wenige MB zu groß für die Recovery Partition ist.
Ich könnte mich irren, aber möglicherweise liegt das nichtmal am Update ansich, sondern es liegt an der Art, wie eben Updates eingespielt werden. -> das ist leider (muss man MS klar so vorwerfen) etwas, was der User im Nachgang nicht beheben kann, das kann nur MS selbst. Sie müssten den Inhalt der WinRE.WIM oder die ganze WinRE.WIM über Update austauschen anstatt die vorhandene patchen.

1704992762616.png


Oben ist die gepatchte - unten die "originale".
dvor schrieb:
Dass das Update nicht funktioniert ist eine Sache. Dass der sinnfreie Installationsversuch immer wieder neu gestartet wird eine andere.
Tja, das ist halt dem geschuldet, dass die Nutzer offenbar nicht in der Lage sind, das selbstständig durchzuführen, wenn es nicht erzwungen wird. Auto Update, so bescheuert das auch ist, ist halt gängige Praxis und keine Erfindung von Microsoft.
Btw. gibt es dann halt auch keine Abbruch Bedingung. Aber das gibt es auf nahezu keinem System, wo man automatisch ohne Zutun des Anwenders Updates durchführen lässt.
 
  • Gefällt mir
Reaktionen: aragorn92
DANKE Computerbase
Hab den beschrieben Weg per CMD im verlinkten Microsoft-Artikel genutzt,
ist jetzt 1GB und das Wiederholen des Updates war Erfolgreich.
 
fdsonne schrieb:
Naja, brauchste dich halt nicht wundern wenn dann komische Sachen passieren. Kein Plan wie die Leute das immer hinbekommen, sich via Updates den PC zu zerrupfen...
Es stand ja schon ca. ne Stunde an der Stelle. Die Platten-LED hat ab und zu (in scheinbar regelmäßigem Abstand) kurz geblinkt, sonst aber keine Aktivität weiter gezeigt. Leider war das ein lüfterloser PC, ich konnte also nicht wissen, ob er gerade unter Last war. Wenn das System kaputt geht wäre es mir sowieso egal, weil es nur für Experimente überhaupt aufgesetzt wurde.
 
Inplace Update hat mein Recov repariert und das Update ist jetzt Durchgelaufen.
Vor hatte ich halt die Partition von Hand gelöscht und mit 1,65GB eine neue erstellt von der sind im Moment noch 740MB frei von 1,65GB, hat sich also gut gegönng, vorher war die 500MB groß und fast voll.

Was bleibt, es ist ein katastrophales Update und für Laien nicht wirklich machbar, stelle mir meine Mutti mit ihren 69j vor an ihrem Lappy, würde sie niemals hinbekommen.

Kommt mir so vor MS dachte sich kool damit treiben wir viele Leute zu Win11 ;)
 
  • Gefällt mir
Reaktionen: LukS, TP555 und Teckler
fdsonne schrieb:
Auto Update, so bescheuert das auch ist, ist halt gängige Praxis und keine Erfindung von Microsoft.
Btw. gibt es dann halt auch keine Abbruch Bedingung. Aber das gibt es auf nahezu keinem System, wo man automatisch ohne Zutun des Anwenders Updates durchführen lässt.
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.
 
  • Gefällt mir
Reaktionen: iron_monkey und Kuristina
C4rp3di3m schrieb:
Kommt mir so vor MS dachte sich kool damit treiben wir viele Leute zu Win11
Oder den harten Kern der noch bei W10 ist zu W12 treiben
Vielleicht passiert sowas nun zufällig öfter :D
 
  • Gefällt mir
Reaktionen: C4rp3di3m
Zurück
Oben