- nicht in Disk-Reihenfolge
- überlappend
Wenn nur eine, dann einfach mal ne Partition mit Startsektor 2048 und maximaler Größe anlegen und erstmal nur schauen, ob
ntfsinfo -m (aus dem Paket ntfs-3g) da was mit anfangen kann.not a bootable Disk VM MS Server 2016
- Thread starter CKFrizz
- Start date
Wenn nur eine, dann einfach mal ne Partition mit Startsektor 2048 und maximaler Größe anlegen und erstmal nur schauen, ob
Bei einem Nullpointer auf RAM hagelt es halt beim Zugriffsversuch sofort SEGVs, aber auf Platte eben nicht, und dann passiert sowas hier.
Jemand muß mal einen Build mit nem assert(writeaddress!=0) bauen. (Klappt natürlich nur mit bereits eingerichteten VM-Containern.)
Schon mal versucht ne Windows iso zu booten und in der Reparaturkonsole ein bootrec /fixboot und bootrec / fixmbr auszuführen?
Das hilft nur, wenn der Bootloader Stage 1 oder 2 beschädigt ist, aber nicht, wenn die Partitionstabelle komplett weg ist.
Hi,
Wenn wir die Kriterien weiter einschränken, nur bei SATA, nur wenn nach Sektor 0 und nur ein Sektor geschrieben wird (in den wenigen bisherigen Dumps, die wir bekommen haben, war wirklich nur der erste Sektor korrupt) und Heuristiken einbauen, um valide Writes zu erkennen, dann könnten wir uns überlegen das Logging generell im Standard-Build einzubauen und die Wahrscheinlichkeit einen Treffer zu landen wesentlich erhöhen.
das Problem ist, dass es viele gültige Write-Szenarien nach Sektor 0 gibt. Z.B. bei einer Disk die ext4 formatiert ist (ohne Partitionen), beim Mounten/Unmounten. Oder bei jeder validen Änderung einer Partitionstabelle. Ein Build, wo solche Writes und relevante Infos geloggt werden (nicht assert) könnten wir zur Verfügung stellen, aber wäre auch zu viel Lärm für alle die nicht betroffen sind. Leider scheint es jetzt auch bei den Betroffenen nicht wirklich häufiger aufzutreten, also ist eher fraglich ob so ein on-demand-Build einen Treffer landen würde.
Wenn wir die Kriterien weiter einschränken, nur bei SATA, nur wenn nach Sektor 0 und nur ein Sektor geschrieben wird (in den wenigen bisherigen Dumps, die wir bekommen haben, war wirklich nur der erste Sektor korrupt) und Heuristiken einbauen, um valide Writes zu erkennen, dann könnten wir uns überlegen das Logging generell im Standard-Build einzubauen und die Wahrscheinlichkeit einen Treffer zu landen wesentlich erhöhen.
Ist das Problem denn überhaupt schon einmal mit einem Filesystem direkt auf dem Device aufgetreten? In den Threads die mir bisher aufgefallen sind stand immer was von Windows und MBR ...
Oder repariert fsck -a das automatisch, und es fällt daher niemandem auf?
Was allerdings nicht so häufig vorkommt und schon gar nicht ohne manuellen Eingriff. Da könnte man die VM dann auch mal kurz ungepatcht starten.
Früher gab das ja mal häufig eine Option im BIOS, wo man den MBR-Zugriff einschränken konnte. Hat sich natürlich mit GPT weitgehend erledigt, das hat seine Daten ja woanders.
So oft tritt das ja nicht auf. Ich hätte eher Bedenken, daß das die Schreibgeschwindigkeit spürbar verschlechtert.
Nicht dass ich wüsste. Aber das ist ja nicht der Punkt. Wenn wir Logging machen, müssen wir valide Writes detektieren, um nicht allen Leuten ihre Logs vollzuspammen. Und das mit dem Filesystem ist halt ein Beispiel, wo solche Writes valide sind.
Im Bug-Report gibt's auch Fälle mit Linux, und sogar einen mit FreeBSD, aber leider haben wir da keine Dumps. Die wären sehr interessant, um zu sehen, ob es die Korruption bei verschiedenen Gästen das gleiche Muster hat oder eben nicht.
Für Leute die öfters betroffen sind könnten wir schon eher einen Build mit mehr Logging machen, die würde es vermutlich nicht so stören, wenn false positives in den Log-Messages auftauchen (kann man dann ja gleich sehen welches Device es war).
Checks ob offset < 512 ist, ist eine CPU-Instruktion. Das wäre vernachlässigbar. Alle anderen Checks und False-Positive-Dedektionen werden dann nur gemacht falls der erste Check getriggert hat.
Genau weil es nicht häufig auftritt und nicht reproduzierbar ist, wäre allgemeines Logging viel besser als ein Spezial-Build, der erst extra installiert werden muss. Sonst haben wir dann im Laufe des nächsten Jahres ~10 neue Reports und bei allen war der Spezial-Build nicht installiert. Aber wie gesagt, allgemein Logging einzubauen, erfordert, dass eben nur unter den ganz bestimmten Kriterien geloggt wird, um nicht aller Leute Logs vollzumüllen. Wie solche Kriterien sein könnten, hab ich ja schon geschrieben:
Aber mount/umount macht man auch nicht so oft.
Und selbst das sollte daran erkennbar sein, daß sich nicht der ganze Sektor verändert.
Allerdings.
War das eigentlich immer auf zfs bisher?
Zu prüfen ob der Sektor auf 55AA endet oder - für den Fall von fs on raw device - fs magic enthält oder im Fall von Schreibzugriffen auf Sektor 0 mit dem vorigen Inhalt zu vergleichen und kleine Änderungen zu ignorieren sollte eigentlich alle legitimen Zugriffe abdecken.
Ansonsten käme es mal auf nen Versuch an, wieviel Logging denn so auf einem üblichen System auftritt.
Ach Leute, ist ja Wahnsinn, da kann ich euch nicht folgen.
Die Umwandlung von cqow2 zu raw und zurück habe ich mit folgenden Befehlen durchgeführt:
und zurück mit
Aber ja, auf die Idee, mit der Installations-DVD den Bootsektor neu zu schreiben, bin ich gekommen und dieser Versuch war nicht erfolgreich.
Vielen Dank
Michael
Die Umwandlung von cqow2 zu raw und zurück habe ich mit folgenden Befehlen durchgeführt:
qemu-img convert -f qcow2 -O raw vm-110-disk-0.qcow2 vm-110-disk-0.imgund zurück mit
qemu-img convert -f raw -O qcow2 vm-110-disk-0.img vm-110-disk-0.qcow2Aber ja, auf die Idee, mit der Installations-DVD den Bootsektor neu zu schreiben, bin ich gekommen und dieser Versuch war nicht erfolgreich.
Vielen Dank
Michael