Posts by speefak

    CPU Tausch - keine Änderung = CPU OK


    RAM Ausgebaut , keine Änderung = Ram irrelevant für ILO, ILO immernoch gleiches Fehlerprofil


    Damit hab ich wohl das Glück das es das MB erwischt hat - es ist zum K**** ² , es ist Freitag, ich hab ne Mandelentzündung und nichts geht mehr, Mediathek Streamen aufm Tablet ist das einzige was geht und das bis Montag - jetzt hab ich grad so richtig den Hass auf HP - wozu kauft man Serverhardware ? Da kann ich mir lieber gleich wieder ein 0815 Consumer PC als Server einrichten, sch***** auf ILO, ECC Ram und den ganze mist ( das funktioniert wahrscheinlich noch )


    PS : ILO geht auch ohne RAM, ggf auch Ohne CPU, Ohne CPU nicht gestestet.


    PSS : Alternative Vorschläge für ein Rechner mit ähnlichen specs wie HassPc Gen 8 für um die 200 €, gebraucht geht auch. Der Dell T30 wurde mal genannt, aber der kost ja al eben 600€ aufwärts.


    Hab grad mal ein anderes Netzteil angeschlossen, gleiches Fehlerprofil. Irgendwie steig ich da nicht ganz durch :


    Code
    1. Power Supplies
    2. Bay Present Status PDS Hotplug Model Spare Serial Number Capacity Firmware1  Not installed    N/A

    Da ist nirgendwo ein sensor - wie will ILO wissen das kein NT installiert ist ?


    Code
    1. Temperatures Not installed

    Auch komisch ... Hat jmd ein HP Gen 8 und kann mal schauen ob im ILO dort werte zu sehen sind wenn der Server aus ist ?

    Sollte das der Fall sein wird ein Mainboard deffekt immer wahrscheinlicher.

    Hab den server jetzt auf Firmware 2.73 geflasched und jetzt wird mysteriös :

    Code
    1. Subsystems and Devices
    2. Agentless Management Service Not available
    3. BIOS/Hardware Health OK
    4. Fans Not installed
    5. Memory Other
    6. Network OK
    7. Power Supplies Not installed
    8. Processors OK
    9. Storage OK
    10. Temperatures Not installed

    Wenn NT im Eimer ist wieso funktioniert ILO dann noch ? Wenn die CPU hin ist funktioniert ILO doch auch nicht mehr oder ist ILO komplett vom System getrennt ? Und der Lüft ist lt. Log auch nicht angeschlossen ?!

    Ist das teil nun hin ? Lohnt sich da noch eine Reperatur zumal ich gar nicht weis was hin ist.


    Was gibt es für aktuellere Alternativen als sich den Gen8 nocheinmal zu kaufen ?

    Ich sitz hier grad echt übelst aufm schlauch, da hier nichts mehr geht. Der gesamte datenbestand ist offline, TV geht nicht mehr, Backups laufen nicht - kurz um hier geht nichts mehr. Das der Server nach nichtmal 4 Jahren den Geist aufgibt hätte ich von HP Produkten nicht gedacht - schon gar nicht von den Serverprodukten :/

    Moin ich musste heute feststellen das mein HP Microserver gestern um 17:44 offline ging. Ich habe nichts an dem server verändert. Aus dem Nichts fuhr er runter und lässt sich jetzt nicht mehr starten.

    Normalerweise start beim Drücken der Powertaste direkt der Lüfter. Und jetzt passiert nichts. Drücke ich den Powerbutton leuchtet dieser grün und 5-10 sek später Blinkt die untere LED Rot.


    ILO geht noch. hier die Logs :


    Was mich grad verweundert :

    Code
    1. 1122 10/01/2020 17:44 10/01/2020 17:44 1 Server power removed.
    2. 1121 10/01/2020 17:44 10/01/2020 17:44 1 Embedded Flash/SD-CARD: Restarted.Embedded Flash/SD-CARD

    Bezieht sich Flash/SD-Card auf den internen Speicher für Firmware ilo und co oder auf den internen USB Steckplatz ?

    Wenn der interne USB Stick ( zum Booten / Grub ) defekt ist warum höre ich dann beim starten nicht mal den Lüfter ?

    Embedded Flash wurde in der Vergangenheit öfters neu gestartet und es kam nie die Meldung :

    1122 10/01/2020 17:44 10/01/2020 17:44 1 Server power removed.


    Soviel zum ILO Eventlog


    Der integrated Management Log grenzt den Fehler schon eher ein :

    Code
    1. 121 Power 01/01/1970 00:01 03/27/2020 12:28 11 System Power Fault Detected (XR: 10 00 MID: FF F5 FE 01 FF FF FF 06 06 00 00 02 00 05 80 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
    2. 120 System Revision 10/01/2019 11:51 10/01/2019 11:51 1 Firmware flashed (iLO 4 2.70)
    3. 119 OS 07/25/2019 14:05 07/25/2019 14:05 1 Automatic Operating System Shutdown Initiated Due to Overheat Condition
    4. 118 Environment 07/25/2019 14:05 07/25/2019 14:05 1 System Overheating (Temperature Sensor 1, Location Ambient, Temperature 42C)


    Wieso wurde ILO geflashed ( Eintrag 120 ) Flasht sich der Server automatisch ? das kann ich mir eigentlich nicht vorstellen, ergo müsste jmd anders das Update angestoßen haben. Auf dem Server läuft Debian 10 ohne X server oder Desktop - gibts da in Debian 10 irgendwas was den Flash ausgelöst haben könnte ( wäre mir allerdings neu ).


    Dann bliebe nur noch jmd von Außen ( Hacker ) aber auch das halte ich für unwahrscheinlich, da der Server gar nicht von INet erreichbar ist und nur als Datenstorage und TV Streaming Server fungiert. Wenn sich jmd Zugriff auf der Server verschafft hätte müsste er über mind. einen weiteren Rechner gehen und auch dort ist nicht auffälliges zu finden, weder in den Logs noch im verhalten des Servers selbst.


    Oder ist vllt einfach nur der Lüfter im Eimer ? Aber das würde man doch in den ILO Logs sehen.


    Es scheint an einem Firmwareupdate zu liegen, wie auch immer das zu Stande gekommen ist.


    Was ist jetzt zu tun ? Firmware/ILO mit der aktuellen Version ( 2.70 ) reflaschen oder eine ältere Version nehmen ?

    Das würde mich auch interessieren, wie verhält es sich denn generell mit BlueTooth Fernbedienungen ? Werden die Über Lirc eingebunden oder wie bekommt man Kodi dazu mit der FB zu kommunizieren ?


    Eine FunkFB ohne Airmouse Funktion ist schon fast eine Seltenheit.


    Oder gibt es eine Möglichkeit die Airmouse Funktion OS seitig ( debian 9/10 ) zu deaktivieren und somit die Auswahl der Möglichkeiten an FB zu vergrößern ?

    Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.

    Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.

    Danke für die Info: mk-build-deps -i <packetname>. Die Installation von vdr-dev als Sourcecodebasis habe ich erfolgreich vorgenommen ( und die der anderen Kompilertools )

    Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.

    Das ist mir seit dem letzten Umsteig von Debian 8 auf 9 klar geworden. Darum wunderte ich mich ja über die Angabe des vdr-plugin-epgsearch Quellcodes aus den o.g. Quellen auf Basis des VDR 2.4.0 und dann wurde vdr-dev 2.4.1 statt 2.4.0 verlangt. 2.4.1 ist aber nicht in den Repos verfügbar und bevor ich mein System wieder mit zig Quellen überlade dachte ich mir es muss auch mit vdr-dev 2.4.0 gehen ( was es mit dem Quellcode link von wolfi-m auch tat. ).


    Die Suche nach dem Passenden Quellcode war nicht so einfach.

    Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.

    Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.

    Darum suchte ich ja eine gepachte vdr-plugin-epgsearch Version die kompatibel zum vdr-dev 2.4.0 ist. Und daran scheiterte es dann. Die VDR ABI zu ändern habe ich seit dem letzten update gelernt möglichst zu vermeiden, da in Folge dessen noch mehr Fehler auftraten.

    Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.


    Nimm es mir nicht übel aber das habe ich vor knapp 3 Jahren schon einmal gemacht und es klappte auch alles wunderbar - Nur leider ist mein Hirn kein USB Stick oder Kristallspeicher und verliert daher die ein oder andere Information in Abhängigkeit des Faktors Zeit. Analytisch bin vorgegangen, einfach nach dem "Try and Error" Prinzip vorzugehen endet beim Kompilieren meist in Chaos.


    In dem Sinn Danke für Infos.


    EDIT : Ein Test Ergab gerade Folgendes Szenario :


    EPG Konflikte werden genau 1 mal im Live Plugin angezeigt, aktualisiert man den Browser nach der Anzeige wird kein Konflikt mehr angezeigt - Timerkonflikt besteht allerdings weiterhin.


    Klickt man im Live Plugin auf den Timerkonflikt wird dieser nicht angezeigt. DAS fenster und der Header der Liste wird angezeigt, aber nicht der Timerkonflikt selbst.


    Solange der Rest stabil läuft kann ich damit leben.

    wie bist du an den Link gekommen ? Unter "https://launchpad.net/~yavdr" fand ich nichts ?!


    funktioniert :

    Code
    1. sudo apt install vdr-dev build-essential devscripts pkg-config libpcre3-dev
    2. sudo apt build-dep vdr-plugin-epgsearch
    3. dget -xu https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc
    4. cd vdr-plugin-epgsearch*
    5. dpkg-buildpackage -us -uc
    6. dpkg -i ../vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic_amd64.deb

    Ich habe den Überblick verloren und stehe hier grad total aufm Schlauch. Ich konnte anhand der Logfiles des VDR das vdr-plugin-epgsearch als Segmentaion fault verursachendes Plugin Identifizieren. Aber jetzt geht der Mist wieder los ( Debian 10 / vdr 2.4.0 aus main Repos )


    Nachgelesen = o.g. Plugin hat im Programmcode eine Fehler in einem Loop => selbst kompilieren


    Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc ) => Datei Offline


    Dann habe ich auf GIT Hub nach e-Tobis code gesucht, in der Repoliste steht eien gepachte version drin, aber ich diese nicht herunterladen.


    Als auch das nicht erfolgreich war habe ich nach einer Debian 10 Quelle für das EPG search Plugin gesucht : (https://packages.e-tobi.net/vd…ch/binary/vdr-multipatch/


    Wie fast immer bei den verfluchten VDR Kompilations Horror lief auch das nicht wirklich.


    Es ist jede mal der gleich Mist : Beim VDR Update läuft danach erstmal nichts stabil und richtig.


    Hier auch : https://salsa.debian.org/vdr-team/vdr-plugin-epgsearch: lt VDR version läuft alles auf vdr 2.4.0.. Die Kopilation endet dann wieder mit :

    Code
    1. dpkg-buildpackage -us -uc
    2. dpkg-buildpackage: Information: Quellpaket vdr-plugin-epgsearch
    3. dpkg-buildpackage: Information: Quellversion 2.4.0+git20190507-2
    4. dpkg-buildpackage: Information: Quelldistribution unstable
    5. dpkg-buildpackage: Information: Quelle geändert durch Tobias Grimm <etobi@debian.org>
    6. dpkg-buildpackage: Information: Host-Architektur amd64
    7. dpkg-source --before-build .
    8. dpkg-checkbuilddeps: Fehler: Nicht erfüllte Bauabhängigkeiten: vdr-dev (>= 2.4.1)
    9. dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
    10. dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)


    Warum wird vdr-dev 2.4.1 verlangt wenn doch 2.4.0 als Code Grundlage genutzt wird ?



    Es wäre nett wenn mir helfen könnte, wie ich das vdr-plugin-live kompilieren kann, was ich außer den Standartkpompilertools noch brauche und wo ich welche Software herbekomme, was ich genau an Paketen installieren muss.


    Gibt es keine Möglichkeit, das System anhand des installierten VDR kompilierbereit zu machen ( apt install "alles was zum kompilieren von $(dpgk -l | grep vdr ) nötig ist ) , dann den aktuellen passenden Plugin Quellcode von "keine was wozu wie passt" laden und kompilieren. Was bei viele anderen Programmen recht Problemlos klappt endet beim VDR jedes mal in Tagelangen Read-Compile-Frustration Horror.


    EDIT : lt. :

    Code
    1. dpkg -l | grep epg
    2. ii vdr-plugin-epgsearch 2.2.0+git20170817-2 amd64 VDR plugin that provides extensive EPG searching capabilities

    ist jetzt eine 2te Version des Plugins installiert worden. Ist das EPG Search Confict Programmteil deaktiviert worden ? Der VDR läuft zwat jetzt ( stabil ??? ) auch mit dem epg search plugin, meldet nur keine Timerkonflikte mehr. Wäre für mich akzeptabe solange der vdr denn endlich stabil läuft und die Suchtimer laufen.

    Grad getestet : In Version :

    Code
    1. show_sources vdr vdr-plugin-epgsearch
    2. vdr | 2.4.0-1+b1 | http://deb.debian.org/debian buster/main amd64 Packages
    3. vdr | 2.4.0-1 | http://deb.debian.org/debian buster/main Sources
    4. vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main amd64 Packages
    5. vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main Sources

    wurde der epg conflict check deaktiviert. Der VDR läuft stabil, Timer etc läuft alles, Timerkonflikte werden ignoriert. Frei nach dem Prinzip " Wer zuerst kommt mahlt zuerst" werden die Timer abgearbeitet.

    Bin mal gespannt ob der VDR länger 1-2 Stunden läuft ....

    Oft bezahlt man gerade bei Komplettlösungen, wie es die Massen NAS Systeme nun mal sind, mit eingeschränkten Konfigmöglichkeiten. Gern werden auch sinnlose Features ( oder teils sogar Bugs ) als ach so tollen Zusatz beworben. So hab ich auf Mineralwasser auch schon groß gelesen : "Neu ! Jetzt Laktosefrei und für Veganer geeignet". Ist in der IT Welt nicht anders - Alle bekloppt *fg


    Ergo : Alles muss man selber machen !


    Ich verfahre folgendermaßen : NAS unverschlüsselt ( macht bei 24/7 auch nicht so viel Sinn ) dafür liegen auf dem NAS LUKS Container für alles Mögliche. Die LUKS Container werden via sshfs auf den jeweiligen Clients entschlüsselt. Hat den Vorteil, dass bei einem Kompromittieren NAS keine Schlüsseleingaben abgefangen werden können und das NAS nicht entschlüsseln muss.


    Alternativ könnte man eine Prüfsumme aus fest verbauten ( also Geräte, die immer online sind wie z.b. der Router ) Netzwerkgeräten genieren. Damit hätte man einen Schlüssel der Automatisch erzeugt wird und das System entschlüsselt. Startet man das NAS in einem anderen Netzwerk ( NAS wurde geklaut und steht beim Dieb zu Hause ) wird kein oder der falsche Schlüssel generiert. Man könnte auch ein Altes Handy nehmen und nur wenn dieses im WLAN ist wird nach dem o.g. Muster der Schlüssel generiert - das wäre auch DAU tauglich.



    Code
    1. EncKey=$(arp -a | grep -w '(192.168.1.1\|192.168.1.2)' | tr -d [[:cntrl:]] > /tmp/file && md5sum /tmp/file | cut -d " " -f1 && rm /tmp/file)
    2. echo $EncKey





    Ob das allerdings mit den "DAU" Systemen der Hersteller möglich ist bezweifle ich allerdings.

    Vvdrctl ist bequem aber das geht zur noch manuell. Wichtig ist das Zusammenspiel der conf Dateien deren Verlinkung und Inhalt. Funktioniert wie beim Apache, find' ich klasse.


    In dem Sinne : Danke ;)


    PS : für versierte User wäre ein Hinweis "Configaufbau wie beim Apache" sehr hilfreich.

    Die Seite hatte ich gestern auch des öfteren aufm Schirm. (https://github.com/yavdr/vdr/blob/master/debian/vdr.service ). Nach 6 Stunden Server einrichten dachte ich, mal eben vdr noch einrichten und fertig - war wohl nix :/. Habs gestern noch mit nem cronjob gelöst, allerdings griffen die Configs dann nicht mehr. Die Datei /etc/default/vdr ist damit überflüssig wenn ich das richtig verstanden habe.


    Die vdr Konfiguration erfolgt jetzt z.B. in /etc/vdr/conf.avail/vdr.conf und wird dann in gegen /etc/vdr/conf.d/00-vdr.conf verlinkt ( sieht lt. vdr Dateistruktur so aus). Die genaue vdr.conf Struktur ist mir allerdings nicht so ganz klar. Im Netz finden sich zig Infos zu den Startparametern aber keine wie die vdr.conf auszusehen hat und ob die Startparameter mit der gleichen Syntax dort definiert werden wie im VDR Wiki gelistet ( http://www.vdr-wiki.de/wiki/index.php/VDR_Optionen ).

    Die vielen Infos sind teils widersprüchlich und verwirrend. Lt. http://www.vdr-wiki.de/wiki/index.php/Struktur sind die Configs in /var/lib/vdr statt in /etc/vdr. Lt. aktuellen Infos sind die Configs aber doch in /etc/vdr. Bei den ganzen VDR Anleitungen und Wikis fehlt in vielen Fällen die Versionsangabe was eine Strukturzuordnung nicht ermöglicht.


    Eine kurze Info zum Aufbau der vdr.conf wäre hilfreich ;)


    EDIT : s. Verständnisfrage zu /etc/vdr/conf.d

    Die Rechte der Aufnamen scheinen auch anders vergeben zu sein.


    Unter Debian 9 vdr v? waren die Aufnahmen mit vdr.vdr gesetzt. Jetzt mit Debian 10 und vdr v2.4 ist es root.root

    Ich hatte den Ordner /var/lib/video damals versuch via Link umzumappen, dies scheiterte allerdings oft an den Rechten. Jetzt ist die Verlinkung als root von

    /var/lib/video -> /mnt/fstab_UUID_System_storage/vdr_recdir/ ohne Fehler möglich.


    den VDR Starte ich jetzt einfach über ein @reboot cronjob

    systemd - bisher konnte ich mich davor erfolgreich drücken. Nach dem vdr Update von Debian 8 auf 10 steh ich nun ratlos da.


    Das Liveplugin sowie sämtliche in der /etc/vdr/default befindlichen Startparameter werden nicht geladen. Wie kann ich Debian 10n dazu bringen den VDR direkt zu starteb ( kein crontab oder /etc/rc.local, sondern mit sytemd )


    Wo muss ich nachgucken um dem Grund für den Fehler im Live Plugin zu finden ?