[yavdr-ansible] Doku für die Ubuntu Server Installation?

  • Hallo,


    ich würde gerne mal yavdr-ansible ausprobieren. Leider fehlt unter https://www.yavdr.org/document…ntation.html#installation das Kapitel 1.2.2 zur Ubuntu Server Installation noch. Ich scheitere schon an der Anweisung "wichtig: ISOs für den alternative Ubuntu Server Installer nutzen" in 1.2, da ich unter https://releases.ubuntu.com/20.04/ nur ein Ubuntu Server ISO (https://releases.ubuntu.com/20…4.2-live-server-amd64.iso) finde. Ist das das richtige? Das bootet, scheint dann aber auf ein kompletten Remote Setup Prozess per SSH ausgelegt zu sein.


    Könnte mir da jemand ein paar Tipps geben? Wie ich das System bis zu dem Punkt bringen kann, an dem es dann in der Doku wieder mit Ansible weiter geht? Ziel sollte ein lokaler VDR (kein headless Server o.ä. sein).


    Gruß,

    Reiner

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Für Ubuntu 20.04 kann man problemlos das live-server ISO nutzen. Falls du den Legacy-Installer brauchst, bekommst du den mittlerweile hier: http://cdimage.ubuntu.com/ubun…r/releases/20.04/release/


    Für den Installationsvorgang mit dem Live-Installer inkl. Anmeldung über SSH (man kann das alles auch problemlos direkt am Gerät machen, mir ging es nur mal darum das auszuprobieren) hatte ich mal OBS mitlaufen lassen (interessant sind da vermutlich nur die ersten zwei Minuten, danach rödelt die VM vor sich hin, bis der Installationsvorgang durch ist und man einen Neustart machen kann:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke seahawk1986 , mit dem legacy installer aus dem Link konnte ich Ubuntu installieren. Der neue Installer ist reproduzierbar immer beim anlegen der Partitionen gescheitert, obwohl die SSD komplett leer war (mit gparted gecheckt).


    Nach der Installation habe ich dann das sudo -H ./install-yavdr.sh laufen lassen. Das liefert einen Fehler beim TASK [yavdr-xorg : unload kms drivers]:


    Sollte ich das Skript nochmal ausführen?

    Files

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Sollte ich das Skript nochmal ausführen?

    Ja, aber zuerst den Rechner neu starten, damit der noveau-Treiber nicht mehr geladen wird. Bei einigen älteren nvidia-Karten klappt das Entladen des Treibers zur Laufzeit leider nicht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nach dem reboot bricht das Skript jetzt hier ab:

    sudo journalctl -xe -u x-verbose@vt7.service gibt das hier aus:


    Ich vermute, das liegt daran, dass auf dem System der Gnome Desktop läuft. Den hatte ich installiert weil es in der Doku hieß, das der X-Server über den Ubuntu Installer konfiguriert werden soll. Da hab ich dann dort das Ubuntu Gnome Desktop Paket ausgewählt. War das ein Fehler?


    Ich hab noch mal einen reboot gemacht, und das Skript nochmal neu gestartet, aber die Fehlermeldung ist wieder die gleiche.

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Ich vermute, das liegt daran, dass auf dem System der Gnome Desktop läuft.

    Genau, es darf kein Login-Manager installiert sein, das Playbook richtet eigene Systemd-Units ein, um den X-Server zu starten und wenn da schon etwas anderes läuft, kann die Bildschirmerkennung nicht klappen.


    Den hatte ich installiert weil es in der Doku hieß, das der X-Server über den Ubuntu Installer konfiguriert werden soll. Da hab ich dann dort das Ubuntu Gnome Desktop Paket ausgewählt.

    Ich vermute du beziehst dich auf diesen Satz:

    Zunächst wird eine Ubuntu Server Installation (wichtig: ISOs für den alternative Ubuntu Server Installer nutzen, damit Bootsplash, X-Server und Abhängigkeiten zu bestehenden Netzwerkverbindungen korrekt funktionieren) durchgeführt, bei der der Nutzer beliebige Point-Releases (und damit neuere Kernel) wählen kann.

    Das ist dann wohl von mir suboptimal formuliert - der Text in den Klammern bezieht sich auf die Gründe für die Nutzung des Alternate Installers (der bei Ubuntu 18.04 nötig war, weil ich damals noch nicht soweit war cloud-init automatisiert vom System zu werfen, das sich in den Start diverser Dienste wie z.B. Plymouth, systemd-networkd und des X-Servers einmischt). Ich habe den Text mal etwas überarbeitet, damit das hoffentlich klarer wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, das war genau der Satz, den ich falsch verstanden habe. Dann mache ich die Ubuntu Installation einfach nochmal ganz neu. Macht ja jetzt keinen Sinn an dem bereits vergurkten System weiter zu frickeln.


    Brauche ich für suspend eigentlich eine separate Swap Partition? Die Ubuntu Server Installation legt von sich aus ja erst mal keine an. Die würde ich dann auch gleich mit anlegen.

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Nach der Ubuntu Neuinstallation ohne X11 lief das Skript erfolgreich durch und ich hab jetzt zumindest mal ein Bild :-)


    Leider scheint die Fernbedienung (eine Hauppauge RC5 Fernbedienung mit einem TSOP-Homebrew IR Empfänger an ttyS0 nicht zu funktionieren, obwohl serial_ir_device: ttyS0 in host_vars/localhost gesetzt ist. Eine definition der FB habe ich (mit den vorgeschriebenen KEY_* Namen in /etc/lirc/lircd.conf.d angelegt und auch die lirc_options.conf so angepasst, wie es unter Debian 10 funktioniert hatte. Es wird aber scheinbar kein lircd dafür geladen. Kannst Du mir da noch etwas weiterhelfen seahawk1986 ?

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Eine definition der FB habe ich (mit den vorgeschriebenen KEY_* Namen in /etc/lirc/lircd.conf.d angelegt und auch die lirc_options.conf so angepasst, wie es unter Debian 10 funktioniert hatte

    Die seriellen Empfänger laufen über rc-core (vgl. https://www.yavdr.org/document…entation.html#ir-keytable) und eventlircd liest direkt vom für den Empfänger angelegten Kernel Input Device, lircd bleibt dabei unter yaVDR komplett außen vor und sollte deaktiviert bleiben.


    https://github.com/yavdr/yavdr…r/rc_keymaps/rc-hauppauge ist eine Beispiel-Keymap, die man in der /etc/rc_maps.cfg für den Empfänger hinterlegen kann (standardmäßig ist da eine rc-6 MCE Keymap gesetzt - vgl. https://github.com/yavdr/yavdr…plates/rc_maps.cfg.j2#L36)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die seriellen Empfänger laufen über rc-core (vgl. https://www.yavdr.org/document…entation.html#ir-keytable) und eventlircd liest direkt vom für den Empfänger angelegten Kernel Input Device, lircd bleibt dabei unter yaVDR komplett außen vor und sollte deaktiviert bleiben.

    Mein Empfänger wird irgendwie nicht richtig erkannt: Wenn ich ir-keytable -c -p all -t ausführe (nachdem eventlircd wie in deiner Anleitung beschrieben gestoppt wurde), bekomme ich nur:

    Code
    1. /sys/class/rc/: Datei oder Verzeichnis nicht gefunden
    2. keine Geräte gefunden

    Das serial_ir Kernel Modul ist auch nicht geladen. Wenn ich es händisch mit modprobe serial_ir lade, wird es sauber geladen und lädt auch das rc_core Modul mit. Dann ist die erste Zeile der obigen Fehlermeldung weg, aber ir-keytable gibt weiter "keine Geräte gefunden" aus. Sollte der Ansible Task das serial_ir Modul nicht so konfigurieren, dass es automatisch geladen und für das im yaml angegebene Device konfiguriert wird?

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Sollte der Ansible Task das serial_ir Modul nicht so konfigurieren, dass es automatisch geladen und für das im yaml angegebene Device konfiguriert wird?

    Serielle Empfänger können nicht über udev erkannt werden, man muss also dem Playbook explizit sagen, dass es die Rolle für den seriellen Empfänger ausführen soll (vgl. https://www.yavdr.org/document…mentation.html#org83ca2be) - dazu entfernt man die Raute vor dem Eintrag für serial-ir in https://github.com/yavdr/yavdr…lob/focal/yavdr07.yml#L42 - hast du das gemacht, bevor du das Playbook ausgeführt hast?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • dazu entfernt man die Raute vor dem Eintrag für serial-ir in https://github.com/yavdr/yavdr…lob/focal/yavdr07.yml#L42 - hast du das gemacht, bevor du das Playbook ausgeführt hast?

    Nein, natürlich nicht :-( Den Teil habe ich dann auch noch missverstanden. Ich dachte, das würde über das setzen von serial_ir: ttyS0 in der host_vars/localhost aktiviert, weil es in der Doku hieß "Die in dieser Datei definierten Variablen übersteuern die Vorgabewerte aus dem Playbook und der group_vars/all.".

    Da dachte ich, dass alles über das setzen von Variablen passiert.

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Wofür ist eigentlich die Rolle autoinstall-virtualbox-guest im yavdr07.yml?

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Wofür ist eigentlich die Rolle autoinstall-virtualbox-guest im yavdr07.yml?

    Wenn man das Playbook in einer VirtualBox-VM laufen lässt, installiert er über diese Rolle die Gasterweiterungen und wählt vdr-sxfe für die Ausgabe, weil softhddevice mit einer virtualisierten Maschine ohne Hardwarebeschleunigung nicht funktioniert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • https://github.com/yavdr/yavdr…r/rc_keymaps/rc-hauppauge ist eine Beispiel-Keymap, die man in der /etc/rc_maps.cfg für den Empfänger hinterlegen kann (standardmäßig ist da eine rc-6 MCE Keymap gesetzt - vgl. https://github.com/yavdr/yavdr…plates/rc_maps.cfg.j2#L36)

    Nachdem das serial_ir Modul jetzt korrekt geladen wird, habe ich in /etc/rc_maps.cfg die Zeile für serial_ir so abgeändert:

    Code
    1. serial_ir rc-nexus-s rc-nexus-s

    und eine entsprechende Keymap als /etc/rc_keymaps/rc-nexus-s erstellt:

    Die Codes hab ich über ir-keytable -c -p rc5 -t herausbekommen.


    In VDR funktioniert die Fernbedienung allerdings immer noch nicht. Ich habe dann noch eine Kopie der Keymap nach /lib/udev/rc_keymaps gelegt und den Eintrag in der rc_maps.cfg entsprechend abgeändert, so dass dort dann


    In VDR funktioniert die Fernbedienung allerdings immer noch nicht. Ich habe dann noch eine Kopie der Keymap nach /lib/udev/rc_keymaps gelegt und den Eintrag in der rc_maps.cfg entsprechend abgeändert, so dass dort dann

    Code
    1.  serial_ir rc-nexus-s /lib/udev/rc_keymaps/rc-nexus-s

    steht. Das hat aber auch nichts geändert. Zwischen den Versuchen hab ich immer rebootet.


    Außerdem funktioniert die Audio-Ausgabe über HDMI noch nicht. Ich habe wie in 2.7.3 Deiner Doku beschrieben das zu verwendende Device so in die /etc/pulse/default.pa eingetragen:

    Code
    1. load-module module-alsa-sink device=hw:1,7

    Das macht aber leider auch keinen Unterschied. Mit

    Code
    1. aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Right.wav

    wird der Test-Sound korrekt über HDMI ausgegeben, nur der VDR bleibt stumm.

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Das Sound-Problem hat sich erledigt: Über das VDR OSD Menü konnte ich das Standardausgabegerät im pulsecontrol Untermenü setzen.

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Egal was ich in der /etc/rc_maps.cfg für serial_ir eintrage, das System scheint beim Start immer nur die rc-rc6-mce zu laden:

    Code
    1. [ 5.712725] serial_ir serial_ir.0: auto-detected active low receiver
    2. [ 5.780741] Registered IR keymap rc-rc6-mce
    3. [ 5.807819] IR RC6 protocol handler initialized
    4. [ 5.836858] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
    5. [ 5.837228] rc rc0: lirc_dev: driver serial_ir registered at minor = 0, raw IR receiver, raw IR transmitter
    6. [ 5.837441] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input11

    Hast Du eine Idee, warum die rc-rc6-mce keymap geladen wird, seahawk1986 ? In der rc_maps.cfg habe ich sie für "*" auskommentiert und bei serial_ir steht sie auch nicht mehr drin.

    Files

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • Ich habe testweise auch mal alle Zeilen, in denen rc-rc6-mce erwähnt wird, auskommentiert. Nach dem reboot wird aber trotzdem im dmesg Output angezeigt, das die rc-rc6-mce geladen wurde. Das heißt doch, das die /etc/rc_maps.cfg komplett ignoriert wird, oder?

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)

  • rc-rc6-mce ist die Standard-Keymap für serial_ir, die Meldung wirst du nicht loswerden. Die udev-Regel /lib/udev/rules.d/60-ir-keytable.rules sorgt dafür, dass ir-keytable mit der rc_maps.cfg für jeden erkannten rc-core Empfänger aufgerufen wird und dann die Keytable dafür lädt.


    Du solltest anhand der Ausgabe von ir-keytable sehen können, dass das Protokoll auf rc5 umgestellt wurde, wenn das Laden der Keymap für die Hauppauge Fernbedienung geklappt hat und in der Ausgabe vonir-keytable -r sehen können, dass die Scancodes aus der Datei genutzt werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Du solltest anhand der Ausgabe von ir-keytable sehen können, dass das Protokoll auf rc5 umgestellt wurde, wenn das Laden der Keymap für die Hauppauge Fernbedienung geklappt hat und in der Ausgabe vonir-keytable -r sehen können, dass die Scancodes aus der Datei genutzt werden.

    Das passiert leider nicht. Laut ir-keytable wird rc-5 nicht aktiviert:

    Frontend 1: Intel Atom D525, Digital Devices CineS2 DVB-S2 Karte, yaVDR-ansible

    Frontend 2: Intel NUC, TerraTec Cinergy S2 USB, easyVDR 3.0.0

    Backend: Intel Core i7, Digital Devices CineS2 DVB-S2, Debian 10, vdr (e-tobi)