Eine Übersicht über die aktuellen Versions-Nummern der wichtigsten Kernel-Bäume bekommt man durch:

finger @finger.kernel.org

Die selbe Information ist unter http://www.kernel.org/kdist/finger_banner verfügbar.

Eine nette Erklärung gibts auch unter http://de.wikipedia.org/wiki/Linux-Kernel.

Inhalt

1. Links und News

• 2.0er Kernel auf ftp.de.kernel.org

• 2.2er Kernel auf ftp.de.kernel.org

• 2.4er Kernel auf ftp.de.kernel.org

• 2.6er Kernel auf ftp.de.kernel.org

• Wöchentliche Zusammenfassung der Kernel-Mailingliste

• Usermode-Linux

• Alles rund um die Kernelprogrammierung, nicht nur für Neulinge

• Porting device drivers to the 2.6 kernel

• Online ansehbare Kernel-Sourcen (auch als InterWiki-Link `KernelSource:`), z.B. KernelSource:Documentation.

• kernel.org

• KernelTrap.org

• WOLK

• Bitkeeper-Kernelarchiv

• Ketchup, automatisches Kernelpatching

• Die Changelogs auf www.kernewbies.org in übersichtlicherer Form

2. Kernelversionen

In allen LinuxDistributionen sind bereits fertig kompilierte Kernel enthalten, man muss also sich oft nicht selbst darum kümmern, es sei denn man hat einen zwingenden Grund.

Stabile Versionen:

• Versionen mit gerade Ziffern an 2. Stelle
• 0.xx .. 1.xx - historische Versionen
• 2.0.xx - veraltet, nur noch in spez. Anwendungen (z.B. embedded systems)
• 2.2.xx - nicht mehr aktuell, aber noch viel im Einsatz

• 2.4.xx - War bis zum 18.12.2003 der aktuelle Kernel, zumindest als Alternative oder für einige Distributionen speziell für ältere Rechner wird er aber wohl noch eine ganze Weile angeboten werden. Siehe auch Kernel24

• 2.6.xx.y - Der aktuelle, stabile Kernel Kernel26

Entwickler-Versionen (möglicherweise nicht stabil, nicht funktionierend):

• Versionen mit ungeraden Ziffern an 2. Stelle, also z.B.:
• 2.1.xx, 2.3.xx, 2.5.xx

Seit Kernel26 ist diese Regel nicht mehr aktuell, die Entwicklung findet derzeit im -mm Patch von AndrewMorton statt. Wenn man sich aber die Erklärung zu den Patches von Andrew Morton ansieht, sind diese Patches wohl mehr experimenteller Art.

Ab 2.6.11 existieren zusätzliche Kernelversionen, in denen nur Build- und Securityfixes enthalten sind. Diese werden durch das Anhängen einer 4. Ziffer gekennzeichnet. Diese Versionen erscheinen ungefähr im Wochenrythmus. Mit dem Erscheinen des nächsten offiziellen Kernels wird der Support für diese Kernelversionen eingestellt und als Basis diese nächste Version genommen.

Mit

uname -r

oder

cat /proc/version

kann man herausfinden, welcher Kernel aktuell verwendet wird.

3. Wie übersetze ich einen Kernel?

3.1. Allgemein

3.1.1. Das erste Mal

Irgendwo auspacken und bereinigen

tar xjf linux-2.4.21.tar.bz2
cd linux-2.4.21
make mrproper

Konfigurieren über Textfragen

make config

Konfigurieren über ein ANSI-Menü (benötigt ncurses)...

make menuconfig

oder über eine X11-GUI (benötigt Tcl/Tk (bei 2.4.x) bzw. QT (bei 2.6.x))

make xconfig

oder über eine X11-GUI basierend auf GTK (benötigt selbstredend GTK)

make gconfig

Bei einer Kernel-Versionen vor 2.6.x macht man nun

make dep

und nun kann man mittels folgender Befehle kompilieren

