orm@doc-tcpip.org

Erstellt: April 2005 - Letzte Modifikation: Februar 2006

[ Main | Local ]


Kernel Konfiguration - System Panic

Notizen

Der Kernel

Der Kernel ist liegt als File /boot/kernel/kernel auf der Maschine. In einem Verzeichnis /boot/modules liegen die Module, die zum Kernel passen und einzeln geladen werden müssen. Oft finden sich weitere Kernel, z.B. ist es eine gute Idee, einen generischen Kernel (der Kernel, der alles kann ;-) dort abzulegen (kernel.GENERIC). Hat man nur den generischen Kernel installiert, so werden die meisten Module integriert und liegen dann auch im Verzeichnis /boot/kernel.

Der Kernel hat jetzt eine große Menge an Parametern, über die man sein Verhalten beeinflußen kann. Das gilt natürlich auch für alle Subsysteme wie Netzwerk-Stack, Virtual Memory Manager oder Filesystem-Dienste. Einige der Parameter beeinflußen die Datenstrukturen, die beim Boot angelegt werden - Speichergrößen, Größe von Tabellen etc. Diese Werte müßen beim Boot bekannt sein und werden im File /boot/loader.conf abgelegt. Im File /boot/default/loader.conf sind alle hier gültigen Parameter aufgeführt. Uber dieses File werden auch Module geladen.

Andere Parameter sind dynamisch und können im laufenden Betrieb geändert werden oder werden beim Start eines Modules angezogen. Diese Parameter werden im File /etc/sysctl.conf

sysctl

Alle Variablen sind einem Baum angeordnet - einer MIB (Management Information Base) - analog SNMP. Die verschiedenen Kategorien der Wurzel verzweigen sich in weitere Ebenen. Die Namen der Variablen setzen sich aus den Namen der einzelnen Ebenen zusammen.

Die Werte der Variablen sind:

Man kann sich mit dem sysctl-Kommando den Baum abfragen. Dabei kann man direkt die Variable abfragen, oder einzelne Ebenen, wenn man den Namen teilweise angibt. Nicht alle Variablen können gesetzt werden. Einige reflektieren Eigenschaften der Hardware und sind nur lesbar.

Dynamische Parameter kann man immer setzen. Parameter, die beim Software-Boot gesetzt werden sollen, werden in das File /etc/sysctl.conf geschrieben. Hier finden sich also alle dynamischen Parameter, die immer angezogen werden sollen.

Parameter, die schon beim Hardware-Boot gesetzt werden müßen, kommen in das File /boot/loader.conf. Es sind aber trotzdem ganz normale sysctl-MIB Parameter.

In beiden Files wird der ganze Name der MIB angegeben, und die Setzung eines Wertes:

bla.blu.ble="42"
In der Datei /boot/loader.conf kann man Kernel-Module laden. Kernel-Module sind Binäre Dateien im Verzeichnis /modules, deren Namen immer gleich aufgebaut sind: Der Name des Moduls mit der Endung .ko. Diese Endung ersetzt man durch _load="YES".

Es ist auch möglich, den Bootvorgang zu unterbrechen und am Prompt direkt Eingaben vorzunehmen:

ok ?  ==> Hilfe zum Bootprompt
ok ls ==> wie ein Unix ls
ok load / unload ==> Man kann Module und auch einen Kernel laden
Beim Laden eines Kernel muß man den aktuellen Kernel, also den, der gerade gebootet wird,zuerst entladen. Module werden mit ganzem Pfad aus /modules geladen, mit ls kann man schauen, was es so gibt.

Am boot-Prompt kann man auch sysctl-Parameter setzen: set bla.blu.ble="42".

Laden von Kernel-Modulen

kldstat zeigt alle geladenen Module kldstat -v zeigt alle geladenen Module sowie die Submodule, die das eigentlich Modul angezogen hat. Geladen werden die Module mit den Kommandos kldload und kldunload.

