Am Donnerstag, 21. Februar 2002 15:08 schrieb Reiner Zimmermann:

Hallo Leute,

ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten.

SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart. Alles geht gut (scsi wird geladen die Platten erkannt) bis:

VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug

<0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-(

Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.

Warum hast du devfs aktiviert ? SuSE ist darauf noch nicht vorbereitet. So ohne weiteres dürfte es also nicht laufen... Das muss nicht der Fehler sein, aber das fällt mir erst mal auf.

Hi, Werner Franke wrote:

Hallo Reiner,

Reiner Zimmermann wrote:

...

Hallo Leute,

ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten.

SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart.

Initrd: Als ich hier Fagen zum Kernelbacken hatte, wurde mir gesagt, dass eine initrd bei einem eigenen Kernel NICHT sinnvoll ist. Das wird nur benoetigt, wenn ein Kernel auf unterschiedlichen Systemen laufen soll.

Seh' ich auch so, in den Kernel gehört alles, was man unbedingt (zum booten) braucht, also Filesysysteme, Plattentreiber EIDE/SCSI und alle Hardware, die sowieso ständig benutzt wird (Netzwerk,Keyboard,Maus,Graphik etc ..) Module nur für selten benutzte Dinge oder Geräte, die evtl. mit verschiedenen Parametern getestet werden sollen oder müssen. Ich versteh diesen Aufwand mit der initrd nicht oder habe ich da mir unbekannten einen Vorteil übersehen ?

Versuch doch mal die Module, die Dein System benoetigt, fest reinzukompelieren (reiserfs + SCSI beispielsweise).

Ob's Dir hilf weiss ich nicht :-(

Ist auf jeden Fall ein vernünftiger Ansatz.

...

Alles geht gut (scsi wird geladen die Platten erkannt) bis:

VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug

<0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-(

Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.

viel Erfolg Werner

mfg Harry

Hallo, hier nochmal eine Zusammenfassung aus dem SuSE Handbuch zum Thema initrd: Früher wurden für die verschiedenen SCSI-Treiber unterschiedliche Kernel zur Installation angeboten (>40). Dies war notwendig, da der Linux-Kernel das Root-Dateisystem mounten können muß. Außerdem braucht der Kernel den Code für das Dateisystem um es lesen zu können und, falls auch noch verschlüsselt, die Eingabe des Schlüssels/Passwort. Würden die SCSI-Treiber als Module geladen, währe das zu spät - zu mindest, wenn man ein SCSI-CD ROM Laufwerk zur Installation bzw. eine SCSI-Festplatte zum booten verwendet. Die initial ramdisk schafft die Möglichkeit, Userspace-Programme vor dem Mounten des Root Dateisystems auszuführen. Wenn also der 'neu' gebackene Kernel die SCSI-Treiber einkompiliert hat und auch das entsprechende fs, so muß man das erneute Laden der selbigen Module unterbinden. Gruß Michael From: "Harry Rüter" Sent: Thursday, February 21, 2002 3:52 PM

Hi,

Werner Franke wrote:

...

Hallo Reiner,

Reiner Zimmermann wrote:

...

Hallo Leute,

ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu

...

...

Initrd: Als ich hier Fagen zum Kernelbacken hatte, wurde mir gesagt, dass eine initrd bei einem eigenen Kernel NICHT sinnvoll ist. Das wird nur benoetigt, wenn ein Kernel auf unterschiedlichen Systemen laufen soll.

Seh' ich auch so, in den Kernel gehört alles, was man unbedingt (zum booten) braucht, also Filesysysteme, Plattentreiber EIDE/SCSI und alle Hardware, die sowieso ständig benutzt wird (Netzwerk,Keyboard,Maus,Graphik etc ..)

Module nur für selten benutzte Dinge oder Geräte, die evtl. mit verschiedenen Parametern getestet werden sollen oder müssen.

Ich versteh diesen Aufwand mit der initrd nicht oder habe ich da mir unbekannten einen Vorteil übersehen ?

Hallo, Dieter Kluenter writes:

Reiner Zimmermann writes:

...

Hallo Leute,

ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere.

[...]

...

Alles geht gut (scsi wird geladen die Platten erkannt) bis:

VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug [...] Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.

Hast du im Kernel auch devfs und tmpfs aktiviert ?

Das ist eine sinnentstellende Formulierung gewesen, eigentlich sollte die Frage lauten Hast du im Kernel etwa auch devfs und tmpfs aktiviert ? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour

Hallo, Ratti:

...

Firewall entsprechend geöffnet (Im Log fängt sich auch nix). Geht nicht. Ich öffne Filemaker, gebe die IP 1.1.1.1 manuell an, und - keine Datenbanken da.

Jetzt habe ich gewühlt, und im Filemakersupport gelesen: Filemaker verwendet ausschliesslich TCP, nur beim "einloggen" wird UPD verwandt. Kann es daran liegen? Habe ich einen Denkfehler? Geht das generell nicht mit rinetd? Würde es mit xinetd gehen? Womit dann?

Thorsten Dieckhoff:

Hi, vielleicht solltest Du vorher mal so eine Filemaker Session mit dem Netzwerkmonitor beobachten und anhand des Trace entscheiden, ob Du mit rinted weiterkommst. Vermutlich klemmt also nicht der rinetd, sondern es werden Pakete nicht an den Filemaker gelassen, die andere Ports benutzen etc. Prinzipiell wäre das Forwarding ja auch mit iptables oder DeleGate machbar. HTH, Thorsten !

Hallo, Danke für die Tips. Die Ports sind es definitiv nicht, die habe ich vom Filemakersupport, und außerdem haben wir Filemaker auf einem Windows-Webserver laufen, für den eine Profi die Firewall gemacht hat. Um ganz sicher zu gehen, habe ich kurzzeitig die Firewall deaktiviert, und es hat auch nix gebracht. Da ich nicht so der Netzwerkprofi bin: Auf der Manpage von rinetd steht ja z.B. ganz klar, daß man ftp _nicht_ umleiten kann, da es über zwei Ports läuft, und auch gleich im ersten Satz: rinetd redirects _TCP_ connections. Ist das wohlmöglich zu wenig, und ich bin mit rinetd einfach beim falschen Tool? Gruß, Ratti

Waldemar Brodkorb: [Filemaker über rinetd]

Wenn u.a. zum Verbindungsaufbau oder Authentifizierung ("einloggen") UDP verwendet wird, dann kommst du mit rinetd nicht auf einen grünen Zweig.

Danke, das wollte ich wissen. Ja, UDP wird verwandt.

Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert.

Das Tool kannte ich noch gar nicht. Werde ich heute tun und dann berichten.

Hast du einen speziellen Client dafür oder warum muß "Filemaker" von außen erreichbar sein?

Ja. Ich habe das alte Filemaker 3 am laufen, der hat noch keinen http-Server drin, sondern nur sein eigenes Protokoll. Ich würde ungern dem Mac-Server eine externe IP verpassen. Er soll aber von außen erreichbar sein. Welche Alternativen gibt es denn zu rinetd? Ich nehme an, das iptables das auch kann, aber reichlich komplexer ist? Gruß, Danke, Ratti

Hallo Ratti,

From the keyboard of Ratti,

Hallo,

...

Waldemar Brodkorb:

...

Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert.

Ups, der will wohl ein X. Sowas hab ich nicht drauf.

Wahlweiße mit tcpdump einen Snapshot machen und dann die Analyse auf irgendeinem Rechner mit ethereal machen.

Aber deine Aussage, daß ich rinetd vergessen kann, wenn ich UDP brauche, langt ja eigentlich schon, um rinetd zu verwerfen.

Hmmm...was nehmt ihr denn so in solchen Fällen?

iptables könnte man dafür nehmen, könnte deswegen weil es ohne genau analyse des verwendeten Protokolls nicht pauschal zu erläutern ist. Mit iptables kann man aber udp-Ports forwarden. f.e.: IPT=`which iptables` $IPT -t nat -A PREROUTING -p udp --dport 4000 -i $OUTIF -j DNAT --to 192.168.0.2:4000 gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'