Frank Liebelt wrote:

[...] Kopiere vmlinuz in /boot nach /boot/vmlinuz.ok Kopiere initrd in /boot nach /boot/initrd.ok Kopiere System.map in /boot nach /boot/System.map.ok

Danach baust oder installierst Du Dir den Kernel!

Wenn er die gleiche Kernel-Version (nur in einer neueren bzw. anderen Ausgabe) installiert, dann wird er sich die Module unter /lib/modules ueberschreiben! Das kann zu Problemen fuehren. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===

Hallo und guten Morgen! 1. Bitte lerne, Emails ordentlich zu quoten, siehe dazu z.B. http://learn.to/quote/ 2. Bei Antworten, verwende bitte ein "Re: " zum Markie- ren der Antworten, kein "AW: ". Wie man anhand von so manchem Thread hier in letzter Zeit sieht, kommt der eigene MUA (der das produziert) nicht damit zu- recht und das Subject wird immer laenger und laenger und laenger... (AW: Re: AW: AW: AW: WG: <subject>) Das ist, mit Verlaub, ziemlich bloed. Frank Palvölgyi wrote:

Laut Anleitung von SuSE folgendes vorgehen:

rpm -Uhv --nodeps --force

mk_initrd

lilo

shutdown -r now

Werden jetzt dabei die Module in /lib/modules überschrieben?

Man unterscheidet da besser zwei Faelle: a) Du spielst einen neuen Kernel mit gleicher Versions- nummer (aber anderer Build-Nummer ein), also z.B. willst Du ein installiertes Kernel-RPM k_deflt-2.4.18-58 durch k_deflt-2.4.18-176 ersetzen. b) Du spielst einen neuen Kernel mit anderer Versions- nummer ein, also z.B. willst Du das Kernel-RPM k_deflt-2.4.18-58 durch k_deflt-2.4.19-54 ersetzen. Wenn Du wie oben ein "rpm -Uhv" verwendest und vorher keine Sicherungsmassnahmen ergreifst, dann wird in bei- den Faellen der alte Kernel durch den neuen Kernel er- setzt! Das bedeutet, sollte der neue Kernel nicht booten, kannst Du erst einmal nicht auf eine alte Version zu- rueckgreifen, sondern musst ueber das Rettungssystem Dein System wieder auf Vordermann bringen. Wenn Du nach dem Update im Fall (b) noch ein Verzeichnis /lib/modules// hast, dann liegt das wahrscheinlich daran, dass dort eigene Module installiert sind, die nicht Teil des Kernel-RPMs sind. Damit kann RPM beim Update das alte Module-Verzeichnis nicht loeschen. Im Prinzip muesste das Verzeichnis aber verschwunden sein. Will man sich den alten Kernel erhalten, so reicht es im Fall (b), die Dateien System.map, vmlinuz* sowie initrd unter /boot - wie bereits mehrfach ausfuehrlich darge- stellt - zu sichern. Den neuen Kernel muss man dann mit "rpm -ihv --nodeps --force" einspielen. In diesem Falle (und vermutlich nur hier) ist IMHO die Anwendung von --nodeps und --force beim Einspielen via RPM gerechtfer- tigt. Die alten Module bleiben unter /lib/modules/ er- halten, weil die neuen Module aufgrund der anderen Ker- nelversion in ein anderes Verzeichnis installiert werden. Wichtig: der neue Kernel unter /boot muss auch mit einer Versionsnummer versehen werden (d.h. zum Beispiel "mv vmlinuz vmlinuz-2.4.19", und insbesondere die System.map nicht vergessen). Grund: Wenn Du mehrere System.map mit verschiedenen Kerneln verwenden willst, dann muss jede eine Versionsnummer tragen, sonst wird naemlich _immer_ (egal welchen Kernel Du bootest) die Datei /boot/System.map _ohne_ Versionsnummer verwendet, und die passt dann u.U. nicht. Verwendet man mehrere Kernel, dann muss man auch mit /etc/modules.conf ein bisschen aufpassen. Was da genau zu beachten ist, laesst sich sehr schoen bei David nachlesen, siehe http://www.dhaller.de/linux/multikernel.html. Natuerlich sollte man noch seinen Boot-Loader anpassen (d.h. grub oder lilo in den meisten Faellen) und dort einen Eintrag zum Booten des alten Kernels vornehmen. Bei lilo ist an- schliessend zwingend noch /sbin/lilo aufzurufen, sonst wird das Update schief gehen! Im Fall (a) ist die Sache nicht so einfach. Selbst wenn Du dort die Dateien unter /boot sicherst, werden die Mo- dule unter /lib/modules beim Einspielen des RPMs via "rpm -ihv --nodeps --force" ueberschrieben, da diesmal kein neues Verzeichnis fuer die Module angelegt wird (da ja die gleiche Kernel-Version, nur eine neuere Build- Nummer, installiert wird). Das kann gut gehen (da die Module bei gleicher Kernel-Version kompatibel sein soll- ten, zumindest wenn Du bei einem SuSE-Kernel bleibst), muss aber nicht. In so einem Falle (und eigentlich mache ich das immer), wuerde ich den neuen Kernel selbst com- pilieren und mit einer Minor-Versionsnummer versehen, wie in o.a. Multikernel-Howto auch ausfuehrlich beschrieben. Als Vorlage kann man sich die Datei /boot/vmlinuz.config aus dem neuen Binary-RPM besorgen, diese nach /usr/src/<meine-neuen-kernel-quellen>/.config kopieren und dort dann ein "make oldconfig" ausfuehren, dann hat man exakt die Konfiguration des SuSE-Kernels kopiert. Zu- dem wie schon angedeutet im Makefile eine Minor-Versions- nummer setzen und dann den Kernel normal compilieren und installieren. Generell compiliere ich Kernel eigentlich immer selbst, so weiss man genau, was im Kernel enthalten und was als Modul realisiert ist und kann auch auf eine initrd ver- zichten. Zudem kann man dabei recht viel lernen. Nimmt man als Startpunkt eine alte funktionierende Konfigu- ration (die laesst sich ja klonen und somit auf den neuen Kernel uebertragen), dann kann auch nicht so viel schief gehen :-) Gruesse, Thomson PS: @David: David, wir hatten es schon mal davon, evtl. einen Abschnitt zum Einspielen mehrerer Kernel-RPM in das Multikernel-Howto aufzunehmen. Hast Du da- rueber mal nachgedacht? Irgendwie ist die Frage ja immer aktuell :-) -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===