Kernel-Oops beim VPN-Start: Belege, die es wert sind, aufbewahrt zu werden

Den VPN-Client zu starten ist ein bequemer Zeitstempel und keine Ursache, und dieser Unterschied entscheidet, was als Nächstes geschieht. Wenn ein Kernel-Oops in diesem Moment auftritt, geht es um die Wahl zwischen einem brauchbaren Fehlerbericht und dem fünfmaligen Wiederholen desselben Absturzes auf einer Produktionsmaschine. Bewahren Sie vier Dinge vor dem Neustart auf: den exakten Kernel-Build, den ersten Fehler-Trace, den Taint-Zustand und eine kurze Beschreibung alles anderen, was sich in derselben Minute geändert hat. Der Rest ist Interpretation, und die Interpretation kann warten, bis die Belege an einem sicheren Ort sind.

Den ersten Fehler erfassen, nicht die letzte Zeile

Der erste Oops im Protokoll ist der, auf den es ankommt, denn jeder spätere Fehler kann Folgeschaden eines bereits ungesunden Kernels sein. Kopieren Sie den Kopf zusammen mit dem Call Trace, da der Kopf die fehlerhafte Anweisung und den Registerzustand enthält, die den Codepfad bestimmen. Ein Bericht, der bei der letzten Zeile beginnt, ist für den, der ihn eine Woche später liest, wenig wert.

Wenn die Maschine bereits neu gestartet ist, liegt der Kernel-Puffer des vorherigen Starts oft noch im Journal, sofern damals ein persistenter Speicher aktiviert war. Lesen Sie ihn aus der gespeicherten Datei, statt die Last neu zu erzeugen, denn eine zweite Reproduktion kann überschreiben, was Sie brauchen. Wo die Maschine kein Journal über Neustarts hinweg behalten kann, ist eine serielle Konsole oder netconsole der einzige Weg, auf dem der Fehler jemals sichtbar wird.

Den Build festlegen, bevor Sie ein Symbol lesen

Funktionsnamen und Offsets bedeuten nur gegenüber der Binärdatei etwas, die sie erzeugt hat, also notieren Sie Kernel-Release-String und Build-Kennung der Distribution zusammen. Eine Symboldatei aus einem anderen Build zeigt mit voller Überzeugung auf die falsche Zeile, was schlimmer ist als gar kein Symbol zu haben. Behalten Sie die Version des Kernel-Pakets, nicht nur die Upstream-Nummer, weil Distributionen viel zurückportieren.

Module außerhalb des Baums verdienen eine eigene Zeile im Protokoll, da ein getainteter Kernel begrenzt, was ein Betreuer schließen darf. Lesen Sie den Taint-Wert, statt ihn aus einer Modulliste abzuleiten.

Ein Taint ungleich null ist keine Anschuldigung und macht den Bericht nicht wertlos. Er sagt dem Leser, welche Komponenten beim Fehler geladen waren, und manche Flags führen dazu, dass ein Bericht eher durch Richtlinie als durch Urteil herabgestuft wird. Notieren Sie den Wert, die Modulnamen und ob dieselbe Hardware und Last jemals einen Kernel ohne sie ausgeführt haben. Genau dieser letzte Vergleich trennt eine neue Regression von einem langjährigen Fehler.

Auslöser und Defekt trennen

Das Starten des Tunnels nutzt normalerweise einen Pfad, der bereits existierte: einen Netzwerktreiber, eine Queue-Disziplin, eine Offload-Funktion oder einen Energiezustand. Der Auslöser erklärt, wann der Fehler auftritt, nicht welcher Code falsch ist, und den Auslöser als Ursache zu behandeln führt zu einer Reihe von Konfigurationsänderungen, die nichts beheben.

Ein funktionierendes früheres Image ist ein Beleg, kein Beweis. Ändern Sie beim Vergleich je Start eine Komponente und bewahren Sie die Ergebnisse an einem Ort auf, der die Maschine überlebt.

Prüfen, was der Betreuer tatsächlich verwenden kann

Lesen Sie den Bericht, wie ein Fremder ihn lesen würde, bevor Sie ihn senden. Wenn die Konfiguration, die genaue Abfolge und die Build-Identität vorhanden sind und die Zugangsdaten entfernt wurden, ist der Bericht verwendbar. Wenn es ein Screenshot eines Stack Traces ist, kommt er mit der Bitte um dieselben Informationen zurück. Der Leitfaden zur Fehlersuche im Kernel beschreibt, wie ein brauchbarer Trace und passende Symbole aussehen.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Jeder Befehl oben liest nur Zustand, und die ersten beiden sollten vor dem nächsten Neustart laufen, wenn die Maschine sie noch beantworten kann. Wo das Journal nicht persistent ist, sind diese beiden die einzigen, die jemals wieder funktionieren werden.

Schwärzen Sie Schlüssel, Passwörter und fremden Verkehr, aber behalten Sie die Funktionsnamen und Offsets, die jemand zum Lesen des Traces braucht. Senden Sie das Material über den Meldeweg, der für die Distribution oder den Kernel gilt, nicht über eine öffentliche Paste mit angehängtem Hostnamen. Warten Sie dann auf eine Rückfrage, statt weitere Abstürze zu ernten, denn ein lokalisierter Fehler gegen einen passenden Build ist das einzige Ergebnis, das den Bericht voranbringt. Kommt nichts zurück, ist der Rückfall eine kontrollierte Reproduktion auf Ersatzhardware, niemals auf der Maschine, von der andere Menschen abhängen.