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.
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 Hardware-Konflikte 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 linux-source-2.x.xx), welche mit apt-get installiert werden können. Es können aber
auch die Original Kernel-Quellen 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.
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 linux-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: linux-image), der Versionsnummer des Kernels (zum Beispiel 2.6.18, 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/linux-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 Verzeichnis zeigen, in dem zusätzliche
Dokumentation liegt, die im Verzeichnis /usr/share/doc/linux-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 Kernel-Paket mittels make-kpkg und den gewünschten Optionen erzeugt.
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: Wird 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 Setzen der Konfigurationsvariablen patch_the_kernel oder der
Umgebungsvariablen PATCH_THE_KERNEL auf den Wert YES. Zu beachten ist, dass alle Patches
wieder aus dem Quellcode entfernt werden, wenn clean aufgerufen wird. Dieses
Verhalten kann verhindert werden, indem die Umgebungsvariable NO_UNPATCH_BY_DEFAULT gesetzt wird.
Für das bisher Beschriebene gilt, dass 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 Hardware-Plattformen (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 linux-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 Source-Code ü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, dass alle Module im Verzeichnis /usr/src/modules abgelegt sind. Es
wird ein Debian Modul-Paket erzeugt, eine entsprechende
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. Es ist
voreingestellt auf oldconfig. Dies bietet die
Möglichkeit, von make config erzeugte Dateien
anzupassen, so dass 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.
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.
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.
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.
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 linux-source-2.x.x.tgz abgelegt und müssen noch
von Hand entpackt werden. Dies wird mit dem Befehl
tar xvfz linux-source-2.x.x.tgz
erreicht. Die entpackten Sourcen finden sich nun in dem Verzeichnis linux-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.
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.
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/linux-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 zur Verfügung.
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.
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.6.x erstellt eine aktuelle Datei für
Sie, wobei 2.6.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.
© 1999-2008 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).