Hallo Liste! da ich jetzt davon überzeugt wurde, dass ich die Firewall-Redirect-Funktion doch selber in den Kernel einbacken muss, ein Problem der Faulheit: Ich muss nur EINE Option ändern, möchte dafür aber nicht eine halbe Stunde y/n/m wählen. Wo gibt es die Einstellungen, die für die SuSE-Kernel gewählt wurden? Eine schöne Konfig-Datei wäre eine tolle Sache. Danke! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Andreas Achtzehn wrote:
da ich jetzt davon überzeugt wurde, dass ich die Firewall-Redirect-Funktion doch selber in den Kernel einbacken muss, ein Problem der Faulheit: Ich muss nur EINE Option ändern, möchte dafür aber nicht eine halbe Stunde y/n/m wählen. Wo gibt es die Einstellungen, die für die SuSE-Kernel gewählt wurden? Eine schöne Konfig-Datei wäre eine tolle Sache.
Haengt von der SuSE-Version ab. Bei 6.4 (davor weiss ich's nicht) gibt's eine Datei /proc/config.gz. Die kannst Du nach /usr/src/linux gunzip'pen und in .config umbenennen. Allerdings ist da d'rin so gut wie =alles= angewaehlt -- das willst Du, wenn Du Dir selbst einen Kernel baust, =bestimmt= nicht!(?) Kannst aber auch meine relativ minimalistische .config haben. Andere in der Liste schicken sie Dir auch sicher gerne (auf Anfrage!, nicht alle 2500 unaufgefordert ;-). Musst halt nur sagen, was Du so ungefaehr haben willst. m. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
From: a8603365@unet.univie.ac.at [mailto:a8603365@unet.univie.ac.at]
eine Datei /proc/config.gz. Die kannst Du nach /usr/src/linux gunzip'pen
Die Datei hab ich gefunden. Scheint auch der Kernel-Konfiguration von SuSE sehr ähnlich. Nun läuft auf dem Server ein Kernel speziell für 486er-PCs. In der conf-Datei ist jedoch von Optimierung für 586er die Rede. Ist die conf-File nun die Conf-File des Kernels, der tatsächlich auf dem System läuft (bei Installation gewählt wurde), oder ein anderer SuSE Standard-Kernel? --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Andreas Achtzehn wrote:
* From: a8603365@unet.univie.ac.at [mailto:a8603365@unet.univie.ac.at]
eine Datei /proc/config.gz. Die kannst Du nach /usr/src/linux gunzip'pen Die Datei hab ich gefunden. Scheint auch der Kernel-Konfiguration von SuSE sehr ähnlich. Nun läuft auf dem Server ein Kernel speziell für 486er-PCs. In der conf-Datei ist jedoch von Optimierung für 586er die Rede. Ist die conf-File nun die Conf-File des Kernels, der tatsächlich auf dem System läuft (bei Installation gewählt wurde), oder ein anderer SuSE Standard-Kernel?
Das sollte schon die tatsaechliche Konfiguration sein! Die wird beim Kernelkompilieren gepackt und mitgelinkt, zur Laufzeit dann im virtuellen /proc-Filesystem dargestellt. Die Daten sind also =im=Kernel= d'rin! (Wenn diese Konfiguration nicht wirklich zum laufenden Kernel passen wuerde, waere das ein schwerer Bug, den Du unbedingt melden muesstest. Aber, probier's einfach einmal aus. Es kann ja nicht viel schiefgehen. m. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, Melchior FRANZ wrote:
Das sollte schon die tatsaechliche Konfiguration sein! Die wird beim Kernelkompilieren gepackt und mitgelinkt, zur Laufzeit dann im virtuellen /proc-Filesystem dargestellt.
Das scheint dann aber wohl ein Feature des von SuSE gepatchten Kernels zu sein, oder? Jedenfalls finde ich bei mir (SuSE Linux 6.3, Kernel 2.2.17-pre6) keine Datei namens "config.gz" unter "/proc" liegen. Auch in den Kernel-Sourcen habe ich auf Anhieb nichts dazu gefunden (z.B. in einer Dokumentation). Aber vielleicht habe ich ja auch nur zu wenig intensiv gesucht... Gruss, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Steffen Moser wrote:
* Melchior FRANZ wrote:
[Kernel-Konfiguration in /proc/config.gz] Das scheint dann aber wohl ein Feature des von SuSE gepatchten Kernels zu sein, oder? Jedenfalls finde ich bei mir (SuSE Linux 6.3, Kernel 2.2.17-pre6) keine Datei namens "config.gz" unter "/proc" liegen. Auch in den Kernel-Sourcen habe ich auf Anhieb nichts dazu gefunden (z.B. in einer Dokumentation). Aber vielleicht habe ich ja auch nur zu wenig intensiv gesucht...
Nein, nein. Du hast recht, das gibt's nur beim SuSE-Kernel. Oder besser gesagt, es gibt fuer den Originalkernel einen Patch, den SuSE eben auf ihre Kernel anwendet. Dieses Feature ist dann ueber die Kernelkonfiguration an- und abstellbar. Fuer einen Distributor, der viel mit Newbies zu tun hat, ist die Sache IMHO auch recht sinnvoll. Wer sich aber oefter selbst Kernel kompiliert, wird wohl eher darauf verzichten (wie er ueberhaupt auf SuSE-Kernels verzichten wird. ;-) Schliesslich landet die Konfiguration auf diese Weise nicht nur im Kernel-Binary, sondern ist auch waehrend der gesamten Laufzeit im Speicher! Das mag bei den heutigen Speicherkapazitaeten kein Problem sein, aber allein der Gedanke daran ist ziemlich unangenehm. Darum empfehle ich, sich folgendes zur Angewohnheit zu machen: Jeder Kernel kommt in einen eigenen Ordner in /boot, und dort wird =IMMER= die zugehoerige System.map und die .config heineinkopiert. Auf diese Weise weiss man =auch=, welche Konfiguration man bei welchem Kernel aktiviert hat. $ ls -l /boot/2.2.17pre9/ /boot/System.map lrwxrwxrwx 1 root root 21 Jul 2 14:47 System.map -> 2.2.17pre9/System.map 2.2.17pre9/: -rw-r--r-- 1 root root 12183 Jul 2 11:53 .config -rw-r--r-- 1 root root 158917 Jul 2 11:53 System.map -rw-r--r-- 1 root root 419761 Jul 2 11:53 vmlinuz m. PS: Ja, ich weiss, dass es fuer die Auswahl der richtigen System.map auch noch Tricks mit `uname` gibt, aber das funktioniert wohl nur, wenn man fuer jede Kernelversion nur =einen= Kernel verwendet. Ich hab' aber oft mehrere Varianten... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Melchior, Melchior FRANZ wrote:
Darum empfehle ich, sich folgendes zur Angewohnheit zu machen: Jeder Kernel kommt in einen eigenen Ordner in /boot, und dort wird =IMMER= die zugehoerige System.map und die .config heineinkopiert. Auf diese Weise weiss man =auch=, welche Konfiguration man bei welchem Kernel aktiviert hat.
[..]
PS: Ja, ich weiss, dass es fuer die Auswahl der richtigen System.map auch noch Tricks mit `uname` gibt, aber das funktioniert wohl nur, wenn man fuer jede Kernelversion nur =einen= Kernel verwendet. Ich hab' aber oft mehrere Varianten...
Das ist auch kein Problem. Einfach vor oder nach make menuconfig, jedenfalls vor make bzImage im Makefile editieren der Variable EXTRAVERSION einen Wert geben, so wie das z.B. auch bei den aktuellen 2.4.0-testN gemacht wird (Bei einem neuen, d.h. frisch ausgepacken Kernel) solltest man vielleicht erst mal ein make dep laufen lassen). $ head -6 /usr/src/linux/Makefile VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 0 EXTRAVERSION = -test1 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) $ head -6 /usr/src/linux-2.2.15/Makefile VERSION = 2 PATCHLEVEL = 2 SUBLEVEL = 15 EXTRAVERSION = -6 ARCH=[snipped] $ grep -n EXTRAVERSION /usr/src/linux-2.2.15/Makefile 4:EXTRAVERSION = -6 68:KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) Und genau so wie hier das offizielle -test1 bzw. ein -6 von mir drankommt, kannst man auch eine "eigene" Extraversion definieren, also z.B. "-a" oder "-1" oder was auch immer. Anschliessend installierst du dann das Image in /boot mit der _kompletten_ Angabe von $KERNELRELEASE bzw. dem was ein `uname -r` ergibt. z.B (gerkuerzt wg. uralt "Leichen") $ ls -l /boot -rw-r--r-- 1 root root 720868 Mai 8 00:44 bzImage-2.2.15-1 -rw-r--r-- 1 root root 666852 Mai 24 22:25 bzImage-2.2.15-5 -rw-r--r-- 1 root root 689676 Mai 30 16:13 bzImage-2.2.15-6 -rw-r--r-- 1 root root 909524 Mai 11 13:21 bzImage-2.3.99-pre6-1 -rw-r--r-- 1 root root 905903 Jun 29 16:41 bzImage-2.4.0-test1 -rw-r--r-- 1 root root 234948 Mai 8 00:43 System.map-2.2.15-1 -rw-r--r-- 1 root root 218860 Mai 24 22:25 System.map-2.2.15-5 -rw-r--r-- 1 root root 222556 Mai 30 16:12 System.map-2.2.15-6 -rw-r--r-- 1 root root 445447 Mai 11 13:21 System.map-2.3.99-pre6-1 -rw-r--r-- 1 root root 446273 Jun 29 16:40 System.map-2.4.0-test1 Wichtig dabei ist: Es darf _keine_ /boot/System.map geben, auch nicht als link, denn die wuerde dann immer genommen. $ ls -l /boot/System.map ls: /boot/System.map: Datei oder Verzeichnis nicht gefunden Die Kernel duerfen natuerlich auch vmlinuz-`uname -r` heissen. Die lilo.conf muss dann natuerlich angepasst werden. Ausserdem erlaubt obiges auch jedem Kernel eine passende conf.modules bzw. modules.conf zu stricken: $ cat /etc/modules.conf if test -f /etc/modules.conf-`uname -r` include /etc/modules.conf-`uname -r` else include /etc/modules.conf-default endif Dabei kann man gemeinsame Eintraege sicher auch vor oder nach obigem unterbringen, aber soviel Platzmangel habe ich nicht ;) Die "-default" kann (sollte imho sogar!) die bisherige modules.conf bzw. conf.modules sein. Nachteil oder Vorteil der Sache: Jeder Kernel bekommt auch ein eigenes /lib/modules/`uname -r`/ Verzeichnis und man braucht mehr Platz. Es haelt sich aber in Grenzen: $ ls /lib/modules/ | wc -l 16 $ du -hs /lib/modules/ 25M /lib/modules (Bei mir lagern da eben einige uralt Sachen rum - muss ich mal ausmisten ;) Jedesmal wenn ich eine groessere Aenderung vornehme erhoehe ich mein Suffix -N. Der 2.4.0-test1 hat von mir noch keine bekommen ;) Auf Anfrage maile ich gerne ne html-Anleitung die ich vor ner Weile geschrieben habe, und die ich demnaechst auch ins Netz stellen moechte. CU David -- Wer im Sinne schwach ist, der kann nicht anders. Er muss Schwachsinn produzieren. [WOKO in dag°] --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
David Haller wrote:
... Nachteil oder Vorteil der Sache: Jeder Kernel bekommt auch ein eigenes /lib/modules/`uname -r`/ Verzeichnis ...
Kein Nachteil. Ein Erfordernis - es sei denn, man ist scharf auf "unresolved symbols in ..." Meldungen Henning -- H. Henning Vossieck http://hhv.de [currently inactive] SuSE Linux 6.4 Kernel 2.4.0-test3-pre5-270 glibc 2.1.3 gcc 2.95.2 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
David Haller schrieb am 09.07.2000 um 01:52:47 +0200: Hallo David,
Nachteil oder Vorteil der Sache: Jeder Kernel bekommt auch ein eigenes /lib/modules/`uname -r`/ Verzeichnis und man braucht mehr Platz. Es haelt sich aber in Grenzen:
das ist doch sogar Vorraussetzung das es mit Modulen läuft. Von Nachteil kann da keine rede sein. Module für Kernel 2.2.X werden sehr wahrscheinlich bei 2.2.Y nur Fehlermeldungen bringen. Bis denne, Michael -- "If you play this stuff backwards, it says 'This sucks!'" Beavis & Butthead --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Michael, Michael Schulz wrote:
David Haller schrieb am 09.07.2000 um 01:52:47 +0200:
Nachteil oder Vorteil der Sache: Jeder Kernel bekommt auch ein eigenes /lib/modules/`uname -r`/ Verzeichnis und man braucht mehr Platz. Es haelt sich aber in Grenzen:
das ist doch sogar Vorraussetzung das es mit Modulen läuft. Von Nachteil kann da keine rede sein. Module für Kernel 2.2.X werden sehr wahrscheinlich bei 2.2.Y nur Fehlermeldungen bringen.
Ich bezog mich eher auf die Variante, dass Kernel 2.2.15-X die gleichen Module wie 2.2.15-Y und nur ein oder zwei andere als 2.2.15-Z verwendet. Was den "Nachteil" hat, dass z.B. 90% der Module identisch sind und so eben Plattenplatz verschwendet wird. Dass liesse sich zur Not aber sicher auch mit Links verringern (hardlinks wohl). Mit diff/cmp bekommt man ja heraus ob zwei Module gleich sind. Diesen Vergleich in eine Schleife ueber alle Module (via noch ner Schleife/Substitution+sed+grep+... -- die bash und die GNU-Tools seien gelobt)... sollte gehen wenn der Platz eng waere... aber das ist wohl eh unwahrscheinlich ;) Naja, man lernt auch hier, wann es noetig waere, EXTRAVERSION zu erhoehen :) CU David -- Since this Galaxy began, vast civilizations have arisen and fallen, risen and fallen, risen and fallen so often that it's quite tempting to think that life in the Galaxy must be a) something akin to seasick -- space-sick, time sick, history sick or some such thing, and b) stupid. --- Douglas Adams | email: David@dhaller.de www: www.dhaller.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo David, * David Haller wrote:
* Melchior FRANZ wrote: [...]
PS: Ja, ich weiss, dass es fuer die Auswahl der richtigen System.map auch noch Tricks mit `uname` gibt, aber das funktioniert wohl nur, wenn man fuer jede Kernelversion nur =einen= Kernel verwendet. Ich hab' aber oft mehrere Varianten... Das ist auch kein Problem. Einfach vor oder nach make menuconfig, jedenfalls vor make bzImage im Makefile editieren der Variable EXTRAVERSION einen Wert geben, [...]
[EXTRAVERSION] Ich halte mich ja nicht fuer den grossen Linux-Kernel-Kenner -- aber eigentlich dachte ich =schon=, dass ich die meisten guten Tricks schon kenne. ... Und dann =das=! :-) Hab' Deine Ausfuehrungen gleich in meinem "Tricks"-Ordner konserviert und werde sie ernsthaft in Erwaegung ziehen. So eine `Sauwirtschaft' will ich zwar in meinem /boot/-Ordner nicht haben,
$ ls -l /boot -rw-r--r-- 1 root root 720868 Mai 8 00:44 bzImage-2.2.15-1 -rw-r--r-- 1 root root 666852 Mai 24 22:25 bzImage-2.2.15-5 [...]
aber dafuer wird's auch noch eine Leosung geben. ;-) Trotzdem gilt: Die .config gehoert =zum=, aber nicht =in=den= Kernel. m. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Melchior, Melchior FRANZ wrote:
* David Haller wrote: [EXTRAVERSION] [Alle Kernel/System.map's in /boot] aber dafuer wird's auch noch eine Leosung geben. ;-) Trotzdem gilt: Die .config gehoert =zum=, aber nicht =in=den= Kernel.
ACK. Werde ich in Zukunft wohl auch machen, allerdings eben als /boot/.config-`uname -r`... Denn mit den Unterordnern hat das mit den System.map's bei mir nicht funktioniert. Hm, was man evtl. mal testen koennte, ist nur die System.map-`uname -r` in /boot, die Kernel und die jew. .config in einem Unterorder... CU David -- hier ist es ja wie im Urlaub! Nix mehr zu tun. Kein Dau zu beerdigen. Kein Elch zu verjagen. Nicht mal ein kleiner Troll möchte sterben Žgehen. Na dann setz Ich mich mal hier auf die Friedhofsbank und geniesse die Ruhe. Ach ja ! Meine Froschpillen werden langsam knapp. [WOKO in dag°] --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
From: a8603365@unet.univie.ac.at [mailto:a8603365@unet.univie.ac.at]
Haengt von der SuSE-Version ab. Bei 6.4 (davor weiss ich's nicht) gibt's eine Datei /proc/config.gz. Die kannst Du nach /usr/src/linux gunzip'pen und in .config umbenennen. Allerdings ist da d'rin so gut wie =alles= angewaehlt -- das willst Du, wenn Du Dir selbst einen Kernel baust, =bestimmt= nicht!(?)
Ich habe auf einer anderen Maschine jetzt den Kernel gebacken (aus der .config von /proc der Maschine, auf dem der Kernel nachher laufen soll). Mit make bzImage habe ich den Kernel gemacht, dann aus /usr/src/linux/arch/i386/boot die Datei zImage ins boot-Verzeichnis des Zielrechners verschoben, ausserdem die neue System.map kopiert, lilo umkonfiguriert (/etc/lilo.conf editiert und danach lilo ausgeführt) und neu gestartet: Resultat: no setup signature.... was habe ich vergessen? --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Andreas Achtzehn wrote:
Ich habe auf einer anderen Maschine jetzt den Kernel gebacken (aus der .config von /proc der Maschine, auf dem der Kernel nachher laufen soll). Mit make bzImage habe ich den Kernel gemacht, dann aus ^^^^^^^ /usr/src/linux/arch/i386/boot die Datei zImage ins boot-Verzeichnis des ^^^^^^ Zielrechners verschoben, ausserdem die neue System.map kopiert, lilo umkonfiguriert (/etc/lilo.conf editiert und danach lilo ausgeführt) und neu gestartet: Resultat: no setup signature.... was habe ich vergessen?
Weiss zwar nicht, was mit "no setup signature" gemeint ist, aber wenn Du `make bzImage' aufgerufen hast, musst Du auch die Datei `bzImage' verwenden, nicht `zImage' (die dann wohl noch von einem frueheren `make zImage' stammt)! m. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (6)
-
a8603365＠unet.univie.ac.at -
andreas＠linux-society.de -
David＠dhaller.de -
hhv＠hhv.de -
micha28＠gmx.de -
moser＠egu.schule.ulm.de