Mantel-Kernel: ipt_tos.h: No such file or directory
Ich versuche einen eigenen Kernel von kernel-source-2.4.21-4.i586.rpm für ein Multisystem zu bauen und habe dazu das rpm installiert, das Sourcen-Verzeichnis wurde gesichert und dann auf einen (fast) identen Rechner übertragen. Weiters wurden dieses Verzeichnis in /usr/src/linux-2.4.21-4-own umbenannt, sodass das Original-Verzeichnis linux-2.4.20.SuSE weiter vorhanden ist. Warum ich später von linux-2.4.21-4-own auf linux-2.4.21-4-mantel-own nicht mit make menuconfig umbenennen konnte, ist mir nicht klar, aber meinetwegen soll der Kernel weiter "own" heißen. Bei "mantel-own" lief die Kompilierung einige Zeit und dann wurde im Pfad linux-2.4.21-4-own und nicht in linux-2.4.21-4-mantel-own gesucht. Ich wollte im Makefile EXTRAVERSION = -$(CONFIG_RELEASE)-$(CONFIG_CFGNAME) KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) nichts manuell eintragen, da ich nicht weiß, ob das irgendwelchen weiteren Auswirkungen hat. Irgendwann kam es dann im "netfilter_ipv4-Bereich" zu u.a. Fehlermeldungen. Diese Option kann ich aber nicht im Kernel streichen und so scheint es, dass ich hier anstehe. Ausgeführt wurde: time make dep clean bzImage modules modules_install 2>&1 | tee make.out /lib/modules # ls . .. 2.4.20-4GB 2.4.20-4GB-original "Original" ist einfach eine Kopie für Notfälle. Es gab also noch kein Verzeichnis 2.4.21-4-own gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_REJECT -c -o ipt_REJECT.o ipt_REJECT.c In file included from /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1048, from ipt_REJECT.c:13: /usr/src/linux-2.4.21-4-own/include/net/tcp_ecn.h: In function `TCP_ECN_send': /usr/src/linux-2.4.21-4-own/include/net/tcp_ecn.h:52: warning: comparison between signed and unsigned In file included from ipt_REJECT.c:13: /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `tcp_cwnd_validate': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1130: warning: comparison between signed and unsigned /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `tcp_minshall_update': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1175: warning: comparison between signed and unsigned In file included from ipt_REJECT.c:13: /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `tcp_select_initial_window': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1542: warning: comparison between signed and unsigned /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `keepalive_intvl_when': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1803: warning: signed and unsigned type in conditional expression /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `keepalive_time_when': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1808: warning: signed and unsigned type in conditional expression /usr/src/linux-2.4.21-4-own/include/net/tcp.h: In function `tcp_fin_time': /usr/src/linux-2.4.21-4-own/include/net/tcp.h:1815: warning: comparison between signed and unsigned ipt_REJECT.c: In function `send_unreach': ipt_REJECT.c:200: warning: comparison between signed and unsigned ipt_REJECT.c:213: warning: comparison between signed and unsigned ipt_REJECT.c:238: warning: comparison between signed and unsigned gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_MIRROR -c -o ipt_MIRROR.o ipt_MIRROR.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_TOS -c -o ipt_TOS.o ipt_TOS.c ipt_TOS.c:5:42: linux/netfilter_ipv4/ipt_tos.h: No such file or directory ipt_TOS.c: In function `match': ipt_TOS.c:21: error: dereferencing pointer to incomplete type ipt_TOS.c:21: error: dereferencing pointer to incomplete type ipt_TOS.c: In function `checkentry': ipt_TOS.c:31: error: invalid application of `sizeof' to an incomplete type ipt_TOS.c: At top level: ipt_TOS.c:53: error: parse error before "sizeof" ipt_TOS.c:55: error: parse error before '->' token ipt_TOS.c:66: error: conflicting types for `checkentry' ipt_TOS.c:30: error: previous declaration of `checkentry' ipt_TOS.c: In function `checkentry': ipt_TOS.c:67: error: dereferencing pointer to incomplete type ipt_TOS.c:69: error: invalid application of `sizeof' to an incomplete type ipt_TOS.c:72: error: invalid application of `sizeof' to an incomplete type ipt_TOS.c:85: error: `IPTOS_NORMALSVC' undeclared (first use in this function) ipt_TOS.c:85: error: (Each undeclared identifier is reported only once ipt_TOS.c:85: error: for each function it appears in.) ipt_TOS.c: At top level: ipt_TOS.c:94: error: `target' undeclared here (not in a function) ipt_TOS.c:94: error: initializer element is not constant ipt_TOS.c:94: error: (near initialization for `ipt_tos_reg.target') ipt_TOS.c:97: error: redefinition of `init' ipt_TOS.c:41: error: `init' previously defined here ipt_TOS.c:105: error: redefinition of `fini' ipt_TOS.c:46: error: `fini' previously defined here ipt_TOS.c:109: error: redefinition of `init_module' ipt_TOS.c:50: error: `init_module' previously defined here ipt_TOS.c:109: error: redefinition of `__init_module_inline' ipt_TOS.c:50: error: `__init_module_inline' previously defined here ipt_TOS.c:110: error: redefinition of `cleanup_module' ipt_TOS.c:51: error: `cleanup_module' previously defined here ipt_TOS.c:110: error: redefinition of `__cleanup_module_inline' ipt_TOS.c:51: error: `__cleanup_module_inline' previously defined here ipt_TOS.c:111: error: redefinition of `__module_license' ipt_TOS.c:52: error: `__module_license' previously defined here {standard input}: Assembler messages: {standard input}:36: Error: symbol `__module_license' is already defined make[2]: *** [ipt_TOS.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.21-4-own/net/ipv4/netfilter' make[1]: *** [_modsubdir_ipv4/netfilter] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21-4-own/net' make: *** [_mod_net] Error 2 Der Grund für diesen Kernel, ist dass ich mit meiner Auerswald-Telefonanlage mit dem 2.4.20 nicht klarkomme und als Alternative zum Vanilla-Kernel mal einen SuSE-Kernel probieren wollte. Al
Al Bogner schrieb:
Ich versuche einen eigenen Kernel von kernel-source-2.4.21-4.i586.rpm für ein Multisystem zu bauen und habe dazu das rpm installiert, das Sourcen-Verzeichnis wurde gesichert und dann auf einen (fast) identen Rechner übertragen. Weiters wurden dieses Verzeichnis in /usr/src/linux-2.4.21-4-own umbenannt, sodass das Original-Verzeichnis linux-2.4.20.SuSE weiter vorhanden ist.
Verstehe ich nicht... Die Original-Quellen, die mit der SuSE 8.2 kommen, werden in das Verzeichnis /usr/src/linux-2.4.20.SuSE installiert. Die Quellen aus kernel-source-2.4.21-4.i586.rpm werden in ein Verzeichnis /usr/src/linux-2.4.21-4 installiert. Wo soll da was kollidieren? Wel- chen Sinn sollte es also haben, das Verzeichnis von linux-2.4.21-4 in linux-2.4.21-4-own umzubennenen. OK, ist nicht weiter tragisch, Du kannst es auch linux-pillepalle nennen, es spielt schlicht keine Rolle, ich verstehe es nur nicht.
Warum ich später von linux-2.4.21-4-own auf linux-2.4.21-4-mantel-own nicht mit make menuconfig umbenennen konnte, ist mir nicht klar, aber meinetwegen soll der Kernel weiter "own" heißen.
Seit wann kann man mit Hilfe von "make menuconfig" Verzeichnisse um- benennen? Du redest in Raetseln. Mit SuSE-Kernel 2.4.21 hat sich die Benennung des Kernel-Release geaendert, das spiegelt sich auch in der Variablen EXTRAVERSION im Makefile wider. Du kannst bei der Konfigu- ration hier die Punkte CONFIG_CFGNAME und CONFIG_RELEASE setzen - aus denen wird dann letztendlich der Name aufgebaut. Wenn Du also z.B. in .config CONFIG_RELEASE=4 und CONFIG_CFGNAME="own" setzt, dann wird Dein Kernel als "uname -r" ein 2.4.21-4-own liefern. Wenn es ein 2.4.21-4-mantel-own sein soll, so muss CONFIG_RELEASE=4 und CONFIG_CFGNAME="mantel-own" sein. Aber das wirkt sich nur auf das Kernel-Release aus, nicht auf irgendwelche Verzeichnisnamen, in denen Du die Kernel-Quellen lagerst.
Bei "mantel-own" lief die Kompilierung einige Zeit und dann wurde im Pfad linux-2.4.21-4-own und nicht in linux-2.4.21-4-mantel-own gesucht.
Wer wurde wie wo gesucht... Immer mehr Raetsel! Vielleicht solltest Du beim naechsten Mal einfach Fehlermeldungen oder genaue Meldungen im xterm posten. So ist das jedenfalls nicht verstaendlich.
Ich wollte im Makefile EXTRAVERSION = -$(CONFIG_RELEASE)-$(CONFIG_CFGNAME) KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) nichts manuell eintragen, da ich nicht weiß, ob das irgendwelchen weiteren Auswirkungen hat.
Du kannst einfach eine EXTRAVERSION setzen von Hand. Oder aber Du setzt wie oben beschrieben die Variablen CONFIG_CFGNAME und CONFIG_RELEASE per "make menuconfig" oder direkt in .config.
Irgendwann kam es dann im "netfilter_ipv4-Bereich" zu u.a. Fehlermeldungen. Diese Option kann ich aber nicht im Kernel streichen und so scheint es, dass ich hier anstehe.
Ausgeführt wurde: time make dep clean bzImage modules modules_install 2>&1 | tee make.out
Wenn Du das so ausgefuehrt hast, bedeutet es, Du hast den Kernel und vermutlich auch die gesamte Konfiguration als Root gemacht. Das solltest Du nicht tun. Nur zum _Installieren_ braucht man Root-Rechte, weder zum Konfigurieren noch zum Compilieren.
/lib/modules # ls . .. 2.4.20-4GB 2.4.20-4GB-original
"Original" ist einfach eine Kopie für Notfälle. Es gab also noch kein Verzeichnis 2.4.21-4-own
Ist logisch, wenn "make modules" nicht durchlaeuft, wurde auch "make modules_install" nicht ausgefuehrt und somit keine Module unter /lib/modules installiert.
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_MIRROR -c -o ipt_MIRROR.o ipt_MIRROR.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_TOS -c -o ipt_TOS.o ipt_TOS.c ipt_TOS.c:5:42: linux/netfilter_ipv4/ipt_tos.h: No such file or directory [...]
Die Fehlermeldung kann ich nicht nachvollziehen. Das Include-Verzeichnis ist korrekt als -I/usr/src/linux-2.4.21-4-own/include angegeben. Im be- sagten RPM kernel-source-2.4.21-4.i586.rpm gibt es auch eine ipt_tos.h, wie Dir "rpm -qpl kernel-source-2.4.21-4.i586.rpm | grep ipt_tos.h" leicht zeigen wird: $> rpm -qpl kernel-source-2.4.21-4.i586.rpm | grep ipt_tos.h /usr/src/linux-2.4.21-4/include/linux/netfilter_ipv4/ipt_tos.h $> Hast Du da von Hand etwas geloescht oder so? Schau halt mal von Hand nach, ob diese Datei existiert, also in Deinem Falle nach dem Umbe- nennen /usr/src/linux-2.4.21-4-own/include/linux/netfilter_ipv4/ipt_tos.h. Deine Mails sind inhaltlich etwas verwirrend bzw. unpraezise... CU, Th.
Am Montag, 18. August 2003 23:21 schrieb Thomas Hertweck:
Ich versuche einen eigenen Kernel von kernel-source-2.4.21-4.i586.rpm für ein Multisystem zu bauen und habe dazu das rpm installiert, das Sourcen-Verzeichnis wurde gesichert und dann auf einen (fast) identen Rechner übertragen. Weiters wurden dieses Verzeichnis in /usr/src/linux-2.4.21-4-own umbenannt, sodass das Original-Verzeichnis linux-2.4.20.SuSE weiter vorhanden ist.
Verstehe ich nicht... Die Original-Quellen, die mit der SuSE 8.2 kommen, werden in das Verzeichnis /usr/src/linux-2.4.20.SuSE installiert. Die Quellen aus kernel-source-2.4.21-4.i586.rpm werden in ein Verzeichnis /usr/src/linux-2.4.21-4 installiert. Wo soll da was kollidieren?
Nachdem ich kernel-source-2.4.21-4.i586.rpm mit rpm -Uvh installiert hatte, gab es kein 2.4.20 mehr. Ich habe darüber geflucht.
chen Sinn sollte es also haben, das Verzeichnis von linux-2.4.21-4 in linux-2.4.21-4-own umzubennenen.
Damit die ursprünglichen Quellen unverändert erhalten bleiben und ich erkenne, dass das kein Kernel mit den voreingestellten SuSE-Optionen ist, sondern mit meinen und mir irgendein Update das Verzeichnis nicht wieder vernichtet.
OK, ist nicht weiter tragisch, Du kannst es auch linux-pillepalle nennen, es spielt schlicht keine Rolle, ich verstehe es nur nicht.
So sehe ich es auch.
Warum ich später von linux-2.4.21-4-own auf linux-2.4.21-4-mantel-own nicht mit make menuconfig umbenennen konnte, ist mir nicht klar, aber meinetwegen soll der Kernel weiter "own" heißen.
Seit wann kann man mit Hilfe von "make menuconfig" Verzeichnisse um- benennen? Du redest in Raetseln.
Ich meinte nicht, dass ich das Verzeichnis mit menuconfig umbenennen wollte, sondern es gibt beim Mantel-Kernel eine Option BuildOptions/ConfigurationName und da glaube ich, hat was nicht so richtig funktioniert. Denn wenn ich Verzeichnis linux-2.4.21-4-mantel-own mit linux verlinke und bei ConfigurationName mantel-own angebe, dann dürfte beim Kompilieren nicht ein Pfad 2.4.21-4-own (ohne Mantel) bemängelt werden. Das ist aber nur eine Randbemerkung.
Mit SuSE-Kernel 2.4.21 hat sich die Benennung des Kernel-Release geaendert, das spiegelt sich auch in der Variablen EXTRAVERSION im Makefile wider. Du kannst bei der Konfigu- ration hier die Punkte CONFIG_CFGNAME und CONFIG_RELEASE setzen - aus denen wird dann letztendlich der Name aufgebaut. Wenn Du also z.B. in .config CONFIG_RELEASE=4 und CONFIG_CFGNAME="own" setzt, dann wird Dein Kernel als "uname -r" ein 2.4.21-4-own liefern. Wenn es ein 2.4.21-4-mantel-own sein soll, so muss CONFIG_RELEASE=4 und CONFIG_CFGNAME="mantel-own" sein. Aber das wirkt sich nur auf das Kernel-Release aus, nicht auf irgendwelche Verzeichnisnamen, in denen Du die Kernel-Quellen lagerst.
Ok, so sehe ich es auch. Wenn ich es richtig verstanden habe, ist es völlig egal wie das Verzeichnis heißt, wo die Quellen gelagert sind. Die Bezeichnung für VERSION / PATCHLEVEL / SUBLEVEL / EXTRAVERSION ist aber entscheidend für das Verzeichnis in /lib/modules, oder?
Bei "mantel-own" lief die Kompilierung einige Zeit und dann wurde im Pfad linux-2.4.21-4-own und nicht in linux-2.4.21-4-mantel-own gesucht.
Wer wurde wie wo gesucht... Immer mehr Raetsel! Vielleicht solltest Du beim naechsten Mal einfach Fehlermeldungen oder genaue Meldungen im xterm posten. So ist das jedenfalls nicht verstaendlich.
Die Ausgabe des xterms habe ich leider nicht mehr und kann es auch nicht mehr reproduzieren. Es waren einfach Merkwürdigkeiten, die mir auffielen, aber für den Kernel unwichtig sind.
Du kannst einfach eine EXTRAVERSION setzen von Hand.
Ok.
Ausgeführt wurde: time make dep clean bzImage modules modules_install 2>&1 | tee make.out
Wenn Du das so ausgefuehrt hast, bedeutet es, Du hast den Kernel und vermutlich auch die gesamte Konfiguration als Root gemacht. Das solltest Du nicht tun.
Bitte kurze Begrüdung, wo die Nachteile liegen. Ich habe es mit ssh an einer remote-Konsole im lokalen Netzwerk gemacht.
Nur zum _Installieren_ braucht man Root-Rechte, weder zum Konfigurieren noch zum Compilieren.
/lib/modules # ls . .. 2.4.20-4GB 2.4.20-4GB-original
"Original" ist einfach eine Kopie für Notfälle. Es gab also noch kein Verzeichnis 2.4.21-4-own
Ist logisch, wenn "make modules" nicht durchlaeuft, wurde auch "make modules_install" nicht ausgefuehrt und somit keine Module unter /lib/modules installiert.
Das ist klar, ich habe es nur der Vollständigkeit halber angeführt, um nicht danach gefragt zu werden, ob sich in /lib/modules ein Verzeichnis einer frühreren Installation befindet.
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_MIRROR -c -o ipt_MIRROR.o ipt_MIRROR.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-4-own/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=pentium3 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ipt_TOS -c -o ipt_TOS.o ipt_TOS.c ipt_TOS.c:5:42: linux/netfilter_ipv4/ipt_tos.h: No such file or directory [...]
Die Fehlermeldung kann ich nicht nachvollziehen. Das Include-Verzeichnis ist korrekt als -I/usr/src/linux-2.4.21-4-own/include angegeben. Im be- sagten RPM kernel-source-2.4.21-4.i586.rpm gibt es auch eine ipt_tos.h, wie Dir "rpm -qpl kernel-source-2.4.21-4.i586.rpm | grep ipt_tos.h" leicht zeigen wird:
/usr/src/linux-2.4.21-4-own # rpm -qpl kernel-source-2.4.21-4.i586.rpm | grep ipt_tos.h open of kernel-source-2.4.21-4.i586.rpm failed: No such file or directory Aha, da ist also irgendwas bei der Installation falsch gelaufen.
Hast Du da von Hand etwas geloescht oder so?
Nein, ganz sicher nicht.
Schau halt mal von Hand nach, ob diese Datei existiert, also in Deinem Falle nach dem Umbe- nennen /usr/src/linux-2.4.21-4-own/include/linux/netfilter_ipv4/ipt_tos.h.
/usr/src/linux-2.4.21-4-own/include/linux/netfilter_ipv4 # ls ipt_t* ipt_ttl.h Ich habe sicher _keine_ Datei händisch gelöscht. Ich werde mich entscheiden müssen, ob ich auf diesem PC den 2.4.20 behalte oder doch mit dem Mantel-Kernel klar komme, denn beim Vanilla-Kernel stellte ich fest, dass der alte Tekram DC-395U nicht dabei ist, vermutlich weil die Hardware ziemlich problematisch ist. Es gibt da ein für Debian einen kernel-patch-tekram-dc3x5. Wie includiere ich den in den Vanilla-Kernel bzw. wie bekomme ich den ohne apt? Al
Al Bogner wrote:
Am Montag, 18. August 2003 23:21 schrieb Thomas Hertweck: [...] Nachdem ich kernel-source-2.4.21-4.i586.rpm mit rpm -Uvh installiert hatte, gab es kein 2.4.20 mehr. Ich habe darüber geflucht.
Ach, jetzt verstehe ich. Schreib das doch gleich so :-) Nun, das ist leider logisch, dass das passieren musste. Ein "rpm -Uhv" steht nun mal fuer "Update" - dabei wird immer das Alte durch das Neue _ersetzt_. In so einem Falle wie hier wuerde ich die Kernel-Quellen nicht per RPM, sondern per Tar-Archiv installieren oder _ausnahmsweise_ mal mit den Optionen "--nodeps --force" arbeiten.
Ich meinte nicht, dass ich das Verzeichnis mit menuconfig umbenennen wollte, sondern es gibt beim Mantel-Kernel eine Option BuildOptions/ConfigurationName und da glaube ich, hat was nicht so richtig funktioniert. Denn wenn ich Verzeichnis linux-2.4.21-4-mantel-own mit linux verlinke und bei ConfigurationName mantel-own angebe, dann dürfte beim Kompilieren nicht ein Pfad 2.4.21-4-own (ohne Mantel) bemängelt werden. Das ist aber nur eine Randbemerkung.
Das kann man ohne _genaue_ Fehlermeldung nicht nachvollziehen. Ich habe gestern den 2.4.21 mal compiliert und eigentlich in dieser Hinsicht keine negativen Erfahrungen gemacht. Man muss sich nur dran gewoehnen, dass nun die beiden Variablen in der .config Datei stehen, das ist ja neu.
Ok, so sehe ich es auch. Wenn ich es richtig verstanden habe, ist es völlig egal wie das Verzeichnis heißt, wo die Quellen gelagert sind.
Das ist wirklich voellig egal. Du brauchst zum Konfigurieren, Compilieren und Installieren des Kernels auch keinen Link /usr/src/linux setzen. Linus Torvalds geht sogar so weit und sagt, dieser Link sollte heutzutage gar nicht mehr existieren.
Die Bezeichnung für VERSION / PATCHLEVEL / SUBLEVEL / EXTRAVERSION ist aber entscheidend für das Verzeichnis in /lib/modules, oder?
Entscheidend ist das KERNELRELEASE.
[...] Wenn Du das so ausgefuehrt hast, bedeutet es, Du hast den Kernel und vermutlich auch die gesamte Konfiguration als Root gemacht. Das solltest Du nicht tun.
Bitte kurze Begrüdung, wo die Nachteile liegen. Ich habe es mit ssh an einer remote-Konsole im lokalen Netzwerk gemacht.
Prinzipiell gilt: man arbeitet nur als Root, wenn es wirklich notwendig ist. Zum Konfigurieren und Compilieren ist es nicht notwendig, also sollte man es vermeiden. Wie schnell gibt man mal ein falsches Kommando ein: Da willst Du irgendetwas loe- schen und machst aus Versehen eine falsche Eingabe - als Root hat das eben andere Auswirkungen im Vergleich zu einem User. Ausserdem hat es gewisse Sicherheitsaspekte, von o.a. Selbst- schutz mal abgesehen. Vor einiger Zeit gab es mal ein Problem bei ssh - wenn Du das compiliert hast, dann wurde einem Rech- ner im Internet Daten uebermittelt. Tja, das Quellcode-Paket auf einem FTP-Server war kompromitiert worden. Oder es kann mal eine falsche Angabe im Kernel-Makefile stehen, die dann nicht das macht, was sie soll, sondern eben falsche Sachen... Es gibt viele Gruende, nicht als Root zu arbeiten oder nur dann, wenn es _wirklich_ notwendig ist (z.B. fuer ein "make modules_install", das Kopieren des Kernels nac /boot oder dem Editieren der Bootloader-Konfig).
/usr/src/linux-2.4.21-4-own # rpm -qpl kernel-source-2.4.21-4.i586.rpm | grep ipt_tos.h open of kernel-source-2.4.21-4.i586.rpm failed: No such file or directory
Aha, da ist also irgendwas bei der Installation falsch gelaufen.
Nein! Ich habe das natuerlich auf das bei mir in diesem Ver- zeichnis, in dem der Befehl ausgefuehrt wurde, vorhandene RPM angewandt. Wenn Du Kernel-Source bereits installiert hast, dann musst Du ein $> rpm -ql kernel-source-2.4.21-4 | grep ipt_tos.h ausfuehren. Du solltest Dich vielleicht nebenbei auch mal ein bissl mit "rpm" beschaeftigen, nicht nur mit Kernel-Compi- lieren :-)
[...] /usr/src/linux-2.4.21-4-own/include/linux/netfilter_ipv4 # ls ipt_t* ipt_ttl.h
Da stimmt etwas nicht. Ich habe das gleiche RPM Paket und bei mir ist die Datei ipt_tos.h vorhanden! Du solltest es nochmal mit einem "fresh install" versuchen.
Ich habe sicher _keine_ Datei händisch gelöscht.
<ironie-modus> Dann war es wohl jemand anderes </ironie-modus>
Es gibt da ein für Debian einen kernel-patch-tekram-dc3x5. Wie includiere ich den in den Vanilla-Kernel bzw. wie bekomme ich den ohne apt?
Weiss ich nicht. Wie man den in den Vanilla-Kernel bekommt haengt schlicht davon ab, wie der Patch erstellt wurde... CU, Thomson
participants (2)
-
Al Bogner -
Thomas Hertweck