make bzImage modules

Installieren als root

su
make modules_install
cp arch/i386/boot/bzImage /boot/bzImage-2.4.21
cp System.map /boot/System.map-2.4.21
cp .config /boot/.config-2.4.21

BootLoader anpassen (natürlich immer noch als root)

vi /etc/lilo.conf
# dann passenden Eintrag machen - siehe vorhandene

# nach dem bearbeiten von /etc/lilo.conf muss man lilo ausführen, 
# damit die Änderungen wirksam werden.
lilo

3.1.2. Updates

Man braucht sich nicht jedesmal einen kompletten Kernelsource vom ftp-Server ziehen, sondern man spart sich und dem ftp-Server-Betreiber Zeit, Geld und Bandbreite, wenn man sich einen Patch besorgt und dann einbindet.

Ebenso muss man nicht jedesmal wieder alles mit menuconfig durchkonfigurieren, sondern kann gefahrlos eine .config einer Vorversion nehmen.

Erstmal die Konfiguration sichern

cd linux-2.4.21
cp .config ../config-2.4.21

danach bereinigen

make mrproper

Patch einspielen

bzcat ../patch-2.4.21-ac1.bz2 | patch -p1

Konfiguration wieder einspielen

cp ../config-2.4.21 .config

Bei folgendem Kommando wird man nur noch Dinge gefragt, die neu sind und noch nicht konfiguriert wurden:

make oldconfig

Optional (wenn man noch was ändern will oder sich umschauen will):

make menuconfig

Danach geht's weiter wie oben.

3.1.3. Tipps für Poweruser

Wer seine Kiste richtig auslasten will, kann beim Kompilieren auch folgendes Kommando verwenden und damit mehrere Compiler gleichzeitig starten. Auf SMP-Maschinen bringt das richtig was, weil dann beide CPUs beschäftigt werden (wer mehr als 2 CPUs hat, darf auch mehr als 6 angeben ), aber selbst auf Einprozessormaschinen bringt es etwas, weil während einem Compilevorgang ja nicht immer gerechnet wird, sondern auch ab und zu auf I/O gewartet werden muss - und in der Zeit könnte dann ein anderer Compiler was rechnen.

make -j6 bzImage modules

Wer einen richtigen Stresstest veranstalten will (und viel RAM und SWAP hat und viele Filehandles), verwendet folgendes, das startet (fast) unlimitiert viele Compiler gleichzeitig. Vorsicht: die Kiste ist dann schwer beschäftigt und nicht mehr sonderlich ansprechbar für den User:

make -j bzImage modules

3.1.4. System.Map

Zum Kernel gehört auch eine Symboltabelle, die System.map. Diese Datei liegt üblicherweise direkt "neben" der Kerneldatei im gleichen Verzeichnis und trägt die gleiche Endung, z.B.:

• Kernel = /boot/bzImage, System.map = /boot/System.map
• Kernel = /boot/bzImage-2.4.18-tw1, System.map = /boot/System.map-2.4.18-tw1

Der Sinn dieser Symboltabelle liegt darin, dass z.B. bei Kernelabstürzen die Absturzadresse einem Funktionsnamen zugeordnet werden kann.

Diese Datei ist optional, der Kernel funktioniert auch ohne sie.

3.2. Kernelpakete für Distributionen

3.2.1. Debian kernel-package

Unter Debian GNU/Linux kann man sich ganz einfach einen eigenen Kernel als .deb-Paket bauen - dazu gibt es das Paket kernel-package.

Siehe auch Anleitung in der #debian.de FAQ.

• Zunächst mal muss man das Hilfsprogramm installieren: apt-get install kernel-package

• Danach in /etc/kernel-pkg.conf die eigene E-Mail-Adresse eintragen (die steht nachher als "Maintainer" im fertigen Paket).

