http://www.dhaller.de/linux/multikernel.html erklärt mehrere Kernels am Beispiel von 2.2.x Kernels. Kann man das auch für 2.4.x mit grub anwenden? Wie gehe ich am besten vor? Wie man einen Kernen grundsätzlich kompiliert, weiß ich. Erstmal ein make cloneconfig? Soll ich dann das Verzeichnis linux-2.4.20 von linux-2.4.20.tar.gz einfach nach /usr/src kopieren? Dort gibt es bereits ein linux-2.4.20.SuSE und in das Verzeichnis linux-2.4.20 wechseln? Ich habe noch nie einen Kernel gepatcht, sondern immer die Vollversion kompiliert, Wie läuft das mit patch-2.4.21-rc2? Muß ich vorher linux-2.4.20 installieren oder kann ich gleich patchen oder ist es besser noch einen weiteren Kernel zu bauen? Al
Al Bogner schrieb:
http://www.dhaller.de/linux/multikernel.html erklärt mehrere Kernels am Beispiel von 2.2.x Kernels.
Kann man das auch für 2.4.x mit grub anwenden?
Prinzipiell schon. Allerdings ist die Syntax der Boot- loader-Konfigurationsdatei anderst, es entfaellt zudem der Aufruf von /sbin/lilo.
Wie gehe ich am besten vor?
Wie im Multikernel-Howto beschrieben.
Wie man einen Kernen grundsätzlich kompiliert, weiß ich.
Hmm.
Erstmal ein make cloneconfig?
Das haengt davon ab, ob Du einen SuSE-Kernel hast oder nicht: Ein "make cloneconfig" geht nicht, wenn Dein neuer Kernel ein Vanilla-Kernel ist. Dort muss man auf andere Weise vorgehen, wenn man eine bestehende Konfi- guration klonen will (kopieren der .config und ausfueh- ren von "make oldconfig"). Ferner musst Du selbst wis- sen, ob Du Deine Konfiguration "from scratch" starten willst, oder ob Du mit einer funktionierenden Konfigu- ration starten und dann Veraenderungen vornehmen willst.
Soll ich dann das Verzeichnis linux-2.4.20 von linux-2.4.20.tar.gz einfach nach /usr/src kopieren? Dort gibt es bereits ein linux-2.4.20.SuSE und in das Verzeichnis linux-2.4.20 wechseln?
Wo die Kernel-Quellen liegen, ist prinzipiell nicht so wichtig. Meistens findet man sie unter /usr/src. Du kannst im Prinzip so vorgehen, wie Du es vorschlaegst. Dann gibt es neben linux-2.4.20.SuSE eben auch ein linux-2.4.20 bzw. linux-2.4.21-rc2 in /usr/src. Der Link /usr/src/linux, falls er besteht, sollte uebri- gens immer auf die Quellen des momentan laufenden Kernels zeigen.
Ich habe noch nie einen Kernel gepatcht, sondern immer die Vollversion kompiliert, Wie läuft das mit patch-2.4.21-rc2? Muß ich vorher linux-2.4.20 installieren oder kann ich gleich patchen oder ist es besser noch einen weiteren Kernel zu bauen?
Du entpackst die Quellen des Kernels 2.4.20. Dann gehst Du in das Verzeichnis und fuehrst dort ein gunzip -c /pfad/zu/patch-2.4.21-rc2.gz | patch -p1 aus. Je nachdem, wie der Patch erstellt wurde, muss man evtl. die Option -p anpassen, fuer den o.a. Patch sollte das aber passen. Nach dem Einspielen des Patches solltest Du das Kernel-Sourceverzeichnis dann in linux-2.4.21-rc2 umbenennen, falls das noch nicht geschehen ist. Anschlies- send die Kernelkonfiguration durchfuehren, Kernel compi- lieren und installieren. Falls Du mehrere Kernel mit un- terschiedlicher Konfig testen willst, dann beachte die Variable EXTRAVERSION im Makefile - das wird auch im o.a. Multikernel-Howto beschrieben. CU, 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, On Thu, 22 May 2003, Peter Lipp wrote:
Am Donnerstag, 22. Mai 2003 20:56 schrieb Thomas Hertweck:
Der Link /usr/src/linux, falls er besteht, sollte uebri- gens immer auf die Quellen des momentan laufenden Kernels zeigen.
Walum?
Dalum! Im Ernst: es gibt diverse Leute (AFAIR u.a. Linus) die das Gegenteil sagen. Das ganze haengt dann noch obendrein davon ab, ob /usr/include/linux ein symlink auf /usr/src/linux/include/linux ist oder ein Verzeichnis mit den Kernel-Headern, gegen die die installierte glibc gelinkt wurde. Kurzfassung: Probleme bekommst du bei Inkompatibilitaeten in allen Varianten, der Unterschied ist, _wann_ du die Probleme bekommst/bemerkst. Bei der Variante, dass /usr/include/linux ein symlink ist und in /usr/src/linux der aktuelle Kernel liegt bekommst du evtl. Probleme frueher mit als bei den anderen Varianten. Jedenfalls: jede Variante hat Vorzuege und Nachteile. Und deswegen ziehe ich (und offenbar auch Thomson) diese Variante vor. Du bekommst Fehlermeldungen i.d.R. spaetestens beim linken, und nicht erst, wenn du ein Programm starten willst usw... Ich bin bisher jedenfalls immer gut mit der symlink-Variante gefahren, d.h.: /usr/src/linux -> /usr/src/linux-`uname -r` /usr/include/linux -> /usr/src/linux/include/linux z.B.: Meine glibc-2.1.3 wurde IIRC gegen den SuSE-Kernel 2.2.10 der SuSE 6.2[1] gelinkt, aktuell laeuft 2.4.16-3 und eben dieser liegt auch in /usr/src/linux. Probleme: keine relevanten. Die Probleme die Auftauchen sind dergestalt, dass sich a) alte Programme nicht mehr neu kompilieren lassen oder b) alte Programme nicht mehr laufen, weil sich der Kerneltreiber geaendert hat. Letzteres hatte ich neulich mit 'kcmjoy', das war gegen Kernel 2.2.10 kompiliert, aber diese Schnittschelle gibt's in meinem Kernel nicht mehr. Ich bekam also ein "no devices detected". Ich hab mir dann das (alte! KDE1) kcmjoy src.rpm geschnappt, den mitgelieferten (alten) joystick-Treiber geloescht und *tada*, das Teil liess sich auch gegen den neuen Treiber kompilieren und das Proggie laeuft auch ;) Ja, und was waere gewesen, wenn ich in /usr/include/linux noch die Linux-Header gehabt haette, gegen die die glibc kompiliert wurde, wie u.a. eben von Linus gefordert? Nun, dann waere kcmjoy wieder gegen diese Header kompiliert worden und haette immer noch nicht funktioniert -- auch wenn es "sauber" durchkompiliert haette, denn diese Header haetten die alte, bei mir nicht mehr vorhandene Schnittstelle deklariert. Fazit: s.o. und ich denke eben einfach, dass wenn man etwas kompiliert, dass Kernel-Header einbindet, dann sollte man auch die Header verwenden, die der aktuellen Realitaet (d.h. dem laufenden Kernel) entsprechen. Diese Problematik betrifft aber i.d.R. nur die, bei denen der Altersunterschied zwischen Kernel und der glibc und den Programmen signifikant ist. Wenn das bei dir (wie bei den meisten) nicht der Fall ist, dann wirst du in der Praxis keine Unterschiede merken. Wer aber z.B. inzwischen mit 2.5er Kernels spielt (oder dann irgendwann auf den 2.6er updated, ohne die Distri zu aktualisieren), der wird mit diesem Thema wohl Bekanntschaft machen. -dnh [1] Oder gegen den SuSE 2.2.12 der 6.3/6.4 ich bin mir nicht ganz sicher, da ich die glibc von 2.1.2 auf 2.1.3 aktualisiert habe. -- 172: Internet Das längste Kabel der Welt. (Lutz Frommberger)
Peter Lipp schrieb:
Am Donnerstag, 22. Mai 2003 20:56 schrieb Thomas Hertweck:
Der Link /usr/src/linux, falls er besteht, sollte uebri- gens immer auf die Quellen des momentan laufenden Kernels zeigen.
Walum?
Splichst Du nun chinesich? :-) Es gibt Programme, die suchen (immer noch) die Kernel-Header in /usr/src/linux - wenn der Link nun auf ein Kernel-Verzeich- nis zeigt, was nicht die zum momentan laufenden Kernel passen- den Sourcen (Header) enthaelt, dann geht das schief. Versuche z.B. mal ein externes Kernel-Modul zu compilieren, wenn der Link falsch ist, das Makefile zum Compilieren diesen Link aber auswertet. Besser waere vielleicht, /lib/modules/`uname -r`/build auszuwerten, aber AFAIK gibt es da (immer noch?) keinen Standard. Dem Problem ist eben auch (in abgewandelter Form) Christof aufgesessen (siehe Thread "kernel kompilieren"). Es gab mal eine laengere Diskussion hier, auf was genau der Link /usr/src/linux gesetzt sein soll (schau mal ins Archiv, das steht IIRC im Zusammenhang mit libc und Kernel, als Suchbegriffe verwendet solltest Du da was fin- den) - inzwischen ist die Problematik aber hinfaellig, da /usr/include/linux einen kompletten Satz Header enthaelt und nicht mehr ein Link auf ../src/linux/include/linux/ ist. Ich sehe gerade, David hat auch geantwortet, dann lies Dir das genau durch, er war IIRC damals auch an der Diskussion (haupt)beteiligt ;-) CU, 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, On Fri, 23 May 2003, Peter Lipp wrote:
Am Freitag, 23. Mai 2003 08:32 schrieb Thomas Hertweck:
Splichst Du nun chinesich? :-) Sing it: I like Chinese, I like Chinese! There's 500 million of them, so you better learn to like them, that's what I say. Wie alt ist wohl dieses Lied?
Sehr alt. Es sind inzwischen 1200 Millionen (IIRC). F'up -dnh -- 175: NT-Admin Turnschuhe, Schweissfüsse Weiß, wo der Computer angeht und daß man Probleme durch Neustart, Neuinstallation oder Neubelegung eines 4000-DM-Kurses in Unterschleißheim lösen kann. (Anders Henke)
Hallo, On Thu, 22 May 2003, Al Bogner wrote:
http://www.dhaller.de/linux/multikernel.html erklärt mehrere Kernels am Beispiel von 2.2.x Kernels.
Ja, das HOWTO ist in Ehren gealtert ;) Update ist aber in Arbeit.
Kann man das auch für 2.4.x mit grub anwenden?
Aber sicher!
Wie gehe ich am besten vor?
So wie beschrieben, nur dass du eben den Kram fuer LILO durch den fuer Grub (d.h. einfach einen neuen Eintrag in die /boot/grub/menu.lst einfuegen und gut is). Wenn du eine initrd verwenden willst musst du diese in beiden Faellen passend erstellen und dem Bootmanager angeben.
Wie man einen Kernen grundsätzlich kompiliert, weiß ich.
Erstmal ein make cloneconfig?
Kommt auf den Kernel an, den du kompilieren willst. 'cloneconfig' ist SuSE-Spezifisch und haengt vom /proc/config.gz-patch ab. [Rest siehe Thomson's Mail] -dnh -- Of course. Anything with more than 2 buttons is too complex. This includes things with 2 or less buttons. This may include clothing. -- Satya in asr
participants (4)
-
Al Bogner
-
David Haller
-
Peter Lipp
-
Thomas Hertweck