Unterschiede zwischen den Revisionen 354 und 356 (über 2 Versionen hinweg)
Revision 354 vom 2006-03-28 08:40:08
Größe: 14697
Autor: thor2
Kommentar:
Revision 356 vom 2006-03-28 18:44:48
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:

DavidWeinehall

MarcChristianPetersen

MarceloTosatti

Greg Kroah-Hartmann u.a.

LinusTorvalds, AndrewMorton

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

TableOfContents()

1. Links und News

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.

  1. Kernel normal entpacken
  2. make mrproper kann nicht schaden

  3. make xconfig und den Kernel nach Wunsch konfigurieren

  4. 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):

  • SparcLinux

  • AlphaLinux

  • 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]

  • ExecShield

  • 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 ;)

LinuxKernel (zuletzt geändert am 2007-12-23 22:46:29 durch localhost)