/var/run/dmesg.boot - Boottime Kernel Message Buffer. Mit dem sysctl kernel="/kernel" setzt man, welcher Kernel gebootet wird. Sich einen funktionierenden Kernel sichern: mkdir modules_ok cp kernel kernel_ok cp -R modules/* modules_ok

Einen Kernel bauen

/sys/i386/conf ==> hier finden sich die Kernel Konfigurationen
                   bzw.  /usr/src/sys/i386/conf
GENERIC ==> das ist die Konfiguration, des aktuell laufenden Kernels
LINT ==> alle möglichen Kernel-Optionen und sämtliche Devices.
Da sich die Einträge teilweise widersprechen, kann man mit LINT
keinen Kernel kompilieren.


Man kopiert sich GENERIC in anderes File (z.B. KERNEL_neu) und legt los.
Zeilen mit "device" sind Device Treiber
Zeilen mit options sind Software Features
Dann gibt es noch ein paar spezielle Keywörter.

Wenn man sein Konfig File fertig editiert hat:

config KERNEL_neu
Wenn das Kommando erfolgreich durchgelaufen ist, gibt es den Pfad
aus, unter dem alle nötigen Dateien zurechtgelegt worden sind.

Dort führt man nun folgende Aufrufe aus:
make depend
make all install  (oder make depend && make all install) 

Der alte Kernel wird vom Make-Skript nach kernel.old kopiert,
der neue Kernel tritt an diese Stelle.
Beim Booten sieht man dann den neuen Kernel in den Boot-Messages.

Funktioniert der Kernel nicht:

Boot unterbrechen
am Boot-Prompt den falschen Kernel per unload abhängen
ls / zeigt alle verfügbaren Kernel
einen Wählen und starten
load /kernel_ok (oder /kernel_GENERIC)
eventuell sind noch Module zu laden:
load /modules_ok/xxxx.ko
Dann booten: 
boot

Tunen von make:
/etc/make.conf (Kopieren von /etc/defaults/make.conf)

CPUTYPE
CFLAGS = -O3 -pipe -funrool-loops -ffast-math
==> Für "normalen" Code
COPTFLAGS = -O2 -pipe -funroll-loops
==> Für Kernel Code
(-ffastmath == nicht ANSI Standard für math. Funktionen)

makeoptions COPTFLAGS
options TOP_TABLE_SIZE=#
# == Primzahl, doppelt so groß wie Zeilen in /etc/passwd
==> Größe des Hash-Indexes  für Usernamen-Abfragen
NFS_NOSERVER
NSWAPDEV
Setzt Anzahl der Swap Devices.

Debug Kernel:
makeoptions DEBUG= -g
Generiert /usr/src/sys/compile/HOSTNAME/kernel.debug
Enthält die Symbole zum Auswerten des Core

Kernel Panic

Kernel Panic: Eine Entscheidung des Kernels. Das kann folgende Gründe haben:

Vorbereitung des Systemes auf einen Crash

Das FBSD Kommando, was diese Informationen ausnutzt, ist savecore.

Wenn der System Crash passiert ist

Ein Dump von einem nicht funktionierenden Kernel

Hier muß man den Prozess von Hand ausführen:

Vorsicht mit Core-Dumps aller Art, besonders Kernel-Dumps

Der Kernel-Dump ist eine komplette Kopie des RAM im Moment des Crashes. Man kann also aus dem Dump einiges an Informationen herauslesen. Je nach dem, welche Files gerade offen waren, oder ob irgendwelche Keys im Zugriff waren, kommt man auch an sensible Informationen heran.

Es kann daher nötig sein, das System im Single User Mode zu starten, den Fehler zu reproduzieren und einen "sauberen" Dump zu ziehen.

Auswerten des Kernel Dumps

In /var/crash finden sich jetzt folgende Files (bei mehreren Crashs mit höheren Nummern):

kernel.0  - Kopie des gecrashten Kernels
vmcore.0  - Dump des Memory, das der Kernel im Moment des Crash im Zugriff hatte.
Wichtig ist das File vmcore.X. Am besten kopiert man sich nun den richtigen (entsprechenden) Kernel daneben als kernel.debug.0.

Mit dem Debugger wird der Dump geöffnet:

gdb -k kernel.debug.0 vmcore.o
Jetzt kann man nochmal die Panic-Meldung sehen und auch kopieren ;-). Am Prompt des Debuggers setzt man jetzt where ab. Die Ausgabe ist der sogenannte Backtrace. Der Backtrace und die Ausgabe von uname -a kann man mit Aussicht auf Erfolg an eine FreeBSD-Liste schicken.

Der Backtrace listet die letzten Aktionen des Kernels auf. Dabei steht der jüngste Aufruf ganz oben, man schreitet dann in der Liste abwärts in die Vergangenheit.

Im Backtrace sucht man jetzt nach der trap-Funktion. Hat man den Kernel mit INVARIANTS kompiliert, so heisst die Funktion panic. Vor der trap-Funktion kommen eine Reihe weiterer, spezifischer Traps, die von der eigentlichen Trap-Funktion aufgerufen worden sind.

Der Aufruf vor der trap-Funktion ist der Aufruf, indem der Kernel gecrasht ist. Dabei ist diese Funktion nicht unbedingt schuldig, so kann z.B. eine Variable falsch belegt übergeben worden sein. Der Aufruf wird (bei Verwendung eines Debug-Kernels) direkt auf den Source Code referenziert - es wird das File und die Zeile angegeben.

Man kann jetzt in der richtigen Reihenfolge durch die Routinen laufen (up-Kommando bzw. down), mit p var kann man Variablen auslesen und prüfen. Mit p *var kann man ganze Datenstrukturen auslesen.


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )