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-jessic…edia-build-dkms

Zur Installation sind diese Schritte erforderlich:

add-apt-repository ppa:jasmin-jessich/media-build-dkms
apt-get update
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)

Commit 8653e9f44145bbf von
Darik Horn am 27. Feb. 2012
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

apt-get install dkms=2.2.0.3-1.1ubuntu5.14.04.9
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

apt-mark unhold dkms
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:

$ cd /usr/sbin
$ sudo patch -p1 < /tmp/dkms.patch
$ 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/media…003-08_Sep_2017

Die im DKMS verwendete media_tree Variante:

https://github.com/jasmin-j/dddvb…master-ddbridge

bzw. https://github.com/jasmin-j/dddvb…003-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.

Updates (2017-Dez-28):

Vor der Installation solltest ihr unbedingt alle nicht mehr benötigten Kernel Versionen entfernen, weil das DKMS für jede installierte Kernel Version gebaut wird und das wirklich Stunden braucht!

Und das De-Installieren braucht ohne dem DKMS Speed Patch extrem lange!

Vielen Danke für's Testen!

Quote from TomJoad

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.

Quote from TomJoad

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.

Quote from TomJoad

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

Quote from TomJoad

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

Quote from jasminj

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:

Quote

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

Danke an alle fürs Testen!

Quote from TomJoad

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).

Quote from TomJoad

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.

Quote from mini73

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.

Quote from mini73

Code

[    4.945195] media: Linux media interface: v0.10
[    4.953502] WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
6f20cbb92a127550308bccb7d3a81ab3d30c8faf ddbridge: don't break on single (last) port attach failure
f51f29c9ec68eade23c3c1d97e7f6d9b5d8ce2f9 ddbridge: improve tuner attach fail
a03e1ad81d151377370e3e712dbb6a6dc5d6ad67 [media] ddbridge: add IOCTLs
[    5.066753] ddbridge: Digital Devices PCIE bridge driver 0.9.31intermediate-integrated, Copyright (C) 2010-17 Digital Devices GmbH
[    5.067390] Linux video capture interface: v2.00
[    5.067393] WARNING: You are using an experimental version of the media stack.

Display More

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

LG,

Jasmin

Quote from TomJoad

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.

Quote from TomJoad

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

Also ja

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

JA!

root@vdrjess:/lib/modules/3.13.0-117-generic# modprobe dvb_core
root@vdrjess:/lib/modules/3.13.0-117-generic# dmesg -c
[151560.514668] WARNING: You are using an experimental version of the media stack.
[151560.514668] 	As the driver is backported to an older kernel, it doesn't offer
[151560.514668] 	enough quality for its usage in production.
[151560.514668] 	Use it with care.
[151560.514668] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
[151560.514668] 	727548a96ca7daa066c91046a5e34dd66dfa6520 ddbridge: don't break on single (last) port attach failure
[151560.514668] 	1fe8ce27f8c93145cd1896f3882317b05085203a ddbridge: improve tuner attach fail
[151560.514668] 	82420a3a24d4ed2b432f6828a5df0bebef95a3c4 [media] ddbridge: add IOCTLs
root@vdrjess:/lib/modules/3.13.0-117-generic# lsmod | grep dvb_core
dvb_core              127039  0
media                  40508  1 dvb_core
root@vdrjess:/lib/modules/3.13.0-117-generic#

Also das geht bei mir nicht!

root@vdrjess:/lib/modules/3.13.0-117-generic# modprobe rc-core
modprobe: ERROR: could not insert 'rc_core': Unknown symbol in module, or unknown parameter (see dmesg)
root@vdrjess:/lib/modules/3.13.0-117-generic# dmesg -c
[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:

Quote

commit 5cee964597260237dd2cabb3ec22bba0da24b25d

Author: Thomas Gleixner

Date: Sun Jun 22 12:06:40 2014 +0200

time/timers: Move all time(r) related files into kernel/time

Except for Kconfig.HZ. That needs a separate treatment.

Signed-off-by: Thomas Gleixner

Display More

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

Das hat der Gute Thomas in diesem Commit eingebaut:

Quote

commit d560fed6abe0f9975b509e4fb824e08ac19adc93

Author: Thomas Gleixner

Date: Wed Jul 16 21:04:31 2014 +0000

time: Export nsecs_to_jiffies()

Required for moving drivers to the nanosecond based interfaces.

Signed-off-by: Thomas Gleixner

Signed-off-by: John Stultz

Display More

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:

root@vdrjess:/lib/modules/3.13.0-117-generic# modprobe rc-core
root@vdrjess:/lib/modules/3.13.0-117-generic# dmesg -c
[174889.931485] WARNING: You are using an experimental version of the media stack.
[174889.931485] 	As the driver is backported to an older kernel, it doesn't offer
[174889.931485] 	enough quality for its usage in production.
[174889.931485] 	Use it with care.
[174889.931485] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
[174889.931485] 	6f20cbb92a127550308bccb7d3a81ab3d30c8faf ddbridge: don't break on single (last) port attach failure
[174889.931485] 	f51f29c9ec68eade23c3c1d97e7f6d9b5d8ce2f9 ddbridge: improve tuner attach fail
[174889.931485] 	a03e1ad81d151377370e3e712dbb6a6dc5d6ad67 [media] ddbridge: add IOCTLs
root@vdrjess:/lib/modules/3.13.0-117-generic# lsmod | grep rc_core
rc_core                37163  0

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.

$ cd /var/lib/dkms/media-build/0004/build
$ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/<kernel-version> \
  <kernel-version> <arch> install

Bei sieht das so aus:
$ ./handle_updated_modules.sh /var/lib/dkms/media_build/0004/3.13.0-117-generic/x86_64 \
    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

Quote from TomJoad

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.

Quote from TomJoad

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

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

Super! Vielen Dank fürs testen!

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

Quote from TomJoad

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.

Quote from TomJoad

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