Freetz-NG nutzen, um Binaries auf der originalen Firmware laufen zu lassen -> geht nicht?

[SvenLuebke]

Hallo Freetz-NG-User!

Als ehemaliger Freetz-Nutzer habe ich über einen langen Zeitraum Binaries von freetz bauen lassen, um diese dann auf meiner 7490 mit der originalen Firmware laufen zu lassen. Das hat auch bis zur Firmware 7.11 (nach Nutzung von modfs) tadellos funktioniert. Weil freetz aber scheinbar noch nicht für die Firmware 7.21 angepasst wurde, hab ich nun Probleme damit bekommen. Oder liegt es vielleicht einfach nur an der 7.21er Firmware? Ich konnte es noch nicht herausfinden, deswegen hoffe ich, dass es hier jemanden gibt, der schon damit Erfahrung sammeln durfte.

Führe ich ein Binary, das mit Freetz-NG gebaut wurde, auf meiner Box aus, dann erscheint immer immer nur´
# ./strace
-sh: ./strace: not found

file gibt folgendes aus:
ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /usr/lib/freetz/ld-uClibc.so.1, stripped
das sollte also passen. Und das Verzeichnis, in dem ausgeführt wird, sieht laut "mount" so aus:
/dev/mtdblock5 on /var/media/ftp type yaffs2 (rw,sync,relatime)

Das obige strace ist laut objdump nur von der libc abhängig, die ich dem Binary auch zur Verfügung stelle. Aber irgendwas ist hier falsch.

Kann mir jemand helfen? Ich danke Euch!

Viele Grüße,
Sven

---

EDIT by @fda77:
Da es unten etwas schwer zu finden ist:
Alle Dateien müssen statisch gebaut werden und nicht "dynamically linked"

EDIT by @SvenLuebke:

Mein Fazit:

Die Verwendung von dynamisch gelinkten Binaries ist weiterhin ohne Probleme möglich, so lange sämtliche Libs für das System auffindbar sind. Für die einfachere Ausführung sollte man den Parameter FREETZ_RPATH benutzen, da man dadurch nicht LD_LIBRARY_PATH verändern muss.

[fda77]

Darfst du Dateien dort ausführen wo du sie ausführst?

AVM nutzt als libc: glibc, uclibc und musl. Je verschiedene Versionen und auf verschiedenen Architekturen, evtl verschiedene Endianess.
Früher gab es nur uclibc und Freetz hat diese ersetzt. Für neue Fritzos ist Freetz davon unabhängig, aber wenn man nur Binaries nutzen will ohne Freetz, muss man auch die Libs in /usr/lib/freetz/ haben - Oder RPATH, LD_LIBRARY_PATH, LD_PRELOAD anpassen/setzen. Aber so dass es nicht für die Datein von AVM gilt

[SvenLuebke]

Darfst du Dateien dort ausführen wo du sie ausführst?

Wenn Du damit die mount-Option exec bzw. noexec meinst, dann ja. Das hab ich über modfs korrigieren lassen.

wenn man nur Binaries nutzen will ohne Freetz, muss man auch die Libs in /usr/lib/freetz/ haben - Oder RPATH, LD_LIBRARY_PATH, LD_PRELOAD anpassen/setzen

Tut mir leid, das hatte ich vergessen zu erwähnen: Natürlich setze ich vor der Ausführung "meiner neuen" ELFs den LD_LIBRARY_PATH und ergänze ein weiteres Verzeichnis, welches sich im internen Speicher (unter /var/media/ftp usw.) befindet.

Das ganze Verfahren mit dynamischem Linken hat - wie gesagt - auch bis zur 7.11 einwandfrei funktioniert.

[fda77]

Das ganze Verfahren mit dynamischem Linken hat - wie gesagt - auch bis zur 7.11 einwandfrei funktioniert.

Genau. Und das ist jetzt anders.
Wenn du unbedingt dynamisch Bins haben willst musst du alle Libs auch mitkopieren, inklusive uclibc

[SvenLuebke]

Genau. Und das ist jetzt anders.

Ahh, ok, diese Änderung in der Firmware 7.21 ist also bekannt und kein Problem nur bei mir. Das ist schon mal gut.

Wenn du unbedingt dynamisch Bins haben willst musst du alle Libs auch mitkopieren, inklusive uclibc

Ich weiß nicht mehr, warum das so war...aber ich benötige wirklich dynamische Binaries. Auf meiner Fritzbox nutze ich subversion in Verbindung mit apache2 und PHP. Wenn ich mich richtig erinnere, dann benötige ich dynamische Binaries wegen der apache2 Module...oder ich wollte einfach nur RAM und Flash sparen. So ganz sicher bin ich da nicht mehr...

Die ganzen Libs habe ich natürlich auch dem System bereitgestellt. Trotzdem ändert sich der Fehler nicht. Ihr habt aber Recht, dass statisch gelinkte Binaries von freetz-ng mit meiner Box laufen. ldd und strace habe ich nun zur weiteren Untersuchung erstmal statisch kompiliert. In Euren Kommentaren unten sehe ich auch genau mein Problem:
Die Libraries können gefunden werden, aber die Lade-Adresse bleibt bei null (bis auf die interne /lib/ld-uClibc.so.1). Zudem behauptet ldd, dass es sich um kein "dynamic executable" handelt.

Ich würde gerne das Problem genau verstehen, warum das hier nicht mehr funktioniert. Habt Ihr das schon genauer untersucht und eine Erklärung dafür? Wenn es denn wirklich nicht zu ändern sein sollte, dann muss ich halt in den sauren Apfel beißen und viele Configs anpassen.

[fda77]

Ich würde gerne das Problem genau verstehe

Das steht doch direkt in er allerersten Antwort: #189 (comment)
Es ist auch nicht wirklich ein "Problem" sondern es wird anders wegen der vielen verschiedenen libcs von AVM so gemach

aber die Lade-Adresse bleibt bei null

mit "patchelf" kannst du die verändern

[SvenLuebke]

Das steht doch direkt in er allerersten Antwort: #189 (comment)

Korrekt...und trotzdem ging es nicht. Nun habe ich herausgefunden, warum es nicht ging. Die Libs waren zwar alle da, die Symlinks für die verschiedenen Versionen wurden aber nicht erstellt. Das scheint eine weitere Änderung in irgendeiner 7.x Firmware zu sein. Um die Binaries und Libs auf die Fritzbox zu bekommen, nutze ich rsync über cifs. Das hat auch immer wunderbar geklappt. Nur leider können nun scheinbar keine symlinks mehr über rsync (und andere Linux-Tools "remote") angelegt werden:

rsync: symlink "symlink_file" -> "symlink_destination_file" failed: Operation not supported (95)

Ich habe versucht beim mounten "-o vers=3.0, ..." usw. auszuprobieren, aber eine Lösung hab ich nicht gefunden. Mittels eines rsync servers sollte das dann wieder klappen...denke ich.

Danke Euch für die Hilfe!!!

[PeterPawn]

Oder man linkt seine Binaries einfach statisch (nicht alle (Freetz[-NG]-Pakete unterstützen das und man muß manchmal selbst Hand anlegen und die Autokonfiguration überlisten) - dann ist es egal, in welcher Reihenfolge da nach welchen Paketen gesucht wird.

Ich würde jedenfalls für modfs keine komplette Umgebung mit DSOs verwenden - u.a. deshalb sind die Files in yf_bin auch üblicherweise (bis auf ganz wenige Ausnahmen, die auch wieder ihre speziellen Gründe haben) statisch gelinkt:

vidar:/home/GitHub/yf_bin/target $ find . -type f -exec file '{}' \; | grep dynamic
./armv7l/4.4.60/privatekeypassword: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./armv7l/4.4.60/ldd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./armv7l/4.4.60/libprivatekeypassword.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
./mips/3.10.107/privatekeypassword: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./mips/3.10.107/ldd: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./mips/3.10.107/libprivatekeypassword.so: ELF 32-bit MSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, stripped
./mips/2.6.28.10/privatekeypassword: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./mips/2.6.28.10/ldd: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./mips/2.6.28.10/libprivatekeypassword.so: ELF 32-bit MSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, stripped
./i686/2.6.39.3/privatekeypassword: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./i686/2.6.39.3/ldd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
./i686/2.6.39.3/libprivatekeypassword.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
vidar:/home/GitHub/yf_bin/target $

Dein strace bietet nun als Freetz-Paket ausgerechnet noch keine Option, es statisch zu linken ... also könntest Du da selbst Hand anlegen und einfach die passenden Optionen/Parameter/Patches für autoconf (das variiert ja auch, je nach Paket) hinzufügen.

Ich habe solche "static"-Patches für einige Pakete auch in meinem Fork, weil ich längst nicht bei allen meinen Vorstellungen, was man noch bräuchte, um die erzeugten Dateien auch ohne Freetz "nachnutzen" zu können, bei den Freetz-Maintainern (Freetz/freetz) Gehör gefunden habe - der dropbear wäre ein Beispiel dafür (auch wenn's da noch weitere Änderungen gibt): PeterPawn@98950c8#diff-5b097a837d6ad622dca52eeca2d3135fb7fd33a3b50163e0d6e04f56eb6b8202R57

Dadurch, daß die Programme in yf_bin größtenteils statisch gelinkt sind, funktionieren die bei mir (fast alle) auch unter 07.2x weiterhin und ich habe bisher noch keine Notwendigkeit gesehen, andere Binaries zu erzeugen, die jeweils die von AVM verwendete C-Library benutzen. Zumal das eben auch immer weiter ausfranst bei AVM - inzwischen gibt es mehrere Versionen der uClibc, der uClibc-ng, der glibc (wobei das wohl ein kurzer Ausflug war) und schließlich seit einiger Zeit (zuerst iirc bei den GRX-Boxen) musl.

Ich habe mit @fda77 irgendwo hier im GitHub auch schon darüber diskutiert (vielleicht findet es ja jemand), wie man das wieder einfangen kann bzw. was ich selbst in Zukunft machen will - ich werde nur noch neue Programme in Binärform erzeugen und bereitstellen, die statisch gegen musl gelinkt sind (weil das auch einer der Vorteile dieser Library ist, daß man damit statisch gelinkte Binaries mit überschaubarer Größe erzeugen kann) und alles andere tangiert mich nicht länger. Solange die Syscalls des jeweiligen Kernels zur verwendeten C-Library passen, sollten sich dabei dann keine weiteren Probleme einstellen.

[fda77]

Und diese statischen Binaries laufen dann auf unmodifizierten 7490(uclibc) UND 7590(musl)? Mindestens der Name der Loader-/Interpreter-Datei ist doch ein anderer:

root@F7590:/var/mod/root# ldd /usr/lib/freetz/libssl.so.1.1
        ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x77ade000)
        libcrypto.so.1.1 => /usr/lib/freetz/libcrypto.so.1.1 (0x00000000)
        libc.so.0 => /usr/lib/freetz/libc.so.0 (0x00000000)
        /usr/lib/freetz/ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x00000000)
        /usr/lib/freetz/ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x00000000)
root@F7590:/var/mod/root# ldd $(which busybox)
        libc.so.0 => /usr/lib/freetz/libc.so.0 (0x7754f000)
        ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x77623000)

Sicher dass strace einen static-Patch braucht?

root@F7590:/var/mod/root# ldd $(which strace)
        libc.so.0 => /usr/lib/freetz/libc.so.0 (0x77dee000)
        ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x77ec2000)

Wenn man (bzw ein Addon) die Pfade durcheinander bringt werden solche Segfaults verursacht: ip-phone-forum.de/threads/e-mail-versand-mit-cron.309220/

[fda77]

bräuchte man das zusätzliche Verzeichnis in LD_LIBRARY_PATH eigentlich auch nicht und damit würden für die AVM-Programme auch nicht die falschen Versionen der uClibc-ng-Libraries gefunden.

Das wird gar nicht gemacht!

root@F7320:/var/mod/root# echo $LD_LIBRARY_PATH
/mod/lib:/mod/usr/lib

Aber siehe Punk "Planloses setzen von Systemvariablen" auf https://freetz-ng.github.io/freetz-ng/ADDONS Vielleicht erinnerst du dich auch noch an die ganzen exportierten Variablen die dir komisch vorkamen

probiere Deinen ldd-Aufruf mal mit einem statisch gelinkten Binary

