Hallo, On Thu, 19 Dec 2002, Thomas Hertweck wrote:

@David Haller: David, waere es moeglich, das Multikernel-HowTo zu erweitern, so dass auch erklaert wird, wie man mehrere fertige SuSE-Kernel-RPM korrekt nebeneinander installiert, so dass der alte Kernel notfalls noch gebootet werden kann? Macht man "rpm -Uhv ...", dann ist der alte Kernel ja weg.

Hm. Ich hab halt selber noch nie (ausser bei der Distri-Installation) ein Kernel-RPM installiert. Rein theoretisch muesste es aber in etwa so gehen, waere gut, wenn das jemand (mit Erfahrung beim Thema) testen/verifizieren koennte (ich werde nicht so schnell dazukommen): - alten Kernel/System.map/modules.conf sichern/kopieren (nach -`uname -r`) - /lib/modules/`uname -r` kopieren (z.B. nach /root/modules-`uname -r`) - rpm -Uvh <neuen Kernel> - neuen Kernel auch gleich ins Schema einfuegen und nach -<neue Kernelversion> kopieren usw. - modules-Sicherung zurueckkopieren - configs anpassen Die RPMDB wird dabei aber natuerlich inkonsistent, da ja die Kernels wohl immer mit den selben Dateinamen daherkommen, bei obigen gehoeren dann eben die alten Kernels zu keinem RPM mehr. (man kann aber auch mehrere RPMs parallel installieren, aber da die dann alle z.T. auf die gleichen Dateien zeigen wuerden... Hmja, ist weniger zu empfehlen.) Ok, dann ist das update wohl so langsam mal faellig ;) -dnh -- "Don't put off 'till tomorrow, responsibilities. They'll just come back to haunt you. (Ignore them totally)" -- TISM

Hallo, [ im Voraus an alle, speziell auch an "Newbies": Das folgende (und die beiden vorangegangenen Mails) sind zwar speziell, und driften teils vom eigentlichen Thema ab, aber wenn ihr Erfahrungen mit den Kernel-RPMs von SuSE habt, die das vorgeschlagene Szenario betreffen, immer her damit (per PM!)! Ich sortiere lieber ein paar dutzend "Doubletten"[4] aus, als eine "Perle" zu verpassen. Und "beissen" tu ich auch nur sehr selten *g* ] [ An den Adressaten des Bcc: Relevant ist der Abschnitt nach '@x'. Reply bitte per PM ] [ f'up vorsichtshalber gesetzt ] On Thu, 19 Dec 2002, Thomas Hertweck wrote:

David Haller wrote:

...

On Thu, 19 Dec 2002, Thomas Hertweck wrote:

...

@David Haller: David, waere es moeglich, das Multikernel-HowTo zu erweitern, so dass auch erklaert wird, wie man mehrere fertige SuSE-Kernel-RPM korrekt nebeneinander installiert, so dass der alte Kernel notfalls noch gebootet werden kann? Macht man "rpm -Uhv ...", dann ist der alte Kernel ja weg.

Hm. Ich hab halt selber noch nie (ausser bei der Distri-Installation) ein Kernel-RPM installiert.

Geht mir aehnlich... Obwohl, ein Kernel-Source-RPM habe ich schon installiert :-) Momentan jedenfalls laeuft ein Vanilla- Kernel 2.4.20 mit xfs-Patch.

Ich bleib wohl bis 2.6.2 (oder so) beim jetzigen 2.4.16 ;)

...

Rein theoretisch muesste es aber in etwa so gehen, waere gut, wenn das jemand (mit Erfahrung beim Thema) testen/verifizieren koennte (ich werde nicht so schnell dazukommen):

- alten Kernel/System.map/modules.conf sichern/kopieren (nach -`uname -r`)

Muss die modules.conf mitgesichert werden?

Wuerde ich machen. Ich habe lieber *noch* ne Kopie der modules.conf in /etc/, als dass es zu Konflikten kommt. $ ls -l /etc/modules.conf* | grep -v '~$' | wc -l 24 $ find /boot/ -name "bzI*" -o -name "vm*" | wc -l 39 $ grep -c 'image' /etc/lilo.conf 29 $ grep -Ec '^[^#]*image' /etc/lilo.conf 7 $ ls -l /etc/modules.conf* | awk '!/~$/{sum+=$5;} END{print sum;}' 93248 Also selbst in meinem "notorischen" Fall mit 24 .confs und 7 (theoretisch[5]) "bootbaren" Kernels, ist das ja bei heutigen Festplattengroessen zu vernachlaessigen ;) 90 KB? Die sollte man doch "ueber" haben, oder? Im Moment habe ich nur die .confs meiner 2.4.16er als symlinks auf eine Version, da sich die Configs nicht relevant unterscheiden. Ansonsten habe ich fuer jeden Kernel eine modules.conf.