• Kernel auspacken, patchen und konfigurieren wie oben. Nur soviel: Am Besten liegen die Sourcen unter /usr/src/linux und evtl. benötigte zusätzliche KernelModule (pcmcia, alsa) unter /usr/src/modules (das können jeweils auch Symlinks sein).

• Zum Kompilieren folgende Befehle verwenden (der String hinter --revision ist die Revisionsnummer: So kann man Pakete unterscheiden, die auf der selben Kernelversion basieren.):

make-kpkg clean
make-kpkg --revision meinkernel.1 kernel_image
make-kpkg modules_image  # nur notwendig, wenn man Module unter /usr/src/modules liegen hat

• Das funktioniert auch gut als normaler Nutzer! fakeroot make-kpkg --revision meinkernel.2 kernel_image

• entpackt man die Zusatzmodule (alsa etc.) in ein anderes Verzeichnis, so kann das mit export MODULE_LOC=pfad ausgewählt werden.

• Man erhält ein Verzeichnis höher .deb-Pakete. Diese kann man mit dpkg -i Paketname installieren -- auch auf einem anderen Rechner!

Als sehr praktisch hat es sich erwiesen, auch --append-to-version -custom1 anzugeben. Damit erzeugt man dann ein Paket namens kernel-package-<kernelversion>-custom1. Dadurch kann man verschiedene Versionen gleichzeitig installieren und bei Upgrades hat man keine Probleme mit den /lib/modules Verzeichnissen.

Entsprechend dem normalen "make -j10" muss man hier die Variable $CONCURRENCY_LEVEL setzen:

export CONCURRENCY_LEVEL=4

Kann man die Kernel Sources auch als Debian-Paket bekommen?

• apt-cache search kernel-source

Ist aber nicht zwingend notwendig, einen Debiankernel zu verwenden.

• make-kpkg buildpackage  --revision revision -us -uc erzeugt sämtliche Debianpakete.

3.2.2. Kernel-RPM aus Vanilla-Sourcen

Unter einer RPM-basierten Distribution kann man sich ganz einfach aus den offiziellen Kernelquellen ein RPM-Paket bauen.

1. Kernel normal entpacken

2. make mrproper kann nicht schaden

3. make xconfig und den Kernel nach Wunsch konfigurieren

4. make rpm-pkg

Entweder alles als root, oder besser als User, der selbst RPMs erstellen kann.

OffeneFrage: mit make rpm wird der Kernel (zumindest bei AMD64-Architektur) nicht komprimiert und LILO beschwert sich dann "Kernel too big". Ist dieser Bug auch bei i386 drin? Mögliche Antwort: versuche make rpm-pkg Siehe Kommentar von mhelios

OffeneFrage: Worin besteht der Unterschied zwischen "make rpm", "make rpm-pkg" und "make binrpm-pkg"?

3.2.3. RedHat Kernel-Source-RPM

Kernel-Sourcen installieren

rpm -i kernel-source-2.4.x-xx.i386.rpm

RedHat-Konfiguration einspielen

cd /usr/src/linux-2.4
cp configs/kernel-*-i686.config arch/i386/defconfig
make mrproper
make oldconfig

und anpassen

make menuconfig # oder xconfig

kompilieren

make dep && make bzImage && make modules && make modules_install

danach gehts weiter wie gewöhnlich.

Will man nur Module nachkompilieren, sollte man im Makefile das "custom" aus der Version entfernen. Dann kann man make bzImage auch weglassen.

make rpm, s. o., geht natürlich auch

Falls man einen neuen Kernel installiert und Module zum booten braucht, mkinitrd nicht vergessen.

4. Linux auf Nicht-Intel-Hardware

