[gelöst][yaVDR 0.5] seltsames Verhalten nach reboot (dbus-Fehler und DisplayLink-Device)

    Hallo zusammen,


    seit (gefühlt) ein paar Tagen habe ich ein Problem nach dem Reboot meines Systems (siehe Sig.). Der VDR startet nicht sauber bzw. gar nicht und im syslog finden sich folgende Einträge:


    Code
    Feb  6 13:36:06 htpc vdr: [2495] create server
Feb  6 13:36:06 htpc vdr: [2495] starting plugin: channellists
Feb  6 13:36:06 htpc vdr: [2495] starting plugin: dynamite
Feb  6 13:36:06 htpc vdr: [2495] dynamite: startup channel is 1
Feb  6 13:36:06 htpc vdr: [2495] setting current skin to "anthra_1920_FSE"
Feb  6 13:36:06 htpc vdr: [2495] loading /var/lib/vdr/themes/anthra_1920_FSE-default.theme
Feb  6 13:36:06 htpc vdr: [2495] ERROR (lirc.c,48): /var/run/lirc/lircd: Datei oder Verzeichnis nicht gefunden
Feb  6 13:36:06 htpc vdr: [2495] remote control graphtft-fe - keys known
Feb  6 13:36:06 htpc vdr: [2495] ERROR: remote control LIRC not ready!
Feb  6 13:36:07 htpc kernel: [   53.499935] udlfb: /dev/fb1 FB_BLANK mode 0 --> 0



    Was passiert da? Wird evtl. /var/run bzw. /run nicht sauber oder zu spät gemountet? Nach mehreren Reboots/Resets passt es dann irgendwann wieder und das System startet sauber.


    Cheers,
    Ole

    2 Mal editiert, zuletzt von OleS ()

    Hummm...


    anscheinend ist's ein Timingproblem im upstart. Die letzte Änderung am System war die
    Inbetriebnahme eines DisplayLink-USB-Monitors, wie hier beschrieben. Ich habe nun
    die entsprechenden upstart-Scripte entfernt und das System lässt sich ohne Probleme
    rebooten - leider ohne Display. Dann mal fix an's Debuggen.


    Cheers,
    Ole

    Hummm zum Zweiten...ich liebe diese Monologe!


    Hier ist das Timingproblem:


    Nehme ich

    Code
    exec /usr/bin/x2x -south -from :1 -to :2


    aus der /etc/init/openbox-tools-DL.conf, kann ich das System rebooten wie ich will - es startet sauber durch.


    Cheers,
    Ole

    Hallo mini73,


    keine Ahnung, wo die Windows-Zeilenumbrüche herkommen. Die Scripte und Konfigurationsdateien haben diese nicht und
    ich habe sie nur mit Linux-Bordmitteln (vi, usw.) bearbeitet. Sicherheitshalber habe ich aber alles mal durch dos2unix gejagt.


    Cheers,
    Ole

    Einmal editiert, zuletzt von OleS ()

    Moin,
    dos2unix hat keine Änderung in Bezug auf die Zeilenumbrüche gemacht, allerdings ist das reboot-Problem auch noch nicht wieder aufgetaucht und
    das hängt dann wohl doch mit einer anderen Änderung im System zusammen. Ich hatte vor etlicher Zeit, genauer gesagt nach Umstellung auf SSD,
    /tmp und /var/tmp in ein tmpfs gemountet, um Schreib-/Lesezugriffe der SSD zu minimeren. :D


    Wie's scheint, ist genau das etwas, was beim Bootvorgang zu Timingproblemen führen kann, denn momentan läuft das System wieder mit /tmp und
    /var/tmp auf SSD und der VDR startet sauber (auch das DisplayLink).


    Die Meldung in /var/log/upstart/openbox-tools-DL rührt wohl daher, dass mein TV zum Bootvorgang nicht an war/ist und daher x2x nicht auf das
    Display :1 zugreifen kann. Sollte ich mich irren, wäre ich über eine Richtigstellung dankbar.


    Cheers,
    Ole

    Zitat von OleS

    Die Meldung in /var/log/upstart/openbox-tools-DL rührt wohl daher, dass mein TV zum Bootvorgang nicht an war/ist und daher x2x nicht auf das
    Display :1 zugreifen kann. Sollte ich mich irren, wäre ich über eine Richtigstellung dankbar.


    Das sollte aber kein Problem sein solange der entsprechende X-Server läuft. Wenn du im Webfrontend die EDID-Informationen abspeicherst sollte der X-Server auch hochkommen, wenn der Fernseher nicht an ist.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Primäres Display im WFE ist :1.0 Panasonic TV, DFP-1, modeline: 1920x1080 50 Hz, falls du das meinst.
    Die X-Server laufen auch:

    Code
    root@htpc:/var/log/upstart# ps -ef | grep X
