Posts by Flachzange

    Danke aber, dass du mich daran erinnerst.
    Flachzange : hast du dbus2vdr aktiv? Wenn ja, mit welchen Parametern (/etc/vdr/plugins/plugin.dbus2vdr.conf)?


    Wenn dbus2vdr aktiv ist und mit "--upstart" gestartet wird, dann muss "expect stop" in den Job, wenn nicht aktiv oder ohne "--upstart", dann darf da kein "expect stop" drin stehen.


    Den Hinweis hatte ich in der conf Datei gelesen. dbus2vdr habe ich nicht. Aber wie gesagt. Das vdr script wird regulär ausgeführt, wenn ich am Anfang "start on started networking" setze. Das networking noch läuft ist wohl das eigentliche Problem.

    Hintergrund: /etc/init/networking macht ein ifup -a - was alle interfaces die in /etc/network/interfaces konfiguriert sind hochbringt.
    in /etc/network/if-up.d/upstart wird beim letzten Gerät dann ein initctl emit --no-wait static-network-up gemacht. Also ist wenn das signal static-network-up da ist oder der Task networking gestoppt ist das Netzwerk fertig. Ich vermute das es nicht das besagte event ist was den Unterschied gemacht hat ... wenn man nichts anderes konfiguriert hat, sollte zumindest lo da drin stehen.


    Müsste networking dann nicht stoppen, wenn ich manell "initctl emit --no-wait static-network-up" mache? Das tut es nämlich nicht

    Da gab es ein Missverständnis bei mir: Du schreibst im Thread-Titel "yavdr unstable". Es gibt ein Launchpad-PPA namens unstable-yavdr. Ich dachte, das meinst Du in diesem Thread. Du meinst aber das PPA unstable-vdr. Das habe ich falsch verstanden.


    Okay, sorry für die Verwirrung. Tatsächlich habe ich das unstable-yavdr eingebunden, aber ich beziehe mich natürlich hier nur auf den vdr.

    hepi
    Nicht hilfreich!


    @Rest
    Danke für eure Antworten.


    Wie sieht denn deine /etc/default/vdr aus? Ist da der Job aktiviert?


    Ja, sonst würde das Script auch bei manuellem Aufruf nicht starten


    Was hast du an dem PC für Netzwerkschnittstellen? Ist da vielleicht irgendwas anders (statisch) konfiguriert, so dass "networking" vielleicht nicht richtig arbeitet?


    /etc/network/interfaces:

    Code
    1. # The loopback network interface
    2. auto lo
    3. iface lo inet loopback
    4. # The primary network interface
    5. auto eth0
    6. iface eth0 inet dhcp



    Flachzange :
    stopped networking ist schon ganz richtig - wie sieht denn bei dir status networking aus ?


    Code
    1. # sudo initctl list | grep network
    2. network-interface (lo) start/running
    3. network-interface (eth0) start/running
    4. network-interface-security (network-interface/eth0) start/running
    5. network-interface-security (network-interface/lo) start/running
    6. network-interface-security (networking) start/running
    7. networking start/running
    8. network-interface-container stop/waiting


    Networking läuft also weiter. Das ist ja auch der Grund, warum meine Änderung auf "started networking" funktioniert. Ich werden also mal bei "/etc/network/if-up.d/upstart" weiterschauen

    Ich habe mir in einer Raring Testinstallation den vdr aus dem yavdr unstable repo installiert. Beim Booten wurde vdr jedoch nicht gestartet. Das Upstart Script selbst funktionierte. Nachdem ich im Script "start on [...] stopped networking" auf "started networking" geändert habe, läuft es auch beim Booten hoch. Jetzt meine Frage: Warum steht da "stopped networking". Rein intuitiv macht das für mich nicht so viel Sinn.

    dvbdvb


    Typically, this due to incompatible/old/other modules still being in in your /lib/modules directories. Make sure you don't have duplicate modules in this directory. For example when I do a "make install" some modules are put into /lib/modules/<version>/kernel/drivers/linux/drivers, and I manually have to move such modules to /lib/modules/<version>/kernel/drivers.

    Danke für eure Antworten. Auch wenn sie nicht direkt zielführend waren, haben sie mich in die richtige Richtung geführt.


    Natürlich lief bei mir das fintek-cir Modul. Das nuvoton tuts ja nur mit Intel. Den Thread habe ich verwendet, weil hier die CIR-Experten mitlesen und da sich die beiden Treiber nicht so sehr unterscheiden kann es ja durchaus sein, dass die geschilderten Symptome bekannt sind.


    Letztendlich scheint es aber ein Anfängerfehler gewesen zu sein. Ein simples depmod -a brachte die Lösung. Bei mir kommt fintek-cir aus media_build_experimental . Da ich die Module aber noch manuell kopiert hatte, waren die Abhängigkeiten kaputt, insbesondere die zu rc-core. Ich vermute, dass beim Booten mal rc-core und mal fintek-cir zuerst geladen wurde. In ersterem Fall gibt es keine Problem, in zweitem eine Kernel Panic, die ich aber nie gesehen habe. Das habe ich erst beim manuellen Laden der Module festgestellt.


    Edit: Das war's noch nicht. Modul war noch auf der blacklist

    Puh, also irgendwie ist das jetzt noch ein Showstopper. Linux bootet einfach nicht (oder nur sehr selten) sobald der Receiver dranhängt. Völlig unabhängig vom LCD-TV und ob ich den Receiver komplett abdecke oder nicht. Ansonsten funktioniert es. Wake-up, Tasten werden erkannt, XBMC lässt sich bedienen. Ich habe zwar einen TSOP1738, aber mit dem 1238, den ich vorher vom Atric benutzt habe, war es genauso. Das muss doch irgendeinen Grund haben.


    Auch ein halbes Jahr später mit einem anderen Board (Jetway NF9G statt NC9B) und einer neuen Installation mit neuem Kernel (Ubuntu 12.10 mit 3.5 statt 12.04 mit 3.2) habe ich noch keine Lösung für obiges Problem. Ich habe mir jetzt spontan auch noch mal einen zweiten Empfänger gelötet mit anderen Komponenten und nur in der Minimal-Variante mit 3 Bauteilen. Das Fehlerbild bleibt identisch: Linux hängt mit 50% Wahrscheinlichkeit beim Booten ohne Ausgabe oder sonstige Anzeichen. Dabei ist mir aufgefallen, dass dieses Problem auch auftritt, wenn überhaupt kein Empfänger am CIR-Header angeschlossen. Erst das Deaktivieren von CIR im BIOS hilft dauerhaft. Der Chip scheint bei beiden von mir getesteten Boards irgendein Fintek Super IO zu sein.


    Ich bin verzweifelt, wie kann ich die Ursache des Problem herausfinden? Welche Debug-Möglichkeiten habe ich? Linux steigt extrem früh beim Booten aus. so dass ich auch kein syslog oder ähnliches habe.

    Puh, also irgendwie ist das jetzt noch ein Showstopper. Linux bootet einfach nicht (oder nur sehr selten) sobald der Receiver dranhängt. Völlig unabhängig vom LCD-TV und ob ich den Receiver komplett abdecke oder nicht. Ansonsten funktioniert es. Wake-up, Tasten werden erkannt, XBMC lässt sich bedienen. Ich habe zwar einen TSOP1738, aber mit dem 1238, den ich vorher vom Atric benutzt habe, war es genauso. Das muss doch irgendeinen Grund haben.