Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Linux Pakete]

Also... deine v0.13.0-Binary läuft auf meinem RPi 5 dlueth

Die, die ich hier gerade angehângt hatte? easy4me

Zitat von dlueth

Vielleicht könnte mal einer von den RPI 5 Usern mit Bookworm folgende Binary ausprobieren bitte: https://filetransfer.io/data-package/6O1WVWYz#link

Diese Datei meine ich...

Ok, dann war das die Testversion, das ist schonmal gut! Und die andere, aus dem repo, lief ja problemlos unter bullseye?

Pagesize war 4k unter bullseye und 16k unter bookworm, korrekt?

Was den Docker angeht ist das echt mistig. Ein Image kann Multi-Arch sein und Docker wählt das zur Architektur passende Image selber aus (amd64/arm64/arm). Allerdings interessiert ihn dabei die Pagesize natürlich nicht und es gibt auch keine Möglichkeit Images für die gleiche Architektur bei unterschiedlicher Pagesize zu hinterlegen.

Es wird vermutlich darauf hinauslaufen, dass ich neben dem normalen Docker-Tag noch spezielle für den Pi bereitstellen muss. Diese dann an die zugrundeliegende Debian-Version zu hängen macht nicht wirklich Sinn, oder? Die Umstellung erfolgte zwar mit Umzug zu Bookworm, allerdings kann man den Kernel ja via config wieder auf 4k Pagesize zurückdrehen. Ergo erscheint es mir am sinnigsten ggf. sowas wie rpi-4k und rpi-16k zu verwenden.

Was meint Ihr?

Ich hoffe, das ist nicht zu sehr off topic - hat jedenfalls mit der aktuellen Diskussion zu tun, und möglicherweise kommt ja was hilfreiches bei raus.

Wo liegt denn genau die Abhängigkeit von der page size? Ich hätte erst Mal erwartet, dass Anwendungsprogramme nicht direkt von der Page Size abhängig sind (möglicherweise für spezifische Funktionen verwendete lib wie glibc schon, aber die ist ja schon passend im System). Spezifische Techniken, wie memory mapped files, sind abhängig von der page size. Aber dafür gibt es dann den getpagesize(2) Aufruf, was ein Anwendungsprogramm wiederum unabhängig von der tatsächlichen page size macht. Ist die page size hier irgendwo (möglicherweise implizit) hart codiert in den Programmen? Vielleicht kann man das dann relativ einfach im Quellcode fixen?

Ich hatte früher u.a. Linux Binaries eines eigenen Programms "vertrieben" (= verschenkt ...). Nach meiner Erinnerung liefen die identischen Binaries unter Linux Distributionen mit large page size und mit normal page size - ohne dass ich mir jemals Gedanken dazu gemacht habe.

buers Ich bin mir da ehrlich gesagt nicht ganz sicher. Ich bin zwar Softwareentwickler, allerdings weniger auf der Binary-Ebene. Ich glaube wir können Docker an der Stelle auch außen vor lassen, denn es läuft ja schon die "Standalone-Binary" nicht, ohne Docker.

Grundsätzlich sind die vermeintlich statischen Binaries (die via Nuitka aus Python-Code erstellt werden) eben nicht wirklich "statisch", da sie durchaus Libs aus dem Betriebssystem brauchen und mitbringen. Ich bin jetzt gerade nicht sicher, ob es der "Binary"-Teil ist, der Probleme macht oder der Lib-Part (die ja aus dem erstellenden System kommen). Nimmst Du das Archiv einer Binary und entpackst es, siehst Du auch die Libs die inkludiert sind. Ich baue meine Binaries im Docker auf Basis von Debian Buster mit Python 3.9.

Was ich jetzt testweise einfach mal gemacht habe ist, dass ich ein anderes Baseimage, nämlich ein Pi OS mit Python 3.9 auf Basis von Bookworm verwendet habe. Das scheint so weit zu laufen. Ich kann Dir aber nicht sagen, ob die Pagesize dabei jetzt beim erstellen der Binary wichtig ist oder schlicht die Libs entsprechend mit einer anderen Pagesize erstellt wurden.

Es könnten rein die Libs sein, denn ich meine mich zu erinnern, dass ich mal per E-Mail einen Kontakt zu einem QNAP-Nutzer hatte wo das OS auch eine andere Pagesize hatte. Und der hat, meine ich, einfach die Libs im Archiv ausgetauscht, nach dem Entpacken, und es lief - meine ich.

