des weiteren habe ich festgestellt: eine make modules_prepare löscht mit mein /usr/src/Makefile, d.h. das Makefile löscht sich selbst mit dem Code in Makefile: [...] prepare2: $(Q)if /usr/bin/env test ! $(srctree) -ef $(objtree); then \ $(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \ $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL) \ > $(objtree)/Makefile; \ fi [...] dann steht nur noch folgendes in Makefile: # Automatically generated by /usr/src/linux-2.6.8-24.25/scripts/mkmakefile: don't edit VERSION = 2 PATCHLEVEL = 6 KERNELSRC := /usr/src/linux-2.6.8-24.25 KERNELOUTPUT := /usr/src/linux-2.6.8-24.25 MAKEFLAGS += --no-print-directory all: $(MAKE) -C $(KERNELSRC) O=$(KERNELOUTPUT) %:: $(MAKE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@ DANN nämlich, beim zweiten Aufruf von make modules_prepare ist Endlosschleife angesagt. Was ist da defekt? Kopiere ich das Original-Makefile wieder dahin, dann ist die Endlosschleife wieder weg und z.B. Kompilierung des Kernel mit allen Modulen funktioniert einwandfrei. Damit zusammenhängen wird vermutlich, dass vmware-Module nicht mehr kompilierbar sind: [...] CC [M] /tmp/vmware-config3/vmmon-only/linux/driver.o In file included from /tmp/vmware-config3/vmmon-only/linux/driver.c:11: include/linux/kernel.h:10:20: stdarg.h: No such file or directory [...] Der Compiler findet die sonst fest eingebaute stdarg.h nicht!!!! Habe vorhin von einem Suse 9.2-Laptop mit 24.25er-Kernel mit kompilierbaren vmware-Modulen den gesamten /usr/src/ auf den PC mit dem Defekt gesynct, ebenso die /lib/modules/2.6.8-24.25-default. Leider immer noch der gleiche Fehler. Die Links in /lib/modules/2.6.8-24.25-default/: total 980 drwxr-xr-x 5 root root 4096 Jul 31 15:10 . drwxr-xr-x 8 root root 4096 May 23 11:28 .. lrwxrwxrwx 1 root root 43 Sep 27 16:51 build -> /usr/src/linux-2.6.8-24.25-obj/i386/default drwxr-xr-x 2 root root 4096 Feb 12 2007 extra drwxr-xr-x 10 root root 4096 Feb 12 2007 kernel -rw-r--r-- 1 root root 2339 Aug 30 2006 megaide.LICENSE drwxr-xr-x 2 root root 4096 Sep 27 15:42 misc -rw-r--r-- 1 root root 157761 Jul 31 15:10 modules.alias -rw-r--r-- 1 root root 69 Jul 31 15:10 modules.ccwmap -rw-r--r-- 1 root root 285494 Jul 31 15:10 modules.dep -rw-r--r-- 1 root root 517 Jul 31 15:10 modules.ieee1394map -rw-r--r-- 1 root root 700 Jul 31 15:10 modules.inputmap -rw-r--r-- 1 root root 16504 Jul 31 15:10 modules.isapnpmap -rw-r--r-- 1 root root 149703 Jul 31 15:10 modules.pcimap -rw-r--r-- 1 root root 149250 Jul 31 15:10 modules.symbols -rw-r--r-- 1 root root 175578 Jul 31 15:10 modules.usbmap lrwxrwxrwx 1 root root 26 Sep 27 16:46 source -> /usr/src/linux-2.6.8-24.25 lrwxrwxrwx 1 root root 25 Jul 26 01:07 updates -> ../2.6.8-override-default Was zum Teufel muss ich tun, damit ich den Kernel auf dem defekten PC komplett erneuere? Warum dreht der Compiler durch? Warum das schrottig erzeugte Makefile bei jedem make-Aufruf? Wo bekommt das make_prepare oder make und der makeprozess von vmware-Modulen die falsche Information her? Nach einem make modules_install wird übrigens der Link "build" in /lib/modules/2.6.8-24.25-default/ falsch gesetzt, nämlich auf: build -> /usr/src/linux-2.6.8-24.25 Leute, ich habe keine Zeit mich mit dem Suse-Klapparatismus für Kernel- Kompilierung auseinanderzusetzen, ich kann mich nicht wochenlang mit dem Kernel beschäftigen. Ich will den Mechanismus nur darauf zurücksetzen, wie er bei Suse normalerweise ist. Wie geht das? Tipps? - Danke schonmal Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org