Die liegt doch in /etc/ und stammt bei mir aus dem Paket aaa_base-2002.8.24-0,

Achso. Aehm, fast *snigger*: $ rpm -qf /etc/modules.conf file /etc/modules.conf is not owned by any package $ rpm -qf /etc/conf.modules aaa_base-99.9.8-0 $ ls -l /etc/conf.modules ls: /etc/conf.modules: No such file or directory $ ls -l /etc/conf.modules* [..] 11462 Jul 29 1999 /etc/conf.modules.orig Hm. Hatte ich da mal nicht nen symlink von conf.modules nach modules.conf? Oder hab ich den entfernt weil Yast...? Ach, egal, das laeuft seit $LONG_TIME so, dann kann's auch so weiterlaufen :) Ich mach mir mehr Sorgen um die HW, als um die SW ;)

also nicht aus einem Kernel-RPM. Gut, schaden kann es natuerlich nicht :-)

Genau ;) Und in Sachen Kernel gehe ich doch lieber auf Nummer sicher... Ich kann ja ne Fussnote einbauen, das das evtl. unnoetig ist ;)

...

- /lib/modules/`uname -r` kopieren (z.B. nach /root/modules-`uname -r`)

- rpm -Uvh <neuen Kernel>

- neuen Kernel auch gleich ins Schema einfuegen und nach -<neue Kernelversion> kopieren usw.

- modules-Sicherung zurueckkopieren

- configs anpassen

Ein kleines Problem sehe ich noch: das ganze Vorgehen haengt ein wenig davon ab, ob man wirklich einen neuen Kernel mit einer neuen Versions-Nummer (z.B. bisher 2.4.10-4GB, neu nun 2.4.19-4GB) oder ob man (wie z.B. im Falle des IDE-Problems) nur eine neue Build-Nummer des Kernels einspielt. Da muss man dann mit den Namen gut aufpassen.

Jep. Hm. Das Kernelimage koennte man dann wohl -<uname>-<rel> nennen, den Rest nur -<uname> die System.map wird kritischer, weil sich evtl. doch die Kernel-Symbole geaendert haben koennten... Die anderen Dateien sollten "kompatibel" sein. In dem Fall, dass die System.maps inkompatibel sind kommt man aber wohl eh nicht drum rum auf die naechste Version warten oder selber zu kompilieren... @x Die Kernels passend zu versionieren wuerde das Problem "erledigen" ;) Also z.B. -<uname>-<rpmrel>-<feature> statt dem bisher verwendetem Schema -<uname>-<feature>... Machbar?

...

Die RPMDB wird dabei aber natuerlich inkonsistent, da ja die Kernels wohl immer mit den selben Dateinamen daherkommen, bei obigen gehoeren dann eben die alten Kernels zu keinem RPM mehr. (man kann aber auch mehrere RPMs parallel installieren, aber da die dann alle z.T. auf die gleichen Dateien zeigen wuerden... Hmja, ist weniger zu empfehlen.)

Stimmt, die RPM Datenbank wird inkonsistent, aber a) darf man das in dem Falle glaube ich in Kauf nehmen (der Vorteil, den alten Kernel noch booten zu koennen ueberwiegt da IMHO)

Ack. Was den Kernel betrifft sind Paketverwaltungen IMO voellig egal -- wenn man keinen Kernel installiert, wird man das sicher bemerken ;)

und b) sollten Abhaengigkeiten

Das finde ich beim Kernel Humbug. Ausserdem: in welchen RPMs ist denn eine Abhaengigkeit auf "kernel" definiert? Zufaellig seh ich grad, dass ich das Kernel-RPM bei mir noch in der DB rumtreibt: $ rpm -q --whatprovides kernel lx_suse-2.2.10.SuSE-2 $ rpm -q --whatrequires kernel no package requires kernel Ach ja, dascha interessant! Kein RPM braucht das? Ja wie? Dann kann ich das RPM ja also beruhigt loeschen? Braucht ja keiner... *lol* Hm. Wie sieht obiges bei dir oder auf ner SuSE 8.1 aus? Gibt's da Abhaengigkeiten auf ein kernel-rpm (also via rpm, nicht Yast)? z.B. beim 'bc'-rpm? Evtl. mal stoebern, was ein 'rpm -qa --provides | sort' so alles ausspuckt... Ah, ich seh grad: lx_suse ist eh nur das rpm mit den quellen... -- die schon "ewig"[tm] geloescht sind *g* Oha, ein 'kernmod' mit den Modulen (die auch geloescht sind) hab ich auch noch in der DB *g* Und das eigentliche Kernel-RPM hab ich wohl deinstalliert, als der Kernel (wg. dem MTRR) auf meiner neuen HW eh nicht mehr bootete ;) Den Kernel selbst scheine ich aber noch zu haben (wohl ein Backup von irgendwann) Oehm. Beim Kernel scheint also bei mir bzgl. rpm so ziemlich _alles_ falsch zu sein... *lol*