$ ldd $(which vsftpd)
        not a dynamic executable
$ readelf -d  $(which vsftpd)
There is no dynamic section in this file.

Also ist wohl die Antwort auf die ursprüngliche Frage: Alle Dateien müssen statisch gebaut werden

[PeterPawn]

Ich weiß schon, worum es da ging ... nur wird das noch über Jahre so weitergehen, wenn diejenigen, die diese Add-Ons "verbrechen", nicht einfach mal die Grundlagen erlernen und (wie manch anderer aber auch) immer nur nach irgendwelchen "Workarounds" suchen, mit denen man das dann doch noch "irgendwie zurechtfummeln" kann. Dabei reißt man eben mit dem Hinterteil beim Umdrehen gleich wieder ein, was man zuvor erst aufgebaut hatte.

/mod/lib:/mod/usr/lib

Und schon das dürfte aber ein Problem sein, wenn in einem der beiden Verzeichnisse eine ld-uClibc.so.1 (so heißt der DynLoader der uClibc-ng) und eine libc.so (das ist die eigentliche C-Library, siehe Deine ldd-Ausgaben weiter oben) zu finden sind ... denn dann nimmt der Loader eben diese.

Du brauchst ja nur mal Dein ldd auf der Box für die /sbin/mailer zu probieren und Dir die Pfade der Libraries, die dabei nachgeladen werden sollen, genau ansehen. Wenn da die libc.so(ggf. auch noch mit weiteren Anhängen am Namen) aus dem Verzeichnis /usr/lib/freetz kommen soll und das ist nicht dieselbe, wie in /lib (wo AVM die Bibliotheken ablegt), dann ist so ein Segfault nicht unbedingt verwunderlich.

Da könnten dann die "Add-On"-Leute gar nichts dafür ... die Frage ist, ob der crond (in dem Fall aus dem Thread) seinerseits den Cron-Jobs ein "sauberes" Environment bereitstellt - dann klappt der Aufruf auch für mail (aus dem CallMonitor-Paket), weil das selbst nur ein Shell-Skript ist (dem sind die Libraries schnuppe) und der AVM-Mailer dann aber wieder seine passenden Bibliotheken findet.

Andererseits würde es hier eben auch reichen, wenn man vor den Aufruf von /sbin/mailer in dem Skript aus dem CallMonitor-Paket einfach noch ein LD_LIBRARY_PATH= setzen würde, was dann auch wieder nur für diese eine Zeile wirkt und die zusätzlichen Bibliothekspfade einfach aus der Suchreihenfolge nimmt. Das /lib braucht man da auch nicht extra zu setzen, das ist Teil des "Standardpfads", der immer am Ende durchsucht wird, wenn zuvor nichts gefunden wurde.

[fda77]

/mod/lib:/mod/usr/lib ist schon Ewigkeiten so gesetzt, es war wohl für Tests gedacht. Es ist aber normal leer!
AVM binaries haben keine Problem mit /usr/lib/freetz, da dies nicht im Suchpfad ist und diese Dateien nie genutzt btw überhaupt gefunden werden.

Da könnten dann die "Add-On"-Leute gar nichts dafür

Nein? LD_LIBRARY_PATH kommt aber aus dem addon: Screenshot in ip-phone-forum.de/threads/e-mail-versand-mit-cron.309220/page-2#post-2408907

"oscam-1.5.2.tar.gz", Datei /etc/init.d/rc.oscam:
Zeile 173:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/freetz

Zeile 301

    mailer -s "$WATCHDOG_NAME - $ERROR_MSG" -f $OSCAM_MAIL_FROM -t $OSCAM_MAIL_TO -m $OSCAM_MAIL_SERVER -a $OSCAM_MAIL_USER -w $OSCAM_MAIL_PASSWORD

[PeterPawn]

Ich schrieb ja deutlich: WENN in einem der beiden Verzeichnisse die Dateien stehen SOLLTEN. Wenn das nicht so ist - auch gut. Dann gibt es damit eben keine Probleme ... stellt sich mir nur die Frage, warum man die Variable dann überhaupt setzen sollte. Daß Du da mittlerweile vieles auch durcheinander gewirbelt hast und man damit jedesmal erst langwierig nachsehen müßte, wie der aktuelle Stand in Freetz-NG gerade sein mag, wirst Du ja auch nicht abstreiten wollen. Hättest Du gleich dazu geschrieben bei Deiner "Anzeige" von LD_LIBRARY_PATH, daß die Verzeichnisse leer sind oder gar nicht existieren, wäre die ganze Diskussion obsolet.

