• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kernelbau schlägt fehl

Hallo
wolle eben eine Kernel basteln. Beim ersten versuch musste ich abbrechen weil die Konsole sich während es Kenelbaus nach einem Lock nicht mehr entsperren lies.

Der Befehk make lief durch. make modules lief gerade.

Nach dem neustart wollte ich weitermachen, allerdings kommt nun folgende Fehlermeldung. ich habe schon die Sourcen entfernt und neu installiert

Hier nun die Meldung :

bluevelvet2:/usr/src/linux # make
scripts/kconfig/conf -s arch/i386/Kconfig
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
GZIP kernel/config_data.gz
IKCFG kernel/config_data.h
CC kernel/configs.o
LD kernel/built-in.o
CC [M] drivers/media/dvb/dvb-usb/au6610.o
drivers/media/dvb/dvb-usb/au6610.c:182: error: ‘USB_VID_ALCOR_MICRO’ undeclared here (not in a function)
drivers/media/dvb/dvb-usb/au6610.c:182: error: ‘USB_PID_SIGMATEK_DVB_110’ undeclared here (not in a function)
make[4]: *** [drivers/media/dvb/dvb-usb/au6610.o] Error 1
make[3]: *** [drivers/media/dvb/dvb-usb] Error 2
make[2]: *** [drivers/media/dvb] Error 2
make[1]: *** [drivers/media] Error 2
make: *** [drivers] Error 2

Hat jemand eine Idee was das sein könnte.


bluevelvet2:/usr/src/linux #
 
OP
B

Bluevelvet64

Hacker
Was meinst Du mit : welche version baust DU

Ich bin nach einer Anleitung hier aus dem Forum zum ändern von Kernelparamertern für einen USB-Stick ( Yakumo-Quick Basic ) vorgegangen. ich habe dieses schon öfter gemacht und es hat jedesmal funktioniert.

Vorgehensweise: auf Suse 10.3

1. Installation Kernelsourcen
2. ändern von 2 Dateien unter /usr/src/linux/drivers/media/dvb/dvb-usb
3. zcat /proc/config > .oldconfig ( unter /usr/src/linux)
4. make oldconfig
5. make
6. make modules.

Es hat eben auch funktioniert, nur musste ich eben abbrechen weil ich die Konsole nicht mehr entsperren konnte. Aber bis zum make modules ( Schritt 6 ) war alles ok. Nun bricht schon der make Befehl ( Schritt 5 ) ab.

Nach einem Neustart kam und kommt der Fehler.

Da ich die Sourcen deinstalliert und dann neu installiert habe, sollte ich eigentlich den gleichen Stand haben, wie beim ersten Versuch. Was kann also anders sein.
 

Gimpel

Guru
Bluevelvet64 schrieb:
Was meinst Du mit : welche version baust DU
Na die kernel version.

Ich bin nach einer Anleitung hier aus dem Forum zum ändern von Kernelparamertern für einen USB-Stick ( Yakumo-Quick Basic ) vorgegangen. ich habe dieses schon öfter gemacht und es hat jedesmal funktioniert.

Vorgehensweise: auf Suse 10.3

1. Installation Kernelsourcen
2. ändern von 2 Dateien unter /usr/src/linux/drivers/media/dvb/dvb-usb
Und genau daher rührt auch der compile error.

Evtl ein Tippfehler beim editieren?
 
OP
B

Bluevelvet64

Hacker
Ein Tipfehler kann nicht sein weil :

1. Ich die Dateien schon vor einem Jahr angepasst habe und immer wenn ich den Kernel ändere nur ins Zielverzeichnis kopiere und
2. Der fehler sich auf eine Datei bezieht, die mit den änderungen nichts zu tun hat.

Danke für Deine Antwort
 

Gimpel

Guru
Im letzten Jahr hat sich dann in /usr/src/linux/drivers/media/dvb/dvb-usb doch einiges getan, und auch im USB subsystem. Wie bist du dir also sicher, dass deine Änderungen noch funktionieren?

Definiert ist USB_PID_SIGMATEK_DVB_110 in
/usr/src/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h

au6610 scheint ja ein Modul für einen speziellen chip zu sein. Wenn du diesen nicht verwendest, deaktiviere ihn einfach in menuconfig. Evtl läufts dann durch.
 
OP
B

Bluevelvet64

Hacker
...der erste versuch mit den gleichen Sourcen und den gleichen angepassten Dateien funktionierte.

Wenn es also an einem falschen Eintrag oder änderungen an den Sourcen seit 10.1 handeln würde, hätte der erste Versuch auch fehlgeschlagen.
 

Gimpel

Guru
Wenns einmal kompiliert, kompilierts auch zweimal. Beim zweiten mal hat make ja bei dem Modul weiter gebaut. Es baut immer da weiter, wo was geändert wurde. Und dass beim ersten mal Was schiefging, haste ja gemerkt :p

Hast du drivers/media/dvb/dvb-usb/dvb-usb-ids.h geändert?
 
OP
B

Bluevelvet64

Hacker
aber liest Du auch was andere schreiben.

Beim "ersten" Male hat es eben funktioniert. Ich musste nur abbrechen weil während der Kernel kompiliert wurde, die konsole vom Screensaver gesperrt wurde und ich die Konsole nicht mehr entsperren konnte. Da war aber der make Befehl schon fertig, Hat also beim "ersten" Mal funktioniert. Der make modules befehl war seit ca. 10 Minuten voll am gange. Ging also auch.

Erst der "zweite" Versuch und alle weiteren Versuche gingen schief. Und zwar beim make. Da ich die Kernelsourcen deinstalliert und wieder installiert habe, habe ich wohl im /usr/src/linux Verzeichnis den gleichen Inhalt wie beim ersten Mal.

es müssen also woanders Dateien vom ersten make aufruf vorhanden sein, die ein weiteres make stören.
 
OP
B

Bluevelvet64

Hacker
Ja und eine weitere

dtt200u.c
dvb-usb-ids.h

Diese musten laut Anleitung geändert werden um diese an die Firmware an zu passen.
 

Gimpel

Guru
Bluevelvet64 schrieb:
Ja und eine weitere

dtt200u.c
dvb-usb-ids.h

Diese musten laut Anleitung geändert werden um diese an die Firmware an zu passen.
Ich habe durchaus gelesen was du geschrieben hast, sonst wüsste ich ja schliesslich nicht, in welcher Datei du was vermasselt hast. Die Frage danach war eher rhetorisch und als hint zu verstehen, mal nachzusehen, ob du da nicht nen Fehler gemacht hast beim editieren. Und wenn du dir 200% sicher bist, dass das nicht so ist, dann sind wir wieder bei dem Punkt, ob dein ein Jahr altes Zeug da mit kernel 2.6.22 überhaupt noch zu gebrauchen ist.

make kann vom ersten Aufruf keine Dateien mehr irgendwo haben, wenn du nach dem reset alles gelöscht und neu installiert hast. Es speichert nichts im RAM, und ccache haste sicher auch nicht verwendet.
Dass es beim ersten Mal funktioniert haben soll, ist somit vollkommen irrelevant.

Ach vergisses.

Lol, du machst das schon, großer Meister. :roll:
 
OP
B

Bluevelvet64

Hacker
ich habe auf meinem Notebook auf zwei Partitionen je das gleiche Suse 10.3

1 System ist Produktiv 1 System ist zum Testen.

Ich habe gestern auf dem Testsystem den Kernel zu ändern versucht.

Nachdem es beim 2. Mal nicht ging, habe ich es dann auf dem Produktivsystem versucht. Auch hier ging es beim ersten Versuch. Ich konnte also den Kernel ändern. Nun habe ich auf dem Testsystem Suse neu installiert. Und nun ging auch hier der Kernelbau. Ich habe dann nochmal die Sourcen deinstalliert und wieder installiert und nun ging der make befehl wieder nicht. Also bei jedem 1. Mal kann ich den Kernel neu kompielieren, bei jedem 2. Mal kommt die Fehlermeldung.

Also ist die Vorgehensweise ok und auch die Dateien die ich übernehme. Es liegt nachweisslich an dem 2. make
 

DogaShell

Newbie
Bluevelvet64 schrieb:
ich habe auf meinem Notebook auf zwei Partitionen je das gleiche Suse 10.3

1 System ist Produktiv 1 System ist zum Testen.

Ich habe gestern auf dem Testsystem den Kernel zu ändern versucht.

Nachdem es beim 2. Mal nicht ging, habe ich es dann auf dem Produktivsystem versucht. Auch hier ging es beim ersten Versuch. Ich konnte also den Kernel ändern. Nun habe ich auf dem Testsystem Suse neu installiert. Und nun ging auch hier der Kernelbau. Ich habe dann nochmal die Sourcen deinstalliert und wieder installiert und nun ging der make befehl wieder nicht. Also bei jedem 1. Mal kann ich den Kernel neu kompielieren, bei jedem 2. Mal kommt die Fehlermeldung.

Also ist die Vorgehensweise ok und auch die Dateien die ich übernehme. Es liegt nachweisslich an dem 2. make

Wie die Vorposter schon geschrieben haben muss es beim zweiten mal klappen, wenn das erste mal geklappt hat.

Mach doch bitte mal ein "make 1>>make.log 2>&1" von beiden Läufen (wird angehängt) und stelle sie irgendwo ins Internet zum anschauen. :)
 
OP
B

Bluevelvet64

Hacker
Mache ich nachher mal.

Aber wie gesagt, so wie beschrieben lief es ab. Und das reproduzierbar. Ich ging auch davon aus, das wenn das 1. make geht das 2. make auch gehen muss. Aber in diesem Fall ist es eben anders.
 

Gimpel

Guru
Das ist dann tatsächlich höchst kurios.

Funktioniert es ein zweites mal wenn du vorher ein make clean, bzw sogar ein make mrproper ausführst? Letzteres gefolgt von einem make cloneconfig
 
Oben