Dass Linux auf normalen PCs läuft, ist weit bekannt. Aber es gibt ja auch noch andere Rechner, die oft deutlich schneller sind als ihre Gigahertz-schnellen Intel/AMD/...-Kollegen. Auch auf diesen Alphas, SPARCs, MIPS, m68k und vielen anderen Rechnern kann man Linux laufen lassen. Manchmal (noch) nicht ganz so stabil wie die Original-Betriebssysteme, aber immerhin kann man so an aktuelle Software (und vor allem: Bugfixes!) kommen, und man hat immernoch ein freies Betriebssystem. Leider ist die Benutzung solcher Rechner oft nicht so ganz einfach, und wenn man einen ganzen Zoo solcher Exoten betreibt, dann kratzt man sich oft am Kopf und muss überlegen, wie z.B. man die unterschiedlichen Systeme bootet. Daher hier ein paar Exoten-Tips (die jetzt leider noch fehlten):

• SparcLinux

• AlphaLinux

• PowerPC-Linux (Mac, RS6000)

• m68k-Linux
• StrongARM-Linux
• sh-Linux
• MIPS- und MIPSel-Linux

• Linux for S/390 Linux390

• Linux for zSeries (64bit) Linux390

5. Usermode-Linux

Siehe UserModeLinux.

6. Kernelpatches

Der Standard-Vanilla-Kernel ist zwar recht brauchbar; mittels weiterer Patches können Funktionen nachgerüstet werden, die nur in der Entwicklerversion zur Verfügung stehen oder noch nicht in dern Kernel aufgenommen worden sind.

• http://www.plumlocosoft.com/kernel/patches/2.4/ - Hier gibt es Kernelpatches für die 2.4.xx Kernel, die einige Entwicklungen aus dem aktuellen 2.5er Entwicklerkernel auch für den 2.4er zur Verfügung stellt; hautpsächlich sind das Änderungen am Scheduler, die sich im Desktop sehr positiv bemerkbar machen (das Wechseln zwischen den virtuellen Desktops läuft erheblich schneller, die ganze GUI fühlt sich erheblich schneller an). Ein so gepatchter Kernel läuft bei mir seit ein paar Tagen wunderbar -- JoergHoh

• der gr-security-Patch (http://www.grsecurity.net) bringt Änderungen mit, die die Sicherheit des Kernels beeinflussen;

• Working Overloaded Linux Kernel - WOLK ist eine Zusammenfassung vieler kleiner Kernelpatches, die jeweiligen Features können ganz normal mit der Kernelkonfiguration eingestellt werden http://sourceforge.net/projects/wolk

• ExecShield

• international kernel patch - Verschlüsselte Dateisysteme, unterstützt viele Verschlüsselungsalgorithmen http://www.kerneli.org

  • kerneli.org ist down - /pub/linux/kernel/crypto auf ftp.kernel.org hilft euch weiter

• C++ Support im Kernel http://netlab.ru.is/exception/LinuxCXX.shtml

7. Tipps und Tricks

• Man sollte im Kernel, wenn man PCMCIA-Karten benutzt, nicht den ISA-Support und evtl. auch nicht den ISAPNP-Support abschalten, weil sonst auch PCMCIA-Karten nicht mehr erkannt werden!

Frage: Gibt es eine Webseite, auf der Kernel-Konfigurationen gesammelt werden? OK, bei PCs könnte das ausufern, aber es gibt doch Hardwarezusammenstellungen, die oft auftreten, z.B. bei Laptops oder Aldi-PCs. Ganz konkret bin ich schon seit einer Weile auf der Suche nach einer vorgefertigten Config für einen Thinkpad X41-Kernel, aber ich habe noch keine aktuelle gefunden ... -- OliverKopp 2005-07-31 11:52:14

• Ich denke einmal, so was wird es nicht geben. Die Hardware wird zwar immer gleich sein, bloß jeder User ist individuell. Angefangen bei den Dateisystem: Ein echter Linuxer gibt sich mit ext3 und swap zufrieden. Ein Windows-User dagegen benötigt vfat und ntfs. Weiter geht es bei iptables: Wer keine Firewall braucht (da er z.B. einen Router verwendet), kann auf iptables verzichten. Es gibt noch weitere Beispiele