Ubuntu 12.10 „Quantal Quetzal“
Ubuntu 12.04 „Precise Pangolin“
Ubuntu 11.10 „Oneiric Ocelot“
Ubuntu 10.04 „Lucid Lynx“
Ubuntu 8.04 „Hardy Heron“
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Manchmal benötigt man einen angepassten Kernel mit zusätzlichen Funktionen, oder ein normalerweise dynamisch zu ladender Treiber soll fest eingebaut werden. Dann kann man sich seinen eigenen Kernel aus den Quellen kompilieren.
Wenn man einen selbstkompilierten Kernel verwendet ist es sehr schwierig bei Problemen Hilfe zu bekommen. Man kann zum Beispiel keinen Fehlerbericht auf Launchpad erstellen.
Es gibt verschiedene Möglichkeiten, einen Kernel zu kompilieren:
Die Ubuntu-Methode: Der Kernel wird auf die gleiche Weise gebaut wie der in den Paketquellen enthaltene. Diese Methode ist etwas aufwendiger, lässt sich aber teilweise automatisieren.
Die Debian-Methode mit make-kpkg: Damit lässt sich auch der originale Kernel bauen. Die erstellten deb-Pakete unterscheiden sich etwas in der Aufteilung und in der Benennung von den Ubuntu-Kerneln.
Man kann den Kernel zwar auch über die Makefiles im Quellcode kompilieren. Diese Methode wird in diesem Artikel nicht beschrieben und ist auch nicht empfehlenswert, da dabei keine deb-Pakete erstellt werden.
Man ist ein Kernel-Entwickler oder -Tester,
man möchte den Kernel auf eine spezielle Art kompilieren (z.B. um experimentelle Funktionen zu nutzen),
man besitzt Hardware, die der offizielle Ubuntu-Kernel nicht unterstützt
oder man ist einfach nur neugierig.
Wenn man nur einen Treiber kompilieren möchte, reicht es die entsprechenden linux-headers Pakete zu installieren.
Man weiß nicht, was man tut, und braucht Hilfe, wenn etwas schief läuft. Abhängig vom gemachten Fehler, kann es nötig sein, das System neu zu installieren.
Zunächst installiert man die zum Kompilieren benötigten Pakete [1].
Für die Ubuntu-Methode kann man dazu folgenden Befehl verwenden:
Befehl zum Installieren der Build-Abhängigkeiten:
sudo apt-get build-dep linux-image-$(uname -r)
sudo aptitude build-depends linux-image-$(uname -r)
Außerdem braucht man noch zusätzlich:
linux-kernel-devel (Hardy)
fakeroot (ab Maverick)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install linux-kernel-devel fakeroot
sudo aptitude install linux-kernel-devel fakeroot
Für die Debian-Methode installiert man dagegen folgende Pakete:
fakeroot
build-essential
kernel-package
mit apturl
Paketliste zum Kopieren:
sudo apt-get install fakeroot build-essential kernel-package
sudo aptitude install fakeroot build-essential kernel-package
Für das Programm zur Bearbeitung der Kernelkonfiguration braucht man weitere Pakete:
Qt3-Oberfläche | Qt4-Oberfläche | GTK-Oberfläche | ncurses-basierte Oberfläche |
Paketliste zum Kopieren: sudo apt-get install libqt3-mt-dev
sudo aptitude install libqt3-mt-dev
|
Paketliste zum Kopieren: sudo apt-get install libqt4-dev
sudo aptitude install libqt4-dev
|
Paketliste zum Kopieren: sudo apt-get install libgtk2.0-dev
sudo aptitude install libgtk2.0-dev
|
Paketliste zum Kopieren: sudo apt-get install libncurses5-dev
sudo aptitude install libncurses5-dev
|
Wenn man den offiziell ausgelieferten Kernel modifizieren will, bekommt man den Quell-Code am einfachsten über die Paketverwaltung:
apt-get source linux-image-$(uname -r)
Anschließend findet man im aktuellen Ordner folgende Dateien (evtl. andere Versionsnummern):
linux_3.2.0.orig.tar.gz (Quellcode des Kernels)
linux_3.2.0-21.34.diff.gz (Debian/Ubuntu-Patches zum Kernel)
linux_3.2.0-21.34.dsc (Beschreibung des Quellcode-Paketes)
linux-3.2.0 (Verzeichnis mit dem entpackten und gepatchten Quellcode)
GIT Trees der unterstützten und zukünftigen Ubuntuversionen: Der Inhalt ist meistens etwas aktueller als aus den Paketquellen.
Topic Branches: Kernel für spezielle Hardware oder Einsatzgebiete
Dazu braucht man das Versions-Kontroll-System Git [2] aus dem Paket
git-core
und führt folgenden Befehl aus (in diesem Beispiel für Lucid) [3]:
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.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-oneiric/ git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
Nähere Informationen zur Verwendung von git für den Kernel findet man hier.
Von kernel.org bekommt man den originalen Kernel ohne Ubuntu-spezifische Änderungen. Man findet dort Tarballs, Patches und Links zu Git [2].
Diese Anleitung geht von einem 64-Bit-Desktopsystem aus. Für andere Systeme ersetzt man amd64 durch i386 oder generic durch server.
Eine gute Vorlage bietet die Konfiguration des bereits installierten Kernels. Man findet sie im Verzeichnis /boot/. Um sie zu bearbeiten, kopiert man sie in das aktuelle Verzeichnis:
cp /boot/config-KERNELVERSION .config
Für Quellcode aus Ubuntu-Quellen findet man die Konfigurationsdateien des Kernels unter debian/config/ (Hardy) oder debian.master/config/ (ab Lucid). Sie sind aufgeteilt in Konfigurationen für Architekturen und Konfigurationen für Varianten. Um sie zu bearbeiten, muss man Architektur- und Varianten-Konfigurationen verbinden. Für Hardy:
cat debian/config/amd64/config >.config cat debian/config/amd64/config.generic >> .config
Ab Lucid:
cat debian.master/config/config.common.ubuntu >.config cat debian.master/config/amd64/config.common.amd64 >>.config cat debian.master/config/amd64/config.flavour.generic >> .config
Eine gute und leicht verständliche Zusammenfassung der Kerneloptionen findet sich unter Kernel-Seeds.org
Man kann die Änderungen mit einem Texteditor durchführen [4]. Bequemer ist allerdings die Verwendung eines Konfigurationsprogramms. Die Konfiguration muss dabei in der Datei .config vorliegen.
Je nach anfangs installierten Bibliotheken stehen verschiedene Befehle zur Verfügung:
Befehl | Beschreibung |
make gconfig | GTK-Oberfläche |
make xconfig | Qt-Oberfläche, komfortabler als gconfig und deshalb auch für GNOME-Benutzer interessant |
make menuconfig | ncurses basierte Oberfläche zur Verwendung im Terminal |
make nconfig | komfortablere ncurses basierte Oberfläche ab Kernel 2.6.35 |
make config | Zeilen-orientierte Oberfläche für die Konsole, die ohne zusätzliche Abhängigkeiten auskommt |
Für Ubuntu-Quelltext kann man zum Konfigurieren auch folgende Befehle nehmen:
fakeroot debian/rules clean debian/rules editconfigs
Vorteil: es entfällt das Hin- und Herkopieren der Konfiguration
Nachteil: Man ist beschränkt auf die ncurses-basierte Oberfläche. Außerdem wird das Konfigurationsprogramm nacheinander für alle Varianten des Kernels aufgerufen. Man sollte nur dann Änderungen vornehmen, wenn die zutreffende Variante angezeigt wird.
Es gibt weitere Make-Kommandos zum Bearbeiten oder Erzeugen der Kernel-Konfiguration:
Falls die config-Datei von einer älteren Kernelversion stammt, kann man die Konfiguration für die aktuelle Version aktualisieren:
make oldconfig
Dabei wird nach den Einstellungen für die neuen Kerneloptionen gefragt.
Seit dem Kernel 2.6.32 gibt es ein neues Kommando mit dem man eine Konfiguration so verändern kann, dass nur Module kompiliert werden, die das System gerade verwendet:
make localmodconfig
Dabei werden alle benutzten Module als Modul erstellt.
Ebenfalls ab Kernel 2.6.32 gib es das Kommando
make localyesconfig
durch das alle benutzten Module fest in den neuen Kernel einkompiliert werden. Dadurch spart man sich das Erstellen einer zum Kernel passenden initrd.
Mit dem Befehl
make defconfig
kann man eine Standardkonfiguration erzeugen. In der Regel, wird man diese Konfiguration aber noch bearbeiten müssen, um sie auf die eigenen Bedürfnisse anzupassen, zum Beispiel wird nur Unterstützung für ext2 und ext3 konfiguriert, also unter "File Systems" korrigieren, falls man ein anderes Dateisystem verwendet.
Es empfiehlt sich, ein Backup der Konfiguration außerhalb des Quellcode-Verzeichnisses anzulegen, z.B.:
cp .config ../config.variante
Oder man erstellt einen neuen Git-Branch und verwaltet die Änderungen dort.
Eine Liste aller verfügbaren Make-Kommandos kann man mit
make help
erhalten.
Weitere Informationen über die Kommandos zum Konfigurieren des Linux Kernels findet man in der Datei Documentation/kbuild/kconfig.txt.
Alternativ kann die Konfiguration des laufenden Kernels auch aus einer komprimierten Datei in /proc gelesen werden:
zcat /proc/config.gz >.config
Dies ist im Standard-Kernel von Ubuntu nicht aktiviert, bei einem selbstkompilierten kann man dieses Feature aber aktivieren.
Unter "general Setup - LOCALVERSION" kann in der Konfiguration 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). Kompiliert man den Kernel nach der Ubuntu-Methode, erstellt man stattdessen besser eine neue Variante.
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 Paket-Repository zu haben ist. Einige Patches finden sich beispielsweise in universe. 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.
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 | patch -p1
Bei bz2-Kompression ist zcat durch bzcat zu ersetzen. Liegt der Patch als Textdatei vor (.diff oder .patch) kann man diesen Befehl verwenden:
patch -p1 <PATCHDATEI
Diese Anleitung funktioniert nur mit aus Ubuntu GIT-Trees und mit apt-get source
heruntergeladenen Quellen, aber nicht mit Quellcode von kernel.org.
Für die weitere Anleitung wechselt man in das Verzeichnis mit dem Kernel-Quellcode.
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[5]. Außerdem wird angenommen, dass auf einem 64-Bit-System gearbeitet wird. Auf einem 32-Bit-System muss man "amd64" durch "i386" ersetzen.
Es müssen folgende Dateien und Verzeichnisse erstellt werden:
debian/binary-custom.d/variante/config.amd64 (Kernelkonfiguration der eigenen Variante)
debian/binary-custom.d/variante/rules
debian/binary-custom.d/variante/vars
debian/binary-custom.d/variante/patchset (Verzeichnis für Patche)
Das kann man mit folgenden Befehlen machen:
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
Außerdem müssen zwei Dateien geändert werden:
debian/control.stub
debian/control
In beiden Dateien kopiert man die drei Abschnitte, die mit folgenden Zeilen beginnen:
Package: linux-image-2.6.28-11-generic
Package: linux-headers-2.6.28-11-generic
Package: linux-image-debug-2.6.28-11-generic
Abschnitte werden dabei begrenzt durch Leerzeilen und in den kopierten Abschnitten ersetzt man "generic" durch "variante" in der Package-Zeile.
Zunächst muss man einige Dateien neu erzeugen [3]:
cp debian.master/abi/3.2.0-17.27/amd64/generic debian.master/abi/3.2.0-17.27/amd64/variante cp debian.master/abi/3.2.0-17.27/amd64/generic.modules debian.master/abi/3.2.0-17.27/amd64/variante.modules cp debian.master/control.d/vars.generic debian.master/control.d/vars.variante
Außerdem müssen einige Dateien geändert werden
debian.master/etc/getabis
debian.master/rules.d/amd64.mk
debian.master/control.d/vars.variante (optional)
Im Einzelnen:
debian.master/etc/getabis:
Man sucht nach der Zeile, die mit getall amd64
anfängt und hängt den Namen der Variante an. Zum Beispiel ersetzt man
1 | getall amd64 generic server |
durch
1 | getall amd64 generic server variante |
oder man benutzt folgenden Befehl:
sed -i "/getall amd64/s/$/ variante/" debian.master/etc/getabis
debian.master/rules.d/amd64.mk:
Man sucht nach der Zeile, die mit flavours
anfängt und hängt den Namen der Variante an. Zum Beispiel ersetzt man
1 | flavours = generic server |
durch
1 | flavours = generic server variante |
oder man benutzt folgenden Befehl:
sed -i "/flavours/s/$/ variante/" debian.master/rules.d/amd64.mk
Eine geänderte Kernel-Konfiguration muss in das debian-Verzeichnis integriert werden. Dazu kopiert man die Konfiguration an den entsprechenden Platz. Unter Hardy:
mv .config debian/binary-custom.d/variante/config.amd64
Ab Lucid:
mv .config debian.master/config/amd64/config.flavour.variante
Hinweis: Die Konfigurationsdatei .config sollte jetzt nicht mehr vorhanden sein, sonst behindert das die Kompilierung. Ebenso kann das Verzeichnis include/config/ stören, falls es beim Konfigurieren angelegt wurde, und sollte gelöscht werden.
Bei Quellcode, der mit apt-get
heruntergeladen wurde, muss man ein paar Skripte ausführbar machen, damit man keine Fehlermeldungen bekommt:
chmod +x debian/scripts/* chmod +x debian/scripts/misc/*
Anschließend führt man folgende Befehle aus:
fakeroot debian/rules clean debian/rules updateconfigs
Um den Kernel zu kompilieren führt man folgende Befehle aus:
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-variante AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-indep
Für selbst erstellte Varianten unter Hardy nimmt man folgenden Befehl:
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-variante
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.
AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian/rules binary-variante
Nach erfolgreichem Ende wurden einige Pakete erstellt (Beispiel):
$ ls ../*.deb ../linux-doc_2.6.31-21.58_all.deb ../linux-headers-2.6.31-21-variante_2.6.31-21.58_amd64.deb ../linux-headers-2.6.31-21_2.6.31-21.58_all.deb ../linux-image-2.6.31-21-variante_2.6.31-21.58_amd64.deb ../linux-source-2.6.31_2.6.31-21.58_all.deb
Vor der Installation sollte man darauf achten, dass der selbstkompilierte Kernel eine andere Version oder eine andere Variante hat als der laufende Kernel, damit man im Falle eines Fehlers den ursprünglichen noch zur Verfügung hat.
Installieren mit
sudo dpkg -i linux-headers-2.6.31-21_2.6.31-21.58_all.deb linux-headers-2.6.31-21-variante_2.6.31-21.58_amd64.deb linux-image-2.6.31-21-variante_2.6.31-21.58_amd64.deb
Dabei werden ab Intrepid Treiber, die DKMS verwenden (z.B. für Grafikkarten oder Virtualbox) falls notwendig automatisch angepasst.
Um den Vorgang zu vereinfachen gibt es ein halbautomatisches Skript .
Man speichert das Skript z.B. unter ~/bin/, macht es ausführbar und startet es aus dem Verzeichnis mit dem Kernelquellcode.
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.
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:
make-kpkg clean fakeroot make-kpkg --initrd --append-to-version=BEZEICHNUNG kernel_image kernel_headers
Mit dem ersten Befehl säubert man den Quellcode, ohne diesen Befehl kann es zu Problemen kommen.
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.
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.
BEZEICHNUNG
wird an die Kernelversion angehängt und kann aus Kleinbuchstaben, Ziffern und den Zeichen ~
-
+
.
bestehen, 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
.
Das erzeugte Kernelpaket kann nun mit dem folgenden Befehl installiert werden:
sudo dpkg -i ../kernel-image-XXX.deb
Sollte nach der Installation und Neustart eine Kernel-Panik erscheinen, die in etwa wie kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)
aussieht, kann es möglich sein, dass trotz der Eingabe --initrd
kein Initram erzeugt wurde.
Abhilfe schaffen die folgenden Befehle:
sudo update-initramfs -k version -c sudo grub-mkconfig -o /boot/grub/grub.cfg
Ersterer erzeugt zu dem neuen Kernel, welcher durch die version definiert wird, einen neuen Initram. Der Parameter version ist entsprechend der jeweiligen Kernelversion inkl. den Zusatznamen anzupassen. Der zweite Befehl fügt den neu erzeugten Initram in grub hinzu.
Nach einem Neustart des Systems lässt sich der neue Kernel im Bootmenü auswählen.
Um zu überprüfen, ob der selbstgebackene Kernel größer oder kleiner als der alte ist, kann man die /boot/vmlinuz im Terminal [3] vergleichen.
ls -lh /boot/vmlinuz-3.2.*
-rw------- 1 root root 4,8M Mär 30 07:05 /boot/vmlinuz-3.2.0-21-generic -rw------- 1 root root 4,7M Apr 1 00:47 /boot/vmlinuz-3.2.0-21-homebrew
Wie man sieht, ist der neue Kernel um 0,1 MB kleiner...
Um einen Vanilla Kernel schnell und einfach zu kompilieren, gibt es das Programm Kernelcheck. Eine ausführliche Videoanleitung gibt es in einem englischsprachigen Blog . In dem entstehenden Kernel können während der Konfiguration Patches integriert und verschiedene Optimierungen vorgenommen werden.
Die aktuelle Version der Quellen und Build-Abhängigkeiten bekommt man mit:
Befehl zum Installieren der Build-Abhängigkeiten:
sudo apt-get build-dep linux-restricted-modules-common
sudo aptitude build-depends 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[5]. Auf einer 32-Bit-Architektur ersetzt man "amd64" durch "i386".
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):
1 | ifeq "$(DEB_HOST_ARCH)" "amd64"
|
und ersetzt in diesem Abschnitt die Zeilen
1 | flavours := $(addprefix $(kernel_abi_version)-,generic openvz rt server xen) |
durch:
1 | flavours := $(addprefix $(kernel_abi_version)-,generic openvz rt server xen variante) |
Außerdem muss noch eine weitere Zeile geändert werden. Man sucht
1 | binary-arch: install build-udebs |
und ersetzt sie durch:
1 | 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
1 2 3 4 5 6 7 8 | 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:
1 | Package: linux-restricted-modules-@@ABIVER@@-generic |
Diesen Abschnitt kopiert man und ersetzt alle "-generic" durch "-variante".
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
Linux Kernel in a Nutshell - kostenloses und freies Ebook über das Konfigurieren und Kompilieren des Kernels