Lustige Geschichte, letzte Woche erlebt kommt nun hier.

Tatsächlich habe ich bei mir hier einen uralten Acer Aspire Netbook bei mir mit Linux Mint im Einsatz. Läuft sehr gut damit, nichts einzuwenden. Aus einer Übergangszeit ist dort auch noch ein Dualboot mit vorher Windows 7 vorhanden. Später hatte ich mal mit der gleichen Freischaltnummer Windows 10 installiert und war überrascht, dass er damit sogar gefühlt schneller geworden war.

Jedoch wollte das Teil bis letzte Woche niemals das 1703 Creators Update holen. Konnte ich gut verstehen, die Hardware wäre sicher nichts für jahrelange Updates von Microsoft. Spasseshalber, ich arbeite dort eh nur mit Linux, habe ich dann letzten Dienstag 1703 per manuellem Doppelklick auf Setup.exe laufen lassen. Ich rechnete fest damit, dass dies nie zu Ende durchlaufen würde. Tat es nach etwa vier Stunden und etlicher Neustarte aber doch. 1703 läuft darauf immer noch gleich schnell (oder eben behäbig) wie zuvor. Ist doch nicht schlecht für einen Single-Corer.

Am Donnerstag hatte sich das Gerätchen bereits die einzigen zwei Zwangs-Updates für 1703 geholt: Flash und ein sonstiges Paket von Microsoft. So gut, so recht. Danach sprang die Update-Routine aber wieder an und der Lüfter säuselte in gewohnter Manier lauter, wenn das Ding beschäftigt ist. Was macht er denn nun? Tatsächlich! Er holt sich, ohne Nachhilfe das "Fall Creators Update" und installierte es etwas später gleich zügig. - Ich war baff. Das ging nun aber schnell! Und ohne Hänger, ohne komische Meldungen, na sowas?

Warum ich dies hier dann überhaupt schreibe? Nun, der Update-Vorgang hatte nicht nur das Bootmenü von Windows selber zurückgesetzt, sowas sind wir uns nach einem Feature-Update ja gewohnt. Nein, er hatte Linux sich selber (!) wieder ins Bootmenü geholt. Dass MS seit dem "Linux Subsystem für Windows" etwas vom Kuchen holt, hatten wir ja schon bemerkt. Sollte sich so die kleine Freundschaft etwa ausbauen lassen? Nicht wirklich, denn im gesamten Vorgang hat es noch Fehler.

Erst jetzt habe ich mal recherchiert. Seit dem 1607 "Anniversary Update" sei nämlich auch bekannt, dass Windows bei Feature Updates die Partitionstabelle zerschiessen kann. Und deswegen schreibe ich diesen Artikel nun wirklich: Mein Update auf 1709 hat die gemeinsame Datenpartition D: in der Partitionstabelle unnerreichbar hinterlassen! Sie war für Microsoft nicht unerkennbar, sie war in NTFS formatiert, weil man sie so auch aus Linux erreichen und gar beschreiben kann.

Einen freien Bereich der Platte hat das Feature Update sogar genutzt, um die zwei Wiederherstellungs-Partitionen einzurichten, die MS so wahnsinnig toll findet. Auf Geräten mit MBR-basierendem Partitionierungs-Schema nutze ich die maximal vier möglichen, primären Partitionen jeweils lieber, um weitere startbare Betriebssysteme einrichten zu können. Bei GPT würde das weniger eine Rolle spielen.

Unter Linux kann man u.a. mit dem Paket "testdisk" kaputten Partitionstabellen zu Leibe rücken. Dabei muss man aber jeden Wert der Tabelle kennen und die Geometrie der Platte beherrschen. Ich habe das Tool dann auch nur gerade genutzt, um ein paar Dateien von der Partition zu holen, die ich zuletzt bearbeitet hatte. Danach habe ich sie gleich neu angelegt und den Rest der Daten aus dem letzten Backup zurückgeholt.

Hätte ich den gleichen Vorfall nochmals (vielleicht bei 1803?), dann würde ich neu wohl statt mit "testdisk" mit einem richtigen Partitionseditor beginnen. Vor zehn Jahren hatte ich sowas mit "Ranish Partition Manager" gemacht, vielleicht gibt es was Anderes. Wer also, wie ich, eine etwas abweichende Anordnung auf der Platte hat, vielleicht vorsichtig etwas Zeit für Feature Updates einrechnen?