Hoi,
Jetzt habe ich ein Problem. Du sagst nichts falsches, aber du
vergisst das wichtigste ;-)
Nein, eigentlich nicht.
Doch, eigentlich schon.
Beim Linux-Kernel gibt es ein ausgefeiltes Versions-System: es gibt
Developer-Versionen und User-Versionen. Die Developer-Versionen kann
man als Pre- oder Alpha-Versionen verstehen, fuer die besonders
mutigen. Sie sind mit einer ungraden Versions-Zahl gekennzeichnet.
Kann mißverständlich sein:
stabil: 2.0.x, 2.2.x, 2.4.x ... 3.0.x
instabil: 2.1.x, 2.3.x, 2.5.x ... 3.1.x
Richtig.
- lies die Dokumentation
- lies die Dokumentation
- lies die Dokumentation
Du hast was vergessen:
- lies die Dokumentation nochmal
- lies die Dokumentation nochmal
- lies die Dokumentation nochmal
Große Versionsprünge (z.B. von 2.2.x auf 2.4.x) können in's Auge gehen
Eigentlich nicht. Das Update von 2.0er auf den 2.4er Kernel ist absolut
problemlos verlaufen.
/usr/src/linux ist in allen mir bekannte Fällen ein schlichter Link auf
eines der Kernelquellbäume.
Und genau deshalb habe ich geschrieben 'mv linux-kernel-sources' und nicht
'mv linux'.
root@erde> fetch url-to-sourcen
Nimm lieber "wget -c", das ist schneller und sicherer.
Quatsch. Sicherer nur, wenn die Gefahr besteht, dass Download abbricht,
und schneller kein Stueck.
root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig
Alternativ, falls X-Window installiert ist auch ein 'make xconfig', das
startet ein kleines aber sehr komfortables TCL/Tk Programm.
s/kompfortabel/unuebersichtlich/
root@erde> make bzImage
Zuerst ein 'make zImage' versuchen, erst wenn das wirklich nicht mehr
klappt bzImage, aber vorher würde ich kontrollieren, ob da nicht
einiges besser als Modul kompiliert weredn könnte. Der große Kernel ist
nicht zu empfehlen.
Auch quatsch. Der Kernel wird dadurch nicht groesser, sondern es werden nur
Teile ausgelagert. Ach ja, ausserdem:
http://www.linuxdoc.org/HOWTO/Kernel-HOWTO-5.html:
In older kernels, you don't have the option to build a
bzImage; it was simply a zImage. That option is at the
moment still available, however, given the code size of
newer kernels, it is now more or less mandatory to build
a bzImage because the older methods can't handle a kernel
that's just too large.
'more or less mandatory'...
Wenn du sagst 'ein grosser Kernel ist nicht zu empfehlen', dann stimme ich
dir zu. Man sollte so viel in Module packen, wie es geht.
root@erde> make modules modules_install
Das funktioniert nicht unbedingt mit jedem 'make', besser nacheinander
ausführen.
Quark. Wieso? der Error passiert auch, wenn man es gleichzeitig ausfuehrt.
root@erde> mv /boot/vmlinuz /boot/vmlinuz.old
Lieber vorher kontrollieren, ob er da überhaupt sitzt!
Der liegt bei SuSE-Standard-Installationen da.
root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot
Wenn das einmal getan wurde, können bei nachträglichem Bauen von
Modulen, diese ohne Reboot angedockt werden. (modprobe modul)
Das allerdings nur als root.
Wenn es etwas ausgefallenes ist, funktioniert es nirgendwo auf Anhieb ;-)
Meine TV-Karte lief unter Unix nach einem Kernel-Compile auf Anhieb ;-)
Und warum baust Du dann einen? (bzImage)
bzImage ist kein grosser Kernel (s.o.)
Mittlerweile ist aber selbst bei den Distributionen alles ausgelagert,
der Kernel gar nicht merh so riesig.
Nun, einige (ueberfluessige) Teile koennen nicht als Modul eingebunden
werden.
Ein sehr entscheidender Vorteil des Selberkompilierens ist aber der,
daß der Kernel genau auf Deine Architektur abgestimmt wird. Bei SuSE
z.B. waren die Kernel alle nur für den 386er. ein deutlicher
Geschwindigkeitsgewinn ist da zu erwarten wo mindestens ein PentiumPro
oder besser läuft.
Auch bei einem 486er ist durchaus ein grosser Vorteil zu erwarten. Die
Prozessor-Architektur des 486ers unterscheidet sich wesentlich von der
des 386ers.
Gruesse,
CK