Beiträge von kolja

  • Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Danke, damit muss ich mal herumspielen. Hat noch den Nachteil, dass Sound-Treiber auch entladen werden. Aber sich nur auf drivers/media/dvb zu beschränken, reicht scheinbar auch nicht.


    Was basename angeht, das braucht man tatsächlich nicht:


    Code
    # DVB-Module ermitteln; Pfad und Extension abtrennen; '-' in '_' umwandeln
modules=$(find /lib/modules/$(uname -r)/kernel/drivers/media -type f|sed "s/\([^/]*\/\)*\([^/]*\)\.ko/\2/g;s/-/_/g")

  • Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Kacke, ist das kompliziert. Eine Lösung für mein System habe ich jetzt natürlich, ich kann die Liste der Module einfach hardcoden, aber ein Patch, der das Problem allgemeingültig löst, scheint alles andere als trivial zu sein. Das Perl-Script von v4l funktioniert übrigens nicht so ohne weiteres, wenn man nur ein Standard-Kernel-Paket installiert hat.

  • Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Ich habe gerade testweise 2.6.25-2-686 (2.6.25-7) gebootet, und damit tritt das Problem bei mir auch nicht mehr auf, aber aus einem ganz einfachen Grund: die Module werden gar nicht mehr neu geladen! (Das sieht man im syslog und mit dmesg, onur, kannst Du das bei Dir bestätigen?) Außerdem glaube ich nun auch verstanden zu haben, worin das Problem bei 2.6.26-1-686 (2.6.26-8) besteht.


    Die Ursache für diesen Unterschied zwischen beiden Kerneln hängt mit der Strategie zusammen, mit der /usr/sbin/runvdr ermittelt, welche Module zu entladen sind, und den unterschiedlichen Abhängigkeiten zwischen den Modulen bei den beiden Kerneln.


    Die Funktion get_modulenames() filter zunächst per awk aus lsmod alle Module aus, die dvb_core nutzen, kehrt deren Reihenfolge um, und fügt der Liste noch dvb_core hinzu. Beim Emergency-Neustart des vdr werden die Module in der so erzeugten Liste der Reihe nach mit rmmod entladen.


    Das führt bei 2.6.25 zu folgendem Effekt:


    Wie man sieht, findet der aus get_modulenames() entnommene Filter nur ein Modul, videobuf_dvb, und wenn dieses und anschließend dvb_core entladen werden soll, passiert gar nichts, weil die Abhängigkeiten nicht korrekt berücksichtigt wurden.


    Mit 2.6.26 sieht der Effekt dank veränderter Abhängigkeiten etwas anders aus:


    Wie man sieht, findet der Filter nun zwar alle relevanten Module, aber auch hier ist die Reihenfolge unbrauchbar, so dass am Ende nur cx88_dvb entladen wird.


    Es sieht so aus, als sei in get_modulenames() implementierte Ansatz nicht ausreichend, um komplexere Abhängigkeiten zwischen den Modulen zu berücksichtigen.


    Vielleicht sollte man auf diesen Automatismus verzichten, und den Leuten, die aus Stabilitätsgründen das Neuladen der Module brauchen, die Möglichkeit anbieten, die richtige Liste von Modulen in der richtigen Reihenfolge in einer Config-Datei einzutragen.


    Oder man schreibt Code, der die Dependencies in lsmod komplett auswertet und eine Liste in der richtigen Reihenfolge erzeugt. Das dürfte aber nicht ganz trivial sein.


    Das Script stammt doch von Tobi, oder? Kann Tobi mal seine Meinung dazu sagen?

  • Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Vorher:


    Code
    server:/# ls -l /dev/dvb/adapter0/
total 0
crw-rw---- 1 root video 212, 4 2008-10-23 22:37 demux0
crw-rw---- 1 root video 212, 5 2008-10-23 22:37 dvr0
crw-rw---- 1 root video 212, 3 2008-10-23 22:37 frontend0
crw-rw---- 1 root video 212, 7 2008-10-23 22:37 net0
server:/# cat /dev/dvb/adapter0/dvr0
^C

    Nachher:


    Code
    server:/# ls -l /dev/dvb/adapter0/
