Archiv verlassen und diese Seite im Standarddesign anzeigen : Debian Lenny nach Kernelupdate auf 2.6.26-2-686 Decoderproblem
Hallo
Habe endlich mal mein etch auf lenny geupdatet.
Nachdem der alte decoder nicht mehr lief, habe ich die neuste statisch verlinkte Version otrdecoder-bin-linux-static-v518(2).tar.bz2 runtergeladen und installiert.
Den alten habe ich gelöscht.
Der otrdecoder-gui hängt mit 100%CPU und tut garnix, bis ich den Prozess kille.
Der Kommandozeilendecoder bringt simpel Speicherzugriffsfehler!
Nun habe ich die Aufnahmen mit dem alten system (etch) geladen, aber das dürfte wohl eher nebensächlich sein.
Ist es bekannt, dass unter Lenny der Decoder nicht mehr läuft? Gibt es eine Lösung dafür?
Es währe schade, wenn nicht. Ich habe nur diesen einen PC mit diesem einen OS (Debian) und mag deshalb auch nicht auf Bunti oder so umsteigen.
Windows kommt ohnehin nicht in Frage zumahl ich davon auch keine CD erwerben will.
Danke für die Hilfe
Schade, dass ich nichtmal eine Antwort bekomme.
Ich war gern hier, aber wenn ich nicht mehr decodieren kann, hat das keinen Sinn mehr.
Ich würde ja auch gern helfen, das Problem mit zu lösen, aber ohne Quellcodeinfos kann ich mich nichtmal bemühen, das für Debian Lenny zu kompilieren.
Gibt es hier wirklich keinen, der Debian verwendet und von seinen Erfahrungen berichten kann?
So werde ich vorerst meinen Premiumaccount nicht verlängern.
Du bekommst keine Antwort, weil keiner bei deinem Problem helfen kann. Du benutzt scheinbar ein exotisches Betriebssystem und ich schätze mal es ist für den Programmierer des Dekoders zeitaufwendig für jedes x-beliebige OS einen Dekoder bereitzustellen. Wäre es da nicht einfacher das Betriebssystem zu wechseln ?
Debian ist die Basis für den ganzen Buntu Hype. Also alles andere als exotisch.
Wahrscheinlich verbreiteter als MAC.
Also warum sollte ich wegen einer Anwendung das OS wechseln? Zumal es im Falle M$ oder MAC mit nicht unerheblichen Kosten verbunden ist.
Wie ich andeutete. wär ich bereit das Problem mit zu lösen, aber mit closed Source ist das nicht möglich.
So bleibtwohl nur, mir andere Alternativen zu suchen.
Bis Debian etch lief es ja noch. Aber da ist seit Februar 2009 veraltet!
War nett mit Euch tschau, denn so nützt es mir nichts mehr.
Ist es bekannt, dass unter Lenny der Decoder nicht mehr läuft? Gibt es eine Lösung dafür?
Es währe schade, wenn nicht. Ich habe nur diesen einen PC mit diesem einen OS (Debian) und mag deshalb auch nicht auf Bunti oder so umsteigen.
Windows kommt ohnehin nicht in Frage zumahl ich davon auch keine CD erwerben will.
Was dein Problem ist weiß ich nicht, aber ich kann dir versichern das es absolut nichts mit Lenny oder dem Kernel zu tun hat, das läuft hier seit mindestens einem ¾Jahr problemlos. ;)
Du bekommst keine Antwort, weil keiner bei deinem Problem helfen kann. Du benutzt scheinbar ein exotisches Betriebssystem und ich schätze mal es ist für den Programmierer des Dekoders zeitaufwendig für jedes x-beliebige OS einen Dekoder bereitzustellen. Wäre es da nicht einfacher das Betriebssystem zu wechseln ?
Sorry DiVip, aber wenn du keine Ahnung hast um was es geht und was Debian ist wäre es bessser nicht zu antworten. So was von einem Moderator ist wenig hilfreich.;)
Es werden seit Jahren Decoder für Linux angeboten, die werden sogar auf einem debianbasierten System gebaut.
Sorry DiVip, aber wenn du keine Ahnung hast um was es geht und was Debian ist wäre es bessser nicht zu antworten.
Wolle_1 wollte eine Antwort ;) und meine Antwort bezog sich auf seine Vermutung, das der Fehler im Zusammenhang mit dem OS steht. Weshalb er ja gerne die Sources haben möchte, um den Decoder zu kompilieren. Die Sources bekommt er aber nicht und wie ich schon sagte, OTR wird eben nicht für jede OS-Variante den Decoder komplieren oder testen können.
Mit dem OS-Wechsel bezog ich mich nicht unbedingt auf Win oder Mac, sondern auch eine der anderen Linuxvarianten, denn mit seiner alten Version lief es ja.
Das der Fehler womöglich woanders ist wieder eine andere Geschichte, aber wenn jeder hier nur antworten würde, weil er 100% die Lösung kennt, dann hätten so manche Problem-Threads hier nur 2 Beiträge. :)
SGE danke für den Hinweis, dass es unter Lenny laufen müsste.
Da weiß ich doch schonmal, dass ich den Fehler woanders suchen muss.
Auf was ist denn bei dir /usr/bin/python verlinkt? Bei mir auf die Verrsion python.2.5
Werde es mal mit der 2.4-er Version versuchen
Gruß wolle_1
cyberwolf
08.07.2009, 13:04
SGE danke für den Hinweis, dass es unter Lenny laufen müsste.
Da weiß ich doch schonmal, dass ich den Fehler woanders suchen muss.
Auf was ist denn bei dir /usr/bin/python verlinkt? Bei mir auf die Verrsion python.2.5
Werde es mal mit der 2.4-er Version versuchen
Gruß wolle_1
Also bei mir läuft die GUI mit python2.6 einwandfrei (bis auf die DeprecationWarning, aber die hat für mich grad keine hohe Priorität, zudem ist die GUI ja eh open-source;-)).
Startet denn der Kommandozeilendekoder überhaupt nicht? Sprich kommt sofort der Segfault? Oder kann er zumindest einen Teil dessen, was er tun soll, machen? Funktioniert die Hilfeseite mit der Option -h? Oder kommt da schon der segfault?
Hallo
Also ich habe das strace nicht mit der gui laufen lassen, sondern nur das Kommandozeilentool.
Der Fehler kommt erst, wenn ich mit den entsprechenden Decoderoptionen starte.
Schreibberechtigungsprobleme im Zielverzeichnis ist ausgeschlossen.
Die Version und die Hilfe kann ich mir ausgeben lassen.
Die GUI Version startet, aber nach Dekodieren hängt sie mit 99% CPU und kann nur über kill abgeschossen werden.
Allerdings habe ich schon vorher die GUI selten benutzt, die ist mir nicht so wichtig.
Mit python2.4 oder auch mit python 2.5 geht es nicht.
Mit welchen GCC ist das denn kompiliert?
Aber eigentlich ist das doch egal, da es eh die statisch verlinkte Version ist, die ich nutze.
Danke schonmal für Deine Bemühungen.
cyberwolf
08.07.2009, 17:30
Hallo
Also ich habe das strace nicht mit der gui laufen lassen, sondern nur das Kommandozeilentool.
Der Fehler kommt erst, wenn ich mit den entsprechenden Decoderoptionen starte.
Schreibberechtigungsprobleme im Zielverzeichnis ist ausgeschlossen.
Die Version und die Hilfe kann ich mir ausgeben lassen.
Mit Decoderoptionen meinst du jegliche Parameter, die sich auf die Dekodierung beziehen? Also inputfile, outputdirectory, email, password,...
Also fängt er praktisch noch gar nichts an zu machen. Es kommt also außer Segfault überhaupt kein Output?
Die GUI Version startet, aber nach Dekodieren hängt sie mit 99% CPU und kann nur über kill abgeschossen werden.
Allerdings habe ich schon vorher die GUI selten benutzt, die ist mir nicht so wichtig.
Naja, dass die GUI hängen bleibt, wenn der Kommandozeilendekoder einen Segfault hat ist ja klar. Das berücksichtigt die GUI leider nicht. Aber auf die GUI habe ich eben auch nicht so viel Wert gelegt;-).
Mit python2.4 oder auch mit python 2.5 geht es nicht.
Mit welchen GCC ist das denn kompiliert? Aber eigentlich ist das doch egal, da es eh die statisch verlinkte Version ist, die ich nutze.
Weiß nicht mehr genau. Derzeit läuft hier GCC 4.3.3. Aber das ist schon eine Weile her, als ich den Dekoder gebaut habe. Das einzige Problem, was es manchmal mit der statischen Version geben kann, ist dass er sich nicht zum Server verbinden kann, weil er den Domainnamen nicht auflösen kann. Da muss irgendwie dieselbe Version von libnspr oder wie die lib hieß, wo gethostbyname, getprotobyname und getservbyname drin enthalten sind, auf dem Rechner laufen, wie auf dem, auf dem der Dekoder kompiliert wurde.
Mit Decoderoptionen meinst du jegliche Parameter, die sich auf die Dekodierung beziehen? Also inputfile, outputdirectory, email, password,...
Also fängt er praktisch noch gar nichts an zu machen. Es kommt also außer Segfault überhaupt kein Output?
Danke für deine Bemühungen.
Ja das meine ich damit.
Naja, dass die GUI hängen bleibt, wenn der Kommandozeilendekoder einen Segfault hat ist ja klar. Das berücksichtigt die GUI leider nicht. Aber auf die GUI habe ich eben auch nicht so viel Wert gelegt;-).
Das ist auch nicht so wichtig. ;)
Weiß nicht mehr genau. Derzeit läuft hier GCC 4.3.3. Aber das ist schon eine Weile her, als ich den Dekoder gebaut habe. Das einzige Problem, was es manchmal mit der statischen Version geben kann, ist dass er sich nicht zum Server verbinden kann, weil er den Domainnamen nicht auflösen kann. Da muss irgendwie dieselbe Version von libnspr oder wie die lib hieß, wo gethostbyname, getprotobyname und getservbyname drin enthalten sind, auf dem Rechner laufen, wie auf dem, auf dem der Dekoder kompiliert wurde.
Aber es kommt IMHO garnicht erst zum Versuch eine Verbindung aufzubauen.
Und GCC 4.3.3 läuft hier auch.
libnspr ist die default von debian stable also v 4
Was mich wundert ist halt nur, dass es hier bei jemanden auf Lenny zu laufen scheint.
Ich habe ein sauberes stable hier vorliegen, also nix mit fremden (testing) versionen oder so.
Gruß Wolle_1
Das python wird sowieso nur für die GUI benutzt, die startet ja auch bei dir. Daran hängt es auf alle Fälle nicht.
Sagt 'ldd otrdecoder' irgendwas auffälliges?
Das das an der libnspr liegt kann ich mir nicht vorstellen, hier tut es ja auch in lenny. Du sagts die GUI-version hängt *nach* dem Dekodieren? Also decodiert er doch was, oder wie?
Vielleicht solltest du mal den ganzen strace-Output posten, eventuell entdeckt man ja was auffälliges.
Auf was steht dein gcc?
Hier
ls -al /usr/bin/gcc
lrwxrwxrwx 1 root root 7 10. Okt 2008 /usr/bin/gcc -> gcc-4.3
monarc99
08.07.2009, 19:37
Wenn ldd und strace nix bringen sollten:
Wenn im Thema schon steht: Nach Kernelupdate.
Welchen Kernel verwendest du denn? Schon länger her, dass ich mich mit Debian rumgeschlagen habe, aber da gabs doch etliche verschiedene Kernelversionen zur Auswahl. Auch etliche mit Security-Patches. Aktuell ist 2.6.30.1, vielleicht gibts eh eine neuere Version.
mfg,
Monarc
Hallo SGE
ldd macht ja bei der statisch verlinkten Version keinen Sinn.
Alle libs werden ja selbst mitgebracht.
Wie ich schon sagte, es kommt nicht zum Decodieren.
Die GUI hängt in einer Endlosschleife einer read Funktion, wo scheinbar ein Parameter leer ist. (lt. strace)
Habe die Kommandozeile mal mit extra falschen Logindaten benutzt, was zum gleichen Abbruch führt. Also kommt es garnicht bis dahin.
dd macht ja bei der statisch verlinkten Version keinen Sinn.
Hast du auch wieder recht ;)
Wie ich schon sagte, es kommt nicht zum Decodieren.
Du schriebst hier
Die GUI Version startet, aber nach Dekodieren hängt sie
deshalb fragte ich
Mit nach Decodieren meinte ich doch nur den Klick auf gleichnamigen Button.
Ich besorg mir morgen mal eine LiveCd von BuntuKlicki und beobachte, ob es damit geht.
Hab nämlich rausgefunden, dass auch die statisch verlinkte Version mit Ubuntu erstellt wurde. :)
Ich finde es aber nett, dass es doch Einige gibt die sich um mein Problem mit meinem exotischen OS kümmern.:cool:
Gute Nacht
wolle_1
cyberwolf
09.07.2009, 08:28
Die GUI hängt in einer Endlosschleife einer read Funktion, wo scheinbar ein Parameter leer ist. (lt. strace)
Die GUI ist open source. Da musst du nicht extra strace zu anschmeißen;-).
cyberwolf
09.07.2009, 08:38
Mit nach Decodieren meinte ich doch nur den Klick auf gleichnamigen Button.
Ich besorg mir morgen mal eine LiveCd von BuntuKlicki und beobachte, ob es damit geht.
Hab nämlich rausgefunden, dass auch die statisch verlinkte Version mit Ubuntu erstellt wurde. :)
Ich finde es aber nett, dass es doch Einige gibt die sich um mein Problem mit meinem exotischen OS kümmern.:cool:
Gute Nacht
wolle_1
Hast du denn auch mal die dynamisch gelinkte Version getestet? So viele libs verwendet der otrdecoder ja nun nicht. Und wie du richtig sagst ist Ubuntu ja auch nur ein Debian Derivat;-).
Ich habe z.B. Ubuntu Jaunty hier laufen, verwende aber immer noch den otrdecoder, den ich dynamisch gelinkt unter Ubuntu Hardy gebaut habe. Das ist zwar dann immer noch Ubuntu, aber da ändert sich ja auch immer wieder einiges.
wolle, nimm mal den dynamisch gelinkten, ich erzähl die ganze Zeit völligen Blödsinn.:o
Man sollte doch mal in Threads suchen in denen man vor einem Jahr geantwortet hat
http://otrforum.com/showthread.php?t=43488:rolleyes:
Ich hab nämlich doch auch den dynamischen am laufen, deswegen hab ich natürlich auch Output bei ldd. Mich hat irritiert das ich hier das tgz des statischen auf der Platte habe, deswegen war ich der irrigen Ansicht der leif hier auch.
Mannnoman, Wald, Bäume und so...Sorry;)
Irgendwo wußte ich im Hinterkopf noch das sich was entscheidendes von etch auf lenny geändert hatte, aber war zu lange her bei mir....
Zu dem ld.so.nohwcap hab ich nur das gefunden
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409018
Ich würde mir an deiner Stelle mal einen 24er-Kernel dazu installieren und dann testen ob es mit dem in deinem System funktioniert. Vielleicht ist ja doch irgendeine Einstellung dort schuld? Ich habe einen selbstgebackenen 2.26, von daher nicht so leicht vergleichbar. Aber das fertige Debian-Image hat ja eigentlich schon alles wesentliche einkompiliert....
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.