---

Warum die Autoren (oder der/die/das Autor) des oscam-Pakets dann da den Pfad noch hinzufügt, wird sicherlich auch ewig sein Geheimnis bleiben ... welche Alternativen es gäbe beim Linken, habe ich ja schon aufgezählt und wenn er/sie/es sich damit einmal etwas befassen würde, wäre das sicherlich auch schnell erledigt.

Ich verstehe sogar, wenn Du die Nase voll hast, da immer wieder gegen Windmühlen zu kämpfen (wie gesagt, ich kann ja auch lesen), aber wenn das immer wieder ausufert, leistest Du nun mal auch Deinen Beitrag dazu. Ich will da überhaupt niemanden ausnehmen bei der Frage, wer das warum immer wieder eskalieren läßt - ich verstehe Dich, aber auch nur bis zu einem gewissen Punkt und da setzt Du dann schon ab und an noch eins drauf.

---

Beim CallMonitor-Paket könnte/sollte man das trotzdem (und sei es als Prophylaxe) lösen - und das war nun mal die Stelle aus dem Thread im IPPF, um die es am Ende ging. Das Skript ist Bestandteil des Pakets und es sollte am Ende auch dafür verantwortlich sein, daß es "unter allen Umständen" funktioniert - da kann man schon noch einiges verbessern/verändern.

