Kernel

Der Linux-Kernel ist der urspünglich von Linus Torvalds programmierte Kern und damit das Herzstück des Linuxsystem. Im allgemeinen Sprachgebrauch ist der Linux-Kernel auch der Namensgeber, da jedoch die ursprünglichen Zusatzprogramme von GNU programmiert wurden, besteht Richard M. Stallmann (der Gründer der FSF) immer auf der Bezeichnung GNU/Linux.

Der Linuxkernel kann statisch (monolitisch) aufgebaut sein, d.h. alle benötigten Module sind fest einkompiliert, weit häufiger ist er jedoch modular gehalten, was die Möglichkeit bietet zur Laufzeit Module (und Funktionen) nachzuladen und somit den Kernel klein zu halten. Fast alle Distributionen setzten heute modulare Kernel ein.

Bei den Kernelversionen hat die mittlere Nummer eine besondere Aussagekraft: gerade Nummern (2.4.x, 2.6.x) sind stabile Anwenderkernel, ungerade (2.1.x, 2.3.x) instabile Entwicklerkernel. Mit der Kernelreihe 2.6 wird dieses Schema aufgeweicht. Sie wird vom maintainer (=Projektbetreuer und Hauptverantwortlicher) Andrew Morton betreut.

In der aktuellen 2.6.x-Version gibt es vier Hauptbäume:

1. main 2.6.x (Linus Torvalds Vanilla-Kernel)
2. 2.6.x.y-stable (sehr stabil, Fokus auf Bugfixes)
3. 2.6.x-git (experimenteller, täglicher Snapshot von Linus Torvalds Kernel-tree)
4. 2.6.x-mm (neue und ungeteste Änderungen, diese wandern später in Linus Torvalds Kernel-tree ; Betreuer Andrew Morton).

Einen eigenen Kernel kompilieren macht Sinn, wenn man sich sein System exakt an seine Bedürfnisse anpassen möchte. Also spezielle Optionen braucht oder einige Teile rauswerfen will (die im Standardkernel der jeweiligen Distribution enthalten sind). Außerdem ist fast immer nicht der neueste Kernel dabei, so dass man für manche Hardware oder zum testen auf die neueste Version angewiesen ist. Auch zu Lern- und Verständniszwecken sollte man so etwas mal versucht/gemacht haben.

Bei Sicherheitslücken oder veränderter Hardware ist allerdings schnell eine Anpassung (Neukompilieren) erforderlich. Da muss jeder selber entscheiden, ob er sich die Mühe machen will oder mit dem vorkompilierten Standardkernel zufrieden ist.

Die Kernelkonfiguration geht grundsätzlich auf drei verschiedene Arten:

1. make config (geht im Textmodus alle Optionen durch, für „hardcore-Linuxer“)
2. make menuconfig (Menu im Textmodus mit Navigation über Tastatur)
3. make xconfig (grafische Konfigurationsoberfläche).

Die Schritte zum Kernelübersetzen:

1. Kernelsourcen auspacken
2. make config, make menuconfigoder make xconfig (siehe oben)
3. make dep
4. make bzimage (übersetzt den Kernel)
5. make modules (übersetzt die Module)

Nun splitet sich die weitere Vorgehensweise nach dem Bootmanager auf:

1. Grub: den Kernel per Hand nach /boot kopieren + Eintrag in /boot/grub/menu.lst vornehmen.
2. lilo:
   1. make bzlilo (installiert den Kernel für lilo in /boot zusammen mit wichtigen Systemdateien)
   2. make modules_install (installiert die Module)

• Anatomy of the Linux kernel
• KernelNewbies
• LinuxChanges
• Kernel (2.6) Konfigurations-Howto
• Writing device drivers in Linux: A brief tutorial
• Linux übers Internet mit boot.kernel.org
• Anteil der Freizeit-Kernel-Hacker sinkt

• Linux Kernel backen – the Debian Way
• HowtoForge: How To Compile A Kernel--The Debian (Sarge) Way
• Realtime Linux für Debian

• How To Compile A Kernel - The Ubuntu Way
• Custom Kernel HowTo

• lsmod listet aktuell geladene Module auf
• insmod / rmmod: Module laden und entfernen
• modprobe lädt Module indem es auf zusätzliche Abhängigkeiten zu anderen Module prüft und diese ggf. ebenfalls lädt
• rmmod MODULNAME entlädt Module
• depmod baut die Liste der Abhängigkeiten auf. Diese stehen in einer Datei unter /lib/modules/KERNELVERSION/modules.dep. Der Aufruf ist bei einem neuen Kernel oder einzelner Module nötig.
• modinfo MODULNAME sollte Informationen über ein Modul ausgeben

Das Laden einzelner Module kann man verhindern indem man einen Eintrag in der Datei /etc/modprobe.d/blacklist anlegt:

blacklist MODULNAME

Beim Systemstart zu ladene Module werden bis Kernel 2.4 ist die Konfigurationsdatei für die Module /etc/modules.conf (oder auch /etc/conf.modules).

Seit Kernel 2.6 ist es grundsätzlich die Datei /etc/modprobe.conf oder die Dateien unterhalb von /etc/modprobe.d/ . Allerdings wird die Datei /etc/modules auch noch unter Ubuntu ausgewertet. Manche Distributionen (bisher Suse, Feodora und in Zukunft evtl. Redhat) wollen eigene Änderungen in der Datei modprobe.conf.local abgelegt wissen.

Wenn es /etc/modprobe.conf gibt, dann wird alles unter /etc/modprobe.d/ ignoriert. Darum steht in der Regel am Ende von /etc/modprobe.conf die Zeile „include /etc/modprobe.d“.

Fallweise:

modprobe MODULNAME

Bereits geladene Kernelmodule lassen sich mit

rmmod MODULNAME

entladen.

Viele Dienst erlassen sich auf eine korrekt laufende (syncronisierte) Zeit. Das ist z. B. in vollvirtualisierten Gästen ein großes Problem.

Auch in virtualisierten KVM-Gästen kann es zu Meldung wie diese kommen:

Clocksource tsc unstable (delta = -4398046495868 ns)

Für die Beurteilung ob das ein Problem darstellt oder nicht ist es wichtig die aktuell verwendete „clocksource“ anzuzeigen:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Die Antwort ist in diesem Fall kvm-clock (in den physikalischen Rechner oft „tsc“). Somit wäre die o. g. für den Gast unwichtig.

Die Liste der unterstützten Quellen bekomme ich wie folgt.

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

kvm-clock hpet acpi_pm jiffies tsc

Die verwendete Quelle kann mittles Boot-Parameter geändert werden, Beispiel: clocksource=acpi_pm