Es ist gar nicht so einfach mit dem Ubuntu 8.10. Ich habe mich nun aus Performance-Gründen dafür entschieden, seit X Jahren mal wieder den Kernel selbst zu bauen. Nicht das es außer Erfahrung einen messbaren Erfolg gebracht hätte, aber die Erfahrung mache ich hoffentlich mit diesem Artikel messbar ;-). Mein Problem: Ich habe 4GB RAM im Notebook und nutze ein 32-bit System. Damit bin ich quasi auf den -server Kernel von Ubuntu angewiesen, da alle anderen Kerne die PAE- und HIGHMEM64G-Option nicht aktiviert haben. Der Server-Kernel ist nun aber auch für eben diese optimiert und nicht für Desktops. Also habe ich einen -generic Kernel mit den entsprechenden Optionen versehen und neu gebaut.Zunächst besorgt man sich den Kernel im Quellcode und macht die Skripte nutzbar:

apt-get source linux-image-2.6.27-11-generic
cd linux-2.6.27/
chmod a+x debian/rules
chmod a+x debian/scripts/misc/*

Danach wird die Konfiguration des Kernels angepasst. Insbesondere wenn man unsicher ist sollte man so wenige Optionen wie möglich ändern. Ich habe neben den beiden oben genannten noch die Prozessoroptimierung von 586 auf MCORE2 umgestellt (was später zu weiterem Streß führte …):

cat debian/config/i386/config debian/config/i386/config.generic > .config
make menuconfig
debian/rules updateconfigs
make mrproper

Das „cat“-Kommando nimmt die Standardkonfiguration auch als Vorgabe für die „normalen“ Kernelskripte, wie z.B. menuconfig. In eben diesem wird die Kernelkonfiguration bearbeitet. Das updateconfigs-Kommando von Ubuntu/Debian überschreibt die Standardkonfiguration mit der aktualisierten und mrproper räumt so auf, dass man ohne Fehlermeldungen weiterarbeiten kann. Das meint das eigentlich übersetzen des Kernels in seiner -generic Variante. Die vorab gesetzten Variablen aktivieren u.a. alle CPU-Kerne:

CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 debian/rules binary-generic

Die Warnungen, dass __init_-Funktionen fehlen usw. habe ich mal gelinde ignoriert ;-). Allerdings überraschen gegen Ende einige Fehler. Zum einen werden Module aufgezählt, die nicht mehr vorhanden sind. Das passiert, weil diese wohl schlicht nicht mit den neuen Optionen zusammenpassen. In der Datei „debian/abi/2.6.27-11.23/i386/generic.modules“ müssen diese schlicht entfernt werden, da das rules-Skript sonst  Ungemach vermutet.

Ganz großen Ärger gibt es, wenn man den CPU-Typ ändert. Das verändert nämlich auch die MD5-Summen aller Module und verstimmt das rules-Skript erneut. Das ist nun so richtig doof. Bevor ich alle Hashes ändere, habe ich in „debian/scripts/abi-check“ einfach in der Zeile 178 das Hochzählen der nicht passenden Hash-Summen abgestellt ;-).

Jetzt baut man mit folgendem Kommando den finalen Kernel (Wichtig: Das Kommando von oben beginnt nochmal von vorn und kostet mehr Zeit):

CONCURRENCY_LEVEL=2 debian/rules binary-generic

Voilá! Die .deb-Files dürfen installiert werden. Ganz korrekt war das alles freilich nicht, da werden Kernel-Name noch Paketrevision angepasst wurden. Aber es ist ja auch nur ein Workaround für Privatzwecke.

Für die Modul-Pakete „linux-backports-modules“ und „linux-restricted-modules“ heißt das Build-Kommando übrigens:

debian/rules binary-arch arch=i386 flavours=“generic“