Keywords: Authentifizierung, BrowserMatch, CoreDumpDirectory, Lockfile, Maintainer, PidFile, Prozess-ID, ScoreBoardFile, ScriptLog, ScriptLogBuffer, ScriptLogLength, Server-Lockdatei, ServerTokens, ServerType, SetEnvIf, update-grub, 32-Bit, 386, 3Com, 404, 486, 64-Bit, 8390, A Package Tool, ACL, AIDE, AM, AMD, APT::Cache::GivenOnly, APT, APT_CONFIG, ASCII-Terminals, ASCII, ATM, AVI, Abhängigkeit, Abhängigkeiten, AbiWord, Access Control Lists, Access, Acrobat-Reader, Administration, Administrator-Passwort, Administrator, Adressverwaltung, Aktualisieren eines Pakets, AllowOverride, Alpha, Alternativen, Alternatives, Amiga, AmigaOS, Aministrator, Anaconda, Angriff, Anrufbeantworter, Apache Module, Apache Webserver - MIME-Typen, Apache, Apple, Applet, Application Maintainer, Applixware, Aptitude, Arbeitsspeicher, Architecture, Architektur-unabhängige Patches, Architektur, Architekturen, Archiv, Archive, Arm, Atari, Auflösung, Ausreden, Authentifizierung, BIND, BIOS-Einstellungen, BIOS-Passwort, BIOS [cell cut: 21416 characters, first 1000 kept]

Kapitel 6. Debian-Pakete im Detail
Zurück | 6.2 Debian-Kernel-Pakete erzeugen | Weiter

## 6.2 Debian-Kernel-Pakete erzeugen

Auf einem Debian GNU/Linux-System gibt es grundsätzlich zwei verschiedene Verfahren, um einen individuellen Kernel zu erzeugen. Zunächst ist es natürlich möglich, alle Arbeitsschritte auf klassischem Wege „zu Fuß“, wie auf jedem anderen Linux-System, durchzuführen. Die elegantere Methode ist es jedoch, ein eigenes Debian-Kernel-Paket zu erzeugen und dieses zu installieren.

Sehen wir uns zunächst die etwas elegantere Debian-Methode an; die klassische Methode werden wir später besprechen.

### 6.2.1 Debian-Kernel erzeugen (`kernel-package`)

Das Paket `kernel-package` unterstützt den Administrator bei der Verwaltung von individuellen Linux-Kerneln auf seinem System.

Sicherlich haben Sie schon die bei Debian GNU/Linux mitgelieferten Kernel-Pakete entdeckt. Diese sind so konfiguriert, dass sie auf den meisten Systemen funktionsfähig sind. Trotzdem ist es manchmal notwendig, einen eigenen Kernel zu übersetzen, um neue Hardware einzubinden oder um Hardwarekonflikte zu umgehen. Sie können hierbei das Paket `kernel-package` zu Hilfe nehmen. Dieses erzeugt ein Debian-Paket mit einem individuellen Kernel und allen Modulen für Ihr System.

Zunächst benötigen Sie, neben dem Paket `kernel-package`, das Sie schon installieren können, ein Paket mit dem gewünschten Kernel-Quellcode (Source). Es stehen einerseits Debian-Pakete mit dem Quellcode des Kernels zur Verfügung (Paketname `kernel-source-2.x.xx`), welche mit `apt-get` installiert werden können. Es können aber auch die Original Kernelquellen verwendet werden. Sie finden die Archive unter ftp://ftp.kernel.org oder auf den Spiegelservern in Deutschland: ftp://ftp.de.kernel.org oder ftp://ftp2.de.kernel.org.

### Aktuelle Kernel-Version herausfinden

Wenn Sie sich nicht per FTP durch die Verzeichnisse auf dem Kernel-Server „wühlen“ möchten, um nachzusehen, ob es eine neue Version gibt, können Sie mit dem Kommando `finger @www.kernel.org` die aktuelle Kernel-Version ermitteln. Bitte verwenden Sie dieses Kommando nicht in Skripten, um den Server nicht zu überlasten. Identische Informationen lassen sich auch auf der Webseite http://www.kernel.org/kdist/finger_banner abrufen.

Weiter benötigen Sie einige zusätzliche Pakete, um einen neuen Kernel zu übersetzen, dies sind: `gcc`, `libc5-dev` oder besser (weil aktueller) `libc6-dev`, `binutils`, `make`, `gawk` oder `mawk`, `gzip`, `shellutils`, `grep` sowie `bin86` auf der `i386`-Plattform. Wenn Sie das Kommando `make menuconfig` zur Kernel-Konfiguration benutzen möchten, muss das Paket `libncurses5-dev` installiert sein. Aber sicher haben Sie einige davon bereits installiert.

Wenn die notwendigen Pakete installiert sind, entpacken Sie die Kernel-Quellen; üblicherweise geschieht dies unter `/usr/src/`.

Wenn Debian-Kernel-Source-Pakete verwendet werden, so befindet sich das zu entpackende Archiv bereits im Verzeichnis `/usr/src/`. Natürlich kann auch jeder andere Linux-Kernel-Source verwendet werden.

Beim Entpacken der Sourcen ist darauf zu achten, dass das Verzeichnis `/usr/src/linux/` nicht durch Inhalte aus dem Archiv überschrieben wird. Wenn Sie verschiedene Kernel-Versionen verwalten wollen, empfiehlt es sich, das Verzeichnis `/usr/src/linux/` umzubenennen, beispielsweise in `kernel-source-2.4.31`.

Sorgen Sie auch dafür, dass das Verzeichnis `/usr/src/` auf einer Partition mit ausreichend Platz angelegt ist. Die aktuellen Kernel-Archive in der Version 2.6 sind in gepackter Form ca. 40-50 Mbyte (je nach verwendetem Komprimierungsprogramm) groß und nehmen im entpackten Zustand ca. 220 Mbyte ein, wenn alles übersetzt ist - und zwar pro entpackter Kernel-Version!

Wechseln Sie nun in das Verzeichnis, in dem die Kernel-Quellcodes liegen.

