9.2: Endlosschleife bei Kompilieren/ wie loesche den Kernel mit allen Modulen?
Ich habe hier Suse 9.2 und seit einem Update auf einen "tollen" neuen Kernel XY per YOU-Update läuft mir beim Kompileren von z.B. der vmware -Moduel das make immer eine Endlosschleife bis der Recher friert. Habe das hier schonmehrfach zur Sprache gebracht, Thomas H. mein ich solle mich mit "Build"-Verzeichnissen beschäftigen, sorry bin aber kein Kernel Guru. Habe schon mal Kernel mit source und /boot gelöscht, dann den Kernel neu von DVD installiert, dann YOU-Kernel update. Leider immer wieder das gleiche Phänomen. DESHALB: WIE LOESCHE ICH DEN KERNEL AUS SUSE 9.2 vollständig heraus? Folgendes reicht offenbar nicht: rpm -e kernel-default-2.6.8-24.25 rpm -e kernel-source-2.6.8-24.25 rpm -e kernel-default-nongpl-2.6.8-24 rm -R /usr/src rm -R /boot Dann Kernel von DVD neu installieren, dann YOU-Kernel-Update. Müssen noch die /lib komplett gelöscht werden? - Steht dann vielleicht plötzlich das System, weil die Module von Yast gebraucht werden? Gibts vielleicht ein YOU-Update auf einen weniger "tollen" Suse-Kernel, bei dem das kompilieren noch geht? Bis zum 2.6.8-24.19 war noch alles in Ordnung. Kann ich gezielt auf den 2.6.8-24.19 updaten? Gruss 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
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
* Ekkard Gerlach (ich) schrieb:
des weiteren habe ich festgestellt: eine make modules_prepare löscht mit mein /usr/src/Makefile, d.h. das Makefile löscht sich nebenbei: kleiner Tippfehler: es muss /usr/src/linux/Makefile heissen 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; \ offenbar ist objtree auf /usr/src/linux gesetzt - daher überschreibt sich das Makefile selbst und wird nicht korrekt nach /usr/src/linux-2.6.8-24.25-obj/i386/default geschrieben, wo es eigentlich hingehört! Warum zum Teufel ist objtree nicht auf /usr/src/linux-2.6.8-24.25-obj/i386/default gesetzt?
Im Makefile wird objtree von CURDIR abgeleitet. Wo kommt CURDIR her? Es exisitiert noch ein Makefile.suse, dort wird build irgendwie gesetzt. Was macht dieses 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!!!!
Ich stelle gerade fest, dass auch hier das /usr/src/linux/Makefile aufgerufen wird, also hängt alles zusammen: das Makefile arbeitet mit falsch gesetzten Variablen! Wie setze ich die richtig? Wie stelle ich diesen Suse-Klapparat auf seinen richtigen Zustand zurück?
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
Ekkard Gerlach schrieb:
* Ekkard Gerlach (ich) schrieb:
[ . . . ]
Was zum Teufel muss ich tun, damit ich den Kernel auf dem defekten PC komplett erneuere? Warum dreht der Compiler durch? Warum das [ . . . ]
Was Du von meinen Angaben gebrauchen willst/kannst, weiß ich nicht. Ich mach das zu Fuß (ohne YOU u.a.m.) wie folgt: mit Unterstützung von http://www.thomashertweck.de/kernel26.htm 1) Kopiere /boot nach /boot-default-old 2) Lösche in /boot alles bis auf "map" und "message" 3) Kopiere /lib/modules nach /lib/modules-default-old 4) Bilde neues Verzeichnis /lib/modules 5) Bilde neues Verzeichnis für den neuen Kernel 6) Lösche /usr/src/linux und /usr/src/linux-obj 7) Etwaiges Löschen vorhandener Kernel-Verzeichnisse dient lediglich der besseren Übersicht 8) Auspacken neuer Kernel-source rpm -ivh --force --nodeps kernel-source.rpm 9) Ausgepackte Kernel-Source kopieren (z.B. cp linux-2.6.8-24.25-default linux-2.6.8-24.25-1) (linux-2.6.8-24.25-default-obj linux-2.6.8-24.25-1-obj) Damit erhält der Kernel einen eindeutigen Namen 10) cd /usr/src/linux . . . -1 (zum Kernel Kompilieren) 10.1 = make mrproper 10.2 = .config-Datei nach /usr/src/linux . . -1 kopieren 10.3 = make oldconfig (oder andere) 10.4 = make xconfig Die .config-Datei bestimmen unter general setup "local version . . . . -1" angeben 10.5 = .config-Datei speichern 10.6 = make prepare 11) öffnen /usr/src/linux . . .-1-obj/i386/default/ vorhandene .config-Datei ersetzen durch /.config-Datei von /usr/src/linux . . -1 12) öffnen /usr/src/linux . . . .-1-obj/i386/ default/include/linux vorhandene Dateien löschen und durch folgende gleichlautende Dateien ersetzen aus /usr/src/linux . . .-1/include/linux 13) make bzImage 14) make modules 15) make modules_install 16) cp System.map /boot/System.map-kernel . . . -1 17) cd arch/i386/boot 18) cp bzImage /boot/vmlinuz-kernel . . .-1 19) ln /boot/vmlinuz-kernel . . -1 /boot/vmlinuz 20) mkinitrd . . . . . 21) ln mkinitrd . . . . . . 22) Für lilo-user = lilo 23) Neustart Kontrolle: depmod -a uname -a Aufräumen nach belieben Schlussbemerkung: Makefile's spielen keine Rolle Wichtig sind die Änderungen in ". . . -1-obj" Diese Methode /lib/modules und /boot erfordert aber bei Boot-Problemen entsprechendes Handling Arno -- 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
besten Dank Arno, aber die Probleme mit dem build-Verzeichnis wäre vermutlich geblieben, wir haben den ganezn Kernel von einer anderen 9.2-Maschine kopiert und der Fehler war auch da immer noch. Nu habe ich den Suse-Kernel runtergeworfen, den 2.6.18 drauf und gut ist. Ging ganz schnell, werde ich in Zukunft immer so machen, bevor ich mich mit dem Suse-Gedöns beschäftige. Vmware-module lassen sich auch wie gewohnt dazukompilieren. :-) Gruss 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
Ekkard Gerlach wrote:
[...] offenbar ist objtree auf /usr/src/linux gesetzt - daher überschreibt sich das Makefile selbst und wird nicht korrekt nach /usr/src/linux-2.6.8-24.25-obj/i386/default geschrieben, wo es eigentlich hingehört! Warum zum Teufel ist objtree nicht auf /usr/src/linux-2.6.8-24.25-obj/i386/default gesetzt?
Wenn Du schlicht ein "make" im Kernel-Verzeichnis absetzt, warum soll dann ein Build-Directory verwendet werden? In dem Falle ist schlicht das Kernel Source-Directory auch das Build-Directory, d.h. Du baust den Kernel "in place", wie es so schoen heisst. Nur bei Verwendung von "O=<build-directory>" werden erzeugte Dateien im Build-Directory abgelegt. Wenn diese Variable nicht angegeben wird an der Kommandozeile, wird normalerweise aber auch nicht versucht, ein rudimentaeres Makefile im Build-Directory zu erzeugen - Du hast definitiv irgendetwas mit dem Source- und Build-Directory auf Deinem System durcheinander gebracht, evtl. auch falsche Links angelegt o.ae.
Im Makefile wird objtree von CURDIR abgeleitet. Wo kommt CURDIR her?
CURDIR ist eine automatische make Variable, die das aktuelle Verzeichnis enthaelt.
Es exisitiert noch ein Makefile.suse, dort wird build irgendwie gesetzt. Was macht dieses Makefile?
$> head -5 Makefile.suse # Makefile.suse # # Use for test compiling external kernel modules. #
[...] Ich stelle gerade fest, dass auch hier das /usr/src/linux/Makefile aufgerufen wird, also hängt alles zusammen: das Makefile arbeitet mit falsch gesetzten Variablen! Wie setze ich die richtig? Wie stelle ich diesen Suse-Klapparat auf seinen richtigen Zustand zurück?
Das kommt nicht von SuSE, das ist das normale Kernel Build-System, das bei einem Vanilla-Kernel genau so funktioniert.
[...] 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
Warum ist das falsch? Wenn Du den Kernel dort compiliert hast statt ein Build-Directory zu verwenden, ist das richtig. Th. -- 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
participants (3)
-
Arno Jung -
Ekkard Gerlach -
Thomas Hertweck