Compiler und Tools installieren¶

Es müssen folgende Pakete installiert sein ^[1]:

• fakeroot

• build-essential

• makedumpfile (ab Intrepid)

und danach für Ubuntu-Versionen vor Intrepid:

• linux-kernel-devel

Für Ubuntu-Versionen ab Ubuntu 8.10 Intrepid verwendet man folgenden Befehl ^[3]:

sudo apt-get build-dep linux 

Kernelquellen herunterladen¶

Jetzt wechselt man in das Verzeichnis, in dem man den Kernel bauen will. In diesem Verzeichnis liegen dann später auch die fertigen Pakete des selbst gebauten Kernels. Dort führt man für Versionen vor Hardy folgende Befehle aus

sudo apt-get build-dep linux-source
apt-get source linux-source 

für Versionen ab Hardy (8.04):

sudo apt-get build-dep linux-image-$(uname -r)
apt-get source linux-image-$(uname -r) 

Anschließend findet man im aktuellen Ordner folgende Dateien (evtl. andere Versionsnummern):

• linux_2.6.28.orig.tar.gz (Quellcode des Kernels)

• linux_2.6.28-11.42.diff.gz (Debian/Ubuntu-Patches zum Kernel)

• linux_2.6.28-11.42.dsc (Beschreibung des Quellcode-Paketes)

• linux-2.6.28 (Verzeichnis mit dem entpackten und gepatchten Quellcode)

Will man eine aktuellere Version, kann man den Kernel auch aus den Git-Archiven herunterladen. Dazu installiert man

• git-core

und führt folgenden Befehl aus (in diesem Beispiel für Jaunty) ^[3]:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git 

Abhängig von der Verbindungsgeschwindigkeit kann das längere Zeit dauern, da mehrere hundert Megabyte geladen werden müssen.

Hat man bereits ein Kernel-Archiv kann man das auf einige Megabytes reduzieren mit

git clone --reference ubuntu-intrepid/ git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git 

Nähere Informationen zur Verwendung von git für den Kernel findet man hier.

Für die weitere Anleitung wechselt man in das Verzeichnis mit dem Quellcode.

Eigene Variante erstellen¶

Dieser Schritt ist nicht unbedingt notwendig, denn man kann natürlich auch eine der originalen Varianten modifizieren, aber er ist sinnvoll, wenn man den eigenen Kernel mit dem originalen vergleichen will. In diesem Schritt wird eine Variante "variante" erstellt, die auf "generic" basiert. Außerdem wird angenommen, dass auf einem 64-Bit-System gearbeitet wird. Auf einem 32-Bit-System muss man "amd64" durch "i386" ersetzen.

mkdir debian/binary-custom.d/variante
cat debian/config/amd64/config.generic debian/config/amd64/config >debian/binary-custom.d/variante/config.amd64
touch debian/binary-custom.d/variante/rules
touch debian/binary-custom.d/variante/vars
mkdir debian/binary-custom.d/variante/patchset 

cp debian/abi/2.6.28-11.41/amd64/generic debian/abi/2.6.28-11.41/amd64/variante
cp debian/abi/2.6.28-11.41/amd64/generic.modules debian/abi/2.6.28-11.41/amd64/variante.modules
cp debian/config/amd64/config.generic debian/config/amd64/config.variante 

getall amd64 generic server

getall amd64 generic server variante

flavours        = generic server

flavours        = generic server variante

Kernel-Konfiguration ändern¶

Die Konfigurationsdateien des Kernels findet man unter debian/config/ARCH/, wobei ARCH für die Architektur steht, die man kompilieren will, z.B. "i386" oder "amd64". Änderungen der Datei config betreffen alle Varianten der jeweiligen Architektur, Änderungen der anderen Config-Dateien (z.B. config.generic) betreffen nur die eine Variante. Man kann die Änderungen mit einem Texteditor durchführen. Bequemer ist allerdings die Verwendung eines Konfigurationsprogramms.

Damit man keine Fehlermeldungen bekommt, muss man vorher noch ein paar Skripte ausführbar machen:

chmod +x debian/scripts/misc/* 

Will man alle Varianten aller Architekturen konfigurieren, verwendet man folgenden Befehl:

debian/rules editconfigs 

Um die Varianten einer Architektur zu ändern, verwendet man folgenden Befehl:

debian/scripts/misc/doconfig ARCH 

ARCH steht wiederum für die Architektur, z.B. i386, amd64.

Das Script verwendet zur Konfiguration die ncurses-basierte Oberfläche. Möchte man das GTK- oder Qt-Konfigurationsprogramm verwenden, kann man in dem Skript menuconfig durch xconfig oder gconfig ersetzen. Entweder mit einem Editor oder einem der folgenden Befehle:

( cd debian/scripts/misc && sed 's/menuconfig/xconfig/' doconfig >doconfig-qt ) 

für die Qt-Oberfläche oder

( cd debian/scripts/misc && sed 's/menuconfig/gconfig/' doconfig >doconfig-gtk ) 

für die GTK-Oberfläche und startet dann:

bash debian/scripts/misc/doconfig-qt ARCH 

oder

bash debian/scripts/misc/doconfig-gtk ARCH 

Nachdem ein Patch angewendet oder die Konfiguration geändert wurde, sollte man folgenden Befehl ausführen um sicherzustellen, dass die Konfiguration konsistent ist.

Für alle Architekturen:

debian/rules updateconfigs 

Oder nur für eine:

debian/scripts/misc/oldconfig ARCH 

Kompilieren und Pakete erstellen¶

Um alle Varianten der Architektur, auf der kompiliert wird, zu erstellen, verwendet man den Befehl:

AUTOBUILD=1 fakeroot debian/rules binary-debs 

Soll nur eine Variante erstellt werden, dann:

AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-VARIANTE 

Für selbst erstellte Varianten unter Hardy nimmt man folgenden Befehl:

AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-VARIANTE 

VARIANTE ersetzt man dann durch z.B. "generic", "server" oder eine selbst erstellte Variante. Hat man mehr als einen Prozessorkern, lässt sich der Vorgang beschleunigen, indem man dem Befehl CONCURRENCY_LEVEL=2 (für zwei Prozessorkerne, ersetze 2 durch die tatsächliche Anzahl) voranstellt.

Hinweis: Die Quellen im Internet empfehlen, hier entweder die Anzahl der CPU-Kerne oder die Anzahl CPU-Kerne + 1 einzusetzen (bei Prozessoren mit Hyperthreading x2). Was auf der eigenen Maschine das beste Ergebnis bringt, sollte man einfach ausprobieren. Wenn man ABI-Fehler erhält, kann man die ABI-Prüfung abstellen, indem man skipabi=true voranstellt. Wenn man Fehler über nicht vorhandene Module erhält, kann man skipmodule=true voranstellen. Also insgesamt dann z.B.

CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian/rules binary-VARIANTE 

Nach erfolgreichem Ende findet man in seinem Verzeichnis das Header- und das Image-Paket bereit zur Installation.

Installieren¶

Installieren mit

sudo dpkg -i headers-paket image-paket 

Dabei werden ab Intrepid Treiber, die DKMS verwenden (z.B. für Grafikkarten oder Virtualbox) falls notwendig automatisch angepasst. Sollte dabei ein Fehler auftreten, kann es notwendig sein die restricted-modules neu zu bauen.

Skript¶

Um den Vorgang zu vereinfachen gibt es ein halbautomatisches Skript . Man speichert das Skript als make-ubuntu-kernel.sh in dem Verzeichnis, in dem man den Kernel erstellen will, und macht es ausführbar.

chmod +x make-ubuntu-kernel.sh 

Weitere Hinweise zur Benutzung erhält man mit

./make-ubuntu-kernel.sh 

Einen Kernel einer einzelnen Variante baut man mit

./make-ubuntu-kernel.sh VARIANTE 

Das Skript folgt dabei ungefähr den Schritten dieser Anleitung.

Compiler und Tools installieren¶

Es müssen folgende Pakete installiert sein ^[1]:

• build-essential

• kernel-package

• fakeroot

Und danach entweder

• libncurses5-dev

für eine ncurses-basierte Oberfläche zur Konfiguration oder

• libgtk2.0-dev

• libglib2.0-dev

• libglade2-dev

für die GTK-Oberfläche oder

• libqt3-mt-dev

für die Qt-Oberfläche.

Eins davon sollte man nehmen, sonst wird es später arg langwierig. Wer ohnehin gelegentlich GTK-Programme kompiliert, hat mit der zweiten Möglichkeit eine komfortable Oberfläche, ansonsten ist ncurses eine sparsame aber benutzbare Möglichkeit.

Kernelquellen installieren¶

Die Quellen des Ubuntu-Kernels, der bereits einige Patches enthält, können als Paket

• linux-source

• linux-headers-generic (der Variante entsprechend, ^[5])

installiert werden ^[1].

Optional: Kernelpatches herunterladen¶

Wer den Kernel patchen will, weiß vermutlich, was er tut und welchen Patch er benötigt. Besonders komfortabel ist es, wenn der benötigte Patch in einem Paketrepository zu haben ist. Einige Patches finden sich beispielsweise in universe, das man gegebenenfalls erst freischalten muss ^[2]. Bei diesen ist wie bei allen Patches auf die richtige Versionsnummer zu achten, die meist erkennen lässt, für welche Kernelversion der Patch gedacht ist. Oft funktionieren aber auch ähnliche Versionen.

Kernelquellen auspacken¶

Die Kernelquellen befinden sich nun als tar.bz2-Archiv im Verzeichnis /usr/src. Um die Kernelquellen auszupacken, wechselt man in das Verzeichnis, in dem man den Kernel bauen will (z.B. ~/src/) und führt folgenden Befehl aus (Versionsnummer kann abweichen):

tar xjvf /usr/src/linux-source-2.6.28.tar.bz2
cd linux-source-2.6.28 

Optional: Kernel patchen¶

Patches, die über das Paketmanagement installiert wurden, befinden sich in einem Unterverzeichnis von /usr/src/kernel-patches/diffs. Sie liegen üblicherweise als gz- oder bz2-komprimierte Diff-Datei vor (.diff.gz oder .diff.bz2). Sie lassen sich mit folgendem Befehl einbauen:

zcat /usr/src/kernel-patches/diffs/<Patchverzeichnis>/<Patchdatei> | sudo patch -p1 

Bei bz2-Kompression ist zcat durch bzcat zu ersetzen.

Kernel konfigurieren¶

Die Konfiguration des Kernels wird in der Datei .config gespeichert. Eine gute Vorlage hierfür bietet die Konfiguration des bereits installierten Kernels. Sie wird ins aktuelle Verzeichnis kopiert:

cp /boot/config-<Kernelversion> .config 

zcat /proc/config.gz | sudo dd of=.config 

Falls die config-Datei von einer älteren Kernelversion stammt, kann man mit dem Befehl

make oldconfig 

die Konfiguration auf die aktuelle Version "updaten". Dabei wird nach den Einstellungen für die neuen Kerneloptionen gefragt.

Alternativ kann man mit

make defconfig 

eine (fast) minimale Standardkonfiguration erzeugen. Danach muss man nur noch sehr wenig ändern.

Auf Basis dieser Konfiguration kann man nun eigene Einstellungen vornehmen. Je nach anfangs installierten Bibliotheken geht das mit

make menuconfig 

(ncurses),

make gconfig 

(GTK), oder

make xconfig 

(Qt).

Unter "general Setup - LOCALVERSION" kann dabei eine Bezeichnung angegeben werden, die die Zuordnung des Kernels später erleichtert. Im Makefile kann auch eine EXTRAVERSION eingestellt werden: sie erscheint an die Versionsnummer angehängt (z.B. 2.6.10-noscsi).

Kernel kompilieren¶

Nach Abschluss der Konfiguration kann der Kernel kompiliert werden. Der folgende Befehl erzeugt auch gleich einfach installierbare .deb-Pakete für kernel-image und kernel-headers:

export CONCURRENCY_LEVEL=3
make-kpkg clean
fakeroot make-kpkg --initrd --append-to-version=-BEZEICHNUNG kernel-image kernel-headers 

Der erste Befehl dient dazu, eine Dual Core CPU vollständig auszunutzen. Da der Kompilierungsprozess normalerweise nur einen Kern benutzt, verkürzt sich die benötigte Rechenzeit deutlich. Siehe dazu auch den Hinweis oben. Den Quellcode säubert man durch den zweiten Befehl, ohne diesen Befehl kann es zu Problemen kommen. Bei dem dritten Befehl kann die BEZEICHNUNG beliebig gewählt werden, sollte aber nicht mit den bereits vorhandenen Kerneln im System kollidieren. Ein Beispiel wäre der Name eines eingespielten Patches (z.B. für einen Pentium 4 mit hdaps hdaps).

Weitere Informationen findet man im Debian-Anwenderhandbuch und in der Manpage von make-kpkg.

Vor einem erneuten Kompiliervorgang kann man das Verzeichnis aufräumen mit:

make-kpkg clean 

und

make clean 

Wenn eine Fehlermeldung kommt, dass die Datei arch/i386/boot/bzImage fehlt, hilft der Aufruf

make clean bzImage && make-kpkg --initrd kernel_image && make && make-kpkg --initrd binary  

Alternativ: Allerdings ist eine initrd nicht zwingend notwendig, wenn man seine Hardware kennt (das tut man meist wenn man seinen eigenen Kernel kompiliert) und keine LVM/Raid/dm_crypt/USB/NFS/SMB/LDAP/etc.-Unterstützung braucht, um das root-Dateisystem zu mounten. In diesem Falle deaktiviert man in der Konfigurationsphase die Unterstützung für initrd und bindet die Treiber für das root-Laufwerk ( meist die ATAPI / IDE Treiber für die Festplatte ) fest und nicht als Modul ein. Hilfreich ist auch das feste Einbinden von USB wenn man eine USB-Tastatur und/oder -Maus benutzt. Will man eine externe Firewire-Festplatte schon beim Booten einbinden, müssen auch die Firewire-Treiber fest in den Kernel kompiliert werden. Danach startet man das Kompilieren ohne den Parameter --initrd.

Kernel installieren¶

Das erzeugte Kernelpaket kann nun mit dem folgenden Befehl installiert werden:

sudo dpkg -i ../kernel-image-<xxx>.deb 

Neustart und Test des neuen Kernels¶

Nach einem Neustart des Systems lässt sich der neue Kernel im Bootmenü auswählen.

Quellen herunterladen¶

Die aktuelle Version der Quellen bekommt man mit:

sudo apt-get build-dep linux-restricted-modules-common
apt-get source linux-restricted-modules-common 

Im aktuellen Verzeichnis sollten jetzt diese Dateien zu finden sein (Versionsnummern können abweichen):

• linux-restricted-modules_2.6.28-13.17.dsc: Beschreibung des Quellpaketes

• linux-restricted-modules_2.6.28-13.17.tar.gz: Quellcode

• linux-restricted-modules-2.6.28/: Verzeichnis mit entpacktem Quellcode

An diesen Dateien kann man ablesen, dass die restricted-modules die ABI-Nummer 13 haben. Der selbstgebaute Kernel muss die gleiche ABI-Nummer haben und muss bereits installiert sein, damit die restricted-modules gebaut werden können. Für die folgenden Schritte wechselt man in das erzeugte Verzeichnis, z.B.:

cd linux-restricted-modules-2.6.28/ 

Für die folgende Anleitung wird angenommen, dass auf einer 64-Bit-Architektur (amd64) kompiliert wird und die Variante des eigenen Kernels "variante" ist. Auf einer 32-Bit-Architektur ersetzt man "amd64" durch "i386".

Variante anpassen (bis Hardy)¶

Man muss zwei Dateien in einem Editor bearbeiten:

• debian/rules

• debian/control.stub.in

Im Einzelnen:

debian/rules: Man sucht die Zeile (natürlich mit der passenden Architektur)

ifeq "$(DEB_HOST_ARCH)" "amd64"

und ersetzt in diesem Abschnitt die Zeilen

flavours := $(addprefix $(kernel_abi_version)-,generic openvz rt server xen)

durch:

flavours := $(addprefix $(kernel_abi_version)-,generic openvz rt server xen variante)

Außerdem muss noch eine weitere Zeile geändert werden. Man sucht

binary-arch: install build-udebs

und ersetzt sie durch:

binary-arch: install # build-udebs

Das verhindert das Erstellen von udeb-Paketen, die man meistens nicht braucht und die häufig Fehler verursachen. Optional kann man noch nach den Zeilen

FGLRX   := 1
NVIDIA  := 1
MADWIFI := 1
BCMWL   := 1
FRITZ   := 1
LTMODEM := 1
VMWARE  := 0
VMDESCHED := 1

suchen und bei den nicht benötigten Treibern "1" durch "0" ersetzen.

debian/control.stub.in: Man sucht den Abschnitt, der mit folgender Zeile beginnt:

Package: linux-restricted-modules-@@ABIVER@@-generic

Diesen Abschnitt kopiert man und ersetzt alle "-generic" durch "-variante".

Variante anpassen (ab Intrepid)¶

Man erzeugt die zwei Dateien debian/control.d/vars.variante und debian/config/amd64/config.variante:

cp debian/control.d/vars.generic debian/control.d/vars.variante
cp debian/config/amd64/config.generic debian/config/amd64/config.variante 

Kompilieren und Pakete erstellen¶

Zuerst erstellt man die Datei debian/control neu:

fakeroot debian/rules debian/control 

Jetzt kann man eine einzelne Variante bauen mit:

fakeroot debian/rules binary-arch arch=amd64 flavours="variante" 

Alle Varianten baut man mit (Unter Hardy scheint nur diese Möglichkeit zu funktionieren):

fakeroot debian/rules binary-arch 

Das fertige Paket installiert man mit:

sudo dpkg -i linux-restricted-modules-2.6.28-13-variante_2.6.28-13.17_amd64.deb