Der Name eines Debian GNU/Linux-Kernel-Pakets besteht immer aus dem Basisnamen (hier: `kernel-image`), der Versionsnummer des Kernels (zum Beispiel 2.2.14, diese wird aus dem Kernel-Makefile ermittelt) und der so genannten Revisionsnummer; Letztere können Sie individuell vergeben (über die Option `--revision`, die Sie dem Programm `make-kpkg` übergeben können). Sie sollten diese Revisionsnummer eindeutig wählen, um zu verhindern, dass ein bereits installierter Kernel überschrieben wird. Weiterhin darf das Zeichen „_“ (Unterstrich) nicht verwendet werden. Alternativ können Sie auch die Umgebungsvariable `DEBIAN_REVISION` auf den gewünschten Wert setzen.

Sie sollten die Revisionsnummer bei jedem neuen Kernel erhöhen; das Debian-Paketsystem kann so automatisch ein Update durchführen.

Auch für das Paket `kernel-package` gibt es natürlich eine Konfigurationsdatei; diese finden Sie wie üblich im Verzeichnis `/etc/` als `kernel-pkg.conf`. Üblicherweise sollten Sie dort mindestens Ihren Namen sowie die E-Mail-Adresse angeben. Sie können so immer feststellen, dass dieses Paket kein Original-Debian-Paket ist. Sie können, wenn nötig, noch weitere Variablen in dieser Datei benutzen. Momentan werden folgende Optionen unterstützt:

- maintainer: Der „ Betreuer“ dieses Kernel-Pakets. Wenn Sie hier einen Apostroph (') verwenden möchten, so müssen Sie dieses wie folgt angeben: John O'\''Brien.

- email: Ihre E-Mail-Adresse.

- pgp: Der Name, der in der PGP-Datenbank gesucht werden soll. Normalerweise wird hier der Maintainer automatisch eingesetzt. Sie können dies auch mit der Umgebungsvariablen `PGP_SIGNATURE` überschreiben.

- debian: Die Revisionsnummer des Pakets; der Standardwert ist `1.00`. Sie können die Umgebungsvariable `DEBIAN_REVISION` benutzen.

- image_in_boot: Wenn Sie diese Variable auf `TRUE` setzen, wird der Kernel im Verzeichnis `/boot/` abgelegt und ein entsprechender symbolischer Link angelegt, anstatt wie sonst üblich den Kernel direkt in das „ root“-Verzeichnis (`/`) zu kopieren. Dies kann auch über die Umgebungsvariable `IMAGE_IN_BOOT` gesetzt werden.

- kimage: Typ des Kernel-Images, zum Beispiel `zImage` oder `bzImage`; der Standardwert ist `bzImage`. Dieser Wert kann über die Umgebungsvariable `IMAGE_TYPE` gesetzt werden.

- no_symlink: Kann nicht zusammen mit `reverse_symlink` verwendet werden. Sinnvoll kann diese Option im Zusammenspiel mit `image_in_boot` verwendet werden. Bei Verwendung der Option `no_symlink` wird das Kernel-Image immer als Datei `vmlinuz` abgelegt (und nicht als `/boot/vmlinuz-x.x.xx`). Ein bereits existierendes Kernel-Image wird in jedem Fall (und nicht nur wenn es sich vom neuen Kernel-Image unterscheidet) in `vmlinuz.old` umbenannt. Dieses bringt eine Beschränkung auf zwei Kernel-Images mit sich; weitere Versionen müssen dann von Hand eingepflegt werden. Diese Option kann auf Systemen eingesetzt werden, die keine symbolischen Links unterstützen, beispielsweise wenn `loadlin` eingesetzt wird. Diese Option ist aber eher als Hack zu betrachten.

- reverse_symlinks: Beschreibt, ob für das Kernel-Image ohne Versionsnummer ein symbolischer Link (mit Versionsnummer) angelegt werden soll. Diese Option wird von einer gesetzten Umgebungsvariablen `REVERSE_SYMLINK` überschrieben. Weiterhin kann diese Option nicht zusammen mit `no_symlinks` verwendet werden, wohl aber mit `link_in_boot`. Wie bei der Option `no_symlink` besteht hierbei eine Beschränkung auf zwei Kernel-Images, wenn nicht weitere Kernel-Images von Hand gepflegt werden. Diese Option sollte nur genutzt werden, wenn es zwingend erforderlich ist, beispielsweise bei der Verwendung eines `umsdos`-Dateisystems auf der `/boot`-Partition.

- patch_the_kernel: Diese Variable ist nur für Experten gedacht. Wird diese Variable auf den Wert `YES` gesetzt (diese Variable kann durch die Umgebungsvariable `PATCH_THE_KERNEL` überschrieben werden), so wird beim Erzeugen des Debian-Pakets das Skript `/usr/src/kernel-patches/$(architecture)/apply` ausgeführt und alle installierten Kernel-Patches auf den Kernel-Source-Code angewendet. Dieser Vorgang wird bei einem Aufruf von `make-kpkg clean` wieder rückgängig gemacht, indem `/usr/src/kernel-patches/$(architecture)/unpatch` ausgeführt wird. Um architektur-unabhängige Patches zu verwenden, kann als Architektur „all“ angegeben werden.

- config_target: Beschreibt, welcher Schritt der Konfiguration durchlaufen werden soll. Der Vorgabewert ist hierbei `oldconfig`, der sich besonders gut für das Erstellen eines Kernels ohne viele Nachfragen eignet. Wenn die Option `patch_the_kernel` gesetzt ist, so werden wahrscheinlich weitere Anpassungen für die neuen Funktionen notwendig. Dann sollte diese Option auf `menuconfig` oder `xconfig` gesetzt werden.

  Die Umgebungsvariable `CONFIG_TARGET` überschreibt den Wert in der Konfigurationsdatei. Entspricht der Wert von `config_target` nicht einem der Werte `config`, `oldconfig`, `menuconfig` oder `xconfig`, so wird der Wert auf `oldconfig` gesetzt.

- use_saved_config: Wird diese Variable auf `NO` gesetzt, so wird die Datei `.config.save` ignoriert.

- root_cmd: Mit dieser Variablen kann ein Kommando bestimmt werden, das es erlaubt, als Benutzer temporär die Rechte des Administrators zu erlangen. Kommandos, die dies ermöglichen, sind beispielsweise `sudo` oder `fakeroot`. Mit der Umgebungsvariablen `ROOT_CMD` kann dieser Wert überschrieben werden.

- delete_build_link: Wird diese Variable auf YES gesetzt, so wird der Link auf die Datei `/lib/modules/$VERSION/build` aus dem erzeugten Debian-Paket entfernt. Das Setzen der Umgebungsvariablen `DELETE_BUILD_LINK` hat die gleichen Auswirkungen.

- do_clean: Das Setzen dieser Variable auf den Wert YES bewirkt den Aufruf von `make clean`, nachdem das Kernel-Paket erzeugt wurde. Alle anderen Werte verhindern den Aufruf. Die entsprechende Umgebungsvariable dafür lautet `CLEAN_SOURCE`.

- install_vmlinuz: Mit dem Setzen dieser Variable auf YES wird zusätzlich zu dem komprimierten Kernel-Image (`vmlinuz`) auch ein unkomprimiertes Kernel-Image installiert.

- source_clean_hook: An dieser Stelle kann vor dem Packen der Kernel-Sourcen zu einem Archiv ein Programm aufgerufen werden, das beispielsweise nicht benötigte Dateien löscht. Dies können Verzeichnisse sein, die zur Versionskontrolle benötigt werden, oder es können Dateien gelöscht werden, die zu einer nicht benötigten Architektur gehören.

  Die Aktion wird nur auf den temporären Kernel-Source-Baum innerhalb von `./debian/tmp-source/usr/src/kernel-source-X.X.XX` angewendet.

- header_clean_hook: Wie zuvor bei `source_clean_hook` beschrieben; diesmal jedoch ausschließlich mit Auswirkungen auf die entsprechenden Kernel-Header.

- doc_clean_hook: Wie zuvor bei `source_clean_hook` beschrieben; diesmal jedoch ausschließlich mit Auswirkungen auf die entsprechende Kernel-Dokumentation.

- extra_docs: Kann auf ein Verzeichniss zeigen, in dem zusätzliche Dokumentation liegt, die im Verzeichnis `/usr/share/doc/kernel-image-X.X.XX/` abgelegt werden soll. Die Dateien werden dabei nicht komprimiert, und es wird auch nicht geprüft, ob Dateien mit gleichen Namen bereits vorhanden sind. Der Pfad kann auch mit der Umgebungsvariablen `EXTRA_DOCS` übergeben werden.

- kpkg_follow_symlinks_in_src: Nützlich für Entwickler, die Symlinks intensiv nutzen, um Kernel zu erzeugen. In den erzeugten Paketen werden die Links umgewandelt, so dass auch tatsächlich alle Dateien enthalten sind. Die entsprechende Umgebungsvariable `KPKG_FOLLOW_SYM-LINKS_IN_SRC` kann ebenfalls genutzt werden.

- make_libc_headers: Diese Variable sollte nur vom Maintainer der libc eingesetzt werden, wenn die libc6 neu übersetzt wird. Nutzen Sie diese Variable nicht! Die entsprechende Umgebungsvariable ist `MAKE_LIBC_HEADERS`.

- CONCURRENCY_LEVEL: Hiermit kann beeinflusst werden, wie viele Compiler-Instanzen von `make` über das Flag `-j` aufgerufen werden. Der Wert muss eine (kleine) Ganzzahl sein.

- ARCH_IN_NAME: Wird diese Variable benutzt, so wird ein zusätzlicher Name für das Kernel-Paket in der Subarchitektur hinzugefügt. So können über ein kleines Skript unterschiedliche Kernel für verschiedene Architekturen erzeugt werden. Beachten Sie, dass lediglich der Paketname mit dieser Variablen verändert wird, nicht die Anordnung der Dateien in Dateisystem.

- CONFDIR: Diese Variable kann den Pfad zu einem Verzeichnis enthalten, in dem sich Konfigurationsdateien (`.config`) für die jeweilige Architektur befinden. Die Voreinstellung zeigt auf das Verzeichnis `/usr/share/kernel-package/Config`.

- IMAGEDIR: Wenn die erzeugten Kernel-Images nicht im Verzeichnis `/boot` gespeichert werden sollen, so kann mit dieser Variablen das Verzeichnis verändert werden. Benutzer von `loadlin` werden dies zu schätzen wissen.

- MODULE_LOC: Zeigt auf ein Verzeichnis, in dem zusätzliche Module abgelegt sind. Die Voreinstellung ist `/usr/src/modules`.

- PATCH_DIR: Zeigt auf ein Verzeichnis, in dem sich Kernel-Patches befinden, die vor dem Übersetzen des Kernels auf den Source-Code angewendet werden sollen. Diese Variable zeigt in der Voreinstellung auf `/usr/src/kernel-patches/ARCHITECTURE`.

- ALL_PATCH_DIR: Hiermit kann ein Verzeichnis angegeben werden, in dem sich architektur-unabhängige Kernel-Patches befinden. Die Vorgabe ist hier das Verzeichnis `/usr/src/kernel-patches/all`.

Die Priorisierung erfolgt in dieser Reihenfolge:

- Eine Variable ist in der Datei `rules` gesetzt. Dies ist die Voreinstellung.

- Eine Variable ist in der Datei `/etc/kernel-pkg.conf` gesetzt und hat damit eine höhere Wertigkeit.

- Variablen können auch über die entsprechenden Umgebungsvariablen gesetzt werden. Umgebungsvariablen überschreiben die Angaben in den Konfigurationsdateien und den Voreinstellungen.

- Werden `make-kpkg`-Optionen auf der Kommandozeile verwendet, so überschreiben diese alle vorhergehenden Definitionen.

Abschließend wird das Debian-Kernelpaket mittels `make-kpkg` und den gewünschten Optionen erzeugt.

#### 6.2.1.1 `make-kpkg`

Mit `make-kpkg` lassen sich Debian-Kernel-Pakete aus dem Kernel-Quellcode (Source) erzeugen. Dabei kann sowohl die Konfiguration des Kernels während des Einsatzes von `make-kpkg` vorgenommen werden, als auch der eigentliche Übersetzungsvorgang (Kompilieren) des Quellcodes angestoßen werden.

`make-kpkg` muss immer innerhalb des Verzeichnisses aufgerufen werden, in dem sich der Quellcode des Kernels befindet. Weiterhin sind administrative Rechte notwendig. Dies kann dadurch erreicht werden, dass `make-kpkg` als Administrator (root) ausgeführt wird. Es ist aber auch ausreichend, das Programm `fakeroot` einzusetzen.

Die Syntax von `make-kpkg` ist recht einfach:

    make-kpkg [options] [target [target ...]]

Als einfaches Beispiel für den Einsatz von `make-kpkg` kann folgendes Beispiel dienen, das auch als normaler Benutzer aufgerufen werden kann:

    make-kpkg --rootcmd fakeroot kernel_image

Es wird ein Debian-Kernel-Paket erzeugt und in dem Verzeichnis abgelegt, das dem aktuellen Verzeichnis übergeordnet ist.

Optionen

`--help`

  Gibt eine kurze Hilfe zu den Optionen von `make-kpkg` aus.

`--revision number`

  Setzt die Revisionsnummer des Debian-Pakets auf das angegebene Argument.

  Diese Option bewirkt nur eine Änderung der Revisionsnummer während der Konfigurationsphase (also wenn die Datei `stamp-configure` nicht existiert). Es empfiehlt sich, in jedem Fall vor der Benutzung dieser Option `make-kpkg clean` aufzurufen. Den gleichen Effekt hat das Löschen der Dateien `stamp-configure` und `stamp-debian`.

  Nach den Informationen im Debian Policy Manual darf die Zeichenkette für die Version ausschließlich aus Zahlen und den Zeichen `+` und `.` bestehen und muss mindestens eine Zahl beinhalten. Die offiziellen Debian-Pakete mit Kerneln weichen davon ab, diese beinhalten auch das Zeichen `-`.

  Der voreingestellte Wert für diesen Parameter ist `1.00.Custom`. Mit der Umgebungsvariablen `DEBIAN_REVISION_MANDATORY` kann eine Warnung ausgegeben werden, falls die Revisionsnummer weder auf der Kommandozeile noch in der Konfigurationsdatei gesetzt wird.

`--append-to-version foo`, `--append_to_version foo`

  Das angegebene Argument „foo“ wird an den Wert der Variablen `EXTRAVERSION` angehängt, die aus den Angaben im Kernel-Makefile generiert wird. Da `EXTRAVERSION` ein Bestandteil der Kernel-Version ist, wird diese Angabe auch im Namen des Debian-Kernel-Pakets erscheinen und muss somit auch den Richtlinien für Paketnamen entsprechen. Das bedeutet, dass ausschließlich Kleinbuchstaben sowie die Zeichen `-`, `+` und `.` erlaubt sind.

  Wird diese Option verwendet, so wird die Umgebungsvariable `APPEND_TO_VERSION` überschrieben. Bei Verwendung dieser Option muss `make-kpkg clean` nach der Konfiguration des Kernels aufgerufen werden, da hiermit die Datei `include/linux/version.h` mit den gewünschten Werten erzeugt wird. Ein einfacher Aufruf von `make-kpkg` würde eine bestehende Datei `include/linux/version.h` nicht verändern und so dazu führen, dass der Kernel die Module nicht findet, da diese in einem Verzeichnis abgelegt werden, das sich von der im Kernel festgelegten Syntax unterscheidet.

  Wird später noch ein Paket mit den Kernel-Modulen erzeugt, so ist dort auch die verwendete Option anzugeben, damit die Module zum Kernel passen.

`--flavor foo`

  Dies ist eine mittlerweile überflüssige Option, die noch aus Gründen der Kompatibilität mitgeführt wird. Zukünftig sollte nur noch `--append_to_version` benutzt werden.

`--added-modules foo`, `--added_modules foo`

  Das Argument zu dieser Option ist ein einzelnes Modul oder eine kommaseparierte Liste von Modulen, die nicht im Standard-Kernel enthalten sind. Dabei muss der komplette Pfad zu den Modulen angegeben werden, falls diese nicht im üblichen Pfad liegen (`/usr/src/modules`, der auch über die Variable `MODULE_LOC` gesetzt werden kann).

`--added-patches foo`, `--added_patches foo`

  Das Argument zu dieser Option ist eine kommaseparierte Liste von Patches, die dem Kernel-Quellcode hinzugefügt werden sollen. Die Verwendung dieser Option setzt automatisch auch die Option `patch_the_kernel` auf `YES`.

  Abweichend zur Behandlung von Modulen, ist es bei Patches ausreichend den Basisnamen des Patches anzugeben. Der volle Pfad ist nicht erforderlich. Für jeden Namen eines Patches in der Liste wird wie folgt nach der passenden Datei gesucht: Wir die Datei in einem der Verzeichnisse `ALL_PATCH_DIR/{apply,unpatch}/` gefunden, so wird die Datei `ALL_PATCH_DIR/apply/<patch_name>` während des Laufs von „configure“ ausgeführt. Passend dazu wird die Datei `ALL_PATCH_DIR/unpatch/<patch_name>` ausgeführt wenn ein „clean“ ausgeführt wird.

  Voreingestellt ist, dass alle vorhandenen Patches angewendet werden in dem die ausführbaren Dateien in `ALL_PATCH_DIR/apply/` bearbeitet werden. Dies geschieht durch setzten der Konfigurationsvariablen `patch_the_kernel` oder der Umgebungsvariablen `PATCH_THE_KERNEL` auf den Wert `YES`. Zu beachten ist das alle Patches wieder aus dem Quellcode entfernt werden wenn `clean` aufgerufen wird. Diese Verhalten kann verhindert werden, indem die Umgebungsvariable `NO_UNPATCH_BY_DEFAULT` gesetzt wird.

  Für das bisher beschriebene gilt das die Variable `ALL_PATCH_DIR` auf das Verzeichnis `/usr/src/kernel-patches/` verweist.

  Wird später `make-kpkg clean` aufgerufen, so werden alle Patches wieder entfernt. Dies kann durch Setzen der Umgebungsvariablen `NO_UNPATCH_BY_DEFAULT` verhindert werden.

`--arch foo`

  Setzt die Hardware-Architektur auf den angegebenen Wert. Diese Option wird nur benötigt, wenn der Kernel nicht auf der Zielplattform erzeugt wird (Cross-Compiling). Derselbe Effekt wird durch Setzen der Variablen `KPKG_ARCH` auf die gewünschte Zielarchitektur erreicht. Normalerweise wird die Architektur automatisch ermittelt.

`--cross-compile foo`, `--cross_compile foo`

  Sollte ebenfalls gesetzt werden, wenn der Kernel für eine fremde Hardware-Architektur erzeugt wird. Die Umgebungsvariable hierfür lautet `CROSS_COMPILE`.

`--subarch foo`

  Auf einigen Hardwareplattformen (beispielsweise Alpha und m68k) müssen unterschiedliche Kernel für die verschiedenen Prozessoren erzeugt werden. Die dieser Option entsprechende Umgebungsvariable lautet `KPKG_SUBARCH`.

`--arch-in-name`, `--arch_in_name`

  Diese Option vergibt einen erweiterten Namen für das Kernel-Image-Paket, so dass in einem Skript mehrere Images für Sub-Architekturen erzeugt werden können. Dies kann auch durch Setzen der Variablen `ARCH_IN_NAME` erreicht werden. Dies beeinflusst lediglich den Namen des Pakets, nicht das Verzeichnis, in dem die passenden Module abgelegt werden.

`--pgpsign name`

  Setzt die Zeichenkette, mit der die Changes-Dateien für externe Module digital signiert werden. Diese Option überschreibt die Werte, die in `/etc/kernel-pkg.conf` oder auch `~/.kernel-pkg.conf` angegeben sind.

`--config target`

  Ändert die Einstellung für die Kernel-Konfiguration. Normalerweise wird „oldconfig“ benutzt, alternativ kann hier auch „config“, „menuconfig“, „xconfig“, „old“, „menu“ oder auch „x“ angegeben werden.

  Sinnvoll ist diese Option im Zusammenhang mit `PATCH_THE_KERNEL`, wenn von den eingesetzten Patches neue Konfigurationsoptionen hinzugefügt werden.

`--targets`

  Zeigt eine Liste der bekannten „Targets“ (Ziele, hier als Zielpakete zu verstehen) an. Mehr zu den Targets später.

`--noexec`

  Übergibt die Option `-n` an das Kommando `make`, so dass keine Kommandos ausgeführt werden. Es wird lediglich angezeigt, was passieren würde.

`--initrd`

  Wenn `make-kpkg` die Option `kernel-image` übergeben wurde, so werden durch diese Option alle zusätzlichen Aktionen aufgerufen, die notwendig sind, um eine passende Init-RAM-Disk zu erzeugen.

  Hierbei ist zu beachten, dass ein zusätzlicher Patch benötigt wird, der bereits in den Debian-Kernel-Sourcen enthalten ist. Wird dieser „cramfs“-Patch nicht verwendet, so muss die Konfiguration von `mkinird` so angepasst werden, dass `cramfs` nicht benutzt wird.

`--zimage`

  Erzeugt einen zImage-Kernel statt eines bzImage-Kernels.

`--bzimage`

  Erzeugt einen bzImage-Kernel.

`--rootcmd foo`

  Kommando, mit dem auf dem System besondere Zugriffsrechte erreicht werden können. Dies können beispielsweise `sudo` oder `fakeroot` sein. Diese Option wird an das Programm `dpkg-buildpackage` weitergereicht.

`--us`

  Diese Option wird an `dpkg-buildpackage` weitergereicht; der Quellcode wird nicht digital signiert.

`--uc`

  Diese Option wird an `dpkg-buildpackage` weitergereicht; die Datei `changelog` wird nicht digital signiert.

Alle genannten Optionen können so lange verkürzt werden, bis diese nicht mehr eindeutig sind. Weiterhin ist es erlaubt, ein oder zwei Minuszeichen (`-` oder `--`) voranzustellen. Argumente können von den Optionen durch ein Leerzeichen oder ein Gleichheitszeichen getrennt sein.

Ziele (Targets)

`clean`

  Löscht alle nicht benötigten Dateien aus dem Kernel-Quellcode, die zuvor über das Target „build“ erzeugt worden sind, und führt dazu das Kommando `make distclean` aus.

`buildpackage`

  Führt die Targets „clean“ und „binary“ aus und erzeugt so ein Kernel-Paket.

`binary`

  Erzeugt alle vier möglichen Debian-Kernel-Pakete, indem die Targets `kernel_source`, `kernel_headers`, `kernel_doc` und `kernel_image` ausgeführt werden.

`kernel_source`

  Erzeugt ein Debian-Paket mit dem Kernel-Quellcode. Zeigt die Umgebungsvariable `SOURCE_CLEAN_HOOK` auf eine ausführbare Datei, so wird diese im Quellcode-Verzeichnis des Kernels ausgeführt, bevor das Paket erstellt wird. Auf diesem Weg können nicht benötigte Dateien und Verzeichnisse entfernt werden (beispielsweise architektur-abhängige Dateien oder auch Verzeichnisse, die der Versionskontrolle dienen (`find . -type d -name CVS -prune -exec rm -rf {}` )).

  Diese Option wirkt sich ausschließlich auf den Kernel-Quellcode aus, der zu einem Debian-Paket gepackt wird. Ähnliche Auswirkungen haben die Umgebungsvariablen `HEADER_CLEAN_HOOK` und `DOC_CLEAN_HOOK`: Es wird ein Programm ausgeführt, das die Kernel-Header- bzw. die Kernel-Dokumentationsverzeichnisse bearbeitet.

`kernel_headers`

  Erzeugt ein Paket mit den Kernel-Headern.

`kernel_doc`

  Erzeugt ein Paket mit der Dokumentation für den Kern.

`kernel_image`

  Erzeugt ein Debian-Paket mit dem Linux-Kernel, der aus dem Quellcode übersetzt wird. Ist noch keine Konfigurationsdatei für den Kern (`.config`) vorhanden, so wird eine Konfiguration benutzt, die der der Debian-Bootfloppies sehr ähnlich ist.

  Das Paket wird so erstellt dass, abhängig von der Hardware-Plattform, der entsprechende Bootloader aufgerufen wird, so dass der neue Kernel auch zuverlässig gestartet wird. Als Bootloader kommt dabei `LILO`, `SILO`, `QUIK`, `VMELILO`, `ZIPL`, `yaboot`, `PALO` oder auch `GRUB` zum Einsatz. Während der Installation des Pakets wird dem Administrator angeboten, eine Bootdiskette zu erzeugen. Diese wird formatiert, falls dies notwendig ist.

`build`

  Hiermit wird lediglich der Compiler gestartet und der Kernel aus dem Sourcecode übersetzt. Dieses Target wird vom Target `kernel_image` benutzt.

`modules`

  Erzeugt alle Module und die entsprechenden Debian-Pakete die sehr eng von einer passenden Kernel-Version abhängen. Hierbei wird vorausgesetzt das alle Module im Verzeichnis `/usr/src/modules` abgelegt sind. Es wird ein Debian Modul-Paket erzeugt, eine entsprechendes komprimierte tar-Datei, eine komprimierte diff-Datei. Weiterhin werden die MD5-Checksummen in der `changes`-Datei aktualisiert (mittels `dpkg-genchanges`). Die Datei wird mit der gleichen Identität digital signiert mit der auch das Kernel-Paket signiert wurde. Diese Option erlaubt einem Maintainer das Paket direkt in die Debian-Archive zu kopieren.

`modules_config`

  Konfiguriert alle Module, die sich unter `/usr/src/modules` befinden.

`modules_image`

  Erzeugt Pakete zu den Modulen unter `/usr/src/modules`, es werden aber keine Quellcode-Pakete oder Diff-Dateien erzeugt. Weiterhin wird die Changes-Datei nicht digital signiert.

`modules_clean`

  Löscht alle nicht benötigten Dateien im Verzeichnis `/usr/src/modules`.

`configure`

  Diese Option führt ein `make configure` aus, genauer genommen das mittels `--config` angegebene `config_target`, dies ist voreingestellt auf `oldconfig`. Dies bietet die Möglichkeit von `make config` erzeugte Dateien anzupassen, so das diese später nicht von `make-kpkg` verändert werden.

`debian`

  Erzeugt das Verzeichnis `debian/` innerhalb des Quellcode-Verzeichnisses und wendet vorhandene Patches auf den Quellcode an.

`libc-kheaders`

  Eine spezielle Option für den Betreuer der C-Bibliotheken.

`make-kpkg` verwendet die folgenden Umgebungsvariablen, falls diese gesetzt sind: `DEBIAN_REVISION_MANDATORY, APPEND_TO_VERSION, VERSION_H_OK, PATCH_THE_KERNEL, NO_UNPATCH_BY_DEFAULT, KPKG_ARCH, CROSS_COMPILE, KPKG_SUBARCH, ARCH_IN_NAME, INITRD, SOURCE_CLEAN_HOOK, MODULE_LOC, INITRD_OK`

Neben den Optionen, die zur Laufzeit übergeben werden, kann `make-kpkg` auch über die Konfigurationsdateien `/etc/kernel-pkg.conf` (systemweite Konfiguration) oder `~/.kernel-pkg.conf` (benutzerbezogene Konfiguration) gesteuert werden.

Die dem Debian-Paket mitgelieferte Konfiguration erlaubt es, den Namen und die E-Mail-Adresse zu überschreiben. Die Konfigurationsdateien sind als Teile eines Makefiles zu verstehen, alle in einem solchen Makefile erlaubten Funktionen können hier aufgerufen werden.

### 6.2.2 Debian-Kernel-Patches

Mit der Debian-Distribution werden neben den Sourcen für die in Debian selbst verwendeten Kernel auch eine Reihe Kernel-Patches geliefert, die in eigene Kernel integriert werden können. Ein guter Einstieg für die ersten Versuche ist der `kernel-patch-debianlogo`; dieser Patch ersetzt den beim Systemstart angezeigten Pinguin durch ein Debian-Logo. Bei der ersten Installation eines solchen Debian-Kernel-Patches wird in `/usr/src/` das Verzeichnis `kernel-patches` angelegt.

Die Installation eines solchen Kernel-Patch-Pakets wendet den Patch noch nicht an; dies geschieht erst mit dem Aufruf von `make-kpkg`:

    bash$ fakeroot make-kpkg --append-to-version=030825 \
     --added-patches=debianlogo kernel_image modules_image

Das Kommando `fakeroot` wird dabei benutzt, um beschränkte administrative Rechte auch als normaler Benutzer zu erlangen.

Wenn weitere Patches in den Kernel eingespielt werden sollen, können diese durch Kommata getrennt an der Option `--added-patches` angegeben werden.

Normalerweise benutzt `make-kpkg` „make oldconfig“, nachdem die Patches angewendet wurden. Wenn von den Patches neue Kernel-Optionen benötigt werden, so werden diese abgefragt. Alternativ kann auch die Option `--config=menuconfig` benutzt werden, um die komplette Konfiguration zu überprüfen.

### 6.2.3 Klassische Kernel

#### 6.2.3.1 Anpassen des Kernels von Hand

In einigen Fällen kann es notwendig sein, den Linux-Kernel an die eigenen Bedürfnisse anzupassen. Debian GNU/Linux installiert einen Standard-Kernel, der in den meisten Fällen ausreichend ist. Zusätzliche Treiber können über Module im laufenden Betrieb hinzugeladen werden.

#### 6.2.3.2 Benötigte Programme

Um aus den Kernel-Sourcen einen lauffähigen Kernel zu erzeugen, müssen die Quelltexte mittels eines passenden Compilers übersetzt werden. Der komplette Linux-Kernel wurde in der Programmiersprache C geschrieben - mit Ausnahme einiger ganz weniger Zeilen, die aus Geschwindigkeitsgründen in der Maschinensprache Assembler geschrieben wurden. Übrigens steht unter Linux der gcc (GNU Compiler Collection) - eine freie Implementierung eines C-Compilers - zur Verfügung.

Es werden folgende Pakete benötigt, um einen Kernel selbst zu erzeugen:

- `binutils` - Der GNU-Assembler, -Linker und einige Zusatzprogramme.

- `libc6-dev` - GNU C-Bibliothek, Entwicklerpaket.

- `gcc` - Der eigentliche GNU (EGCS) C-Compiler.

- `make` - GNU-Version von „make“.

- `bin86` - Ein 16-Bit-Assembler.

Nützlich, aber nicht zwingend erforderlich, sind weiterhin folgende Pakete:

- `libncurses5-dev` - Entwickler-Bibliotheken und Dokumentation für `ncurses`.

- `tkstep8.0-dev` - NeXTStep ähnliche Version des Tk-Toolkits. (oder `tk8.0-dev` oder `tkstep4.2-dev` oder `tk4.2-dev`).

- `kernel-package` - Debian Linux-Kernel-Paket-Skripte.

#### 6.2.3.3 Entpacken der Sourcen

Soll ein individuell auf das System angepasster Kernel installiert werden, so ist es zuerst nötig, die Kernel-Sourcen (Quellcode) zu installieren. Für den ersten Versuch ist es ratsam, die gleiche Kernel-Version zu installieren, die auch schon vom Installationsprogramm installiert wurde. Der Befehl

    cat /proc/version

gibt Ihnen die installierte Version aus. Installieren Sie nun (mit `dselect`, `dpkg` oder `apt`) die Sourcen zu diesem Kernel.

Die Kernel-Sourcen werden vom Installationsprogramm unter `/usr/src/` als Datei `kernel-source-2.x.x.tgz` abgelegt und müssen noch von Hand entpackt werden. Dies wird mit dem Befehl

    tar xvfz kernel-source-2.x.x.tgz

erreicht. Die entpackten Sourcen finden sich nun in dem Verzeichnis `kernel-source-2.x.x/`.

Dass die Debian-Quellcodes des Kernels als ein Archiv installiert werden, mag auf den ersten Blick seltsam erscheinen, da ja durch das Entpacken sogar noch mehr Speicherplatz belegt wird. Dies hat aber bei näherer Betrachtung einen guten Grund. Das Debian-Paketmanagement führt eine Datenbank über alle installierten Pakete und die dazugehörigen Dateien. Würde nun ein Kernel-Quellcode-Paket entpackt installiert werden, so würden die Anwender direkt mit diesen Dateien arbeiten und diese eventuell gar verändern. Damit wäre die zentrale Kontrolle umgangen.

Auf den Servern finden sich die aktuellen Archive des Linux-Kernels auch in einer mit bzip2 (anstatt mit gzip) komprimierten Form. Diese Archive sind noch einmal ein wenig kleiner, da bzip2 bessere Kompressionsalgorithmen verwendet. Die so gepackten Archive enden auf `.bz2`. Diese Archive können ebenfalls mit `tar` entpackt werden; hierzu ist aber die Option `-j` statt `-z` anzugeben. Beachten Sie: Es sind zwischenzeitlich einige Versionen von `tar` im Umlauf gewesen, bei denen für bzip2-komprimierte Archive die Option `-I` zu verwenden ist.

#### 6.2.3.4 Konfiguration des Kernels

Wechseln Sie nun in das Verzeichnis, in dem Sie vorher die Kernel-Sourcen entpackt haben. Mit dem Kommando `make config` erzeugen Sie die benötigte Konfigurationsdatei. Sie können hier den Kernel individuell an Ihre eigene Hardware anpassen. Bei vielen Optionen haben Sie die Möglichkeit, zwischen fest im Kernel integrierten Treibern „ `*` “ oder Modulen „ `M` “ zu wählen. Achten Sie darauf, nur die nötigen Treiber fest in den Kernel einzubinden, da sonst der Kernel zu groß wird und nicht mehr von `lilo` geladen werden kann. Gute Kandidaten auf der Liste der Module sind alle Treiber, die nicht zum unmittelbaren Systemstart benötigt werden (Netzwerk, Bandlaufwerke).

Neben `make config` stehen Ihnen alternativ die Befehle `make menuconfig` mit einer textbasierten Oberfläche ähnlich wie bei `dselect` sowie `make xconfig` unter X11 zur Verfügung. Diese erleichtern kleine Änderungen am Kernel sehr, da die gewünschten Einstellungen direkt anzuwählen sind.

Wenn Sie die Option `menuconfig` benutzen wollen, muss das Paket `libncurses5-dev` installiert sein; dieses stellt die notwendigen Funktionen für die textbasierte Oberfläche zur Verfügung.

#### 6.2.3.5 Übersetzen des Kernels

Nachdem Sie die gewünschten Einstellungen gemacht haben, werden mit dem Befehl `make dep` die Abhängigkeiten geprüft. Ein `make clean` räumt noch übrig gebliebene Dateien von der Festplatte. Einen neuen Kernel erzeugen Sie mit dem Befehl `make bzImage`. Zum Übersetzen des Kernels müssen neben einem C-Compiler auch die Pakete `bin86` und natürlich `make` (das haben Sie aber sicher vorher schon bemerkt) installiert sein. Nach einiger Zeit (wenn alles ohne Fehlermeldungen über die Bühne gegangen ist) finden Sie den neuen Kernel unter `/usr/src/kernel-source-2.x.x/arch/i386/boot/`. Dieser muss nun noch an die passende Stelle (bei Debian üblicherweise `/boot/`) kopiert werden. Abschließend ist die Konfiguration von lilo zu prüfen und ggf. anzupassen.

Statt `make bzImage` können Sie auch `make bzlilo` verwenden: Dieser Befehl kopiert den Kernel nach `/vmlinuz` und benennt vorher den schon vorhandenen Kernel in `vmlinuz.old` um. Danach wird automatisch `lilo` aufgerufen, und somit steht der Kernel dann ab dem nächsten Neustart zu Verfügung.

#### 6.2.3.6 Übersetzen der Module

Sie können nun die Treiber, die Sie bei der Konfiguration als Module ausgewählt haben, übersetzen. Dies geschieht mit dem Befehl `make modules`. Nach dem Übersetzen der Module werden diese mit `make modules_install` an den richtigen Ort kopiert.

#### 6.2.3.7 Tipps

Benutzen Sie das Zeichen „ `;` “, um mehrere Kommandos nacheinander auszuführen. Sie müssen so nicht die einzelnen Schritte beim Übersetzen eines neuen Kernels abwarten. `make dep && make clean && make bzlilo && make modules && make modules_install` erledigt einen kompletten Durchlauf ohne Pause.

Probieren Sie einfach einmal, den Kernel mit der Option `-s` zu übersetzen, also: `make -s zImage` oder `make -s bzImage`. Bei einem so übersetzten Kernel werden lediglich Warnungen und Fehlermeldungen des Kernels beim Systemstart ausgegeben. Alle Ausgaben der Treiber werden unterdrückt.

Sie können das Übersetzen des Kernels beschleunigen, indem Sie den Parameter `-j #` einfügen, wobei `#` für eine (fast beliebige) Zahl steht. Mit diesem Parameter werden, entsprechend der angegebenen Zahl, mehrere Prozesse gestartet und Teile des Kernels gleichzeitig übersetzt. Sinnvolle Werte für die Anzahl der Prozesse sind in erster Linie vom Ausbau des Hauptspeichers (RAM) abhängig. Auf Systemen mit mehreren Prozessoren wirkt sich dies natürlich auch positiv aus. Bedenken Sie bitte, dass zu hoch gewählte Werte zum Auslagern (Swappen) führen und den Vorgang merklich verlangsamen.

Um festzustellen, welcher Wert sinnvoll ist, benutzen Sie das Kommando `time make -j 10 bzImage` und variieren den Wert für die Anzahl der Prozesse.

Sollten Sie nach dem Übersetzen der Module mit `make modules; make modules_install` Probleme haben, diese zu laden, liegt dies wahrscheinlich daran, dass die Datei `modules.dep`, in der die Abhängigkeiten (dependencies) beschrieben sind, nicht aktuell ist. Es ist nicht nötig, in dieser Datei irgendetwas von Hand zu ändern: Der Befehl `depmod -a 2.2.x` erstellt eine aktuelle Datei für Sie, wobei `2.2.x` der neuen Kernel-Version entspricht.

Wenn Sie viele verschiedene Kernel-Versionen auf der Festplatte halten, kann es vorkommen, dass Fehlermeldungen in der Form `Warning: /boot/System.map has an incorrect kernel version.` erscheinen. Neben der Möglichkeit, je eine Version der `System.map` in `/boot/` und eine weitere in `/usr/src/linux/` zu halten (was maximal zwei Versionen erlaubt), bietet Debian GNU/Linux sozusagen eine „Komplettlösung“.

Das Skript `/etc/init.d/klogd` startet beim Systemstart den `klogd`. Sie können am Anfang dieses Skriptes in der Variablen `KLOGD` als Parameter `-k /boot/System.map-$(uname -r)` angeben. Eine entsprechende Zeile findet sich bereits vorbereitet in dem Skript. So wird je nach verwendeter Kernel-Version eine passende `System.map` aus `/boot/` geladen. Diese müssen Sie nach dem Übersetzen des Kernels in das Verzeichnis `/boot/` kopieren und passend zur Kernel-Version benennen. Am einfachsten können Sie das mit folgendem Kommando erledigen: `cp /usr/src/linux/System.map /boot/System.map-`uname -r``.

Hier sehen Sie ein kleines Skript, das in `/boot/` nach Kerneln sucht und eine passende `lilo.conf` erstellt, mit dem neuesten Kernel als Standardkernel.

    #!/bin/bash

    umask 772
    kernel_dir=/boot

    # lilo assumes the default image is the first one in lilo.conf, so
    # we sort the kernel images backwards, hence the highest-version'd kernel
    # will be the default.
    images=`cd $kernel_dir >> ls -1 vmlinuz-* \
     | egrep "vmlinuz-([0-9]+).([0-9]+).([0-9]+)[^-]*$" \
     | sort -rn`

    cp -f /etc/lilo.conf.static /tmp/lilo.conf

    # three lines per entry, 3 x 19 images = 57
    ( for img in $images ; do
       label=`echo $img | sed 's/vmlinuz/linux/ ; s/-//g ; s/\.//g'`
       echo "image=$kernel_dir/$img"
       echo "label=$label"
       echo ""
     done ) | head -57 >> /tmp/lilo.conf

    if /sbin/lilo -C /tmp/lilo.conf ; then
      mv -f /etc/lilo.conf /etc/lilo.conf.last
      cp -f /tmp/lilo.conf /etc/lilo.conf
      echo successfully installed new bootloader.
      rm -f /tmp/lilo.conf
      exit 0
    else
      echo eek, lilo barfed
      rm -f /tmp/lilo.conf
      exit 1
    fi

Wenn Sie einen der neueren Kernel (2.3.x oder 2.4.x) mit Debian GNU/Linux 2.2 verwenden möchten, sollten Sie folgende Zeile in die Datei `/etc/fstab` einfügen:

    none	/var/shm	shm	defaults	0	0

Ab der Kernel-Version 2.3.51 wurde das „Shared-Memory“-Dateisystem eingeführt.

### 6.2.4 SMP - Linux mit mehreren Prozessoren

Mittlerweile sind Motherboards mit mehreren Prozessoren recht preiswert zu erhalten. Diese werden natürlich auch von Debian GNU/Linux unterstützt. Die Kernel-Version 2.0.x kann bereits mit mehreren Prozessoren umgehen, und im Kernel 2.2.x wurde die Unterstützung wesentlich verbessert. Ein Umstieg ist ratsam, aber nicht zwingend nötig.

#### 6.2.4.1 Kernel 2.0

Um einen SMP-fähigen 2.0.x-Kernel zu erzeugen, muss im Makefile die Zeile: `# SMP=1` auskommentiert (also das erste Zeichen `#` entfernt) werden. Dies ist unabhängig von der Anzahl der Prozessoren; es wird lediglich die Fähigkeit aktiviert, mehrere Prozessoren zu nutzen. Linux erkennt die Anzahl der Prozessoren dann automatisch.

#### 6.2.4.2 Kernel ab 2.2

Mit der Kernel-Version 2.2.x wurde die SMP-Funktionalität weiter ausgebaut, und es gibt bei der Konfiguration des Kernels die Option, SMP einzuschalten. Es muss nichts von Hand im Makefile verändert werden. Den Parameter können Sie bei allen Konfigurationsskripten wie `make config`, `make menuconfig` oder `make xconfig` aktivieren.

Zurück | Nach oben | Weiter
Kapitel 6. Debian-Pakete im Detail | Zum Anfang | 6.3 Debian-Pakete anpassen

© 1999-2006 Frank Ronneburg - Dieser Inhalt ist unter einem Creative Commons Namensnennung - Nicht-kommerziell - Keine Bearbeitung Lizenzvertrag lizenziert (creativecommons.org/licenses/by-nc-nd/2.0/de/legalcode).