ergänzende Frage noch in Bezug auf die RPIs dieser Welt: Gibt es diesen Pagesize Wahnsinn nur bei 64 bit oder auch bei den 32 bit Varianten von Pi OS?

Kann hierzu leider nichts sagen, alle RPis laufen hier nur mit 64bit OS.

appleshooter: Hinweis: Unter Debian 12 Bookworm startet der Dienst bei mir nach dem Update von 13.4 auf 13.7 nicht mehr (Error libc.so.6: version `GLIBC_2.38' not found). Höchste Version in Bookworm Stable Repository ist 2.35.

Mir geht es exakt genauso wie Frankschm denn bis 13.4 hat alles wunderbar funktioniert mit den Updates.

Mein System ein Container in Proxmox:

Ubuntu 22.04.5 LTS (GNU/Linux 5.19.17-2-pve x86_64)

Ein System Update bringt keine Besserung.

Die geforderte Version Glibc.so.6: version ist leider zu hoch für ein Ubuntu 22.04.5 LTS

Das gibt das System her:

root@Telerising:~# /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3.9) stable release version 2.35.

Wie gesagt, der Dienst leider startet nicht.

root@Telerising:~# /etc/telerising/api
/etc/telerising/api: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /etc/telerising/api)
/etc/telerising/api: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /etc/telerising/api)
/etc/telerising/api: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by /etc/telerising/libexpat.so.1)
/etc/telerising/api: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /etc/telerising/libexpat.so.1)

Ein libc6 Update hab ich versucht aber die neuste Version ist auf dem System.

root@Telerising:~# sudo apt-get install -y libc6
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libc6 is already the newest version (2.35-0ubuntu3.9).
0 upgraded, 0 newly installed, 0 to remove and 34 not upgraded.
root@Telerising:~#

Da ein System Update keine Lösung bring, was könnte ich noch tun um der hohen glibic Version gerecht zu werden.

Eine Release Upgrade von Ubuntu hat schwere Folgen. Das System startet gar nicht mehr.

failed waiting for client: timed out
TASK ERROR: command '/usr/bin/termproxy 5900 --path /vms/104 --perm VM.Console -- /usr/bin/dtach -A /var/run/dtach/vzctlconsole104 -r winch -z lxc-console -n 104 -e -1' failed: exit code

Update:

Auch habe ich als Anfänger versucht die geforderte Version 2.38 selber zu bauen.

Ich habe fehlende Pakete nach installieren mit apt install gawk bison -y

und mich an diese Anleitung gehalten:

Wie man glibc aktualisiert | Tutorials | Tinkink

Das hat leider nicht funktioniert und lieferte einige Fatal error.

Nun bin ich mit meinem Latein am Ende.

Als Anfänger fällt mir leider nichts mehr ein und würde mich über ein Tipp sehr freuen wie ich das GLIBC_2.38 Problem lösen kann.

Gruß Joerg1909

Aktualisiere das System auf Ubuntu 24.04

Hab ich alles versucht aber leider ist danach ist der Proxmox Container nicht mehr gestartet.

failed waiting for client: timed out
TASK ERROR: command '/usr/bin/termproxy 5900 --path /vms/104 --perm VM.Console -- /usr/bin/dtach -A /var/run/dtach/vzctlconsole104 -r winch -z lxc-console -n 104 -e -1' failed: exit code

Mal schauen wie man das lösen kann.

Update gelöst:

1. Proxmox Update durchgeführt. (War notwendig sonst scheitert das Ubuntu Release update im LXC).

2. Ubuntu aktualisiert.

3. Telersing update durchgeführt.

(Dabei darf das update nicht mehr einfach so runtergeladen und installiert werden sonst passiert das:

Download is performed unsandboxed as root as file '/root/telerising_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) )

Also Verzeichnis anlegen und von dort installieren. z.B ein neues Verzeichnis erstellen und von dort installieren: /home/Download/updates

4. Wireguard config mußte überarbeitet werden da es nicht mehr startete.

5. Der Telerising - Start mußte wieder verzögert werden.

Und jetzt läuft es auch in der aktuellen Version.

Gruß Joerg1909