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