Tach Gemeinde, ich habe hier ein kleines bis mittelgroßes Problem. Ich möchte gerne den Vanilla Kernel 2.4.21 auf meinem SuSE 8.2 porf. System kompilieren, doch leider schlägt dies fehl. Weiterhin würde ich gerne die Config von SuSE weiterbenutzen. Dafür habe ich folgendes gemacht: cd /usr/src tar xvjf linux-2.4.21.tar.bz2 ln -s linux-2.4.21 linux cd /usr/src/linux cp /boot/vmlinuz.config .config make oldconfig make xconfig --> habe atm, irda, isdn und Telephony rausgeschmissen make dep clean bzImage [...] gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o tools/build tools/build.c -I/usr/src/linux-2.4.21/include tools/build.c: In function `main': tools/build.c:126: warning: comparison between signed and unsigned tools/build.c:142: warning: comparison between signed and unsigned objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/bvmlinux.out tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage Root device is (3, 8) Boot sector 512 bytes. Setup is 4766 bytes. System is 1062 kB warning: kernel is too big for standalone boot from floppy make[1]: Leaving directory `/usr/src/linux-2.4.21/arch/i386/boot' Soweit denke ich mal sieht das gut aus. make modules [...] gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=sdla_chdlc -c -o sdla_chdlc.o sdla_chdlc.c sdla_chdlc.c:594:43: missing terminating " character sdla_chdlc.c: In function `wpc_init': sdla_chdlc.c:595: error: parse error before "Failed" sdla_chdlc.c:595: error: stray '\' in program sdla_chdlc.c:595:68: missing terminating " character sdla_chdlc.c: In function `port_set_state': sdla_chdlc.c:3462: warning: comparison between signed and unsigned sdla_chdlc.c: In function `wanpipe_tty_write': sdla_chdlc.c:4008: warning: comparison between signed and unsigned sdla_chdlc.c: In function `wanpipe_tty_receive': sdla_chdlc.c:4145: warning: comparison between signed and unsigned sdla_chdlc.c:4155: warning: comparison between signed and unsigned sdla_chdlc.c: In function `change_speed': sdla_chdlc.c:4352: warning: comparison between signed and unsigned /usr/src/linux-2.4.21/include/asm/io.h: At top level: /usr/src/linux-2.4.21/include/linux/module.h:299: warning: `__module_kernel_version' defined but not used sdla_chdlc.c:4747: warning: `__module_license' defined but not used make[3]: *** [sdla_chdlc.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.21/drivers/net/wan' make[2]: *** [_modsubdir_wan] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.21/drivers/net' make[1]: *** [_modsubdir_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21/drivers' make: *** [_mod_drivers] Error 2 Da waren sie meine Porbleme. Wie schaffe ich es, den vanilla-Kernel zu bauen, ohne Patches zu benutzen? Das muß doch möglich sein, oder? Danke und Gruß Sören
Sören Mindorf wrote:
make[1]: Leaving directory `/usr/src/linux-2.4.21/arch/i386/boot'
Soweit denke ich mal sieht das gut aus.
Ja.
make modules [...] gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=sdla_chdlc -c -o sdla_chdlc.o sdla_chdlc.c sdla_chdlc.c:594:43: missing terminating " character sdla_chdlc.c: In function `wpc_init': sdla_chdlc.c:595: error: parse error before "Failed" sdla_chdlc.c:595: error: stray '\' in program sdla_chdlc.c:595:68: missing terminating " character make[3]: *** [sdla_chdlc.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.21/drivers/net/wan'
Da waren sie meine Porbleme. Wie schaffe ich es, den vanilla-Kernel zu bauen, ohne Patches zu benutzen? Das muß doch möglich sein, oder?
Ja, ist moeglich. Brauchst du denn "drivers/net/wan/sdla_chdlc.o"? Ich konnte bislang gut drauf verzichten. Das sieht hier auch nicht besser aus: /usr/src/linux-2.4.18.SuSE/drivers/net/wan/sdla_chdlc.c: 594 printk (KERN_INFO "%s: 595 Failed to set interrupt triggers!\n", 596 card->devname); 597 return -EIO; Wenn du das Modul brauchst, die Zeile 595 an die Zeile 594 anhaengen. Alternativ hinter 594 ein Leerzeichen und einen Backslash anfuegen, damit der String fortgesetzt wird. Der Anfang der Datei birgt folgenden Kommentar: /***************************************************************************** * sdla_chdlc.c WANPIPE(tm) Multiprotocol WAN Link Driver. Cisco HDLC module. Brauchst du das wirklich? Peter
Hi Peter, Peter Wiersig wrote:
Sören Mindorf wrote: [...] Da waren sie meine Porbleme. Wie schaffe ich es, den vanilla-Kernel zu bauen, ohne Patches zu benutzen? Das muß doch möglich sein, oder?
Ja, ist moeglich. Brauchst du denn "drivers/net/wan/sdla_chdlc.o"? Ich konnte bislang gut drauf verzichten.
Naja, ich dachte ich baue mal den Kernel wie SuSe ihn baut, nur halt ohne Patches, aber das scheint nicht möglich zu sein. :( Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen? [...]
Der Anfang der Datei birgt folgenden Kommentar: /***************************************************************************** * sdla_chdlc.c WANPIPE(tm) Multiprotocol WAN Link Driver. Cisco HDLC module.
Brauchst du das wirklich?
Nein, brauche ich nicht. Ich werde es mal ohne weiterversuchen. Danke Gruß Sören
Sören Mindorf wrote:
Naja, ich dachte ich baue mal den Kernel wie SuSe ihn baut, nur halt ohne Patches, aber das scheint nicht möglich zu sein. :(
Doch, warum nicht. Die "Public Function" wpc_init finde ich in den SuSE-Modulen auch nicht. Ich finde den gepatchten SuSE-Kernel eigentlich nicht schlecht und verwende diesen eigentlich ausschlieslich auf meinen Servern. Ich baue nicht unbedingt alle Module, die im Kernel-Binaerpaket von SuSE enthalten sind, aber die Sourcen konnte ich immer verwenden.
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Weil dieses Modul von fast niemandem gebraucht wird und alle es abschalten. Menschliches Versagen. Peter
Hi Peter, Peter Wiersig wrote:
Sören Mindorf wrote:
Naja, ich dachte ich baue mal den Kernel wie SuSe ihn baut, nur halt ohne Patches, aber das scheint nicht möglich zu sein. :(
Doch, warum nicht. Die "Public Function" wpc_init finde ich in den SuSE-Modulen auch nicht. Ich finde den gepatchten SuSE-Kernel eigentlich nicht schlecht und verwende diesen eigentlich ausschlieslich auf meinen Servern. Ich baue nicht unbedingt alle Module, die im Kernel-Binaerpaket von SuSE enthalten sind, aber die Sourcen konnte ich immer verwenden.
Ok, würde ich auch gerne machen, doch ich möchte den grsecurity-PAtch mit in den Kernel bauen, dies ist jedoch noicht so einfach möglich. Und da ich es mir nicht zutraue, den Patch von Hand da reinzubauen.
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Weil dieses Modul von fast niemandem gebraucht wird und alle es abschalten. Menschliches Versagen.
Hmm, ok, dann entschuldige ich es. ;) Gruß Sören
On Tuesday 24 June 2003 12:26, Sören Mindorf wrote:
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Weil dieses Modul von fast niemandem gebraucht wird und alle es abschalten. Menschliches Versagen.
Aufgrund meiner defekten CPU kann ich es nicht sicher sagen, aber ich hatte Probleme mit irgendeinem SIS-Modul und irgendwas mit Apple-bezogenen Modulen, sowie einem experimentellen AMD-Modul. Ich habe es einfach rausgeworfen und danach lief es durch. Da ich beim Kompilieren von transcode aber auch Fehlermeldungen hatte, die der fehlerhaften CPU zuzurechnen waren, hatte ich die Fehler nicht gemeldet. Vielleicht ist jemandem dieser Hinweis nützlich. Die letzten release-Version von 2.4.21 und die stable 2.4.21 liefen bei mit mit grsec-Patch problemlos durch. Rätsel bleibt für mich, warum ich bei sonst identen Einstellungen keine Einträge der FW mehr in den messages finde, sobald ich grsec verwende. Wer die Lösung dafür kennt, bitte melden! Al
Hi Al, Al Bogner wrote:
On Tuesday 24 June 2003 12:26, Sören Mindorf wrote:
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Weil dieses Modul von fast niemandem gebraucht wird und alle es abschalten. Menschliches Versagen.
Aufgrund meiner defekten CPU kann ich es nicht sicher sagen, aber ich hatte Probleme mit irgendeinem SIS-Modul und irgendwas mit Apple-bezogenen Modulen, sowie einem experimentellen AMD-Modul. Ich habe es einfach rausgeworfen und danach lief es durch. Da ich beim Kompilieren von transcode aber auch Fehlermeldungen hatte, die der fehlerhaften CPU zuzurechnen waren, hatte ich die Fehler nicht gemeldet. Vielleicht ist jemandem dieser Hinweis nützlich. Die letzten release-Version von 2.4.21 und die stable 2.4.21 liefen bei mit mit grsec-Patch problemlos durch.
ich habe den Patch noch gar nicht drin, da ich erstmal versuchen wollte, den Vanilla-Kernel ohne Probleme zu bauen, aber das ist bei mir zumindest so gut wie unmöglich. Ich schmeiße hier ein Modul nach dem Anderen raus und hofffe, das es bald mal durchkompiliert. Welche SuSE-Version nutzt Du? Gruß Sören
Sören Mindorf schrieb: [ . . . ]
ich habe den Patch noch gar nicht drin, da ich erstmal versuchen wollte, den Vanilla-Kernel ohne Probleme zu bauen, aber das ist bei mir zumindest so gut wie unmöglich. Ich schmeiße hier ein Modul nach dem Anderen raus und hofffe, das es bald mal durchkompiliert. [ . . .]
hallo ich glaube, Dein Problem mit den Modulen liegt woanders. Hast Du denn *vorher* /lib/modules/Kernelversion freigemacht? Gruß Sina
Hi Sina, Sina Jany wrote:
Sören Mindorf schrieb: [ . . . ]
ich habe den Patch noch gar nicht drin, da ich erstmal versuchen wollte, den Vanilla-Kernel ohne Probleme zu bauen, aber das ist bei mir zumindest so gut wie unmöglich. Ich schmeiße hier ein Modul nach dem Anderen raus und hofffe, das es bald mal durchkompiliert.
[ . . .]
hallo
ich glaube, Dein Problem mit den Modulen liegt woanders.
Hast Du denn *vorher* /lib/modules/Kernelversion freigemacht?
nö, das wäre doch quatsch, ich will ja vom alten Kernel auch noch booten können. Außerdem legt der neue Kernel das Verzeichnis 2.4.21 an und mein aktueller Kernel ist 2.4.20-4GB. Somit dürfte das keine Rolle spielen. Gruß Sören
Sina Jany schrieb:
ich glaube, Dein Problem mit den Modulen liegt woanders.
Hast Du denn *vorher* /lib/modules/Kernelversion freigemacht?
Uahh, mach das besser nicht!!! Du solltest Dir dringend http://www.dhaller.de/linux/multikernel.html anschauen! Gruesse, Thomson
On Tuesday 24 June 2003 13:04, Sören Mindorf wrote:
Die letzten release-Version von 2.4.21 und die stable 2.4.21 liefen bei mit mit grsec-Patch problemlos durch.
ich habe den Patch noch gar nicht drin, da ich erstmal versuchen wollte, den Vanilla-Kernel ohne Probleme zu bauen, aber das ist bei mir zumindest so gut wie unmöglich. Ich schmeiße hier ein Modul nach dem Anderen raus und hofffe, das es bald mal durchkompiliert.
Welche SuSE-Version nutzt Du?
8.2 Ich schick dir meine config per PM. Ansonsten gehe ich wie folgt vor. Viele Tipps dazu kamen von David Haller und seinem Multikernel-Howto. in /usr/src habe ich ein Verzeichnis angelegt: mkdir /usr/src/linux-2.4.21-rc7-grsec/ Mein Download befindet sich in einem Download-Verzeichnis Dort entpacke ich linux-2.4.21.tar.gz mit gzip -d < linux-2.4.21.tar.gz | tar -xpf - (vor Jahren hatte ich mal Probleme beim Entpacken und so funktionierte es, daher mache ich das so bei kritischen Sachen) Dadurch wird beim Entpacken ein Verzeichnis linux-2.4.21 erstellt. Den Inhalt kopiere ich mit cp -vr nach /usr/src/linux-2.4.21-rc7-grsec/ Den grsec-Patch kopiere ich vom Downloadverzeichnis nach /usr/src. Damit kann ich bei Problemen das neue Kerne-Verzeichnis in /usr/src wieder löschen und völlig von vorne beginnen. Nun wechsle ich in das zu patchendes Verzeichnis, also nach /usr/src/linux-2.4.21-rc7-grsec/ und gebe folgendes ein: patch -p1 < /usr/src/grsecurity-1.9.10-2.4.21.patch Der Patch bewirkt nur einige Optionen am Ende. Man kann den also sofort anwenden. Wenn es Probleme macht, dann mit oder ohne. Als nächstes entferne ich den Link linux, der auf /usr/src/linux-2.4.20.SuSE zeigt und verlinke zum neuen Kernel-Verzeichnis ln -s /usr/src/linux-2.4.21-rc7-grsec/ linux und nun kann es los gehen. Ich mache übrigens alles via ssh von einem anderen Rechner. 2 root-xterms aufmachen und nebeneinander oder unteinerander auf dem Schirm anordnen. Achtung die Breite muß mindestens 80 Zeichen haben, ich habe die Fenster untereinander angeordnet. In 1 Fenster werde ich dann die SuSE-Optionen sehen und im anderen die Default-Einstellungen des Vanilla-Kernels. 1. Fenster (SusE-Kernel): # cd /usr/src/linux-2.4.20.SuSE # test -f .config && mv -i .config .config.default # zcat /proc/config.gz > .config # make menuconfig 2. Fenster (Vanilla-Kernel): # cd /usr/src/linux # make mrproper # test -f .config && rm .config # make menuconfig Nun vergleiche ich die Einstellungen und bin erstmal nicht so großzügig beim Rauswerfen, wenn ich mir nicht 100% sicher bin, dass ich das nicht brauche. Die Optionen sind natürlich nicht ident und eventuell ist sogar die Reihenfolge unterschiedlich. Dann folgt time make dep clean bzImage modules modules_install 2>&1 | tee make.out Ich mache es aber meist Schritt für Schritt, also "make dep", "make clean", etc. Das sollte bis jetzt alles fehlerfrei durchlaufen. Dann folgt ein cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.21-grsec cp /usr/src/linux/System.map /boot/System.map-2.4.21-grsec Bei Modulen kommt dann noch eventuell: mkinitrd -k /boot/vmlinuz-2.4.21-grsec -i /boot/initrd-2.4.21-grsec Ich binde das Dateisystem fix in den Kernel ein und damit kann man sich das IMO sparen. Nun wird /boot/grub/menu.lst editiert und zB folgender Eintrag eingefügt. Bei mir also vi /boot/grub/menu.lst title linux-2.4.21-grsec acpi=on kernel (hd1,0)/vmlinuz-2.4.21-grsec root=/dev/hdb7 vga=0x314 splash=verbose showopts initrd (hd1,0)/initrd-2.4.21-grsec Zum Schluß soll yast auch noch ein bisschen was tun und ich ändere unter System/Konfiguration des Bootloaders/Standardabschnitt den Default-Kernel auf den neu kompilierten Kernel und hoffe, dass der auch hochfährt, denn an meinen Rechnern mit grsec-Kernel habe ich keinen Monitor. Verbesserungsvorschläge sind gerne willkommen! Al
On Tuesday 24 June 2003 17:33, Al Bogner wrote:
in /usr/src habe ich ein Verzeichnis angelegt: mkdir /usr/src/linux-2.4.21-rc7-grsec/
Entschuldigung, ich habe da von 2 Rechnern gemischt. Auf einem läuft noch eine Release-Candidat Version. Das rc-7 ist also zu entfernen. Aber mitdenken ist bei einer Kernelkompilierung sowieso angesagt. Auch habe ich gesehen, dass ich nicht immer die Pfade absolut angegeben habe. Im wesentlichen sollte es den Vorgang aber schon richtig beschreiben. Al
Am Dienstag, 24. Juni 2003 12:02 schrieb Sören Mindorf:
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Das genannte Problem ist eines, dass erst seit gcc 3.3 auftritt, weil der deutlich strenger mit Unsauberkeiten umgeht, als die Vorgänger. Wenn der Autor jetzt nicht den allerneusten Compiler verwendet und auch keiner der Tester, die bereits gcc 3.3 einsetzen, kommt sowas nicht raus. Schreib dem zuständigen ne Mail und ich bin sicher, der Fehler ist in der nächsten Version behoben. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hi Manfred, Manfred Tremmel wrote:
Am Dienstag, 24. Juni 2003 12:02 schrieb Sören Mindorf:
Wieso ist denn der Kernel als stable rausgekommen, wenn sich einige Module gar nicht kompilieren lassen?
Das genannte Problem ist eines, dass erst seit gcc 3.3 auftritt, weil der deutlich strenger mit Unsauberkeiten umgeht, als die Vorgänger. Wenn der Autor jetzt nicht den allerneusten Compiler verwendet und auch keiner der Tester, die bereits gcc 3.3 einsetzen, kommt sowas nicht raus. Schreib dem zuständigen ne Mail und ich bin sicher, der Fehler ist in der nächsten Version behoben.
Ich habe Rücksprache mit einem Freund gehalten, der in der Kernel-ML sehr aktiv ist und der meinte, das der Kernel 2.4.21 voll gcc3.3 kompatibel ist. Naja,. wie man sieht doch noch nicht so ganz. ;) Danke für die vielen Antworten. Ich habe jetzt sehr viele Module rausgeschmissen und siehe da, er kompiliert durch! *freu* Und SuSE 8.2 bootet sogar. Zwar ohne Sound, aber das ist nur eine Anpassung im rc-Script. Dann fange ich heute abend mal an, den grsecurity-Patch dort reinzuprügeln. Und noch mindestens einen Anderen, sofern dies klappt. ;) Gruß Sören
Sören Mindorf schrieb am Mittwoch, 25. Juni 2003 08:02: Hallo Sören,
Und SuSE 8.2 bootet sogar. Zwar ohne Sound, aber das ist nur eine Anpassung im rc-Script.
interessiert mich, was Du da machst. Bei mir geht der Sound auch nicht, nach einem Vanilla-Kernel. Was und wo änderst Du denn da?
Dann fange ich heute abend mal an, den grsecurity-Patch dort
was ist das eigentlich für en patch? Gruß Stefan
Stefan Schlörholz wrote:
Sören Mindorf schrieb am Mittwoch, 25. Juni 2003 08:02:
Und SuSE 8.2 bootet sogar. Zwar ohne Sound, aber das ist nur eine Anpassung im rc-Script.
interessiert mich, was Du da machst. Bei mir geht der Sound auch nicht, nach einem Vanilla-Kernel. Was und wo änderst Du denn da?
Beim SuSE-Kernel werden die ALSA-Module, die Du vermutlich verwendest fuer Deinen Sound, bereits mitgeliefert. Beim Vanilla-Kernel von kernel.org ist dem nicht so. Wenn Du dort also die ALSA-Module willst, musst Du diese explizit fuer den neuen Kernel compilieren und installieren. Danach wird dann auch Dein Sound wieder gehen. Wenn Du OSS verwendest, also Sound-Module, die bereits im Kernel-Source mitgeliefert werden, dann sollte das Problem nicht auftreten. Gruesse, Thomson
Am Mittwoch, 25. Juni 2003 08:02 schrieb Sören Mindorf:
Und SuSE 8.2 bootet sogar. Zwar ohne Sound, aber das ist nur eine Anpassung im rc-Script.
Alsa ist (noch) nicht Bestandteil des Standardkernels. Driver von http://www.alsa-project.org/ besorgen und zum Kernel compilieren. Den rest gibts als RPM in der aktuellen Version bei Packman. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
participants (7)
-
Al Bogner -
Manfred Tremmel -
Peter Wiersig -
Sina Jany -
Stefan Schlörholz -
Sören Mindorf -
Thomas Hertweck