media-build-dkms

  • Hallo!


    Ich habe es endlich geschafft ein DKMS Paket für media_tree/media_build zu machen.

    Es funktioniert zwar bei mir und nst, aber es ist trotzdem Alpha-SW. Ich brauche noch einige Freiwillige die das Paket testen.


    Dieses neue DKMS kann eine bestimmte Kombination von media_tree (genauer dddvb-linux-kernel) und media_build auf einem System installieren. Welche Kombination das ist legt man beim Erzeugen des DKMS Source Paketes fest. Das fertige Source und auch Binary Paket enthält bereits die ganzen Treiber aus media_tree und es muss nichts mehr aus dem iNet geladen werden, wenn man das DKMS installiert.


    Auch wenn ich oben dddvb-linux-kernel erwähnt habe, so beinhaltet das Paket alle(!) derzeit in media_tree verfügbaren Treiber und ein paar Zusätze für die DD Karten, die noch nicht in media_tree integriert wurden. media_build muss ja auf den verwendeten media_tree angepasst werden und deshalb ist die Kombination wichtig. Die derzeit erste verfügbare Kombination ist für alle Kernels bis 2.6.36 zurück fehlerfrei compilierbar!


    Der normale User braucht nur das DKMS Paket aus meinem PPA zu installieren. Es ersetzt automatisch alle anderen verfügbaren DVB Treiber Pakete.

    Das sind:

    s2-liplianin-dkms, v4l-dvb-dkms, linux-tbs-drivers-dkms, linux-media-tbs-dkms, linux-media-dkms, media-build-experimental-dkms, dddvb-dkms


    Falls irgend jemand wissen will wie das alles genau funktioniert, also wie man das DKMS aus einer media_tree und media_build Version bauen kann, bitte ich die entsprechende Doku (README_DKMS) in den entsprechenden Git Repos auf GitHub zu lesen.


    Die fertigen Pakete für die Ubuntu LTS Pakete sind in meinem PPA zu finden:

    https://launchpad.net/~jasmin-…e/ubuntu/media-build-dkms


    Zur Installation sind diese Schritte erforderlich:

    Code
    1. add-apt-repository ppa:jasmin-jessich/media-build-dkms
    2. apt-get update
    3. apt-get install media-build-dkms

    Nicht wundern, das compilieren und installieren der Module dauert wirklich lange! Es wird auch versucht die vorhandenen CPU-Cores ans Limit zu fahren, aber auf meinem Single Core AMD Sempron dauert das doch über eine Stunde.

    Man darf nicht vergessen, dass für Kernel 3.13 616 Module gebaut werden und für Kernel 4.12 sind es noch mehr.

    Nach der Installation sollte man rebooten, weil alle DVB Module getauscht werden und ev. noch in Verwendung befindliche Module nicht automatisch entladen werden.


    Es wird mit diesem DKMS keine Firmware installiert!

    Wenn man DVB Karten hat die eine Firmware benötigen, so muss man diese über andere Pakete installieren!


    Ein "dkms uninstall media-build ..." dauert sehr sehr lange. Das bekommt man dann zu spüren, wenn man einen älteren Kernel deinstalliert, für den irgendwann die Module gebaut wurden. Vielleicht finde ich dafür ja noch eine Lösung.



    ACHTUNG:

    Man benötigt eine DKMS Version, die das "POST_BUILD" Macro unterstützt!

    Siehe DKMS Git (https://github.com/dell/dkms)

    Code
    1. Commit 8653e9f44145bbf von
    2. Darik Horn am 27. Feb. 2012
    3. Add POST_BUILD to the dkms_conf_variables list.

    Die derzeit in yaVDR stable verfügbaren Version kann das nicht!

    Man muss das Ubuntu Paket über das yaVDR Paket installieren (downgraden) und danach das update desselben verhindern

    Code
    1. apt-get install dkms=2.2.0.3-1.1ubuntu5.14.04.9
    2. apt-mark hold dkms

    Ich würde die yaVDR Maintainer bitten auf eine neuere DKMS Version umzusteigen oder das Paket ganz aus dem Repo zu entfernen.


    Wenn die yaVDR Maintainer dieses Problem gelöst habe, kann man das Updaten des Pakets wieder erlauben

    Code
    1. apt-mark unhold dkms
    2. apt-get upgrade

    Für die noch ältere Ubuntu Version Precise, muss man angehängten Patch auf das installierte dkms Script anwenden. Das muss aber als root gemacht werden!


    Angehängten Patch nach "/tmp/dkms.patch" speichern und mit folgenden Kommandos anwenden:

    Code
    1. $ cd /usr/sbin
    2. $ sudo patch -p1 < /tmp/dkms.patch
    3. $ sudo chmod a+x dkms



    Wo findet man die Sourcen:


    Die Scripte um Ubuntu/Debian Pakete zu bauen:

    https://github.com/jasmin-j/media-build-dkms


    Die DKMS Variante von media_build:

    https://github.com/jasmin-j/media_build/tree/dkms-master

    bzw. https://github.com/jasmin-j/me…ree/dkms/0003-08_Sep_2017


    Die im DKMS verwendete media_tree Variante:

    https://github.com/jasmin-j/dd…rnel/tree/master-ddbridge

    bzw. https://github.com/jasmin-j/dd…ree/dkms/0003-29_Aug_2017


    Die Versionen von dddvb-linux-kernel für die DKMS Pakete werden immer auf einem Branch "dkms/????-" abgelegt. Selbiges gilt auch für die Versionen von media_build. Der Ursprung aller dkms Branches in media_build ist aber dkms-master.

    Warum es Branches für die einzelnen DKMS Versionen gibt steht in README_DKMS.



    Insiderwissen für Interessierte:


    Die Problematik an der ganzen Geschichte war DKMS zu überlisten eine beliebige Anzahl von Modulen zu installieren. Das deshalb, weil media-build abhängig von der Kernel Version verschieden viele Kernel Module erzeugt. Normalerweise würde man in dkms.conf jedes einzelne Kernel Modul aufzählen, das funktioniert nur bei media-build nicht, weil eben die Anzahl der Module von der Kernel Version abhängt.


    Der Trick ist mit einem POST_BUILD Script (gen_dkms_dyn_conf.sh) die erzeugten Module nach dem Build Step zu finden und dkms.conf entsprechend zu ändern. Um genauer zu sein, es wird eine Datei dkms_dyn.conf generiert, welche von dkms.conf includiert wird, wenn sie existiert. Außerdem müssen die compilierten Kernel Module auch noch von einem Script in das module Verzeichnis kopiert werden, weil DKMS das in dem Fall nicht automatisch tut.


    Beim install Step von DKMS existiert das File dkms_dyn.conf dann und DKMS installiert schön brav alle Module die in dkms_dyn.conf stehen. Das ist auch die Erklärung warum eine DKMS Version mit POST_BUILD Support gebraucht wird.


    LG,

    Jasmin


    Updates (2017-Sep-10):

    lirc_serial wurde auf serial_ir umbenannt. Es muss also die Lirc Konfiguration angepasst werden.

    Siehe hierzu den Beitrag von Paulaner.


    Dateien

    • dkms.patch

      (608 Byte, 7 Mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von jasminj ()

  • ich habe das dkms mal mit Ubuntu 14.04/Kernel 3.13.0-129 ausprobiert. Gegenüber dem alten media_build_experimental, was man selber konfigurieren konnte, aber vor allem gegenüber dem dddvb-dkms von ppa.launchpad.net/mango-vdr fehlen mir als Modul lirc_serial, lirc_dev und rc_core. Damit geht mein seriell angeschlossen FB-Empfänger nicht mehr.

    Andere Änderungen waren cxd2841er statt cxd2843 und tda18212 statt tda18212dd, was ich nicht beurteilen kann. Jedenfalls bin ich erstmal wieder zurückgegangen.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Vielen Danke für's Testen!


    ich habe das dkms mal mit Ubuntu 14.04/Kernel 3.13.0-129 ausprobiert.

    Fast gleicher Kernel wie bei mir, das ist schon mal gut zum Vergleichen.


    Gegenüber dem alten media_build_experimental, was man selber konfigurieren konnte

    Aha, da konnte man Was, Wie konfigurieren?

    Wäre mir neu bei einem DKMS Paket irgend etwas konfigurieren zu können.


    Wenn du selbst was an den aktivierten Modulen ändern möchtest, dann kannst du ja gleich media_build verwenden. Ich habe aber eine einfache Möglichkeit der Konfiguration geschaffen. Man kann ??_*.inc Files definieren, welche einfache Statements "disable_opt", "set_opt_y", "set_opt_m" und "set_opt_value" enthalten können.

    Man erspart sich damit das menuconfig von media_build. Ursprünglich was das für Distributionen gedacht, die das DKMS ein wenig anders konfigurieren wollen.


    fehlen mir als Modul lirc_serial, lirc_dev und rc_core. Damit geht mein seriell angeschlossen FB-Empfänger nicht mehr.

    Ich habe einen y.a.r.d.2, der braucht kein lirc, deshalb ist mir das nicht aufgefallen. Jetzt fragt sich nur warum das ganze RC Subsystem nicht aktiviert ist. Ich mache das mit stagingconfig, also sollten alle verfügbaren Module gebaut werden. Das muss ich mir anschauen


    Andere Änderungen waren cxd2841er statt cxd2843 und tda18212 statt tda18212dd, was ich nicht beurteilen kann. Jedenfalls bin ich erstmal wieder zurückgegangen.

    Das war ja unter anderem der Sinn der Übung, nämlich den Treiber Stand von Kernel 4.1.4-rc1 als DKMS zur Verfügung zu stellen. Da sind jetzt die von nst portierten DD Treiber enthalten mit ein paar Zusätzen, die noch nicht in Mainline akzeptiert wurden (z.B.: ioctl's). Für die Treiber von nst bitte diesen Thread lesen.


    LG,

    Jasmin

  • Ich mache das mit stagingconfig, also sollten alle verfügbaren Module gebaut werden. Das muss ich mir anschauen

    Also ... das ist bei den neuesten Kernel Sourcen alles ein wenig anders, als wir von 3.13 gewohnt sind.


    Allerdings heißt das Modul rc-core und nicht rc_core.





    lirc-serial suchst du vergeblich, weil das Module heißt jetzt serial_ir. Siehe dazu diesen Commit:

    Zitat

    commit fa5dc29c1fcc9151c3bcfd9e291a2899ae15f61d

    Author: Sean Young

    Date: Mon Nov 21 19:55:53 2016 -0200

    [media] lirc_serial: move out of staging and rename to serial_ir

    Signed-off-by: Sean Young



    Die Zeit bleibt nicht still stehen und der Kernel verändert sich. Das hat dann eben auch zur Folge, dass Module umbenannt werden oder sogar entfallen. Meine Intention war es die aktuellsten verfügbaren DVB Treiber für alle einfach installierbar zur Verfügung zu stellen. Wenn das dann Anpassungen an den System erfordert, dann muss der Anwender damit leben und sein System auch anpassen. Es kann nicht die Aufgabe eines DKMS Paketes (mit der von mir angedachten Zielsetzung) sein, gewohnte Funktionalität 1:1 zu erhalten.

    Wenn das gewünscht ist, dann muss das jemand anders machen, allerdings ist das so wie Eulen nach Athen tragen und außerdem eine Sisyphusarbeit.

    Spätestens mit einem System mit Kernel 4.10 wird man "serial_ir" verwenden müssen, also kann man sich auch jetzt schon daran gewöhnen, wenn man die neuesten Treiber haben möchte.



    LG,

    Jasmin

  • Wenn das gewünscht ist, dann muss das jemand anders machen, allerdings ist das so wie Eulen nach Athen tragen und außerdem eine Sisyphusarbeit.

    Spätestens mit einem System mit Kernel 4.10 wird man "serial_ir" verwenden müssen, also kann man sich auch jetzt schon daran gewöhnen, wenn man die neuesten Treiber haben möchte.

    Zum Thema "serial_ir" hatte ich bereits auch mal etwas geschrieben: Siehe hier, im 3. Beitrag!

    Es sind also nur 2 Änderungen/Anpassungen zu machen, damit "serial_ir" an Stelle von "lirc_serial" verwendet werden kann.


    @Jasmin,

    super Arbeit, werde demnächst auch mal dein Paket testen. :)


    Paul

  • Leider ist es mit Kernel 3.13 nicht so einfach. rc-core läßt sich nicht laden (unknown symbol nsecs_to_jiffies). Das ist zwar in jiffies.h definiert und in /proc/kallsyms aufgeführt, aber trotzdem???

    lirc_serial und dvb_core sind ja noch im staging-Bereich des Kernels, depmod erzeugt aber eine Abhängigkeit von den neuen Modulen. Löscht man lirc_dev.ko und rc-core.ko in dkms und führt depmod -a aus, funktioniert erstmal alles.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von TomJoad ()

  • Ich hab das Paket mal auf meiner Testkiste installiert, kompilieren auf dem Core2Quad Q6700 dauert ungefähr 15 Minuten. Bisher keine Auffäligkeiten,


    Code
    1. $ uname -a
    2. Linux hdvdr2 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    3. $ dkms status
    4. media-build, 0003, 4.10.0-33-generic, x86_64: installed


    Eine Satelco EasyWatch und eine DD-Dual-Tuner-Karte laufen. Für das CI hab ich gerade kein CAM.


    Danke für das Paket!


    Lars.


  • Danke an alle fürs Testen!


    Leider ist es mit Kernel 3.13 nicht so einfach. rc-core läßt sich nicht laden (unknown symbol nsecs_to_jiffies).

    Ich habe da eine Unschönheit in DKMS entdeckt (siehe dkms_issue_31 und dkms_issue_32). Issue 31 ist wirklich ein Problem, weil damit nicht alle Module auf den neuesten Stand gebracht werden.

    Ich glaube zwar nicht, dass das dein Problem war, aber lösen muss ich es trotzdem (arbeite gerade daran).


    lirc_serial und dvb_core sind ja noch im staging-Bereich des Kernels, depmod erzeugt aber eine Abhängigkeit von den neuen Modulen. Löscht man lirc_dev.ko und rc-core.ko in dkms und führt depmod -a aus, funktioniert erstmal alles.

    Das freut mich dann aber!

    Warum bei dir dvb_core in staging ist weiß ich aber nicht. Egal welches Treiber Paket du vorher installiert hattest, durch die Installation meines Paketes, hätte DKMS alle alten Module löschen müssen.

    Ich werde dazu einen Hinweis im ersten Post machen.


    Allerdings könnten noch andere Treiber auch umbenannt worden sein und dann werden diese nicht ersetzt, was zu anderen Problemen führen könnte. Ev. muss ich da mit einem DKMS PRE_/POST_INSTALL automatisch aufräumen, sonst müssen die Anwender selbst Hand anlegen.


    Eine Satelco EasyWatch und eine DD-Dual-Tuner-Karte laufen. Für das CI hab ich gerade kein CAM.

    Das CI geht sicher auch, läuft bei mir ja schon seit vielen Tagen mit diesen Treibern.


    Ich glaub das werde ich irgendwie eliminieren, weil das is ned schön.


    LG,

    Jasmin

  • jasminj :


    Ich glaube, das mit dem Staging hast du falsch verstanden. Die Kernel-module aus dem Staging (Paket linux-image-extra-xxx) gehen natürlich noch, während das neu eingefügte dvb-core in updates/dkms, das der depmod heranziehen will, mit meinem Kernel nicht funktioniert. (Weder mit dem neuen serial_ir.ko noch mit lirc_serial.ko).

    Die Idee finde ich ja toll, das alte media_build_experimental mal durch ein entsprechendes dkms zu ersetzen, aber es würde mich wundern, wenn es nur updates/dkms/dvb-core.ko wäre, welches Backports im Kernel selber notwendig machen würde. Aber vielleicht mache ich ja auch noch einen grundsätzlichen Fehler.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Ich glaube, das mit dem Staging hast du falsch verstanden. Die Kernel-module aus dem Staging (Paket linux-image-extra-xxx) gehen natürlich noch, während das neu eingefügte dvb-core in updates/dkms, das der depmod heranziehen will, mit meinem Kernel nicht funktioniert. (Weder mit dem neuen serial_ir.ko noch mit lirc_serial.ko).

    Vielleicht hängt das doch mit dem fehlenden "--force" zusammen. Das hab ich in einer neuen Version bereits gelöst, die teste ich aber gerade.


    Aber vielleicht mache ich ja auch noch einen grundsätzlichen Fehler.

    Also ja :saint:

    Das neue DKMS ersetzt alle Media Treiber durch neue Versionen. Das inkludiert natürlich auch den Media Core. Es muss alles ersetzt werden, was irgendwie mit Media zu tun hat. Das sind Kamera Treiber genauso wie Audio Treiber und eben DVB Treiber.

    Hast du rebootet?


    Aber warte mal mit weiteren Tests, bis ich die neue Version ins PPA geschoben habe. Die neue Version hat jetzt alles richtig gemacht, aber ich möchte auch noch den POST_INSTALL Step dazu bauen, wo ich nicht mehr funktionierende oder umbenannte Module ersetze. Sonst muss ich mehrere Versionen des DKMS machen und das ist zu viel Arbeit.

    Du kannst aber bei dir jetzt schon eine Datei

      /usr/share/dkms/modules_to_force_install/media_build

    mit dem Inhalt

      media-build

    anlegen.


    Dann mit

      dkms uninstall -m media-build -v 0003 -k 3.13.0-???-generic

    entfernen und mit

      dkms install -m media-build -v 0003 -k 3.13.0-???-generic

    neu installieren.


    Dann sollte beim Install Step

      Forcing installation of media-build

    stehen. Wenn nicht, dann brich es ab, aber ich bin mir nicht sicher ob DKMS mit einem Abbruch so gut umgehen kann.


    Wenn dir das Uninstall zu lange dauert, dann kannst du ja angehängten Patch vorher anwenden. Damit geht das Uninstall in wenigen Sekunden.


    LG,

    Jasmin

    Dateien

  • jasminj :

    Nur kurz: Geht bei dir modprobe dvb-core?

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • JA!


  • Ich meinte natürlich modprobe rc-core. Bin schon ganz durcheinander.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Also das geht bei mir nicht!


    Code
    1. root@vdrjess:/lib/modules/3.13.0-117-generic# modprobe rc-core
    2. modprobe: ERROR: could not insert 'rc_core': Unknown symbol in module, or unknown parameter (see dmesg)
    3. root@vdrjess:/lib/modules/3.13.0-117-generic# dmesg -c
    4. [153759.119139] rc_core: Unknown symbol nsecs_to_jiffies (err 0)

    Du hast sicher exakt das gleiche Problem.
    Das kommt daher, dass die Herrschaften im Kernel ganz schön umrühren und dann Dinge wie das machen:

    Danke, dass du das gefunden hast!

    Deshalb muss man die Dinge auf mehreren System testen, weil ich auf meinem Test System kein rc-core verwende.


    Das muss man im media_build mit einer Kompatibilitätsfunktion lösen.

    Sorry, aber das wird ein wenig dauern, weil ich mal zuerst das DKMS fertig machen möchte und dann muss das auch noch von den Maintainern akzeptiert werden. Im DKMS wird es aber schon vorab drinnen sein.


    LG,

    Jasmin

  • Ich habe mal die kernel-sourcen von 3.13 und 4.4 verglichen, und in 4.4 ist in time.c ein

    "EXPORT_SYMBOL_GPL(nsecs_to_jiffies);"

    welches in 3.13 fehlt, obwohl die Funktion durchaus vorhanden wäre.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Das hat der Gute Thomas in diesem Commit eingebaut:



    Ich kann nur nicht rückwirkend ein Symbol exportieren, welches sich im Kernel Tree befinden.

    Aber ich kann in media_build/v4l/compat.h eine passende inline Funktion definieren und diese bei Bedarf (Export in time.c oder

    timers.c fehlt) einschalten. Aber wie gesagt, das dauert ein wenig.


    LG,

    Jasmin

  • Ich habe das nsecs_to_jiffies Problem gelöst!

    Die neuen Pakete sind bereits auf Launchpad.


    Hier der Test:


    Der entsprechende Patch für media-build ist auch schon auf der Media Liste gepostet worden.


    Ich habe auch die Sache mit den nicht mehr erforderlichen Modulen gebaut, allerdings kann ich das nicht perfekt machen, weil DKMS keinen PRE_UNINSTALL Hook hat. Deshalb ist das vorerst einmal deaktiviert.

    Wer es trotzdem ausprobieren möchte, kann das handle_updated_modules.sh Skript nach der Installation ausführen.

    Dieses löscht oder besser verschiebt die nicht mehr erwünschten lirc Module (kann man jederzeit um neue Module erweitern) in den DKMS Baum.


    Code
    1. $ cd /var/lib/dkms/media-build/0004/build
    2. $ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/<kernel-version> \
    3. <kernel-version> <arch> install
    4. Bei sieht das so aus:
    5. $ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/3.13.0-117-generic/x86_64 \
    6. 3.13.0-117-generic x86_64 install

    Mit "uninstall" als action Parameter macht man es wieder rückgängig.


    Ich werde versuchen bei den Maintainern von DKMS den PRE_UNINSTALL Hook zu bekommen. Ohne diesen kann man das zwar auch verwenden, aber meiner Meinung nach nur zum Entfernen, weil man sicher vergisst vor dem nächsten Kernel Update ein Restore zu machen.

    Auf der anderen Seite ist das vielleicht gar nicht nötig, weil wenn man sich schon für die DKMS Treiber entschieden hat, dann braucht man nicht mehr zurück steigen und wenn man das wirklich will, dann braucht man ja nur das ganze "/lib/module/<kernel-version>" Verzeichnis vor der Installation sichern, um es bei Bedarf wieder herzustellen zu können.

    Oder man installiert einfach alles neu aus den entsprechenden Paketen.


    LG,

    Jasmin

  • Version 0004 sieht bei mir erstmal gut aus. Fernbedienung läuft mit den Konfigurationsänderungen die Paulaner oben verlinkt hat und dddvb hat auch keine Auffälligkeiten (ausser dass das femon-plugin keine Signalstärken mehr anzeigt).

    Lasse ich aber mal über alle neuen Module ein modprobe laufen, gibt es diverse, die sich nicht laden lassen und die vielleicht jmd. anders braucht.

    Ich weiss nicht, ob das Entfernen der Originalmodule eine gute Idee ist. Normalerweise sorgt die Priorisierung der Module unter updates dafür, dass das gewünschte geladen wird - und wenn man das dkms entfernt, hat man wieder den vorigen Zustand.

    Problematischer ist es, wenn Module umbenannt worden sind, weil dann i.d.R. wie bei lirc_serial Konfigurationsarbeiten notwendig sind, oder wenn sich Parameter geändert haben. Da wäre etwas mehr Hilfestellung wünschenswert (passende Changelog oder so)

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • ausser dass das femon-plugin keine Signalstärken mehr anzeigt

    Das wird wohl daran liegen, dass die neuen Treiber nur DVBv5 API sprechen und Femon das nicht kann.


    Lasse ich aber mal über alle neuen Module ein modprobe laufen, gibt es diverse, die sich nicht laden lassen und die vielleicht jmd. anders braucht.

    Code
    1. modprobe: ERROR: could not insert 'adv7511': Unknown symbol in module, or unknown parameter (see dmesg)
    2. .....

    Super! Vielen Dank fürs testen!

    Jetzt hab ich zwar einen Haufen Arbeit, aber vielleicht komme ich noch vor dem Urlaub dazu.


    Ich weiss nicht, ob das Entfernen der Originalmodule eine gute Idee ist. Normalerweise sorgt die Priorisierung der Module unter updates dafür, dass das gewünschte geladen wird - und wenn man das dkms entfernt, hat man wieder den vorigen Zustand.

    Problematischer ist es, wenn Module umbenannt worden sind, weil dann i.d.R. wie bei lirc_serial Konfigurationsarbeiten notwendig sind, oder wenn sich Parameter geändert haben.

    Also so einfach ist das nicht mit DKMS.

    Das stimmt zwar für Ubuntu, aber nicht für andere Distributionen. DKMS hat da ein paar Sonderbehandlungen implementiert. Generell ist der Ansatz von DKMS die ersetzten Module in den DKMS Tree zu verschieben. Beim Uninstall werden sie dann wieder zurück verschoben.

    Mit meiner Script Ergänzung hätte dasselbe mit den umbenannten/entfernten Modulen passieren sollen, aber für das Wiederherstellen brauche ich dann den leider nicht vorhandenen PRE_UNINSTALL Hook in DKMS.

    Bei Ubuntu geht es mit der jetzt implementierten Lösung, weil Ubuntu .../updates/* bevorzugt, wie du geschrieben hast.


    Da wäre etwas mehr Hilfestellung wünschenswert (passende Changelog oder so)

    Das ist sehr schwierig, weil die Änderungen nicht immer ersichtlich sind. Gerade die Sache mit serial_ir liegt schon wieder einige Zeit zurück und ich kann nicht 1000 Commits durchsuchen, ob da was dabei ist was ein Problem darstellen könnte.

    Ich kann nur warten bis mir User was sagen und das ev. ins README oder changelog schreiben. Wobei im changelog ist es irgendwann auch aus den Augen und damit wertlos.


    LG,

    Jasmin

  • Danke für die ausführlichen Antworten, ich wollte auch nicht demotivieren.

    Ich kann jetzt nicht verschiedene Distributionen untersuchen. In der man-page von depmod steht

    Code
    1. By default, depmod will give a higher priority to a directory
    2. with the name updates using this built-in search string: "updates
    3. built-in" but more complex arrangements are possible and are used
    4. in several popular distributions

    Wenn Distributionen das komplett über den Haufen werfen, sollten sie auch über dkms nachdenken. Ich wollte nur zum Ausdruck bringen, dass ich die Anpassungen an die älteren Kernelversionen für das drängendere Problem halte, wenn das Paket allgemeingültig sein soll - oder man muss doch eine Grenze setzen.

    Übrigens läuft auch lirc_serial nicht mit dem neuen rc_core wegen nicht passender Abhängigkeiten, so dass man genauso auf eine nötige Änderung gestossen wird, wie wenn es fehlen würde. Eigentlich sollte es bei Querverbindungen von alten und neuen Modulen nicht zu Problemen kommen, wenn alle Schnittstellen befriedigt werden und die Module sich laden lassen. Darauf verlässt man sich ja auch bei den Kernel-Schnittstellen.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen