Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Ich kann mich ganz dunkel erinnern mal etwas über ssh Probleme gelesen zu haben. Allerdings weiß ich nicht mehr in welchen Zusammenhang. Soweit ich mich erinnere, konnte per samba ein update tar eingespielt werden. Aber wie gesagt: Dunkelste Erinnerungen und ich finde den Beitrag nicht mehr.


    Wenn sshd läuft, reagiert und dann die Verbindung (nach dem Login?) gekappt wird.... Da fällt mir nichts zu ein.

    Auch mit einem aktuell neu erzeugten image bleibt das Problem bestehen:



    Mit 20.1-Nexus_devel_20230311020349 (Amlogic-ng.arm) geht es noch.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Auch mit einem aktuell neu erzeugten image bleibt das Problem bestehen:



    Mit 20.1-Nexus_devel_20230311020349 (Amlogic-ng.arm) geht es noch.

    Ich habe jetzt mal das stable 20.1 image von CoreELEC runtergeladen. Damit tritt das Problem nicht auf. Dann habe ich die am 26.03. erzeugte Datei CoreELEC-Amlogic-ng.arm-20.1-Nexus_devel_20230326133437.kernel in /storage/.update gelegt und dachte, dass diese beim Neustart erkannt wird. Da passiert aber nichts. Wird dann mit der auf .system endenden Datei wahrscheinlich auch nicht gehen? Oder muss ich die umbenennen?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich glaube, das update geht nur mit der tar oder img.gz

  • Die tar enthält ja wie das img sowohl Kernel als auch das Dateisystem. Ich weiss, dass der ssh-Fehler nach einem update auftritt. Jetzt wäre interessant zu wissen, ob es am Kernel oder am Dateisystem liegt. Ich würde ja gerne die /usr/sbin/sshd eines funktionierenden images in das neue image verpflanzen, aber wie mache ich das? In einer ssh-Sitzung flash mounten kann ich ja nicht, weil ich gar keine ssh-Sitzung herstellen kann...

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Mich würde interessieren, ob VDR*ELEC den Bug einführt, oder ob da in CoreELEC schon was faul ist.

    Entweder du testest eine reine CoreELEC mit gleichem Stand, wie sie VDR*ELEC hernimmt - dann lass aber das RTL8821CU sicherheitshalber nicht bauen. So würde ich vorgehen ;)

    Oder du baust VDR*ELEC mit dem letzten dir bekannten funktionieren CoreELEC sha. Ist evtl. etwas aufwendiger und du musst die patches evtl. anpassen/streichen, aber damit könntest du letztlich einen bug in VDR*ELEC bisecten... Kann ja dann nur irgendein Patch sein...

  • Wenn du sshd im Verdacht hast, kannst du dir auch in VDR*ELEC einen Patch anlegen, der sshd mit einer älteren Version baut.

  • Ich fürchte, das übersteigt leider alles meine Fähigkeiten.

    An ein Problem mit dem Netzwerktreiber RTL8821CU glaube ich nicht. Zum einen ist das ja anscheinend ein WLAN-Treiber. Ich benutze LAN und ftp und NFS geht ja auch.

    Bezüglich ssh käme wohl nur diese Änderung in Frage:

    openssh update auf 9.2p1: https://github.com/CoreELEC/Co…b9e6da2da4632ec22216ad939

    Es müssten dann aber doch eigentlich noch mehr Leute seit fast 2 Monaten Probleme haben.

    Seit dem 15.03. gibt es auch eine neue Version 9.3p1: https://www.openssh.com/txt/release-9.3

    Vielleicht magst Du mir zwei Patches schreiben, um einmal mit 9.1p1 und einmal mit 9.3p1 zu bauen? Wenn Du mir dann sagst, wo ich die in einer vorhandenen VDRSternELEC-Umgebung ablegen muss und wie ich nach Möglichkeit ein neues image bauen kann, ohne alles andere auch neu kompilieren zu müssen, teste ich das.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Wenn man es mal verstanden hat, ist es ganz leicht ;)


    Index of /vdrelec

    ^ Die Patches gehen gegen coreelec-20


    Den betreffenden Patch kopierst du dir nach ./patches/CoreELEC/coreelec-20 und baust danach einfach VDR*ELEC.


    Nochmal eine kleine Erklärung zum Patchverhalten von VDR*ELEC:

    Die Patches im Verzeichnis patches werden auf das CoreELEC Verzeichnis angewendet, bevor sich bei CoreELEC überhaupt was tut. Damit kannst du die packages.mk ändern und somit auch die Paketquellen etc.

    Welche Patches wohin gehen, sieht man hier Und wenn ich mir die patches alle so ansehe "pfuscht" VDR*ELEC an CoreELEC eigentlich gar nicht so großartig rum. Am besten wäre es, wenn hier gar kein Patch sein müsste...


    Alles, was in package_patches ist, wird zusätzlich benutzt zu den patches, die CoreELEC auf die Pakete eh schon anwendet. Daher ist das nach derselben Verzeichnisstruktur organisiert, wie bei CoreELEC. Das Verzeichnis wird eigentlich vor dem Build nur kopiert, so dass diese Patches in den ./patches-Verzeichnissen der einzelnen Pakete landen.


    Wenns openssh nicht ist, könnts evtl. auch der Kernel sein ... Viel Glück


    Gruß

    Andreas

  • Den betreffenden Patch kopierst du dir nach ./patches/CoreELEC/coreelec-20 und baust danach einfach VDR*ELEC.

    Danke!

    Der Versuch mit dem downgrade auf openssh-9.1p1 bringt leider das gleiche Problem.

    Dann habe ich einfach mal die kernel.img und kernel.img.md5 von der funktionierenden SD-Karte (Stand 17.03.) genommen und damit die Dateien auf der neuen SD-Karten ersetzt. Wieder gleicher Fehler. ;(

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Puh. Dann hilft wohl nur bisecten. Aber vorher würde ich aber ein aktuelles, reines CoreELEC probieren. Dann weißt du zumindest, ob es CE oder VDR*ELEC ist... Tut mir leid für dich, dass das so kompliziert ist... Hier tuts seit Wochen stabil. Aber mit Rockchip und LibreELEC.

  • Zabrimus Nachdem es in der aktuellen Konstellation relativ kompliziert ist, ein Problem durch bisecting herauszufinden, hätte ich folgenden Denkanstoß: Wie wäre es, neue Versionen von CoreELEC/LibreELEC manuell mit einem eigenen commit zu pushen und nicht immer den Stand zu holen, der im jeweiligen branch gerade HEAD ist. Das hätte den Vorteil, dass man keine Vorabpatches mehr braucht und wirklich nur updated, wenn die CE/LE Version baut und auch läuft. Wäre zwar nicht mehr bleeding edge, aber nah dran.

    Bei der Fehlersuche kann man einen bisect auf VDR*ELEC durchführen und den Fehler auf VDR*ELEC oder CE/LE eingrenzen. Was denkst du? Sowas würde hier die Fehlersuche vereinfachen...

  • @reel

    Ursprünglich war es vorgesehen, eine bestimmte Revision von CE/LE zum bauen zu verwenden. Dazu gibt es in den Configs die Revision

    Code
    DISTRO=CoreELEC
    BRANCH=coreelec-20
    TAG=
    REVISION=

    Aber ich habe das gerade mal getestet, weil ich das lange nicht mehr gebraucht hatte. Und es funktioniert nicht, wie gewünscht. Mir ist noch nicht klar, warum eigentlich nicht. Irgendetwas muss ich unterwegs kaputt gemacht haben.


    Eine Schwierigkeit besteht darin, überhaupt herauszufinden, ob alles funktioniert. Nach welchen Kriterien? Ich könnte natürlich das Release erst dann erstellen, wenn bestimmte Kriterien erfüllt sind (z.B. baut eine bestimmte CE oder LE Version). Aber selbst, wenn es baut, scheint es passieren zu können, daß es trotzdem nicht so arbeitet, wie gewünscht.


    Und du meinst, auf das Update von LE/CE zu verzichten und stattdessen nur funktionierende Versionen der Submodule zu verwenden. Aber auch da gibt es die Frage nach den Kriterien.

    Der aktuelle Vorteil ist, daß ich relativ wenig Aufwand habe und nur eingreifen muss, wenn mal etwas schief läuft. Wobei das für meinen Geschmack schon zu oft passiert.


    Was man natürlich machen könnte (das sollte hoffentlich funktionieren, muss noch testen ob wenigstens das noch geht), nur echte CE/LE Releases zu verwenden - also bestimmte Tags. Das hätte den Vorteil, daß die VDR Plugins aktuell gehalten werden können, aber hoffentlich nur funktionierende Versionen von CE/LE verwendet werden. Dann würden die ganz Zufallsversionen den Selbstbauern überlassen werden. Und ich müsste nicht Problemen mit den Paketen hinterherhecheln, weil es immer wieder einen Commit/Update gibt, bei dem etwas nicht mehr baut.


    Zum dem ssh Problem fällt mir so gar nichts ein. Ich bin die Commit-Historie durchgegangen und finde keinen offensichtlichen Commit, der das Problem verursachen könnte. Die CE Kernel ändern sich auch nicht so häufig. In VDR*ELEC selbst sollte das Problem eigentlich nicht sein. Man müsste irgendwie an das Log kommen um zu sehen, ob da etwas zu finden ist. Es ist nur schwierig, wenn man nicht auf die Maschine kommt.


    Bei mir mache ich die ssh Authentifizierung nur per ssh key, nutze also gar kein Login/Passwort. Auch einfach nur, weil mir irgendwann zuviel Aufwand war und zu lange gedauert hat. Dazu müssen nur in /storage/.ssh die keys und die config abgelegt werden.

  • Das Problem mit dem brach/tag/revision liegt am build script. Wenn branch nicht gesetzt ist, scheitert das script an an paar Stellen, wo $BRANCH abgefragt wird.


    Es wäre schon ein Vorteil, die CE/LE Versionen manuell zu pushen, da es die Versionsgeschichte von VE und CE verknüpft und ein bisecting au VE möglich macht. Das wäre ja kein Hindernis, trotzdem nah am bleeding edge zu bleiben, falls man das will.

    Sollte mal ein push von CE/LE nicht mehr funktionieren, könnte man den commit auch reverten und ändert damit nur die CE Version.


    Verschiedene branches und sha bedingen unter Umständen einen höheren Aufwand in VE bzgl. Patches. Ich denke, man muss sich entscheiden, was man will.


    Ich persönlich würde zwischendrin immer mal wieder die CE Version pushen oder aber bei der stable bleiben (maximal aber mit stable und bleeding edge 2 Stände parallel führen). VE sollte dafür verantwortlich sein, die VDR Komponenten mit aktuellstem Stand aufzusatteln und nicht aktuelle Fehler in CE (vorab) zu reparieren.

    Mein PR bei CoreELEC wegen RTL8821CU liegt da z.B. schon ein paar Tage unbeantwortet. Das ist für das Tempo, das du aktuell bei VE vorgibst, zu langsam. An sich auch nicht schlimm, aber das fixen sollte dann auch Sachdn von CE sein und bleiben. Der Mehrwert einer aktuellsten CE/LE steht m.E. nicht im Verhältnis zum Aufwand, den man bei VE dann für Vorab-Fixes hat.


    Aber das ist nur meine persönliche Meinung ;)

  • Zum dem ssh Problem fällt mir so gar nichts ein. Ich bin die Commit-Historie durchgegangen und finde keinen offensichtlichen Commit, der das Problem verursachen könnte. Die CE Kernel ändern sich auch nicht so häufig. In VDR*ELEC selbst sollte das Problem eigentlich nicht sein. Man müsste irgendwie an das Log kommen um zu sehen, ob da etwas zu finden ist. Es ist nur schwierig, wenn man nicht auf die Maschine kommt.

    Ich habe das nochmal weiter versucht zu debuggen. Man kann in /storage/.cache/services/sshd.conf optionale Argumente vorgeben. Das habe ich mit gemounteter STORAGE-Partition an meinem Arbeitsrechner gemacht, und zwar

    Code
    SSH_ARGS="-E /storage/log/sshd.log"

    Die sshd.log habe ich dazu angelegt. Dann SD-Karte wieder in die Tanix, gebootet und eingeloggt. Wie gehabt wird ssh-Verbindung aufgebaut und sofort geschlossen. Dann wieder am Arbeitsrechner nachgesehen, was auf der SD-Karte geloggt wurde. Ist leider nicht aussagekräftig. Nach den Zeilen

    Code
    Server listening on 0.0.0.0 port 22.
    Server listening on :: port 22.

    kommen noch ein paar kryptische Zeichen, die man nur im nano sieht, und dann nichts mehr.


    Nächster Versuch:

    Diesmal habe ich die ssh-Verbindung an meinem Arbeitsrechner mit der Option -vv durchgeführt, dabei werden Informationen von beiden Seiten angezeigt. Den Teil ab der Passwortabfrage habe ich mal angehängt. Schlau werde ich daraus nicht. Aber

    Code
    debug2: channel 0: output drain -> closed
    debug2: channel 0: almost dead
    debug2: channel 0: gc: notify user
    debug2: channel 0: gc: user detached
    debug2: channel 0: send close
    debug2: channel 0: is dead

    klingt nicht gut =O

    Files

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Dr. Seltsam Google hast du sicher schon ausgiebig gefüttert, aber was passen könnte wäre z.B. Hinweise auf eine kaputte .profile oder andere .bash*irgendwas Datei, die nach dem Login gelesen wird. Kannst du mal schauen, ob damit was nicht passt?

    Kannst du direkt mit ssh Befehle ausführen ohne dich einzuloggen bzw. eine Shell zu öffnen?

  • Ja, es gibt diverse Tips dazu, die mich aber nicht weiterbrachten. Ich habe dann heute nochmal ein neues image gebaut und getestet. Nun kam in CoreElec beim Einrichten des sshd-Passwortes zum ersten mal eine Fehlermeldung, dass mein gewähltes Passwort unsicher sei, da es im Internet hinlänglich bekannt sei. Ich habe dann ein neues Passwort vergeben. Danach klappte das Einloggen dann auch. Ich hoffe, der Fehler tritt nicht mehr auf.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich habe die aktuelle Version gestern gebaut (für Raspi4), und prinzipiell funktionieren Kodi und VDR.

    Im VDR gibt es allerdings das Problem, dass das System in eine "Bootschleife" geht, wenn ich in den DVB-Einstellungen versuche, Untertitel zu aktivieren.

    Dabei ist es so, die Einstellung "Untertitel aktivieren" schon von vorneherein auf "ja" steht und sich nicht dauerhaft auf "nein" stellen lässt; nach einem Neustart steht sie wieder auf "ja".

    Sobald ich aber die Einstellungen für "Untertitel-Sprache(n)" vornehme, kommt es kurz hinterher zur erwähnten Bootschleife...


    Hat jemand eine Idee?


    Walter

  • Im VDR gibt es allerdings das Problem, dass das System in eine "Bootschleife" geht, wenn ich in den DVB-Einstellungen versuche, Untertitel zu aktivieren.

    Du meinst keinen echten reboot, oder? Stürzt VDR ab und startet neu? Was steht denn im Log?

    Code
    journalctl -xef

    Dabei ist es so, die Einstellung "Untertitel aktivieren" schon von vorneherein auf "ja" steht und sich nicht dauerhaft auf "nein" stellen lässt; nach einem Neustart steht sie wieder auf "ja".

    Stop mal vdr und ändere manuell die setup Einträge. In der Datei

    /storage/.config/vdropt die beiden Einträge so ändern

    Code
    DisplaySubtitles = 0
    SubtitleLanguages =

    Restart des VDR oder reboot.

  • Du meinst keinen echten reboot, oder? Stürzt VDR ab und startet neu? Was steht denn im Log?

    Du hast recht, es ist kein richtiger reboot, sondern der VDR stürzt ab und startet dann wieder.


    Im Log sieht es so aus:


    Das Einstellen von "DisplaySubtitles =0" (hatte ich in der setup.conf bislang übersehen) bewirkt in der Tat, dass in den DVB-Einstellungen "Untertitel aktivieren" gar nicht mehr erscheint.


    Allerdings hilft mir das nicht weiter; ich hätte halt gerne Untertitel...

  • Das kann evtl. am softhddevice-drm-gles liegen und muss ich mir in den nächsten Tagen ansehen. Du kannst vorerst mal softhddevice-drm testen.

Participate now!

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