total 0
crw-rw---- 1 root video 212, 4 2008-10-24 22:30 demux0
crw-rw---- 1 root video 212, 5 2008-10-24 22:30 dvr0
crw-rw---- 1 root video 212, 3 2008-10-24 22:30 frontend0
crw-rw---- 1 root video 212, 7 2008-10-24 22:30 net0
server:/# cat /dev/dvb/adapter0/dvr0
cat: /dev/dvb/adapter0/dvr0: No such device


    Sieht aus, wie das Problem, welches Du verlinkt hast.


    Seit wann sollte das denn gefixt sein? Debian lenny ist doch ziemlich dicht am aktuellen 2.6.26er Kernel, oder?


    Ansonsten könnte man vielleicht runvdr dahingehend ändern, dass auch dvb_core neu geladen wird.

  • Verursacht das Neuladen der Kernelmodule durch runvdr Probleme?

    Hi,


    ich habe folgendes Problem beobachtet. Aus irgendwelchen Gründen schiebt der vdr Panik und beendet sich mit einem Exitcode ungleich Null. (Kann sein, dass das mit meinem Recording-Hook zusammenhängt, ist aber für die weiteren Konsequenzen unerheblich.) Das veranlasst runvdr, den Wachhund, erstmal die DVB-Kernelmodule zu entladen und neu zu laden und anschließend den vdr neu zu starten.



    Das ist zwar eine nette Idee, führt aber zumindest bei mir zu Problemen. Sobald der vdr Videodaten aufzeichnen soll, kann er /dev/dvb/adapter0/dvr0 nicht öffnen.



    Dieser Zustand ist nur noch durch einen Neustart des Rechners zu beheben. Man kann den Zustand auch künstlich herbeiführen, indem man den vdr mit kill -9 beendet, denn auch dann lädt runvdr die DVB-Module neu. Wenn der vdr sauber neu gestartet wird, tritt das Problem nicht auf.


    Daher nehme ich an, dass es meinem Kernel irgendwie nicht gut tut, wenn die DVB-Module neu geladen werden, oder zumindest der Zusammenhang mit /dev/dvb/adapter0/dvr0 dadurch verloren geht oder so.


    Ist das Problem bekannt? Kann man runvdr abgewöhnen, die DVB-Module neu zu laden? Ich habe in den Manpages und den Initscripten und Configdateien nichts derartiges gefunden.


    Mein System: Debian lenny mit Stock-Kernel linux-image-2.6.26-1-686 (2.6.26-8), vdr (1.6.0-6ctvdr2) von e-tobi.net, Hauppauge Nova-S-Plus DVB-S.


    Grüße, Kolja.

  • e-tobi's project-x

    Damit man project-x wie gewohnt über das Shell-Script /usr/bin/projectx aufrufen kann, muss man dieses noch so anpassen, dass es auch andere jvm's als sun's verwendet:


  • e-tobi's project-x

    So, ausprobiert. Ich hab' das aktuelle project-x .deb von e-tobi heruntergeladen, in den Metadaten die Dependencies und die Version nach meinen Vorstellungen gepatcht, dieses gepatchte .deb in mein lokales APT-Repository gelegt, und dann wie üblich installiert.


    Mit java-gcj-compat funktioniert headless nicht. Project-X bricht trotz "java.awt.headless=true" nach der Begrüßung und der Kommandozeilenhilfe mit "Gtk-WARNING **: cannot open display" ab. Ob es mit GUI funktionieren würde, weiß ich nicht, da ich keinen X-Server habe. Aber mit openjdk-6-jre funktioniert headless einwandfrei, habe soeben eine Aufnahme des VDR nach TS konvertiert! (Anschauen kann ich das TS allerdings erst heute abend, wenn ich wieder zu Hause bin ...)


    Da default-jre in Debian java-gcj-compat installiert, anstatt openjdk-6-jre wie in Ubuntu, ist mein obiger Vorschlag so nicht brauchbar.


    Aber folgende Abhängigkeiten würden gehen: "openjdk-6-jre | sun-java5-jre | sun-java6-jre", oder flexibler: "openjdk-6-jre | java2-runtime".


    Was noch interessant wäre, ob es auch reicht, wenn man nur openjdk-6-jre-headless installiert. Leider kann ich das nicht testen, weil einige andere Java-Libraries indirekt die Installation der nicht-headless-Variante erzwingen (#500839, #500840).

  • e-tobi's project-x

    Anscheinend glaubt der Ubuntu-Betreuer, dass es geht, denn in hardy hängt project-x direkt von "openjdk-6-jre | ...sun-java..." ab, in intrepid ebenfalls, wenn auch indirekt über "default-jre | java2-runtime". Deswegen auch mein Vorschlag.


    Ausprobiert hab' ich's noch nicht, ich hatte die Hoffnung, es wüsste bereits jemand genaueres dazu.

  • e-tobi's project-x

    Hi Tobi,


    könnte "project-x", zumindest die Variante(n) für sid (und bald lenny), von "default-jre" abhängen, anstatt von "sun-java5-jre | sun-java6-jre"? Noch besser, von "default-jre | default-jre-headless"?


    Grüße,
    Kolja.

  • alles aus einen ordner kopieren mit cp

    Zitat

    Original von lexi
    kannst du noch verraten wie man das dauerhaft speichern kann? die shopt -s ist spätestens nach den reboot wieder "weg"


    Hmm, bei jedem Booten? D.h. Du musst nach jedem Booten den Inhalt von /tmp/ und /log/ erneut wegkopieren? Kannst Du nicht die Netzverzeichnisse nach /tmp/ und /log/ mounten, bevor überhaupt in diese Verzeichnisse geschrieben wird? Irgendwie kann ich auch noch nicht ganz folgen ...


    Wie auch immer - einfach so speichern kann man das nicht, aber es gibt Profil-Skripte, die die Shell zur Initialisierung abarbeitet, da kann man beliebige Befehle eintragen. Es gibt aber mehrere davon, und welches das richtige wäre, hängt davon ab, welche Shell verwendet wird und wie diese aufgerufen wird. Einfacher wäre es, den Aufruf von shopt und cp in ein Skript zu packen, oder direkt in einem Schritt aufzurufen ...


    Code
    shopt -s dotglob; cp ...


    ... oder wie oben erwähnt die Wildcards zu vermeiden, damit shopt gar nicht benötigt wird.

  • alles aus einen ordner kopieren mit cp

    Zitat

    mit cp -rfdp ist das resultat das selbe und bei cp -R /tmp/*.* /cf/tmp" wird gemeckert das es kein ordner ist. (ist natürlich an persönliche struktur angepasst wurden)


    Das Problem sind vermutlich nicht die Schalter, sondern die Form, in der Du Quelle und Ziel angibst. Alles mit "*" wird von der Shell expandiert, so das cp eine Liste von Quellen sieht, und deswegen erwartet, dass das Ziel ein bereits existierendes Verzeichnis ist. Wenn Du nur eine Quelle angibst (also auf "*" verzichtest!) und diese ein Verzeichnis ist, dann wird dessen Inhalt komplett kopiert und das Zielverzeichnis automatisch erzeugt.

  • alles aus einen ordner kopieren mit cp

    Zitat

    Original von fitzefatze
    Wenn Dateien, die mit einem Punkt "." beginnen kopiert werden sollen, musst du "*.*" als Maske angeben, um alle Dateien zu kopoeren, z.B. "cp -R /tmp/*.* /cf/tmp"


    So einfach ist das leider nicht, zumindest verhält sich bash bei mir diesbezüglich anders. (Die Shell expandiert "*", nicht cp!) Es gibt eine Reihe von internen Shell-Optionen, die die Expansion von "*" steuern:

    Code
    server:~# shopt|grep glob
dotglob         off
extglob         on
failglob        off
nocaseglob      off
nullglob        off


    Damit findet "*.*" nur Dateien, die einen Punkt mit Zeichen davor und dahinter enthalten, also z.B. "test.ext", aber nicht ".test" oder "test". Auch ".*" hilft nicht weiter, das findet zwar ".test", aber weder "test.ext" noch "test", dafür aber ".", das übergeordnete Verzeichnis, was bei cp -R ziemlich unerwünscht sein dürfte.


    Um Dateien mit Punkt am Anfang gemeinsam mit allen anderen Dateien mit "*" zu finden, muss man vorher dotglob einschalten:


    Code
    shopt -s dotglob


    Am besten lässt man die Wildcards weg und gibt nur den Namen des zu kopierenden Verzeichnis an:


    Code
    cp -a /tmp/ /ziel/


    Oder, um das aktuelle Verzeichnis zu kopieren:


    Code
    cp -a . /ziel/