Hallo,
ich experimentiere gerade mit iptables( 1.2.4 ) und dem fwbuilder. dazu habe ich den kernel ( 2.4.7 ) neu kompiliert( netfilter support als modul ). wenn nun das modul "ip_conntrack" geladen werden soll bricht modprobe mit vielen fehlern wie z.B.: unresolved symbol nf_unregister_hook ab. "depmod -a" bringt ähnliche fehler in allen modulen die was mit netfilter zu tun haben.
hat jemand eine idee woran das liegen könnte???
ich wäre für jeden tip dankbar....
Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 03 December 2001 21:58, Michael Grützner wrote:
Hallo,
ich experimentiere gerade mit iptables( 1.2.4 ) und dem fwbuilder. dazu habe ich den kernel ( 2.4.7 ) neu kompiliert( netfilter support als modul ). wenn nun das modul "ip_conntrack" geladen werden soll bricht modprobe mit vielen fehlern wie z.B.: unresolved symbol nf_unregister_hook ab. "depmod -a" bringt ähnliche fehler in allen modulen die was mit netfilter zu tun haben.
hat jemand eine idee woran das liegen könnte???
ich wäre für jeden tip dankbar....
mach mal "depmod -a", wenn das auch Fehler bringt, dann hast Du zu wenige Module kompiliert, ansonsten sollte modprobe danach funktionieren.
Konrad
- -- BOFH excuse #131:
telnet: Unable to connect to remote host: Connection refused
On 03.12.01 Michael Grützner (Michael_Gruetzner@gmx.de) wrote:
ich experimentiere gerade mit iptables( 1.2.4 ) und dem fwbuilder. dazu habe ich den kernel ( 2.4.7 ) neu kompiliert( netfilter support ^^^^^
Der ist doch steinalt.
als modul ). wenn nun das modul "ip_conntrack" geladen werden soll bricht modprobe mit vielen fehlern wie z.B.: unresolved symbol nf_unregister_hook ab. "depmod -a" bringt ähnliche fehler in allen modulen die was mit netfilter zu tun haben.
In modules.dep wurden aber alle Abhängigkeiten korrekt eingetragen?
hat jemand eine idee woran das liegen könnte???
Ganz sicher, daß bei depmod -a die richtige System.map gelesen wurde?
Hilmar, keine wirklichen Ideen habend.
Hi Hilmar,
On Sun, Dec 09, 2001 at 18:21:58 +0100, Hilmar Preusse wrote:
dazu habe ich den kernel ( 2.4.7 ) neu kompiliert( netfilter
Der ist doch steinalt.
Das ist kein Argument. Neuer heisst nicht zwanglaeufig besser oder weniger Fehler. Nenne mir einen 2.4er Kernel > 2.4.7, der nachweislich stabiler laeuft (oder ueberhaupt stabil).
In 2.4.10 wurde ohne ersichtlichen Grund die VM ausgestauscht, 2.4.11 war voellig im Eimer, bei 2.4.12 funktionierte der Parallelsupport nicht, 2.4.13 scheint okay zu sein, 2.4.14 hat ein kaputtes Loop-Device (was aber offensichtlich durch einen minimalen Patch zu reparieren ist), 2.4.15 war wieder broken und uber 2.4.16 kann ich noch nichts sagen, und zu 2.4.17prewasweissich auch nicht.
Wer hier auf der Liste kann welche 2.4er-Releases als stabil bestaetigen? (haengt natuerlich auch von den verwendeten Treibern ab, beispielsweise war der aic7xxxx in 2.4.3 Schrott)
bye, Chris
On Monday 10 December 2001 09:39, Christian Perle wrote:
In 2.4.10 wurde ohne ersichtlichen Grund die VM ausgestauscht, 2.4.11 war voellig im Eimer, bei 2.4.12 funktionierte der Parallelsupport nicht, 2.4.13 scheint okay zu sein, 2.4.14 hat ein kaputtes Loop-Device (was aber offensichtlich durch einen minimalen Patch zu reparieren ist), 2.4.15 war wieder broken und uber 2.4.16 kann ich noch nichts sagen, und zu 2.4.17prewasweissich auch nicht.
Vielleicht liegt es daran, daß Linux monolithisch released wird und ein solches Entwicklungsmodell bei dieser Code-Größe nicht mehr so ganz passt? Wenn einzelne Module (Loop-Device, Kartentreiber) kaputt sind und sich die der vorherigen Version nicht übernehmen lassen aufgrund von API-Differenzen, dann ist es, per Definition, ein Entwicklerkernel (weil keine Reifezeit vorhanden ist).
Josef Spillner
On Mon Dec 10, 2001 at 13:15:25 +0100, Josef Spillner wrote:
On Monday 10 December 2001 09:39, Christian Perle wrote:
In 2.4.10 wurde ohne ersichtlichen Grund die VM ausgestauscht, 2.4.11 war voellig im Eimer, bei 2.4.12 funktionierte der Parallelsupport nicht, 2.4.13 scheint okay zu sein, 2.4.14 hat ein kaputtes Loop-Device (was aber offensichtlich durch einen minimalen Patch zu reparieren ist), 2.4.15 war wieder broken und uber 2.4.16 kann ich noch nichts sagen, und zu 2.4.17prewasweissich auch nicht.
2.4.16 sowie 17-prex laufen hier ohne Probleme.
Vielleicht liegt es daran, daß Linux monolithisch released wird und ein solches Entwicklungsmodell bei dieser Code-Größe nicht mehr so ganz passt? Wenn einzelne Module (Loop-Device, Kartentreiber) kaputt sind und sich die der vorherigen Version nicht übernehmen lassen aufgrund von API-Differenzen, dann ist es, per Definition, ein Entwicklerkernel (weil keine Reifezeit vorhanden ist).
Linus ist einfach ein schlechter Maintainer fuer stable releases, wie er auch selber sagt. Ganz einfach. Man hat die Hoffnung, dass das mit Marcello besser wird. Und wenn die Leute noch mit Testen kanns ja auch nicht gerade schlechter werden... ;)
Adam
Hi Sebastian,
On Mon, Dec 10, 2001 at 15:02:48 +0100, Sebastian Roth wrote:
Wer hier auf der Liste kann welche 2.4er-Releases als stabil bestaetigen?
2.4.10 bzw. 2.4.16 im persönlichem Dauerlauf (1Tag++).
Ich meinte eher Uptimes in der Groessenordnung von meheren Wochen/Monaten. Mit 2.2.1[89] ist sowas eigentlich normal.
bye, Chris
Am Montag, dem 10. Dezember 2001 um 18:46:40, schrieb Christian Perle:
Wer hier auf der Liste kann welche 2.4er-Releases als stabil bestaetigen?
2.4.3 (?) mit >60 Tagen auf einem SMP-System, unterbrochen durch einen Stromausfall. USB zickt aber noch ein bisschen rum...
Torsten
Am Montag, 10. Dezember 2001 21:59 schrieb Torsten Werner:
Am Montag, dem 10. Dezember 2001 um 18:46:40, schrieb Christian Perle:
Wer hier auf der Liste kann welche 2.4er-Releases als stabil bestaetigen?
2.4.3 (?) mit >60 Tagen auf einem SMP-System, unterbrochen durch einen Stromausfall. USB zickt aber noch ein bisschen rum...
hmm, ich habe im 5 * 10 Stunden Workstation-Einsatz einen 2.4.4er seit ca. einem halben Jahr. Gezickt hat höchstens mal KDE...
Mit freundlichen Grüßen
Jens Puruckherr
2.4.3 (?) mit >60 Tagen auf einem SMP-System, unterbrochen durch einen Stromausfall. USB zickt aber noch ein bisschen rum...
*wenigerzustimm* Bei mir geht der Scanner (USB) und der Joystick einwandfrei. Was für spezielles USB.Zeugs hast du denn? :-)
Torsten
Bye, Sebastian
On 10.12.01 Christian Perle (perle@itm.tu-clausthal.de) wrote:
Moin,
On Sun, Dec 09, 2001 at 18:21:58 +0100, Hilmar Preusse wrote:
[meinte, daß 2.4.7 schon etwas zuviel Staub angesetzt hätte]
Das ist kein Argument. Neuer heisst nicht zwanglaeufig besser oder weniger Fehler.
ACK. Diese ewige Geschichte mit der VM in 2.4.10 wird wohl Linus's "World domination fast" endgültig den Garaus machen. Trotzdem lese ich im Changelog immer wieder "fix, fix", auch wenn es sich natürlich um Fehler handeln könnte, die erst später eingebracht wurden.
Nenne mir einen 2.4er Kernel > 2.4.7, der nachweislich stabiler laeuft (oder ueberhaupt stabil).
Kann ich nicht, weil bei mir bisher 2.4.x zieml. stabil lief. Zieml. bis auf solche Geschichten, wie loopback in 2.4.2, die Geschichte mit dem Einfrieren des Leseprozesses von cdda2wav wg. kaputtem sg-Treibers in frühen Patchlevels. Ja, meine Kiste wird zwangsläufig einmal pro Woche gebootet.
In 2.4.10 wurde ohne ersichtlichen Grund die VM ausgestauscht,
Darüber streiten sich immer noch die Geister. Es hängt sicher vom Einsatzzweck der Kiste ab. Soweit ich das bisher mitgekriegt habe, ist die neue für den "Hausgebrauch" besser.
2.4.11 war voellig im Eimer,
Ja, war er. Damit wurde wohl eine DoS-Attacke gefixt und der Bug wurde auch erst beim Einsatz von SaX2 bemerkt.
bei 2.4.12 funktionierte der Parallelsupport nicht,
Typo's soweit ich das mitgekriegt habe. Es gab einen Patch, so daß man trotzdem backen konnte, aber ob er hinterher funktionierte weiß ich nicht.
2.4.14 hat ein kaputtes Loop-Device (was aber offensichtlich durch einen minimalen Patch zu reparieren ist),
genau, auch Typo's
2.4.15 war wieder broken
jupp.
und über 2.4.16 kann ich noch nichts sagen, und zu 2.4.17prewasweissich auch nicht.
2.4.16 läuft hier und ich bin weder Dauerläufer noch Streßtester. patch-2.4.17.log liest sich erstaunlich gut, weil Marcelo erstmal auf bugfixes, denn auf Featurites Wert zu legen scheint. Daß ein Kernelbuild an einem Typo scheitert finde ich irgendwo nicht so toll, weil das ganz einfach zeigt, daß nicht einmal Probecompiliert wurde. Andererseits weiß ich, daß der Fix meist im Archiv der lkml zu finden ist und heule darum nicht herum. Schlimmer fände ich es schon, wenn FS-updates nicht lange genug getestet werden würden und mit 2.4.7 habe ich auch schon ein Blockdevice an einer Stelle gefunden hab, an der ich es gar nicht erwartet hätte :-(. So, jetzt kann sich noch die Performancefraktion melden, die 2.4.n ( n>=10 ) Scheiße findet und dazu kann ich wirklich nichts sagen. Trotzdem würde wahrscheinlich jeder Kernelentwickler "update!" sagen, wenn ich versuchen würde, einen Bug für 2.4.7 einzukippen.
H.
lug-dd@mailman.schlittermann.de