Größe: 14697
Kommentar:
|
Größe: 14630
Kommentar: 2.6.16.1
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 2: | Zeile 2: |
||Typ: ||["Kernel20"] ||["Kernel20"] prepatch ||["Kernel22"] ||["Kernel22"] prepatch ||["Kernel24"] ||["Kernel24"] prepatch ||["Kernel26"] stable ||["Kernel26"] || ||akt. Version: || 2.0.40 || - || 2.2.26 || 2.2.27-rc2 || 2.4.32 ||2.4.33-pre2 || 2.6.15.6 || 2.6.16 || ||Maintainer: || DavidWeinehall || MarcChristianPetersen || MarceloTosatti ||Greg Kroah-Hartmann u.a. ||LinusTorvalds, AndrewMorton || |
||Typ: ||["Kernel20"]||["Kernel20"] prepatch ||["Kernel22"]||["Kernel22"] prepatch ||["Kernel24"]||["Kernel24"] prepatch ||["Kernel26"] stable||["Kernel26"]|| ||akt. Version: || 2.0.40 || - || 2.2.26 || 2.2.27-rc2 || 2.4.32 ||2.4.33-pre2|| 2.6.16.1 || - || ||Maintainer: ||<-2> DavidWeinehall ||<-2> MarcChristianPetersen ||<-2> MarceloTosatti ||Greg Kroah-Hartmann u.a.||LinusTorvalds, AndrewMorton || |
Zeile 8: | Zeile 9: |
Zeile 12: | Zeile 12: |
Zeile 17: | Zeile 16: |
Zeile 20: | Zeile 20: |
Zeile 37: | Zeile 38: |
In allen LinuxDistribution{{{}}}en sind bereits fertig kompilierte ["Kernel"] enthalten, man muss also sich oft nicht selbst darum kümmern, es sei denn man hat einen zwingenden Grund. | In allen LinuxDistribution``en sind bereits fertig kompilierte ["Kernel"] enthalten, man muss also sich oft nicht selbst darum kümmern, es sei denn man hat einen zwingenden Grund. |
Zeile 40: | Zeile 42: |
Zeile 49: | Zeile 50: |
Zeile 53: | Zeile 53: |
Seit ["Kernel26"] ist diese Regel nicht mehr aktuell, die Entwicklung findet derzeit im -mm Patch von AndrewMorton statt. Wenn man sich aber die Erklärung zu den Patches von Andrew Morton ansieht, sind diese Patches wohl mehr experimenteller Art. | Seit ["Kernel26"] ist diese Regel nicht mehr aktuell, die Entwicklung findet derzeit im -mm Patch von AndrewMorton statt. Wenn man sich aber die Erklärung zu den Patches von Andrew Morton ansieht, sind diese Patches wohl mehr experimenteller Art. |
Zeile 58: | Zeile 59: |
Zeile 62: | Zeile 62: |
Zeile 64: | Zeile 63: |
Zeile 68: | Zeile 66: |
Zeile 73: | Zeile 70: |
Zeile 75: | Zeile 73: |
Zeile 89: | Zeile 86: |
Zeile 93: | Zeile 89: |
Zeile 95: | Zeile 90: |
Zeile 99: | Zeile 93: |
Zeile 101: | Zeile 94: |
Zeile 107: | Zeile 99: |
Zeile 111: | Zeile 102: |
Zeile 113: | Zeile 103: |
Zeile 119: | Zeile 108: |
Zeile 129: | Zeile 117: |
Zeile 142: | Zeile 129: |
Ebenso muss man nicht jedesmal wieder alles mit menuconfig durchkonfigurieren, sondern kann gefahrlos eine .config einer Vorversion nehmen. | Ebenso muss man nicht jedesmal wieder alles mit menuconfig durchkonfigurieren, sondern kann gefahrlos eine .config einer Vorversion nehmen. |
Zeile 145: | Zeile 132: |
Zeile 150: | Zeile 136: |
Zeile 152: | Zeile 137: |
Zeile 158: | Zeile 142: |
Zeile 164: | Zeile 147: |
Zeile 170: | Zeile 152: |
Zeile 176: | Zeile 157: |
Zeile 184: | Zeile 164: |
Wer seine Kiste richtig auslasten will, kann beim Kompilieren auch folgendes Kommando verwenden und damit mehrere Compiler gleichzeitig starten. Auf ["SMP"]-Maschinen bringt das richtig was, weil dann beide CPUs beschäftigt werden (wer mehr als 2 CPUs hat, darf auch mehr als 6 angeben ;-) ), aber selbst auf Einprozessormaschinen bringt es etwas, weil während einem Compilevorgang ja nicht immer gerechnet wird, sondern auch ab und zu auf I/O gewartet werden muss - und in der Zeit könnte dann ein anderer Compiler was rechnen. | Wer seine Kiste richtig auslasten will, kann beim Kompilieren auch folgendes Kommando verwenden und damit mehrere Compiler gleichzeitig starten. Auf ["SMP"]-Maschinen bringt das richtig was, weil dann beide CPUs beschäftigt werden (wer mehr als 2 CPUs hat, darf auch mehr als 6 angeben ;) ), aber selbst auf Einprozessormaschinen bringt es etwas, weil während einem Compilevorgang ja nicht immer gerechnet wird, sondern auch ab und zu auf I/O gewartet werden muss - und in der Zeit könnte dann ein anderer Compiler was rechnen. |
Zeile 198: | Zeile 178: |
Zeile 208: | Zeile 187: |
Zeile 214: | Zeile 194: |
* Kernel auspacken, patchen und konfigurieren wie oben. Nur soviel: Am Besten liegen die Sourcen unter {{{/usr/src/linux}}} und evtl. benötigte zusätzliche KernelModul{{{}}}e (pcmcia, alsa) unter {{{/usr/src/modules}}} (das können jeweils auch Symlinks sein). | * Kernel auspacken, patchen und konfigurieren wie oben. Nur soviel: Am Besten liegen die Sourcen unter {{{/usr/src/linux}}} und evtl. benötigte zusätzliche KernelModul``e (pcmcia, alsa) unter {{{/usr/src/modules}}} (das können jeweils auch Symlinks sein). |
Zeile 216: | Zeile 196: |
Zeile 222: | Zeile 201: |
Zeile 236: | Zeile 214: |
* {{{apt-cache search kernel-source}}} Ist aber nicht zwingend notwendig, einen Debiankernel zu verwenden. * {{{make-kpkg buildpackage --revision revision -us -uc}}} erzeugt sämtliche Debianpakete. |
* `apt-cache search kernel-source` Ist aber nicht zwingend notwendig, einen Debiankernel zu verwenden. * `make-kpkg buildpackage --revision revision -us -uc` erzeugt sämtliche Debianpakete. |
Zeile 247: | Zeile 224: |
1. {{{make mrproper}}} kann nicht schaden 1. {{{make xconfig}}} und den Kernel nach Wunsch konfigurieren 1. {{{make rpm-pkg}}} |
1. `make mrproper` kann nicht schaden 1. `make xconfig` und den Kernel nach Wunsch konfigurieren 1. `make rpm-pkg` |
Zeile 253: | Zeile 230: |
OffeneFrage: mit {{{make rpm}}} wird der Kernel (zumindest bei ["AMD64"]-Architektur) nicht komprimiert und ["LILO"] beschwert sich dann "Kernel too big". Ist dieser Bug auch bei i386 drin? Mögliche Antwort: versuche make rpm-pkg Siehe [http://www.fedoraforum.org/forum/article.php?a=4&page=2 Kommentar von mhelios] | OffeneFrage: mit `make rpm` wird der Kernel (zumindest bei ["AMD64"]-Architektur) nicht komprimiert und ["LILO"] beschwert sich dann "Kernel too big". Ist dieser Bug auch bei i386 drin? Mögliche Antwort: versuche make rpm-pkg Siehe [http://www.fedoraforum.org/forum/article.php?a=4&page=2 Kommentar von mhelios] |
Zeile 258: | Zeile 236: |
Zeile 259: | Zeile 238: |
Zeile 265: | Zeile 243: |
Zeile 274: | Zeile 251: |
Zeile 280: | Zeile 256: |
Zeile 287: | Zeile 262: |
(!) Will man nur Module nachkompilieren, sollte man im Makefile das "custom" aus der Version entfernen. Dann kann man {{{make bzImage}}} auch weglassen. (!) {{{make rpm}}}, s. o., geht natürlich auch |
(!) Will man nur Module nachkompilieren, sollte man im Makefile das "custom" aus der Version entfernen. Dann kann man `make bzImage` auch weglassen. (!) `make rpm`, s. o., geht natürlich auch |
Zeile 294: | Zeile 269: |
Dass Linux auf normalen PCs läuft, ist weit bekannt. Aber es gibt ja auch noch andere Rechner, die oft deutlich schneller sind als ihre Gigahertz-schnellen Intel/AMD/...-Kollegen. Auch auf diesen Alphas, SPARCs, MIPS, m68k und vielen anderen Rechnern kann man Linux laufen lassen. Manchmal (noch) nicht ganz so stabil wie die Original-Betriebssysteme, aber immerhin kann man so an aktuelle Software (und vor allem: Bugfixes!) kommen, und man hat immernoch ein freies Betriebssystem. Leider ist die Benutzung solcher Rechner oft nicht so ganz einfach, und wenn man einen ganzen Zoo solcher Exoten betreibt, dann kratzt man sich oft am Kopf und muss überlegen, wie z.B. man die unterschiedlichen Systeme bootet. Daher hier ein paar Exoten-Tips (die ''jetzt'' leider noch fehlten): | Dass Linux auf normalen PCs läuft, ist weit bekannt. Aber es gibt ja auch noch andere Rechner, die oft deutlich schneller sind als ihre Gigahertz-schnellen Intel/AMD/...-Kollegen. Auch auf diesen Alphas, SPARCs, MIPS, m68k und vielen anderen Rechnern kann man Linux laufen lassen. Manchmal (noch) nicht ganz so stabil wie die Original-Betriebssysteme, aber immerhin kann man so an aktuelle Software (und vor allem: Bugfixes!) kommen, und man hat immernoch ein freies Betriebssystem. Leider ist die Benutzung solcher Rechner oft nicht so ganz einfach, und wenn man einen ganzen Zoo solcher Exoten betreibt, dann kratzt man sich oft am Kopf und muss überlegen, wie z.B. man die unterschiedlichen Systeme bootet. Daher hier ein paar Exoten-Tips (die ''jetzt'' leider noch fehlten): |
Zeile 307: | Zeile 287: |
Zeile 311: | Zeile 292: |
Zeile 314: | Zeile 294: |
* Working Overloaded Linux Kernel - WOLK ist eine Zusammenfassung vieler kleiner Kernelpatches, die jeweiligen Features können ganz normal mit der Kernelkonfiguration eingestellt werden http://sourceforge.net/projects/wolk | * Working Overloaded Linux Kernel - WOLK ist eine Zusammenfassung vieler kleiner Kernelpatches, die jeweiligen Features können ganz normal mit der Kernelkonfiguration eingestellt werden [http://sourceforge.net/projects/wolk] |
Zeile 316: | Zeile 296: |
* international kernel patch - Verschlüsselte Dateisysteme, unterstützt viele Verschlüsselungsalgorithmen http://www.kerneli.org * kerneli.org ist down - /pub/linux/kernel/crypto auf ftp.kernel.org hilft euch weiter :) * C++ Support im Kernel http://netlab.ru.is/exception/LinuxCXX.shtml |
* international kernel patch - Verschlüsselte Dateisysteme, unterstützt viele Verschlüsselungsalgorithmen [http://www.kerneli.org] * kerneli.org ist down - /pub/linux/kernel/crypto auf ftp.kernel.org hilft euch weiter :-) * C++ Support im Kernel [http://netlab.ru.is/exception/LinuxCXX.shtml] |
Zeile 323: | Zeile 303: |
OffeneFrage: Gibt es eine Webseite, auf der Kernel-Konfigurationen gesammelt werden? OK, bei PCs könnte das ausufern, aber es gibt doch Hardwarezusammenstellungen, die oft auftreten, z.B. bei Laptops oder Aldi-PCs. Ganz konkret bin ich schon seit einer Weile auf der Suche nach einer vorgefertigten Config für einen Thinkpad X41-Kernel, aber ich habe noch keine aktuelle gefunden ... -- OliverKopp [[DateTime(2005-07-31T11:52:14Z)]] Ich denke einmal, so was wird es nicht geben. Die Hardware wird zwar immer gleich sein, bloß jeder User ist individuell. Angefangen bei den Dateisystem: Ein echter Linuxer gibt sich mit ext3 und swap zufrieden. Ein Windows-User dagegen benötigt vfat und ntfs. Weiter geht es bei iptables: Wer keine Firewall braucht (da er z.B. einen Router verwendet), kann auf iptables verzichten. Es gibt noch weitere Beispiele ;-) | OffeneFrage: Gibt es eine Webseite, auf der Kernel-Konfigurationen gesammelt werden? OK, bei PCs könnte das ausufern, aber es gibt doch Hardwarezusammenstellungen, die oft auftreten, z.B. bei Laptops oder Aldi-PCs. Ganz konkret bin ich schon seit einer Weile auf der Suche nach einer vorgefertigten Config für einen Thinkpad X41-Kernel, aber ich habe noch keine aktuelle gefunden ... -- OliverKopp [[DateTime(2005-07-31T11:52:14Z)]] Ich denke einmal, so was wird es nicht geben. Die Hardware wird zwar immer gleich sein, bloß jeder User ist individuell. Angefangen bei den Dateisystem: Ein echter Linuxer gibt sich mit ext3 und swap zufrieden. Ein Windows-User dagegen benötigt vfat und ntfs. Weiter geht es bei iptables: Wer keine Firewall braucht (da er z.B. einen Router verwendet), kann auf iptables verzichten. Es gibt noch weitere Beispiele ;) |
Typ: |
["Kernel20"] |
["Kernel20"] prepatch |
["Kernel22"] |
["Kernel22"] prepatch |
["Kernel24"] |
["Kernel24"] prepatch |
["Kernel26"] stable |
["Kernel26"] |
akt. Version: |
2.0.40 |
- |
2.2.26 |
2.2.27-rc2 |
2.4.32 |
2.4.33-pre2 |
2.6.16.1 |
- |
Maintainer: |
Greg Kroah-Hartmann u.a. |
Eine Übersicht über die aktuellen Versions-Nummern der wichtigsten Kernel-Bäume bekommt man durch:
finger @finger.kernel.org
Die selbe Information ist unter http://www.kernel.org/kdist/finger_banner verfügbar.
Eine nette Erklärung gibts auch unter http://de.wikipedia.org/wiki/Linux-Kernel.
Inhalt
1. Links und News
[http://ftp.de.kernel.org/pub/linux/kernel/v2.0/ 2.0er Kernel auf ftp.de.kernel.org]
[http://ftp.de.kernel.org/pub/linux/kernel/v2.2/ 2.2er Kernel auf ftp.de.kernel.org]
[http://ftp.de.kernel.org/pub/linux/kernel/v2.4/ 2.4er Kernel auf ftp.de.kernel.org]
[http://ftp.de.kernel.org/pub/linux/kernel/v2.6/ 2.6er Kernel auf ftp.de.kernel.org]
[http://www.kerneltraffic.org/kernel-traffic/latest.html Wöchentliche Zusammenfassung der Kernel-Mailingliste]
[http://user-mode-linux.sourceforge.net/ Usermode-Linux]
[http://www.kernelnewbies.org/ Alles rund um die Kernelprogrammierung, nicht nur für Neulinge]
[http://lwn.net/Articles/driver-porting/ Porting device drivers to the 2.6 kernel]
[http://lxr.linux.no/source/ Online ansehbare Kernel-Sourcen (auch als InterWiki-Link KernelSource:), z.B. Documentation. ]
[http://www.kernel.org/ kernel.org]
- ["WOLK"]
[http://linux.bkbits.net:8080/linux-2.4/ Bitkeeper-Kernelarchiv]
[http://kerneltrap.org/node/view/2976 Ketchup, automatisches Kernelpatching]
2. Kernelversionen
In allen LinuxDistributionen sind bereits fertig kompilierte ["Kernel"] enthalten, man muss also sich oft nicht selbst darum kümmern, es sei denn man hat einen zwingenden Grund.
Stabile Versionen:
- Versionen mit gerade Ziffern an 2. Stelle
- 0.xx .. 1.xx - historische Versionen
- 2.0.xx - veraltet, nur noch in spez. Anwendungen (z.B. embedded systems)
- 2.2.xx - nicht mehr aktuell, aber noch viel im Einsatz
- 2.4.xx - War bis zum 18.12.2003 der aktuelle Kernel, zumindest als Alternative zum 2.6er wird er wohl noch eine ganze Weile von den Mainstream-Distributionen angeboten werden. Siehe auch ["Kernel24"]
- 2.6.xx.y - Der aktuelle, stabile Kernel ["Kernel26"]
Entwickler-Versionen (möglicherweise nicht stabil, nicht funktionierend):
- Versionen mit ungeraden Ziffern an 2. Stelle, also z.B.:
- 2.1.xx, 2.3.xx, 2.5.xx
Seit ["Kernel26"] ist diese Regel nicht mehr aktuell, die Entwicklung findet derzeit im -mm Patch von AndrewMorton statt. Wenn man sich aber die Erklärung zu den Patches von Andrew Morton ansieht, sind diese Patches wohl mehr experimenteller Art.
Ab 2.6.11 existieren zusätzliche Kernelversionen, in denen nur Build- und Securityfixes enthalten sind. Diese werden durch das Anhängen einer 4. Ziffer gekennzeichnet. Diese Versionen erscheinen ungefähr im Wochenrythmus. Mit dem Erscheinen des nächsten offiziellen Kernels wird der Support für diese Kernelversionen eingestellt und als Basis diese nächste Version genommen.
Mit
uname -r
oder
cat /proc/version
kann man herausfinden, welcher Kernel aktuell verwendet wird.
3. Wie übersetze ich einen Kernel?
3.1. Allgemein
3.1.1. Das erste Mal
Irgendwo auspacken und bereinigen
tar xjf linux-2.4.21.tar.bz2 cd linux-2.4.21 make mrproper
Konfigurieren über Textfragen
make config
Konfigurieren über ein ANSI-Menü (benötigt ncurses)...
make menuconfig
oder über eine X11-GUI (benötigt Tcl/Tk (bei 2.4.x) bzw. QT (bei 2.6.x))
make xconfig
oder über eine X11-GUI basierend auf GTK (benötigt selbstredend GTK)
make gconfig
Bei einer Kernel-Versionen vor 2.6.x macht man nun
make dep
und nun kann man mittels folgender Befehle kompilieren
make bzImage modules
Installieren als root
su make modules_install cp arch/i386/boot/bzImage /boot/bzImage-2.4.21 cp System.map /boot/System.map-2.4.21 cp .config /boot/.config-2.4.21
BootLoader anpassen (natürlich immer noch als root)
vi /etc/lilo.conf # dann passenden Eintrag machen - siehe vorhandene # nach dem bearbeiten von /etc/lilo.conf muss man lilo ausführen, # damit die Änderungen wirksam werden. lilo
3.1.2. Updates
Man braucht sich nicht jedesmal einen kompletten Kernelsource vom ftp-Server ziehen, sondern man spart sich und dem ftp-Server-Betreiber Zeit, Geld und Bandbreite, wenn man sich einen Patch besorgt und dann einbindet.
Ebenso muss man nicht jedesmal wieder alles mit menuconfig durchkonfigurieren, sondern kann gefahrlos eine .config einer Vorversion nehmen.
Erstmal die Konfiguration sichern
cd linux-2.4.21 cp .config ../config-2.4.21
danach bereinigen
make mrproper
Patch einspielen
bzcat ../patch-2.4.21-ac1.bz2 | patch -p1
Konfiguration wieder einspielen
cp ../config-2.4.21 .config
Bei folgendem Kommando wird man nur noch Dinge gefragt, die neu sind und noch nicht konfiguriert wurden:
make oldconfig
Optional (wenn man noch was ändern will oder sich umschauen will):
make menuconfig
Danach geht's weiter wie oben.
3.1.3. Tipps für Poweruser
Wer seine Kiste richtig auslasten will, kann beim Kompilieren auch folgendes Kommando verwenden und damit mehrere Compiler gleichzeitig starten. Auf ["SMP"]-Maschinen bringt das richtig was, weil dann beide CPUs beschäftigt werden (wer mehr als 2 CPUs hat, darf auch mehr als 6 angeben ), aber selbst auf Einprozessormaschinen bringt es etwas, weil während einem Compilevorgang ja nicht immer gerechnet wird, sondern auch ab und zu auf I/O gewartet werden muss - und in der Zeit könnte dann ein anderer Compiler was rechnen.
make -j6 bzImage modules
Wer einen richtigen Stresstest veranstalten will (und viel RAM und SWAP hat und viele Filehandles), verwendet folgendes, das startet (fast) unlimitiert viele Compiler gleichzeitig. Vorsicht: die Kiste ist dann schwer beschäftigt und nicht mehr sonderlich ansprechbar für den User:
make -j bzImage modules
3.1.4. System.Map
Zum Kernel gehört auch eine Symboltabelle, die System.map. Diese Datei liegt üblicherweise direkt "neben" der Kerneldatei im gleichen Verzeichnis und trägt die gleiche Endung, z.B.:
- Kernel = /boot/bzImage, System.map = /boot/System.map
- Kernel = /boot/bzImage-2.4.18-tw1, System.map = /boot/System.map-2.4.18-tw1
Der Sinn dieser Symboltabelle liegt darin, dass z.B. bei Kernelabstürzen die Absturzadresse einem Funktionsnamen zugeordnet werden kann.
Diese Datei ist optional, der Kernel funktioniert auch ohne sie.
3.2. Kernelpakete für Distributionen
3.2.1. Debian kernel-package
Unter ["Debian"] GNU/Linux kann man sich ganz einfach einen eigenen Kernel als .deb-Paket bauen - dazu gibt es das Paket kernel-package.
Siehe auch [http://channel.debian.de/faq/ch-dpkgundco.html#s-makekpkg Anleitung in der #debian.de FAQ].
Zunächst mal muss man das Hilfsprogramm installieren: apt-get install kernel-package
Danach in /etc/kernel-pkg.conf die eigene E-Mail-Adresse eintragen (die steht nachher als "Maintainer" im fertigen Paket).
Kernel auspacken, patchen und konfigurieren wie oben. Nur soviel: Am Besten liegen die Sourcen unter /usr/src/linux und evtl. benötigte zusätzliche KernelModule (pcmcia, alsa) unter /usr/src/modules (das können jeweils auch Symlinks sein).
Zum Kompilieren folgende Befehle verwenden (der String hinter --revision ist die Revisionsnummer: So kann man Pakete unterscheiden, die auf der selben Kernelversion basieren.):
make-kpkg clean make-kpkg --revision meinkernel.1 kernel_image make-kpkg modules_image # nur notwendig, wenn man Module unter /usr/src/modules liegen hat
Das funktioniert auch gut als normaler Nutzer! fakeroot make-kpkg --revision meinkernel.2 kernel_image
entpackt man die Zusatzmodule (alsa etc.) in ein anderes Verzeichnis, so kann das mit export MODULE_LOC=pfad ausgewählt werden.
Man erhält ein Verzeichnis höher .deb-Pakete. Diese kann man mit dpkg -i Paketname installieren -- auch auf einem anderen Rechner!
Als sehr praktisch hat es sich erwiesen, auch --append-to-version -custom1 anzugeben. Damit erzeugt man dann ein Paket namens kernel-package-<kernelversion>-custom1. Dadurch kann man verschiedene Versionen gleichzeitig installieren und bei Upgrades hat man keine Probleme mit den /lib/modules Verzeichnissen.
Entsprechend dem normalen "make -j10" muss man hier die Variable $CONCURRENCY_LEVEL setzen:
export CONCURRENCY_LEVEL=4
Kann man die Kernel Sources auch als Debian-Paket bekommen?
apt-cache search kernel-source
Ist aber nicht zwingend notwendig, einen Debiankernel zu verwenden.
make-kpkg buildpackage --revision revision -us -uc erzeugt sämtliche Debianpakete.
3.2.2. Kernel-RPM aus Vanilla-Sourcen
Unter einer ["RPM"]-basierten Distribution kann man sich ganz einfach aus den offiziellen Kernelquellen ein RPM-Paket bauen.
- Kernel normal entpacken
make mrproper kann nicht schaden
make xconfig und den Kernel nach Wunsch konfigurieren
make rpm-pkg
Entweder alles als root, oder besser als User, der selbst ["RPM"]s erstellen kann.
OffeneFrage: mit make rpm wird der Kernel (zumindest bei ["AMD64"]-Architektur) nicht komprimiert und ["LILO"] beschwert sich dann "Kernel too big". Ist dieser Bug auch bei i386 drin? Mögliche Antwort: versuche make rpm-pkg Siehe [http://www.fedoraforum.org/forum/article.php?a=4&page=2 Kommentar von mhelios]
OffeneFrage: Worin besteht der Unterschied zwischen "make rpm", "make rpm-pkg" und "make binrpm-pkg"?
3.2.3. RedHat Kernel-Source-RPM
Kernel-Sourcen installieren
rpm -i kernel-source-2.4.x-xx.i386.rpm
RedHat-Konfiguration einspielen
cd /usr/src/linux-2.4 cp configs/kernel-*-i686.config arch/i386/defconfig make mrproper make oldconfig
und anpassen
make menuconfig # oder xconfig
kompilieren
make dep && make bzImage && make modules && make modules_install
danach gehts weiter wie gewöhnlich.
Will man nur Module nachkompilieren, sollte man im Makefile das "custom" aus der Version entfernen. Dann kann man make bzImage auch weglassen.
make rpm, s. o., geht natürlich auch
Falls man einen neuen Kernel installiert und Module zum booten braucht, mkinitrd nicht vergessen.
4. Linux auf Nicht-Intel-Hardware
Dass Linux auf normalen PCs läuft, ist weit bekannt. Aber es gibt ja auch noch andere Rechner, die oft deutlich schneller sind als ihre Gigahertz-schnellen Intel/AMD/...-Kollegen. Auch auf diesen Alphas, SPARCs, MIPS, m68k und vielen anderen Rechnern kann man Linux laufen lassen. Manchmal (noch) nicht ganz so stabil wie die Original-Betriebssysteme, aber immerhin kann man so an aktuelle Software (und vor allem: Bugfixes!) kommen, und man hat immernoch ein freies Betriebssystem. Leider ist die Benutzung solcher Rechner oft nicht so ganz einfach, und wenn man einen ganzen Zoo solcher Exoten betreibt, dann kratzt man sich oft am Kopf und muss überlegen, wie z.B. man die unterschiedlichen Systeme bootet. Daher hier ein paar Exoten-Tips (die jetzt leider noch fehlten):
- PowerPC-Linux (Mac, ["RS6000"])
- m68k-Linux
- StrongARM-Linux
- sh-Linux
- MIPS- und MIPSel-Linux
- Linux for S/390 ["Linux390"]
- Linux for zSeries (64bit) ["Linux390"]
5. Usermode-Linux
Siehe UserModeLinux.
6. Kernelpatches
Der Standard-Vanilla-Kernel ist zwar recht brauchbar; mittels weiterer Patches können Funktionen nachgerüstet werden, die nur in der Entwicklerversion zur Verfügung stehen oder noch nicht in dern Kernel aufgenommen worden sind.
http://www.plumlocosoft.com/kernel/patches/2.4/ - Hier gibt es Kernelpatches für die 2.4.xx Kernel, die einige Entwicklungen aus dem aktuellen 2.5er Entwicklerkernel auch für den 2.4er zur Verfügung stellt; hautpsächlich sind das Änderungen am Scheduler, die sich im Desktop sehr positiv bemerkbar machen (das Wechseln zwischen den virtuellen Desktops läuft erheblich schneller, die ganze GUI fühlt sich erheblich schneller an). Ein so gepatchter Kernel läuft bei mir seit ein paar Tagen wunderbar -- JoergHoh
der gr-security-Patch (http://www.grsecurity.net) bringt Änderungen mit, die die Sicherheit des Kernels beeinflussen;
Working Overloaded Linux Kernel - WOLK ist eine Zusammenfassung vieler kleiner Kernelpatches, die jeweiligen Features können ganz normal mit der Kernelkonfiguration eingestellt werden [http://sourceforge.net/projects/wolk]
international kernel patch - Verschlüsselte Dateisysteme, unterstützt viele Verschlüsselungsalgorithmen [http://www.kerneli.org]
kerneli.org ist down - /pub/linux/kernel/crypto auf ftp.kernel.org hilft euch weiter
C++ Support im Kernel [http://netlab.ru.is/exception/LinuxCXX.shtml]
7. Tipps und Tricks
Man sollte im Kernel, wenn man PCMCIA-Karten benutzt, nicht den ISA-Support und evtl. auch nicht den ISAPNP-Support abschalten, weil sonst auch PCMCIA-Karten nicht mehr erkannt werden!
OffeneFrage: Gibt es eine Webseite, auf der Kernel-Konfigurationen gesammelt werden? OK, bei PCs könnte das ausufern, aber es gibt doch Hardwarezusammenstellungen, die oft auftreten, z.B. bei Laptops oder Aldi-PCs. Ganz konkret bin ich schon seit einer Weile auf der Suche nach einer vorgefertigten Config für einen Thinkpad X41-Kernel, aber ich habe noch keine aktuelle gefunden ... -- OliverKopp DateTime(2005-07-31T11:52:14Z) Ich denke einmal, so was wird es nicht geben. Die Hardware wird zwar immer gleich sein, bloß jeder User ist individuell. Angefangen bei den Dateisystem: Ein echter Linuxer gibt sich mit ext3 und swap zufrieden. Ein Windows-User dagegen benötigt vfat und ntfs. Weiter geht es bei iptables: Wer keine Firewall braucht (da er z.B. einen Router verwendet), kann auf iptables verzichten. Es gibt noch weitere Beispiele