Denn schon die Frage, ob man da den Pfad zum AVM-Mailer fest vorgeben sollte, anstatt das einfach (in den richtigen Pfaden) selbst zu suchen, könnte man höchst unterschiedlich bewerten (auch wenn's bei der ersten Implementierung sicherlich noch nicht so viele andere Firmware-Versionen gab) ... sowie AVM hier auf die Idee käme, das mailer nun in /usr/sbin/mailer zu speichern (und es gab - gerade erst bei der 07.2x - schon einiges an Reorganisationen in der Dateisystemstruktur - hatte ich irgendwo im IPPF bei der 07.19 mal zusammengestellt), paßt diese eine Variante des mail-Skripts nicht mehr für ältere und neuere Firmware zugleich ... selbst wenn AVM weiterhin das mailer als Binary bereitstellt.

Das ist in meinen Augen eine vollkommen unnötige Abhängigkeit (auch wenn absolute Pfade eine gute Vorkehrung gegen "untergeschobene Binaries" sind) und wenn das LD_LIBRARY_PATH tatsächlich in Freetz gesetzt wird (aber bei AVM-Programmen nicht erforderlich ist/geändert sein DARF - egal, ob da aktuell Dateien drin stehen oder nicht), dann kann/sollte man auch für die Aufrufe von AVM-Programmen, die aus Freetz-Dateien heraus erfolgen (so viele Stellen sind das auch wieder nicht) sicherstellen, daß beim Aufruf exakt die Bedingungen herrschen, die diese Programme erwarten/brauchen - es sei denn, man will das absichtlich(!) ändern. Ansonsten gilt in meinen Augen auch hier wieder die Prämisse, die ich schon an anderen Stellen vertreten habe: So viel ggü. der originalen Firmware ändern, wie nötig ... aber auch nicht mehr, weil jede zusätzliche Änderung wieder Probleme bereiten kann, wenn AVM etwas an der Firmware ändert.

Ich wage mal die These, daß zu der Zeit, wo dieses CallMonitor-Skript geschrieben wurde, in Freetz die C-Library dieselbe war wie bei AVM und höchstens die OpenSSL-Libraries (die hier wohl nur eine untergeordnete Rolle spielen, wenn überhaupt) andere waren. Daher trifft dieses Skript auch keine Vorkehrungen dagegen, daß da ggf. die falsche C-Library aufgerufen werden könnte (und das könnte immer noch sein, wenn in /mod/lib oder /mod/usr/lib Dateien stehen). Das nun nachzurüsten, ist ja nur eine Fingerübung ... selbst wenn man das nicht "an der Quelle" machen wollte (das ist ja ein Klon des ursprünglichen Projekts, der da als Quelle für den CallMonitor verwendet wird), kann man es ja über passende Patches verbessern. Denn das Verwenden einer C-Library-Version, die nicht mit der von AVM verwendeten übereinstimmt, hast Du (korrigiere mich, falls ich mich irre) ja auch erst "nachgerüstet" - dann sollte man das auch so machen, daß es (so weit wie möglich) gegen "Fehlbenutzung" abgesichert ist. Wenn es vorher gar keine "falsche" Version der C-Library gab, gab es natürlich für die Pakete (und die dort enthaltenen Skript-Dateien) auch keinen Grund, sich gegen die Verwendung der falschen Version abzusichern.

---

Auch wenn das in dem IPPF-Thread vielleicht nur die "lonesome" (und nicht sehr standhafte) Suche nach einem anderen Weg für die o.a. Misere in der rc.oscam war - da fehlt eben bei sehr vielen einfach auch das Verständnis/die Kenntnisse für die Zusammenhänge und damit würde dann auch so ein Versuch des "alternativen Mail-Versands" wieder zu dem gehören, was ich vorhin mit "Herumpfriemeln" meinte - bis es irgendwann dann zufällig doch ein oder zwei Male klappt und danach nie wieder.

Solche Leute werden Dir aber immer wieder begegnen ... und manchmal hilft es sogar (zumindest bilde ich es mir ab und an ein), wenn man denen dann einfach mal versucht zu erklären, was sie da generell falsch machen. Das hilft ihnen dann vielleicht (obwohl man das eigentlich gar nicht will, weil man denkt, daß sie es sich nicht "verdient" haben), aber man hat selbst irgendwann (gesetzt den Fall, sie verstehen es dann doch irgendwann - ansonsten gibt's ja noch das Kill-File, denn es gibt auch aussichtslose Fälle) dann auch seine Ruhe, wenn das endlich mal "richtig" gemacht wurde und muß sich nicht ständig mit denselben Probleme und Nachfragen herumschlagen ... selbst "Ärgern" kostet eben wertvolle Zeit (und bei manchem auch Lebenszeit, die immer kürzer zu werden droht).

Gibt man denen wenigstens mal den Tipp, daß sie die Zeile 301 ändern könnten/sollten (und sie machen das dann auch noch), ist man das Problem ggf. schneller los, als man dachte. Sind sie tatsächlich "beratungsresistent" und das dauerhaft, muß man sie eben ignorieren - da können die dann (zumindest meinetwegen) noch so viel Unsinn über mich schreiben, es interessiert mich dann einfach nicht (wird's beleidigend, zeige ich's an, wenn ich es mitbekomme - außerdem moderiert da wohl auch GitHub, wenn's zu sehr ausufert und man sie darauf hinweist) und ich lasse mich dann aber auch nicht immer wieder in Diskussionen verstricken, wer da am Ende nun recht hat und wer wem etwas Böses angetan hat.

Ignorieren heißt eben auch Ignorieren ... da kann der noch so viel toben (im Rahmen natürlich). Ich hatte (mittlerweile hat es sich beruhigt) ja mit manchem IPPF-Mitglied ähnliche Probleme - aber diese Diskussionen führe ich mittlerweile einfach nicht mehr und das sogar "vom hohen Roß" herab, weil ich mir sage, daß diese Leute dann einfach die Antwort nicht wert sind.

---

So ... ich bin dann mal wieder raus. Ich werde noch die besprochenen Änderungen am juis_check umsetzen und danach kümmere ich mich erst mal wieder um "meine" Projekte - ich will mich bei Freetz ja eigentlich (mit Ansage) rausmischen.

Die Frage hier in der Diskussion, was man da machen könnte, sollte ich in #189 (comment) ausreichend beantwortet haben - der Rest tendiert ohnehin gegen OT.

[fda77]

Die 2 Verzeichnisse in LD_LIBRARY_PATH zeigen ins /tmp, also zu einfachen Testen von Libs auf der Box. Vermutlich ist das noch aus ds-Zeiten, als noch versucht wurde zu AVM 99% kompatibel zu sein.
An der libc hab ich in NG schon länger nichts mehr gemacht, da wurde auch nicht viel hin und her geändert, sondern nur bis es lief. Es ist doch einfach: Mod und Avm nutzen mit Fos 7.2 je ihre eigenen libs

Das ist ja das Problem mit diesem Mistaddon: In den ganzen "Fehlerberichten" wird das Addon verheimlicht und es so hingestellt dss dies ein Bug von NG wäre. Warum derjenige der das Addon verbrochen hat so einen Käse macht? Vielleicht hilft es dir dies zu lesen: https://www.digital-eliteboard.com/threads/oscam-addon-1-5-1-verhindert-wiederherstellung-der-freetz-einstellungen.496451/post-3872662

Eine Freetzsicherung spielt man ja wohl nicht ein, wenn man die Box schon halb eingerichtet hat, oder???
Wenn oscam läuft wurde ja schon allerhand eingerichtet.. Da spielt sich kein Mensch mehr eine Sicherung ein

Bei solchen Aussagen kann man sich über nichts mehr wundern! Bei der Fehlersuche hast du übrigens geholfen, natürlich gab es auch keinen Hinweis aufs Addon, bis heute: https://www.ip-phone-forum.de/threads/flashen-über-bootloader-funktioniert-nicht-bootloader-flashen-gesperrt.309039
CommanderAdama/forenuser/Fox.Mulder ist ja hinlänglich bekannt.
Ich hatte länger versucht im DEB den Nasen dort die grundlegensten Grundlagen zu erklären, viel sind aber einfach beratungsresistent und ich habs aufgegebn, es ist aussichtslos

An Callmonitor mag ich nichts machen. Das programmiere buehmann, und ich versteh nur die hälfte der Befehle die er verwendet. Das Problem tritt (nur) mit NG auch nicht auf. Durch das LD_LIBRARY_PATH Gefummel des Addons werden auch noch andere AVM-buns Probleme bekommen

Im Ignorieren bin ich ganz gut, mich stört nur dass man in den meisten Foren keine Moderatoren ausblenden kann :)

[PeterPawn]

Es gibt noch eine weitere Alternative ... vor ein paar Jahren wurde (schon im Freetz-Trunk) die Angabe von FREETZ_RPATH (Freetz@23210ea) und FREETZ_LIBRARY_DIR (Freetz@9dc7392) konfigurierbar gemacht und die zuvor festen Werte waren dann nur noch die Vorbelegung.

Auch damit kann man natürlich schon bei der Übersetzung dafür sorgen, daß andere Pfade bei der Suche nach Bibliotheken verwendet werden - wenn man die Pfade schon vorher kennt. So etwas macht sich allerdings bei USB-Volumes tatsächlich schlecht(er), weil dort der Pfad ja von mehreren Faktoren abhängig ist.

Ich verwende für die fertigen Binaries in yf_bin eben immer /var/custom als Basis ... und das würde ich auch für die Nachnutzung (in Freetz[-NG]-Builds) in den meisten Fällen empfehlen, wo man von Beginn an mit einem USB-Stick plant.

Es ist um einiges leichter und flexibler, einfach einen passenden Symlink von /var/something zum tatsächlichen Speicherort auf einem gemounteten Stick einzurichten, als den (ggf. über manchen Kopfstand beim Mounten) immer passend einzubinden.

[fda77]

In make/Makefile.in müsste man die 2 /usr/lib/freetz/ld-uClibc.so.1 noch durch Variablen ersetzen, FREETZ_LIBRARY_DIR gibt es an der Stelle aber noch nicht
Das patchelf ist nur zur Sicherheit da, da das Setzen beim make "nicht immer" funktioniert, zB Samba 3.0 ist okay, 3.6 nicht (oder umgekehrt)

[fda77]

Commits 5be89fa + 45246dd

[SvenLuebke]

Nochmals vielen Dank an Euch!

Trotz meiner Probleme bin ich mit dem Endergebnis glücklicher als vorher, da ich den Parameter
FREETZ_RPATH="/var/media/ftp/usr/lib"
nun nutze und scheinbar alle Binaries direkt (ohne das Setzen von LD_LIBRARY_PATH) ausführen kann.