root      1293  1285  0 10:32 tty7     00:00:01 X :1 vt7
root      1444     1  0 10:32 ?        00:00:01 /usr/bin/X :2 -audit 0 -novtswitch -sharevts vt7


    Eigentlich geht jetzt auch alles wunderbar, mich hatte die Meldung bei meiner Suche nur in die falsche Richtung gebracht und wenn ich
    schon dabei bin, die Kiste zu debuggen... :) Sobald ich wieder Zugriff auf die Tastatur habe, werde mal testen ob x2x das macht, was es soll.


    Cheers,
    Ole

    Einmal editiert, zuletzt von OleS ()

    Nachdem ich heute schon wieder Bootprobleme (kein Bild am TV, DisplayLink-Device zeigt nur yaVDR-Logo) hatte, musste
    ich mich zwecks Ausrichtung des Haussegens mal wieder an diese Thema machen. Dabei fiel mir auf, dass das vdr-frontend
    mal vor und mal nach dem DisplayLink-Geraffel gestartet wurde...hmmmm.


    Schnell mal eine kleine Anpassung an /etc/init/vdr-frontend.conf gemacht (stopped openbox-tools in stopped openbox-tools-DL geändert):

    Code
    root@htpc:~# cp --parents -p /usr/share/yavdr/templates/etc/init/vdr-frontend.conf/10_start_stop /etc/yavdr/templates_custom/.


    /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/10_start_stop:

    Code
    start on started vdr or stopped openbox-tools-DL or started sound-device \
         or vdr-frontend-restart
stop on stopping vdr or stopping openbox


    Code
    root@htpc:~# process-template /etc/init/vdr-frontend.conf


    Mal sehen, ob's das jetzt bringt. Sollte doch...


    Cheers,
    Ole

    Es ist zum Haareraufen...die Kiste hängt immer noch sporadisch. Ich habe jetzt wieder den Urzustand hergestellt.
    Interpretiere ich richtig, dass der vdr an sich nicht startet?

    Code
    start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1


    Und hier mal ein Auszug vom syslog:


    Der letzte Eintrag stammt aller Wahrscheinlichkeit nach von meinem kill auf den vdr-Prozess.
    Ausschlaggebend ist wohl eher der Eintrag

    Code
    Feb 19 06:36:35 htpc kernel: [   14.276907] init: vdr main process (1185) killed by PIPE signal


    Vieleicht hat noch jemand eine Idee, in welche Richtung ich schauen kann?


    Cheers,
    Ole

    Hallo zusammen,
    habe gerade --> hier <--einen evtl. zielführenden Hinweis erhalten - bin ja mittlerweile, was dieses spezielle Thema angeht, vorsichtig geworden. :D


    Ich habe (hatte) folgendes in der order.conf:

    Code
    graphtft
-graphlcd
-dvbhddevice
-dvbsddevice
-pvr350
-dummydevice
-xine
-xineliboutput
*dynamite


    Nachdem ich den graphtft-Eintrag gelöscht habe, konnte ich das System bisher immer (~15x) sauber booten. Also abwarten...


    Cheers,
    Ole


    PS: Ich betrachte das Thema als gelöst, da ich nach der oben genannten Änderung bisher immer sauber booten konnte.

    Einmal editiert, zuletzt von OleS ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden