FreeBSD Notizen - Kernel, System Panic und Dump

orm@doc-tcpip.org

Erstellt: April 2005 - Letzte Modifikation: Februar 2006

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:

string - ein beliebiger Text.
integer - ganze Zahlen
opaque - Maschinecode, nicht direkt lesbar
binary - Binär - 0 oder 1

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:

Das System steht vor einer Situation, mit der es nicht umgehen kann.
Eine interne Konsistenz-Prüfung ist fehlgeschlagen.

Vorbereitung des Systemes auf einen Crash

Der Source Code muß installiert sein.
Eine Swap Partition, die größer ist als der RAM des Systemes, muß definiert sein. Es können auch mehrere Swap Partitions sein, die in Summe größer als der RAM sind. Empfehlung ist zwei mal RAM.
Neben dem normalen Kernel muß die Debugging-Version dieses Kernels geben. Der Debugging-Kernel enthält alle Symbole - der normale Kernel ist "striped", hat also diese Zuordnung nicht mehr. Einträge in der Kernel Konfiguration:
- options DDB == Es wird ein normaler und ein Debug-Kernel generiert.
- options DDB_UNATTENDED == das System bootet bei einem Systemdump von selbst.
- makeoptions DEBUG=-g ==
Nach der Konfiguration, der Kompilation und Installation des neuen Kernels findet man im Verzeichnis der Kompilation ein File namens kernel.debug. Das ist der Kernel mit allen Symbolen. Das kopiert man am besten nach /var/crash/.
Setzen des Dump-Devices in /etc/rc.conf:
```
dumpdev="/dev/mein_swap"  (Info aus der /etc/fstab)
```
Das FBSD Kommando, was diese Informationen ausnutzt, ist dumpon.
Setzen des Filesystemes, wo der Kerneldump nach dem Booten hingeschrieben werden soll. Standard ist /var/crash, man kann es in der /etc/rc.conf anpassen:
```
dumpdev="/mein/dump/filesystem"
```

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

Wenn der System Crash passiert ist

Das System bleibt stehen und gibt eine letzte Meldung aus: Kernel Trap mit Fehlerzusammenfassung.
Der Kernel kann jetzt nur noch ganz simple Dinge tun - z.B. auf eine Partition schreiben. (Er kennt keine Filesysteme mehr..). Er schreibt daher den Kernel-Dump in die Swap-Partition, und zwar an das Ende der Partition. Den Fortschritt der Operation zeigt er an.
Anschließend bootet das System.
Jetzt werden die Filesysteme gemountet, und, da ja ein System Crash voran gegangen war, wird fsck gestartet. Der nutzt auch die Swap-Partition - wenn man Pech hat, überschreibt er Teile des Dumps (Das ist der Grund, warum die Swap-Partition größer als der RAM sein soll..).
Wenn alles gemountet ist, wird der Dump per savecore in ein Filesystem kopiert, als normales Core File.

Ein Dump von einem nicht funktionierenden Kernel

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

Booten von einem anderen Kernel (den man immer einrichten sollte...)
Unterbrechen des Bootvorganges, es erscheint ein Prompt.
Am Prompt gibt man boot -s ein und gelangt auf die Kommandozeile.
fsck -p
mount /var (oder wo genug Platz ist für den Kerneldump)
savecore -N /kernel_kaputt /var/crash Hier muß man den gecrashten Kernel angeben, nicht den, von dem man gebootet hat. Wenn alles an seinem Platz ist, kann man entsprechend debuggen.

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.

boot -s
dumpon /dev/mein_swap_device
mount -art ufs (so wird readonly gemountet, und man spart sich den fsck).
Das Problem reproduzieren, dann wie gehabt.

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 | RPi | SMTP | Tracing | GPS | LW ]