Am Mit, 08 Mai 2002 schrieb René Matthäi:
Am Mittwoch, 8. Mai 2002 01:15 schrieb Henne Vogelsang:
On Wednesday, May 08, 2002 at 00:47:12, Guido Laubender wrote:
On Tue, 7 May 2002, Henne Vogelsang wrote:
kernel-source.rpm installieren cd /usr/src/linux zcat /proc/config.gz > .config
make cloneconfig sollte das auch tun.
Beide Methoden funktionieren nur, wenn der laufende Kernel den /proc/config.gz Patch enthält (die SuSE-Kernel tun das, bei vanilla-Kerneln muß man das selbst einpatchen) make cloneconfig erfordert zuätzlich, daß der neue Kernel, den Du übersetzen willst, ebenfalls den Patch enthält.
make menuconfig exit make dep make clean make bzImage cp arch/
/boot/bzImage /boot/vmlinuz.neu cp System.map /boot/System.map.neu Genau das, inklusive lilo-Aufruf, tut make bzlilo
Ich behalte bei sowas lieber die Kontrolle. Außerdem ist es vor allem dann, wenn man an der Konfiguration des Kernels was geändert hat, z.B. etwas als Modul kompiliert, was vorher fest eingebunden war oder umgekehrt, eminent wichtig, auch eine zum Kernel passende modules.conf zu haben. Außerdem ist mit das Namensschema mit vmlinuz und vmlinuz.neu zu starr, ich habe meist mehr als zwei bootfähige und im Prinzip lauffähige Kernel. Deshalb mal wieder der Hinweis auf D.Hallers Multikernel-Howto www.dhaller.de/linux/multikernel.html
make modules make modules_install mk_initrd -k vmlinuz.neu -i initrd.neu
_Das_ ist neu: weiß jemand, ob und warum man das braucht, und zwar auch, wenn man make bzlilo verwendet?
Weiß nicht, was bzlilo macht, aber wenn Du mit einer InitRD arbeitest, mußt Du es machen. SuSE und andere Distributoren machen das aus verständlichen Gründen, für einen selbst kompilierten und auf die Maschine angepaßten Kernel halte ich eine InitRD gelinde gesagt für Schwachsinn, alles was zum Booten benötigt wird, also Filesystem der Rootpartition, SCSI-Controller etc.. gehört fest in den Kernel, warum sollte man das als Modul kompilieren.
in /etc/lilo.conf den neuen kernel und die neue initrd eintragen lilo -v reboot Ok. Die beschreibung war nur für den kernel. Du solltest noch
alsa pcmcia (falls nötig)
ACK.
nvidia treiber (falls nötig)
Wenn man sich das wirklich antun will!
neu kompilieren.
einfach auf das entprechende src.rpm ein rpm --rebuild machen. Dann findest du unter /usr/src/packages/RPMS/<arch>/ die entsprechenden rpms.
Die RPMs enthalten doch dann wohl nur Kernelmodule, ja? Warum sollte ich die per RPM installieren, ich habe die Quellen der externen Treiber auf der Platte, wenn ich einen neuen Kernel compiliert habe, werden die auch für diesen Kernel kompiliert, mit make install installiert, depmod -A und fertig. Was passiert denn bei dem RPM Ansatz, wenn ich die installiere? Werden dann die Module für den alten Kernel gelöscht, oder wie regelt RPM das?
Sind alsa, pcmcia und nvidia wirklich die einzigen Teile, die getrennt übersetzt werden müssen? Früher gab's doch noch z. B. OSS-Module, oder?
OSS ist schon lange im Kernel (zumindest das freie OSS, das kommerzielle hat sich wohl mit ALSA überlebt). ALSA ist übrigens in den aktuellen Entwicklerkernelen (die aber wirklich für Entwickler gedacht sind, vorm Ausprobieren wird gewarnt) auch im Kernel-Tree enthalten. VMWare hat z.B. auch Module die extern kompiliert werden müssen, theoretisch gibt es noch viele andere, eigentlich immer dann, wenn Treiber bereit gestellt werden, die nicht direkt zum Kernel gehören.
Was ändert sich denn, wenn man einen neuen Kernel verwenden will? Man muss sich dann doch nur die neueren externen Sourcen für alsa etc. holen, oder?
Ein neuer Kernel bedeutet jedoch nicht zwangsläufig, daß man auch ALSA updaten muß. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen