verfaßt von baeuchlein, 10.01.2014, 00:46:12
(editiert von baeuchlein, 10.01.2014, 00:55:52)
> Das letzte Verzeichnis (/linux) gibts nicht. Spinn ich? ich hab doch die
> Sourcen installiert...
Ich fürchte, das Skript und überhaupt das (alte) gspca-Zeugs kann man vergessen. 
Das Skript will, dass die Kernel-Sources im Verzeichnis /lib/modules/$KERNELVER/build installiert sind, wobei $KERNELVER die Version des Kernels ist. Die Version des gerade laufenden Kernels wird dafür genommen und mit dem Befehl "uname -r" ermittelt. Schon das könnte unter etwas ungewöhnlichen Umständen ein Problem darstellen.
Dummerweise gehören auch in /lib/modules und dessen Unterverzeichnisse meines Wissens gar keine Kernel-Sources (Kernel-Quellen) hinein. Vielmehr sollen da "Module" landen (das ist sowas Ähnliches wie ein Treiber unter Windows). Warum guckt das Skript bloß ausgerechnet dort nach Sources? 
Oder tut es das gar nicht? Ein Verzeichnis für Module müsste das Skript vermutlich vorfinden, da es (soweit ich die kaum vorhandenen Erklärungen richtig verstanden habe) selber ein solches Modul erzeugen will/soll. Falls es also keine Kernel-Sources, sondern ein vorhandenes Modul-Verzeichnis sucht, würde das schon Sinn ergeben. Wobei das Modul-Verzeichnis vermutlich erst "entsteht", wenn man tatsächlich mal einen Kernel mit Modul-Unterstützung kompiliert. Jedoch gibt es auch Möglichkeiten, "Treiber" unter Linux nicht als Module zu "bauen"...
Ich hab' das Skript jetzt auch mal bei mir loslegen lassen, unter Debil Debian Linux 5. Auch da komme ich auf genau dieselben Probleme wie Du. Ich lasse gerade aber zur Sicherheit nochmal einen Kernel compilieren, der auch Module verwendet, vielleicht klappt's dann doch noch.
Es sieht für mich aber schon nach einem kaum getesteten Skript aus... Und dann noch die bescheuerte Idee, die zuerst auftretenden Fehlermeldungen zunächst zu unterdrücken, danach die Folge-Fehler aufzulisten und erst ganz am Schluss die Fehlermeldungen von "davor", welche den eigentlich alles auslösenden Fehler andeuten, mal hinzuschreiben. Das ist ein hervorragender Kraut-und-Rüben-Saustall. 
Letzter Sargnagel: Das ganze Zeugs ist von ca. 2007. Ist Deine Webcam so alt? Wenn nicht, warum sollte dieses Zeug dann Deine neuere Hardware erkennen? Das ginge ja nur, wenn der Programmierer 'ne Glaskugel beim Programmieren zur Hand gehabt hätte. 
Ich glaube, das ganze Zeugs war dazu da, um vor 5-6 Jahren mal Unterstützung für Kameras zu liefern, welche es damals noch nicht im Linux-Kernel gab. Schon Kernel 2.6 scheint, den Kommentaren auf der von Dir verlinkten Webseite zufolge, nicht mehr so ganz mit dem Zeugs zusammenzuarbeiten. Ob Kernel 3.8.x das wohl tut? Und ob die Linux-Macher nicht inzwischen im Kernel bereits Support für solche Hardware eingebaut haben?
Hast Du eigentlich die Kernel-Quellen (Sources) nur installiert, oder auch mal mit denen einen neuen Kernel compiliert? Erst dadurch wird ein neuer Kernel überhaupt nutzbar. Ansonsten benutzt Du ja immer noch einen 08/15-Kernel, den der Distributionshersteller mal zusammengestellt hat und der beim Installieren des Linux' mit installiert wurde. Und ob der Hersteller beim Compilieren dieses Kernels Unterstützung für alle möglichen Webcams eingebaut hat, das wage ich zu bezweifeln.
Womöglich wäre die Abkehr von diesen "gspca-Sachen" und der Versuch, einen eigenen Kernel zu compilieren, eher der richtige Ansatz in diesem Fall. Oder spricht da von Dir aus was dagegen?
P.S.: Schon Kernel 2.6.30.5 hat gspca und eingebaute Unterstützung für eine "Logitech QuickCam E2500" eingebaut. Ich nehm' an, Deine "Logitech E2500" (laut andinet) ist dieselbe.
Kernel 3.8.2 hat diesen Support auch. Vergiß' also dieses Skript-Zeugs und compiliere einen Kernel aus den installierten Sources, dann hast Du auf jeden Fall aktuellere Treiber.
gesamter Thread: