Beiträge von Flachzange

Ich habe gerade die gleiche Erfahrung gemacht und bin auf Deinen Thread gestoßen. Einige Plugins liefen nicht mehr nach dem Update auf 20.0. u.a. VNSI. Nach einem Neustart nochmal apt cache aktualisiert und merkwürdigerweise stand nochmal eine Update zur Verfügung . Nach der erneuten Installation war dann auch VNSI wieder da in Version: 6:20.4.0-6~jammy

Vielen Dank euch. Damit geht es weiter. Jetzt braucht es nur noch einen Patch für den 3.13.

Ich bin wegen eines bugs aktuell auf Kernel 3.13 angewiesen. Bei mir kommt es aber gar nicht zu irgendwelchen Compiler-Fehlern, sondern es wird einfach nur ein Modul gebaut: cx8802.ko. Sonst passiert nichts. Keine Fehler oder sonstiges. Woran liegt das? In menuconfig ist alles wie immer ausgewählt.

Mit "on static-network-up" funktioniert es wie erwartet

Zitat von mini73

Ah, bei raring ist das wohl kein Task mehr, das erklärt einiges. Dann ist "on static-network-up" korrekt.

Und wieder etwas gelernt gerlernt. Danke. Ich probiere es aus, sobald ich wieder Zugang habe. Heißt das im Umkehrschluss, dass networking unter raring durchläuft, also started bleibt?

Die networking.conf sieht etwas anders aus als bei precise. Ich habe mich jetzt blöderweise durch eine Änderung selbst ausgesperrt und komme bis heute Abend erstmal nicht mehr ans System.

Zitat von mini73

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.

Jetzt habe ich doch noch mal nachgeschaut. Ich war zwar der festen Überzeugung, dass es unstable-yavdr ist , aber du hattest Recht, tatsächlich wird unstable-vdr geladen.

Zitat von steffen_b

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

Zitat von hepi

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.

Zitat von mini73

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

Zitat von mini73

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:

# The loopback network interface
auto lo
iface lo inet loopback


# The primary network interface
auto eth0
iface eth0 inet dhcp

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:18:a6:c4:f6
          inet addr:192.168.5.35  Bcast:192.168.5.255  Mask:255.255.255.0
          inet6 addr: fe80::230:18ff:fea6:c4f6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:166 errors:0 dropped:0 overruns:0 frame:0
          TX packets:230 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:28844 (28.8 KB)  TX bytes:36714 (36.7 KB)
          Interrupt:20 Memory:f7d00000-f7d20000


lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1664 (1.6 KB)  TX bytes:1664 (1.6 KB)

Zitat von steffen_b

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

# sudo initctl list | grep network
network-interface (lo) start/running
network-interface (eth0) start/running
network-interface-security (network-interface/eth0) start/running
network-interface-security (network-interface/lo) start/running
network-interface-security (networking) start/running
networking start/running
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.

Ich schließe mich der Frage an. Bei mir treten auch alle paar Sekunden extrem viele trigger auf

Zitat von 3PO

Vermutlich liegt das an dem komischen XEN, evtl. werden die DVB Devices nicht durchgereicht?

Lässt sich das nicht mit einem einfachen "lspci" feststellen?

Stand schon mal woanders hier im Forum. Du musst die Datei v4l/Kconfig manuell ändern in Zeile 4900. Die Einrückungen stimmen nicht. Einfach etwas mehr einrücken und dann passts

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.

Ich hatte das selbe Problem nach einen hg update. Auch das distclean hat hier nicht geholfen. Erst ein neues hg clone erbrachte den nötigen Erfolg

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

Zitat von Flachzange

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.