Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • MIt einem frisch ausgecheckten und nacktem Build kommt nun folgendes:

    Code
    Apply patch ../patches/CoreELEC.coreelec-21/json-c-checksum.patch
    patching file packages/devel/json-c/package.mk
    Reversed (or previously applied) patch detected!  Assume -R? [n] 

    und

    Code
    Hunk #1 FAILED at 4.
    1 out of 1 hunk FAILED -- saving rejects to file packages/network/wireguard-linux-compat/package.mk.rej

    Edit:

    Nachdem ich die Patches gelöscht habe, ist der build durchgelaufen. Nun frage ich mich was ich falsch gemacht habe beim ersten build.

    Was muss man denn tun wenn ich mit git pull ein update mache. Ein einfaches build danach scheint ja nicht immer zu funktionieren. Wie kann ich den build denn zurücksetzen ohne wieder ALLES compilieren zu müssen.

  • Apply patch ../patches/CoreELEC.coreelec-21/json-c-checksum.patch

    Der Commit ist untergegangen. Wenn man abgelenkt wird ... :(


    Diesmal ist es das plugin dvbapi.

    Okay. Das ist schräg. Das Plugin und die erwähnte Lib sind seit langer Zeit unverändert und wurden nicht aktualisiert und ich finde auch im Repository dazu keine neuen Commits.


    Ich muss mal einen frischen Build machen.

  • Mein frischer build ist ja ohne die beiden patches (siehe oben) durchgelaufen. Ich wollte nur nicht bei jedem Update deines GITs einen frischen build machen müssen. Aber anscheinend geht es nicht anders. Oder hast du da ein Kommando um das zu beschleunigen.

  • Mein frischer build ist ja ohne die beiden patches (siehe oben) durchgelaufen. Ich wollte nur nicht bei jedem Update deines GITs einen frischen build machen müssen. Aber anscheinend geht es nicht anders. Oder hast du da ein Kommando um das zu beschleunigen.

    Die beiden Patches waren versehentlich drin. Einen frischen Build mache ich nur sehr selten. Ansonsten baue ich einfach nur neu mit demselben Kommando. Mein Build-Script sieht so aus:

    Bash
    #!/bin/sh
    export JAVA_HOME=/opt/jdk18_121_hot
    export PATH=$JAVA_HOME/bin:$PATH
    
    ./build.sh -config CoreELEC-20-ng -extra easyvdr,channellogos,remotetranscode,cefbrowser -releaseonly -cebootlabel 


    Falls ein Paket nicht baut, dann lösche ich es durch

    Code
    ./clean-package.sh <package name>
    also z.B.
    ./clean-package.sh _vdr-plugin-dvbapi

    Und manchmal eben nicht nur das Package, das nicht baut, sondern auch Abhängigkeiten, die im Verdacht stehen.

  • Mein frischer build ist ja ohne die beiden patches (siehe oben) durchgelaufen. Ich wollte nur nicht bei jedem Update deines GITs einen frischen build machen müssen. Aber anscheinend geht es nicht anders. Oder hast du da ein Kommando um das zu beschleunigen.

    Ich lösche das VDRSternELEC root Verzeichnis oder die build Verzeichnisse nie. Ausser ein Update der Toolchain macht Probleme, dann lösche ich build oder man kriegts mit einem clean-package der betroffenen Pakete hin.

    Du musst halt vor einem git pull nur das root Verzeichnis wieder auf HEAD zurückstellen und evtl. nicht eingecheckte eigene Patches löschen, die dann nicht mehr gegen die neuen Versionen aus dem git pull funktionieren. Passiert mir öfter, dass der build scheitert, wenn alte temporäre Patches noch drin sind und mit dem pull ein package update gemacht wurde. In keinem Fall musst/darfst du was in build selbst ändern, das wird ignoriert, da bei einem Paket-Neubau das Verzeichnis vorher gelösch wird. Vielleicht machts https://github.com/Zabrimus/VD…ov-file#developer-section etwas klarer.


    Sobald Paketquellen oder -patches geändert wurden, baut die build Routine diese Pakete - und nur diese Pakete - neu . Sonst wirst du ja wahnsinning, wenn du alles immer neu bauen musst ;)

  • Ich bin gerade auch dabei VDRSternELEC für meine Odroids zu bauen. Aktueller Stand aus dem git. build.sh lief durch bis 150/500 und brach dann ab mit der Fehlermeldung, dass das Paket xxd fehlt. Nachinstalliert und nochmals gestartet. Nun geht's weiter. Eventuell sollte man das im build-Skript ergänzen.


    Eine Anfängerfrage zum build.sh-Skript: kann ich nach einem Abbruch wie in meinem Fehlerfall einfach das Skript erneut aufrufen oder kann dabei ein Schritt "halbfertig" abgelegt sein? Momentan zumindest läuft er weiter und ist bei 182/500.


    Zur Info: ich baue unter Debian 12.8 (neue VM, ohne sonstige Veränderung) mit dem Kommando build.sh -config CoreELEC-22-no.


    PS: in die Falle mit zu kleiner Partition bin ich auch getappt. Nun habe ich mittlerweile 64GB zugewiesen. Soltle reichen, oder?

  • Aktueller Stand aus dem git. build.sh lief durch bis 150/500 und brach dann ab mit der Fehlermeldung, dass das Paket xxd fehlt.

    Als Paket auf dem Host für die build Umgebung oder als package von CE?


    Eine Anfängerfrage zum build.sh-Skript: kann ich nach einem Abbruch wie in meinem Fehlerfall einfach das Skript erneut aufrufen oder kann dabei ein Schritt "halbfertig" abgelegt sein? Momentan zumindest läuft er weiter und ist bei 182/500.

    Genau so ist es. Es bleibt normalerweise nichts zurück, was fehlerhaft ist.

  • Als Paket auf dem Host für die build Umgebung oder als package von CE?

    Paket auf dem Host für die Build Umgebung.


    Mittlerweile lief es durch bis 493/500. Nun störte er sich an einem fehlenden aclocal-1.16. Habe nun (auf dem Build-System) auch noch das Paket automake installiert und er kommt einen Schritt weiter, hängt dann aber bei "possibly undefined macro".


    Kann mir hier einer auf die Sprünge helfen? Oder gibt es doch temporäre Dateien, die momentan den Lauf stören? Gibt es die Möglichkeit, ab einem bestimmten Build-Schritt alles zu löschen und neu zu erzeugen?

  • Gibt es die Möglichkeit, ab einem bestimmten Build-Schritt alles zu löschen und neu zu erzeugen?

    Ja, lösche das Build Verzeichnis: ~/VDRSternELEC/CoreELEC/build.<foo>

  • Ja, lösche das Build Verzeichnis: ~/VDRSternELEC/CoreELEC/build.<foo>

    Nein! Damit musst du ja alles wieder neu bauen!

  • Ja, lösche das Build Verzeichnis: ~/VDRSternELEC/CoreELEC/build.<foo>

    Ok, werde wohl zurück auf Los gehen und neu starten. Nur kleine Info zwischendurch: habe mittlerweile auch noch pkg-config auf dem Build-System installiert. Dann ging es wieder etwas weiter. Bekam dann aber die Fehlermeldung

    Code
    /home/odroid/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/_vlc-3.0.21/configure: 27760: ./configure.lineno: Syntax error: word unexpected (expecting ")")

    Egal, neuer Build gestartet...


    Frage in die Runde: hat einer von euch den Build schon auf einem Debian 12.8 erfolgreich durchgeführt?

  • Nein! Damit musst du ja alles wieder neu bauen!

    So wie ich das verstanden habe, möchte mrjoe ja genau das.

  • Mein build host ist ein arm64 debian 12.7 und das Paket xxd ist hier nicht installiert. Hast du da die logs noch?


    Du kannst ein einzelnes Paket mit ./clean-packages.sh "xxx" löschen. Und mit der -package option auch einzeln bauen.

  • So wie ich das verstanden habe, möchte mrjoe ja genau das.

    Wenn er von vorne starten will, dann ja :)


    mrjoe https://github.com/Zabrimus/VD…adme-ov-file#manual-build kennst du?

    Wie sieht denn die Fehlermeldung aus, wenn was fehlt?

  • Mein build host ist ein arm64 debian 12.7 und das Paket xxd ist hier nicht installiert. Hast du da die logs noch?


    Du kannst ein einzelnes Paket mit ./clean-packages.sh "xxx" löschen. Und mit der -package option auch einzeln bauen.

    Komisch, in meinem Fall hat er das Paket xxd explizit als fehlend genannt. Mit welchen Parametern startest du build.sh?


    Mir hätte es tatsächlich gereicht die letzten Pakete neu zu bauen. Aber mittlerweile hat die VM soviele Kerne und Speicher, sollte also schnell gehen (ist auch schon wieder bei 143). Deine Befehle helfen mir aber in der Zukunft. Logs sind leider bereits gelöscht.


    https://github.com/Zabrimus/VD…adme-ov-file#manual-build kennst du?

    Wie sieht denn die Fehlermeldung aus, wenn was fehlt?

    Nach der Anleitung arbeite ich und bin momentan bei "Building the image" ;). Habe leider die Fehlermeldung beim Fehlenden xxd nicht mehr vorliegen. War in der Art "command not found". Also eigentlich eindeutig, dass er xxd benötigt.

  • Nachdem mir der Speicherplatz mal wieder ausgegangen ist, habe ich über Nacht einen erneuten Lauf gestartet und nun erfolgreich gebaut. VDR funktioniert auch OOTB. Wirklich sehr gute Arbeit! Nun muss ich schauen, wie ich in das System die ein oder andere Library hinzufügen kann, da für manche meiner Plugins noch weitere libraries notwendig sind.


    PS: Ich spendiere den Aufwand mit CoreELEC Varianten deshalb, da ich mit meinem Odroid mit dem Hardkernel Ubuntu mit VDR Instabilitäten hatte. Ein Zwischenversuch mit der gechrooteten Variante von beta während des Bauens von VDRSternELEC hat bereits gezeigt, dass die Probleme nicht vorhanden sind. Vermutlich sind manche Patches und Aktualisierungen in CoreELEC für den Odroid stabilitätsfördernd.

  • Nun muss ich schauen, wie ich in das System die ein oder andere Library hinzufügen kann, da für manche meiner Plugins noch weitere libraries notwendig sind.

    Der einfachste Fall wäre, wenn die Lib bereits in CE/LE vorhanden ist und auch gelinkt werden kann. Viele Libs werden nur statisch gebaut und manchmal gibt es Probleme.


    Ansonsten findest du in packages/vdr/vdr-depends auch schon einige Libs, die es entweder in CE/LE nicht gibt oder die anders compiliert werden müssen, damit die gelinkt werden können.


    Und ansonsten die entsprechende (neue) Lib einfach als Abhängigkeit hinzufügen. In der package.mk z.B.

    Code
    PKG_DEPENDS_TARGET="toolchain _vdr curl tinyxml _librepfunc vdr-helper"
  • Was ich vergessen habe zu erwähnen:

    Neue Plugins müssen noch in packages/virtual/vdr-all/package.mk hinzugefügt werden, damit die auch gebaut und installiert werden.

    Super, vielen Dank. Zwei letzte eher generische Fragen:

    • wie kann man im laufenden Betrieb (also nach erzeugen des Images mit deiner Skriptsammlung) diverse Dateien in /etc modifizieren? Bei /flash zum Setzen des PowerOn gpios war ein simples mount -o remount,rw /flash ausreichend. /etc bzw. / ist ein loop-FS und kann so nicht schreibbar gemacht werden. Vorschläge wie mount -o bind /storage/hostname /etc/hostname sind leider nicht zielführend.
    • wie kann man ein "Notfallterminal" ttyX aktivieren, sodass man bei Ausfall von ssh noch direkt am Rechner ein Terminal mit Ctrl-Alt-Fx aktivieren kann? In config.ini beim Parameter coreelec ein tty oder ein debugging anzuhängen brachte nicht die erhoffte Lösung.
  • wie kann man im laufenden Betrieb (also nach erzeugen des Images mit deiner Skriptsammlung) diverse Dateien in /etc modifizieren?

    Ich fürchte das wird nicht funktionieren, weil das Dateisystem tatsächlich als ro angelegt ist. Manche Scripte lesen alternativ aus /storage/.config ihre Konfigurationsdateien, aber das bedeutet immer eine Suche in den Scripten von CE, ob da schon eine Alternativ-Config vorgesehen ist. Manche Einstellungen kann man über Kodi machen.

    In den Foren wird der mount bind aber als mögliche Lösung empfohlen, wobei es natürlich nicht immer funktioniert, weil der Mount vielleicht zu spät stattfindet und die Änderungen nicht mehr gezogen werden.

    wie kann man ein "Notfallterminal" ttyX aktivieren, sodass man bei Ausfall von ssh noch direkt am Rechner ein Terminal mit Ctrl-Alt-Fx aktivieren kann?

    Da muss ich passen. Ob das überhaupt möglich ist, kann ich gar nicht sagen. Auf meinen System habe ich überall einen ssh key hinterlegt und nie das Problem gehabt, daß ich nicht mehr drauf komme.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!