Danke für den Hinweis
Hatte gleich nach dem Update Clonezilla Sicherung gestartet.
Aber auch nach Neustarts kommts Update immer wieder.
Schnellstart ist natürlich ausgeschaltet.
Datenträgerbereinung (incl Systemdateien) und Reparatur (dism+scannow) haben auch nichts gebracht.
Vielleicht sind die 843MB noch zu klein ?
Vielleicht bastel ich weiter ?
Aber nicht mehr heute.
1. eine Eingabeaufforderung mit Administratorrechten öffnen
2. mit dem befehl "reagentc /info" den WinRE Speicherort anzeigen lassen
"\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE" einfach hinter dem Wort "partition" auf die Zahl achten.
3. Deaktivieren der WinRE-Partition mit dem befehl "reagentc /disable"
4. Und hier gehe ich nicht den Weg, den Microsoft vorschlägt, sondern benutze einfach das Programm. "MiniTool Partition Wizard Free -64bit-portable"
5. Da ich noch nicht zugewiesenen Speicherplatz hatte, musste ich die Partition nur auf ca. 800 MB erweitern, wer das nicht hat, kann mit dem Tool aber leicht eine andere Partition erst verkleinern und dann den Speicherplatz neu zuweisen.
6. Neustart des PCs und anschließend Reaktivierung der WinRE mit dem Befehl "reagentc /enable".
Ich werde es lassen. Gestern wollte ich eigentlich mehr oder weniger spaßhalber auf meiner zweiten SSD mit einer Win 10-Installation ans Werk gehen, habe mir die Prozedur aber einfacher vorgestellt und brach dann nach einer Weile ab.
Hatte sich schon geklärt: Beim 1803 war die noch vorne und ab einem 2019er wurde sie bei einer Neuinstallation hinten erstellt.
Donnerkind schrieb:
Ich hab dann noch die übliche Update-Orgie losgetreten (kumulative Updatepacks) und beim anschließenden Runterfahren saß der Rechner eine Dreiviertelstunde lang bei "Windows wird vorbereitet, Schalten Sie den Computer nicht aus". Hab dann natürlich trotzdem ausgeschaltet. Beim Wiederhochfahren wurde ne Bereinigung durchgeführt. Oben angekommen trennt sich jetzt immer das WLAN nach kurzer Zeit
und ich bekomme wiederholt Fehler 8007000d beim Installationsversuch des kum. Updates. Und da fängt die Recherche an à la sfc /scannow. Frickelei, ick hör dir trapsen.
Meinen Erfahrungen nach machen Reparaturversuche von Windows es eher schlimmer und am Ende läuft es trotzdem auf eine Neuinstallation hinaus. Deshalb habe ich es bei merkwürdigen Problemen gar nicht mehr versucht, es irgendwie doch wieder hinzubekommen, sondern es gleich neu installiert. - Darin hatte ich echt Übung.
Bzgl. der Wiederherstellungspartition habe ich noch etwas getestet:
Wenn man das Laufwerk vor der Windows-Installation (egal ob 10 oder 11) so partitioniert, dass es für weitere Partitionen keinen Platz mehr hat, wird das Recovery auf C: erstellt, so dass es gar nicht erst zu so einem Engpass kommen kann.
Hier für GPT/UEFI: (bei MPR/BIOS braucht man nur eine ntfs-Partition (mit 4k-Cluster, da es sonst nicht bootet) übers ganze Laufwerk erstellen)
Nach der Windows-Installation ist die Partitionierung unverändert:
Und nach der Installation bekommt so man das Recovery ganz weg: (man kann noch vom ISO recovern - was sowieso zuverlässiger ist, da Microsoft ja gezeigt hat, dass sie auch das installierte Recovery durch Updates zerschießen können)
Wie mein Vater gerne sagte: Was man nicht hat, geht nicht kaputt.
Wofür ist eigentlich diese leere 16 MiB Partition: (vor dem Shot hatte ich Windows etwas genutzt und u. a. zweimal rebootet)
Bei der manuellen Partitionierung oben wurde sie nicht erstellt, war also nicht erforderlich, aber wenn ich sie nachträglich lösche, ist Windows traurig:
Wenn man das Laufwerk vor der Windows-Installation (egal ob 10 oder 11) so partitioniert, dass es für weitere Partitionen keinen Platz mehr hat, wird das Recovery auf C: erstellt, so dass es gar nicht erst zu so einem Engpass kommen kann.
Man kann die Recovery Umgebung in die Windows Installation integrieren, allerdings nur wenn man diese Partition nicht verschlüsselt oder später verschlüsseln möchte. Man kann die ganze Umgebung aber auch mit viel weniger Aufwand, über "reagentc /disable" deaktivieren und sich die Bastelei sparen.
Caramon2 schrieb:
Wofür ist eigentlich diese leere 16 MiB Partition: (vor dem Shot hatte ich Windows etwas genutzt und u. a. zweimal rebootet)
Eine MSR Partition ist wie schon die WinRE Partition oder überhaupt die Windows Recovery Umgebung in vielen Fällen nicht erforderlich. Sie wird dann allerdings vorausgesetzt, wenn man ein Software Raid erstellen möchte. https://en.wikipedia.org/wiki/Microsoft_Reserved_Partition
In deinem Fall hast du scheinbar zwar geschafft unter Linux die Partitionstabelle zu zerhacken, aber nicht dem Windows Bootlader zu sagen, wo er nach der Windows Installation nun suchen soll.
Leider konnte ich dann am Ende die RE-Partition nicht aktivieren. Es kommt immer wieder der Fehler, dass die RE-Partition nicht existiert.
Jetzt habe ich 250 MB, die nicht zugeordnet sind und von der Windows-Partition abgezogen sind, eine angebliche fehlerfreie RE-Partition, die ich aber nicht aktivieren kann.
Wieso ungeduldig? Wie ist es möglich, die RE-Partition wieder zu aktivieren. Der Befehl reagentc /enable führt zum Hinweis, dass keine RE-Partition gefunden wurde.
Wenn ich das gewusst hätte ... Wie kann ich das Problem oben dann rückgängig machen? Meine RE-Partition funktioniert ja nicht mehr - und kann ich die 250 MB wieder der Boot-Partition zuschlagen? Geht das einfach über die Datenträgerverwaltung, indem ich auf Volumen erweitern gehe bei der Parition c: und 250 MB eingebe?
@Lavater Stand die Beiträge hier immer wieder drin, dass man einfach warten sollte. Hast Du ein vollständiges Systemimage Backup gemacht? Das stellt vorherige Partitionen wieder her.
Habe hier erst reingeschaut, als der Fehler auftrat. Habe kein vollständiges Image Backup. Gibt es einen einfachen Weg, die 250 MB wieder an die Boot-Partition zu heften? Verstehe auch nicht, wieso der von MS beschriebene Weg nicht geklappt hat. Habe jeden Befehl korrekt ausgeführt.
Wenn ich das gewusst hätte ... Wie kann ich das Problem oben dann rückgängig machen? Meine RE-Partition funktioniert ja nicht mehr - und kann ich die 250 MB wieder der Boot-Partition zuschlagen? Geht das einfach über die Datenträgerverwaltung, indem ich auf Volumen erweitern gehe bei der Parition c: und 250 MB eingebe?
Wenn du eine legale Installation hast, wende dich doch einfach an deren Kundendienst: Die haben das verbockt, also sollen sie es wieder gerade biegen. Dafür hast du bezahlt.
Mit irgendwelchen Experimenten zerschießt du es höchstens ganz. Das wäre mir (insbesondere ohne Sicherung) zu heikel.
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.
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 ()
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.
Wir haben auch genug kleinere Kunden, die keinen WSUS betreiben.
WSUS finde ich allgemein eh nur bei Firmen sinnvoll, die groß genug für Kontrollgruppen aus jeder Abteilung sind und nicht einfach alles durchwinken und den als Cache nutzen.
Ohne SCCM/WSUS laden die meisten Firmen die Updates auch nur herunter und installieren die auf einem System zum Test, bevor es bei allen bestätigt wird. Ist halt die "händische" Variante für Kleinstumgebungen.
Und schau dir deine Server lieber nochmal an.
Wenn du die Partition nicht händisch wegkonfigurierst ist die als letzte Partition auf deiner Systemplatte vorhanden.
Ältere Server 2022 Installationen haben hier etwa 520MB, aktuelle 570MB. Server 2022 Azure Edition hat hier sogar >600MB. Man kann ja ruhig ein Update bringen, aber wenn die Partitionen per Default unterschiedlich groß sein können, muss man das auch berücksichtigen.
Und doch, ich werfe MS das vor. Die haben die Partition eigenständig angelegt und sind für die Kompatibilität ihrer Konfiguration verantwortlich. Das ist einer der Hauptgründe für Windows, dass es selten mit der Kompatibilität bricht. Nur weil andere sich nicht darum kümmern, erwarte ich das trotzdem von MS. Dafür zahlt man ja auch nicht wenig.