korrekt aufgeloest werden koennen, da ja der aktuelle Kernel dann in der Datenbank steht. Wenn alles korrekt funktioniert, kann man ja die kopierten "Backups" wieder loeschen.

Jep. Aber s.o. wie's bei mir aussieht ;) Beim Kernel kann's einem IMO schnurz sein, was in der rpmdb steht -- hauptsache man deinstalliert sich nicht ausversehen mal den Kernel oder Module -- aber die will man ja wohl eh um_kopieren_, da kann man dann die Dateien "da" lassen, damit rpm/Yast nix zu meckern haben... :)

...

Ok, dann ist das update wohl so langsam mal faellig ;)

Sorry, wollte Dir keine Arbeit aufhalsen... :-)

Das Update war/ist so oder so faellig, Text zu initrd[0] hab ich auch schon, ich wollte dann aber auch gleich noch mehr machen (die HP ist ja sowieso in einem traurigen Zustand) und hab mich dann auch verzettelt, keine Zeit usw... Naja, demnaechst steht ein Providerwechsel an (mit mehr Platz, d.h. ich habe vor da auch einige goodies (scripte etc., und vielleicht das ein oder andere RPM[1]) von mir unterzubringen), da gibbet dann auch nen sog. "relaunch" meiner Seite. Und ich will sowieso mal schauen, dass ich das Howto nach linuxdoc/docbook umbaue, damit's dann als (offizielles) HOWTO eingereicht werden kann -- inzwischen scheint sich's ja nicht nur bei mir bewaehrt zu haben *bg* Und ISTR, dass bei SuSE zumindest die Kernelimages, System.maps und .configs inzwischen mit einem "-`uname -r`" Anhaengsel daherkommen -- was ich ausdrucklich begruessen wuerde ;) Und gerade jetzt mit der 8.1 ist hier das Thema "neuer Kernel" ja aktuell wie (IIRC) nie zuvor, was noch ein Grund ist, meinen Text zu saeubern/aktualisieren/erweitern... ;)

Mir ist nur aufgefallen, dass diese Frage in letzter Zeit oefters kam, und irgendwie passt sie halt in Dein Multikernel-HowTo, zu- mindest wenn man nicht gnadenlos den alten Kernel platt machen will.

Jep. Faellt ja in die gleiche Kategorie: "Wie bekomme ich mehrere Kernel sauber nebeneinander installiert" ;) Also: Freiwillge, die Erfahrung mit (SuSE) Kernel-RPMs haben vor! Wenn ich das schon einbaue, dann "richtig" ;) Also bitte (per PM!): her mit Text(fragmenten)[3], Erfahrungen, Vorschlaegen... Und zu "initrd" koennte ich auch noch das ein oder andere einpflegen (trotz [0])... -dnh PS: nur der Vollstaendigkeit halber, um was es ueberhaupt geht, hier nochmal die URL: http://www.dhaller.de/linux/multikernel.html Die URL wird (trotz Umzug/relaunch) stabil bleiben. Ggfs. aber "deprecated" und durch .../Multikernel-HOWTO.html abgeloest, aber das bleibt abzuwarten ;) [0] keine Details oder so -- nur, dass man (lt. Distri-HB) dafuer sorgen muss die zu aktualisieren und eine Erklaerung, warum ich das fuer einen selbst- und fuer einen Rechner kompilierten Kernel fuer Unfug halte... [1] i.d.R. eher experimentelle, an meinem WMaker hab ich froehlich rumgepatcht (laeuft aber "rock-stable"[2]) ;) [2] irgendne (KDE- [IIRC])-App hat mal uebel X zerschossen, da hat sich auch ein Grossteil von X (und somit auch WMaker) weggehaengt, WMaker selbst hat ganz selten mal Schluckauf (wenn irgendne App sich daneben benimmt und das halbe X in den Orkus jagt), restartet dann aber selbst dann meist -- aber nicht immer -- was aber weniger an WMaker liegen sollte ;) [3] Formulierung egal, Hauptsache sachlich korrekt [4] ich werd aber versuchen, immer zu antworten -- kann's aber, zumal jetzt wo Weihnachten vor der Tür steht, nicht versprechen ;) [5] ich habe seit >> 1 Jahr keinen der alten Kernels gebootet, zumindest teilweise ist es eher weniger wahrscheinlich, dass die noch booten... Aehm, halt, nein: sicher sogar, ich hab die Tage auf ext3 migriert, das ist in den aelteren Kernels noch nicht drin... Zeit mal die lilo.conf etc. auszumisten, denke ich ;) -- Ashamed of it? Perhaps you're an MCSE? I'm pretty sure that even a pot plant could pass that test, so if you said you were an MCSE I'd be quite likely to actually believe you. -- Lionel, asr