Multikernel (Schritt für Schritt)
http://www.dhaller.de/linux/multikernel.html Dazu wechseln wir ins Verzeichnis /usr/src/linux und editieren mit unserem Lieblingseditor das sich dort befindliche Makefile: Ich verstehe den Sinn in meinem Fall nicht ganz: Ich habe den SuSE-Original-Athlon-Kernel (8.2) und der soll für Notfälle erhalten bleiben. Die ganzen Kernelparameter sind so weit ok und brauchen nicht geändert werden. Dazu habe ich einfach die vmlinuz kopiert und kann auch bereits von dieser vmlinuz2 starten, initrd wurde auch angelegt. Wenn ich jetzt das Makefile editiere und den weiter beschriebenen Schritten folge, kompiliere ich doch nur einen Kernel mit den SuSE-Sourcen. Wenn ich ein make cloneconfig mache und nichts ändere, dann erhalte ich doch wieder den selben Kernel, oder? Ist in diesem Fall der Eintrag der Extraversion wichtig? Welche Zahl empfiehlt sich für die Extraversion zu verwenden, wenn man auch Mantel-Kernel (rpm) testet? Ich möchte aber einen Vanilla-Kernel ausprobieren. Dazu habe ich den Kernel entpackt und linux-2.4.20 nach /usr/src kopiert. Müßte ich in meinem Fall nicht dieses Makefile editieren? On Thursday 22 May 2003 20:56, Thomas Hertweck wrote:
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.
Der augenblickliche Kernel hat die Standard-Einstellungen von SuSE 8.2. Gibt es da einen Unterschied zu "from scratch"? Ich verstehe noch nicht die Auswirkungen für einen Vanilla-Kernel von make oldconfig bzw. warum muß ich die .config kopieren? Gehen wir von der Siutation aus, dass ich die für den SuSE-Athlon-Standardkernel verwendeten Parameter für den Vanilla-Kernel verwenden möchte und für erste Tests nichts ändern will. Al
Hallo, On Tue, 27 May 2003, Al Bogner wrote:
http://www.dhaller.de/linux/multikernel.html
Dazu wechseln wir ins Verzeichnis /usr/src/linux und editieren mit unserem Lieblingseditor das sich dort befindliche Makefile:
Ich verstehe den Sinn in meinem Fall nicht ganz:
Erstmal: 1. bitte ich unten auf o.g. Seite darum bei Verstaendnisschwierigkeiten sich direkt an mich unter der dort angegebene Mailadresse zu wenden. ("Hae? und Diverses" ist doch verstaendlich oder?) 2. zitierst du den Text von o.g. Seiten ohne dass du das Zitat kenntlich machst. 3. ein Update der Seite ist in Arbeit.
Ich habe den SuSE-Original-Athlon-Kernel (8.2) und der soll für Notfälle erhalten bleiben. Die ganzen Kernelparameter sind so weit ok und brauchen nicht geändert werden. Dazu habe ich einfach die vmlinuz kopiert und kann auch bereits von dieser vmlinuz2 starten, initrd wurde auch angelegt.
Das ist ueberfluessig. Eine Kopie hast du schon als vmlinuz.shipped.
Wenn ich jetzt das Makefile editiere und den weiter beschriebenen Schritten folge, kompiliere ich doch nur einen Kernel mit den SuSE-Sourcen. Wenn ich ein make cloneconfig mache und nichts ändere, dann erhalte ich doch wieder den selben Kernel, oder?
Theoretisch ja (wenn die durch das 'make cloneconfig'[1] erzeugte config wirklich identisch ist).
Ist in diesem Fall der Eintrag der Extraversion wichtig?
Nein. In dem Fall laesst du die Kompiliererei lieber ganz.
Welche Zahl empfiehlt sich für die Extraversion zu verwenden, wenn man auch Mantel-Kernel (rpm) testet?
Zahl? Wichtig ist, dass sich fuer $(KERNELRELEASE) eine eindeutige Version ergibt. KERNELRELEASE setzt sich aus VERSION, PATCHLEVEL, SUBLEVEL und EXTRAVERSION zusammen, falls EXTRAVERSION nicht gesetzt ist, haengt das SuSE-Makefile stattdessen ggfs. weitere Strings (-4GB, -SMP, -athlon) als EXTRAVERSION ein. Je nachdem welche Versionierung die Mantel-Kernel haben, muss man die EXTRAVERSION waehlen. Ich verwenden wie gesagt ein '-n' Anhaengsel, wobei 'n' _meine_ Version der config ist. Ausserdem fuege ich ggfs. noch weitere strings an, z.B. hab ich mal '-2-8139dbg' als EXTRAVERSION fuer eine Kernelvariante verwendet, bei der ich das Debugging im 8139-Treiber angeschaltet habe, die aber ansonsten identisch zu meiner '-2' Variante war. Eine bestimmte "Zahl" kann man also nicht "vorgeben", ich fang halt mit nem '-1' an.
Ich möchte aber einen Vanilla-Kernel ausprobieren. Dazu habe ich den Kernel entpackt und linux-2.4.20 nach /usr/src kopiert. Müßte ich in meinem Fall nicht dieses Makefile editieren?
Ja. Das ist noch etwas ungenau bzw. fehlt noch im HOWTO. Wie du vorgehen musst haengt davon ab, wie die aktuelle Situation ist. - /usr/src/linux ist ein Verzeichnis? -> mv /usr/src/linux /usr/src/linux-`uname -r` - /usr/src/linux ist ein symlink auf 'linux-`uname -r`? -> rm /usr/src/linux Anschliessend legst du einen symlink linux auf linux-<neueKernelversion> an. -> cd /usr/src/linux; ln -s linux-<neueKernelversion> linux Ab da gilt dann das im HOWTO beschriebene. Obiges steht uebrigens IIRC im Kernel-HOWTO (das generell Voraussetzung fuer mein Multikernel-HOWTO ist).
On Thursday 22 May 2003 20:56, Thomas Hertweck wrote: [..] Der augenblickliche Kernel hat die Standard-Einstellungen von SuSE 8.2. Gibt es da einen Unterschied zu "from scratch"?
Oh ja. Der SuSE Kernel hat praktisch alle Treiber aktiv[2]. Der Vanilla-Kernel fast keine.
Ich verstehe noch nicht die Auswirkungen für einen Vanilla-Kernel von make oldconfig bzw. warum muß ich die .config kopieren?
Damit du bei der Konfiguration von einer Vorlage ausgehen kannst, die bei dir schon funktioniert hat (eben die von SuSE).
Gehen wir von der Siutation aus, dass ich die für den SuSE-Athlon-Standardkernel verwendeten Parameter für den Vanilla-Kernel verwenden möchte und für erste Tests nichts ändern will.
Ja? Und? zcat /proc/config.gz > /usr/src/linux/.config cd /usr/src/linux/ $EDITOR Makefile #### oder z.B: # cp Makefile Makefile.orig # sed 's/\(EXTRAVERSION = \).*/\1-1/p' < Makefile.orig > Makefile make menuconfig make dep clean usw.... (Ja, du musst eins der make *config aufrufen, kannst es aber ohne Aenderungen der Konfiguration wieder verlassen (dabei bitte die config speichern, nicht abbrechen!)) Irgendwie versteh ich wohl nicht ganz, was dein Problem ist... -dnh [1] das ist SuSE-spezifisch! [2] denn schliesslich muss der ja mit moeglichst aller HW zurechtkommen... -- We're good at Waking Nightmares. Been doing them for decades, and handle them _NO _STRESS_ _AT_ _ALL, Goddamnit! So why are you looking at me like that, anyway? Don't you have something _productive_ to do? NO? Well, _FIND_ some-thing productive to do! -- Mike Andrews in asr
Al Bogner wrote:
http://www.dhaller.de/linux/multikernel.html
Dazu wechseln wir ins Verzeichnis /usr/src/linux und editieren mit unserem Lieblingseditor das sich dort befindliche Makefile:
Ich verstehe den Sinn in meinem Fall nicht ganz: [...]
Darauf hat David ja ausfuehrlich geantwortet.
[...] On Thursday 22 May 2003 20:56, Thomas Hertweck wrote:
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.
Der augenblickliche Kernel hat die Standard-Einstellungen von SuSE 8.2. Gibt es da einen Unterschied zu "from scratch"?
Ja, Du kannst es ja einfach selbst mal ausprobieren, wenn Du schon am Rumspielen bist. Entpacke einfach mal die Kernel-Sourcen des Vanilla-Kernel und starte ein "make menuconfig" und schaue, wie es aussieht. Im Prinzip musst Du nun Punkt fuer Punkt durchgehen und ueberlegen, ob Du das Feature im Kernel brauchst oder als Modul oder gar nicht und so entsprechend auswaehlen. Das dauert eine Weile, weil Du wirklich von vorne bis hinten durchgehen musst. Oder Du klonst eben z.B. die SuSE-Konfig, die bei Dir bisher funktioniert hat. Dann hast Du eine Grundlage, und von der aus startend kannst Du nun konfigurieren. Im Prinzip musst Du nun immer noch Punkt fuer Punkt durch- gehen, hast aber bereits sinnvolle Einstellungen und kannst erst einmal Dinge abwaehlen, wo Du absolut _sicher_ bist, diese nicht zu brauchen (ISDN, Firewire, etc.). Beim Konfigurieren "from scratch" sollte man recht gut Bescheid wissen ueber die einzelnen Punkte der Konfiguration, sonst wird es wohl recht muehsam, einen funktionierenden Kernel zu basteln. Wenn Du vergisst, die Unterstuetzung fuer Dein Filesystem in den Kernel zu compilieren oder die Unter- stuetzung fuer die Console, dann wird es schon beim Booten scheitern, es kommt zu einem Kernel Panic. Wenn man von einer funktionierenden Ausgangskonfiguration startet, dann ist die Gefahr solcher Fehlkonfigurationen wohl geringer...
Ich verstehe noch nicht die Auswirkungen für einen Vanilla-Kernel von make oldconfig bzw. warum muß ich die .config kopieren?
Du kopierst eine funktionierende Konfiguration .config in das Verzeichnis der neuen Kernel-Quellen. Diese .config passt aber eventuell nicht zu den neuen Quellen, da der neue Kernel mehr oder andere Feature hat als der alte Kernel. Man muss also die Konfiguration zum Teil uebernehmen, aber auch zum Teil ergaenzen (oder manche Dinge rausschmeissen, die es nicht mehr gibt). Und genau das macht das "make oldconfig". Es liest die .config ein, vergleicht die darin enthaltene Konfiguration mit den Moeglichkeiten, die der neue Kernel bietet (siehe dazu arch/i386/config.in) und uebernimmt alles, was in beiden Kerneln identisch ist. Werden neue Features gefunden, dann wirst Du gefragt werden, ob Du das im Kernel haben willst oder als Modul oder gar nicht. Du musst dann ent- sprechend waehlen. Die neue Konfiguration wird erst ein- mal in .tmpconfig gepseichert. Am Ende des Durchgangs wird dann .config in .config.old umbenannt, und die neue Konfiguration, die geklont und ergaenzt wurde, wird von .tmpconfig in .config umbenannt. Damit hast Du nun eine auf die neuen Kernel-Sourcen passende Konfiguration. Hat die alte Konfiguration nicht funktioniert, so wird wohl auch die neue nicht funktionieren. Hat die alte aber gut funktioniert, und hast Du bei den evtl. auftretenden Fra- gen bei "make coldconfig" keine falsche Auswahl getroffen, dann sollte es Dir nun gelingen, mit "make dep clean", "make bzImage modules modules_install" einen lauffaehigen Kernel zu compilieren. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
participants (3)
-
Al Bogner
-
David Haller
-
Thomas Hertweck