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) ===