Fehlerbehebung

Brandon Nielsen, Jibec Version unknown Last review: 2021-02-22

Der Kernel enthält, wie jede Software, Fehler. Er ist ein großes, komplexes Projekt und die Fehlersuche kann sich als schwierig erweisen. Dieses Dokument beschreibt einige grundlegende Techniken zur Fehlerbehebung, die dabei helfen, die Ursache eines Problems einzugrenzen.

Bootfehler

Manchmal startet der Kernel nicht. Je nachdem, an welcher Stelle im Startvorgang das Problem auftritt, kann eine Ausgabe erfolgen oder auch nicht. Folgende erste Schritte sind empfehlenswert:

  • Entfernen Sie quiet (um mehr Protokollmeldungen zu erhalten) und rhgb (für die Deaktivierung des grafischen Starts) aus den Boot-Flags. Falls die Textausgabe zu schnell ist, fügen Sie boot_delay=1000 hinzu (die Anzahl der Millisekunden Verzögerung zwischen den printk-Befehlen beim Booten). Sie können die Ausgabe mit einer Kamera fotografieren.

  • Durch das Booten mit vga=791 (oder auch nur vga=1, falls die Grafikkarte 791 nicht unterstützt) wird der Framebuffer in den hochauflösenden Modus versetzt, um mehr Textzeilen auf dem Bildschirm anzuzeigen und so mehr Kontext für die Fehleranalyse zu ermöglichen.

  • Fügen Sie den Parameter initcall_debug hinzu, wodurch die Init-Aufrufe während ihrer Ausführung protokolliert werden.

  • Sollten Sie überhaupt keine Ausgabe vom Kernel erhalten, kann das Booten mit earlyprintk=vga manchmal etwas Interessantes liefern.

Hänger und Einfrieren

  • Prüfen Sie, ob die Feststelltaste (oder die NumLock-Taste oder die Rollen-Taste) eine bestimmte Funktion auslöst Die Kontrollleuchte auf der Tastatur, die den Status ändert, kann als Indikator dafür dienen, ob der Kernel komplett hängen geblieben ist oder ob ein anderes Problem vorliegt.

  • Die SysRq-Magic-Tasten funktionieren möglicherweise noch. Sie müssen eventuell sysrq_always_enabled=1 zur Kernel-Boot-Befehlszeile hinzufügen. Weitere Informationen finden Sie im Wiki-Artikel zu SysRq.

  • Die Einstellung nmi_watchdog=1 in der Kernel-Befehlszeile führt zu einem Kernel-Panic, wenn eine Zeitüberschreitung des NMI-Watchdogs auftritt.

Zu sammelnde Protokolle

Wenn Sie ein Problem mit dem Kernel melden, sollten Sie immer die Kernel-Protokolle beifügen, die üblicherweise mit dem Befehl dmesg erfasst werden. Bei manchen Problemen benötigen Sie möglicherweise weitere Protokolle.

Probleme mit Eingabegeräten (Touchpad usw.)

Informationen zum Sammeln von Protokollen sind auf der libinput-Webseite dokumentiert.

Soundprobleme

alsa-info.sh liefert Informationen sowohl über Kernel- als auch über Benutzerkomponenten. Falls Sie einen funktionierenden und einen nicht funktionierenden Kernel haben, sollten Sie für beide Fälle die Ausgabe von alsa-info.sh bereitstellen.

Das Problem mit git-bisect eingrenzen

Wenn das aufgetretene Problem in älteren Kernelversionen nicht besteht, ist es sehr hilfreich, mit git-bisect den Commit zu finden, der das Problem verursacht hat. Eine allgemeine Übersicht zu git-bisect finden Sie in dessen Dokumentation. Eine Anleitung zur Bisect-Methode im Kernel finden Sie in der Kerneldokumentation. Diese Anleitung enthält Fedora-spezifische Details.

Die Bisect-Methode ist zwar zeitaufwändig, aber sehr einfach und oft der beste Weg, die Ursache eines Problems zu finden. Wenn Sie das Problem wirklich lösen möchten, beschleunigt die Bisect-Methode den Prozess in den meisten Fällen erheblich.

  1. Suchen Sie die neueste Version, die funktioniert. Dies ist die erste „gute“ Version. Die erste gefundene Version, die nicht funktioniert, ist die erste „schlechte“ Version.

  2. Installieren Sie die Abhängigkeiten, die zum Erstellen des Kernels erforderlich sind.

  3. Als nächstes holen Sie den Quellcode.

  4. Erstellen Sie eine .config-Datei. Angenommen, Sie haben sowohl den funktionierenden als auch den fehlerhaften Kernel installiert, befindet sich die Konfiguration für beide im Verzeichnis /boot/. [1]

  5. Starten Sie ein neues git-bisect mit git bisect start.

  6. Markieren Sie die neueste funktionierende Version mit git bisect good <Tag> als „good“. Zum Beispiel: git bisect good v4.16.8.

  7. Markieren Sie die erste Version, die nicht funktioniert, mit git bisect bad <Tag> als „bad“. Zum Beispiel: git bisect bad v4.17.

  8. Bauen Sie den Kernel. Manchmal lassen sich Commits nicht kompilieren. In diesem Fall kann der Commit mit git bisect skip übersprungen werden.

  9. Installieren Sie den Kernel.

  10. Starten Sie das System mit dem neuen Kernel und testen Sie, ob es funktioniert.

  11. Wenn der neue Kernel funktioniert, markieren Sie ihn mit git bisect good als gut. Andernfalls markieren Sie ihn mit git bisect bad als schlecht.

  12. Wiederholen Sie die vorherigen fünf Schritte, bis Sie den Commit gefunden haben, der das Problem verursacht hat.

1. Beim Vergleich zwischen Hauptversionen (z.B. v4.16 und v4.15) werden während des Vergleichs neue Konfigurationsoptionen hinzugefügt und entfernt. Es ist in der Regel unbedenklich, die Standardeinstellungen zu wählen.

Want to help? Learn how to contribute to Fedora Docs ›