BUSYBOX ersetzen, die unter /bin/busybox (read only filesystem)

Moins


Das halt ich nicht für empfehlenswert.
AVM könnte da Applets drin haben die in der Neuen so nicht funktionieren.
...und dann können komische Sachen passieren.

Viel besser ist es, den Suchpfad so zu verändern, dass die neue busybox gefunden wird.
...und zwar so, dass das Verzeichnis bin die Softlinks zur neuen busybox enthält.

Beispiel:

Zum Testen kannst du die /bin/busybox mit mount -o bind übermounten mit der neuen busybox.
Dazu nehmen wir mal an, die neue busybox befindet sich in /var/tmp...
...hält bis zum nächsten Neustart oder...
Überprüfen/Anzeigen lassen kannst du dir das mit: df und mount (ohne Argumente)
...natürlich auch stumpf mit: busybox

Aber bedenke, ab dem mount -o bind bekommen auch die AVM Skripte die neue busybox (Applets) geliefert.
...das muss nicht, aber kann nach Hinten losgehen.

Ich hab keine 7490 und daher weiss ich nicht ob es direkt mit modfs geht.

Normal macht sowas ja freetz mit fwmod.
1. Firmware entpacken
2. Firmware modifizieren
3. Firmware packen
4. Firmware flashen

Bei mir funktioniert eine statisch gelinkte Busybox 1.24.1 auch problemlos im root-FS einer 06.51 ... der minimale Mehrverbrauch an Hauptspeicher (die statisch gelinkte benutzt natürlich die "shared libraries" nicht) ist bei einer 7490 praktisch zu vernachlässigen. Die verwendete Konfiguration ist genau die aus dem SIAB-Image, wo man sie mit "bbconfig" exportieren kann. Bei den von mir verwendeten Funktionen (das schließt z.B. AHA nicht ein) gibt es bisher keine erkennbaren Probleme.

Logischerweise kann man vor dem Einpacken mit "modfs" auch die Busybox einfach ersetzen ... da hat jemand für mein Empfinden die Abläufe beim "modfs" nicht wirklich verstanden - auch die Frage, wie man das Dateisystem unter / mounten könnte (möglichst noch r/w) zeigt das in meinen Augen. Hier würde vielleicht etwas zusätzliche Lektüre (zum Thema SquashFS) helfen und auch das README.ger-File im "modfs" könnte (genauso wie #1 im modfs-Thread) noch wissenswerte Informationen enthalten. Die "Pause" vor dem Einpacken ist ja nicht nur dazu gedacht, daß sich die FRITZ!Box und der Benutzer kurz erholen können ...

Die Lösung mit "bind"-Mount ist zwar denkbar und funktioniert auch ganz gut ... ein solches bind-Mount kann man aber praktisch nie wieder aufheben, weil schon die Ausführung von "umount" hinterher die Busybox wirklich "busy" (in use) sehen würde (solange man das "umount" nicht mit besonderen Vorkehrungen von einer anderen Stelle aus aufruft).

Als Lösung mit mehr Perspektive bietet sich bei einem 3.10er-Kernel fast an (braucht aber einen eigenen Kernel), die overlayfs-Patches anzuwenden. Wenn AVM es irgendwann mal "hinter" die Version 3.18 schaffen sollte (so ca. 2020 vermutlich, bei FRITZ!OS 10), kann man es auch einfach als LKM nachrüsten ... derzeit geht das leider nicht ohne weiteres, weil die Behandlung von "open()" für alle Aufrufe natürlich den passenden "hook" braucht und die potentielle Existenz eines Overlays für die Datei in Betracht ziehen muß beim Lesen bzw. die Kopie erstellen muß für den Schreibzugriff.

Da steht nix von "statischer Link"!
PeterPawn spricht von einer statisch gelinkten Version der busybox.
Da braucht man nichts mehr zusätzlich installieren, alleine der Aufruf von busybox reicht aus.
Zusätzliche Bibliotheken sind dabei auch nicht mehr notwendig.

Joe

Statisch gelinkt bedeutet: Es werden keine Bibliotheken des Systems verwendet oder gesucht, diese sogenannten Libraryfunktionen sind mit in das Programm einkompiliert (statisch gelinkt).
...deswegen ist die fertige busybox Binary auch 1,5 MB gross.
Das hat nichts mit Soft-, oder Hardlinks zu tun, die beliebig im System gesetzt werden können.

Eine statisch gelinkte busybox-mips 1.24.0 gibt es bei busybox.net im Binariesverzeichnis, nicht in einem weiteren Unterverzeichnis.
Also: "https://busybox.net/downloads/binaries/busybox-mips"
...die muss auch noch nach dem Kopieren auf die Box ausführbar gemacht werden mit: chmod +x busybox-mips

Die hat er (PeterPawn) sich aber höchstwahrscheinlich mit einer Crosscompileumgebung (freetz?) selber erstellt.
Offiziell ist die bei busybox.net nicht zu bekommen.

soll störanfällig sein

Zum Vergrößern anklicken....

Davon hab ich bis jetzt noch nichts be/gemerkt.
Wo steht denn das?

Die nächste Version von "modfs" wird wohl tatsächlich zusätzlich zu den SquashFS-Tools noch eine solche Busybox enthalten, weil man dann bestimmte Probleme ganz anders angehen kann ... z.B. wird dann die Verwendung des "patch"-Applets in "modscript"-Dateien möglich, was ggü. der doch manchmal sehr komplizierten sed-Syntax (insbesondere beim Einfügen mehrerer Zeilen) eine echte Erleichterung bringt.

Als einzelne Datei werde ich das jedoch nicht zur Verfügung stellen, das hat aber mit dieser Anfrage nichts zu tun, wie man sicherlich auch früheren Beiträgen von mir zum Thema "Veröffentlichung binärer Dateien" entnehmen kann - das gehört (solange es Alternativen gibt) zu den Dingen, die ich aus prinzipiellen Erwägungen ablehne, solange es nicht gute Grunde dafür gibt.

Noch ein Grund mehr für mich mir eine 7490 zuzulegen.

@PeterPawn: Wenn ich die busybox komplett umbenenne in httpd, dann sind doch quasi alle Applets gesperrt, außer httpd, richtig?

@coco722: Klar die Info gibt es auf busybox.net, wie blöd von mir. :silly:

Nicht zwangsläufig ... kommt darauf an, wie das in der Busybox umgesetzt ist. Es gibt neben der Abfrage des "Aufrufnamens" (das ist der Punkt, wo diese "multi-call binaries" in der Regel ansetzen) auch noch die Möglichkeit, den "Dateinamen" des Binaries abzufragen (z.B. würde dann ein "ls -ld /proc/self/exe" bei Deinem httpd-Beispiel auch "/path_to_somewhere/httpd" anzeigen) und wenn die Busybox (ich müßte auch erst nachsehen) das irgendwie auswertet (ob der Dateiname und das aufgerufene Applet identisch sind), dann könnte es durchaus auch sein, daß da weiterhin Aufrufe a la "httpd cat ..." möglich sind, während die Abfrage über $0/argv[0] (also den Namen des aufgerufenen Kommandos) ja trotzdem "httpd" ergeben würde.

Es kommt also ganz darauf an, was die Busybox da zuerst macht ... die Prüfung des eigenen "realen" Dateinamens oder die Abfrage des Namens, unter dem sie aufgerufen wurde. Es wäre sogar denkbar, daß da auf "symlink" beim Aufruf getestet wird und das ein solcher sein muß, damit auf "direkter Applet-Aufruf" erkannt werden kann.

Wenn man eine Busybox braucht, die nur httpd kann, würde ich mir eine solche übersetzen ... ob das aber überhaupt möglich ist (also eine BB ohne ash und den ganzen Kram), habe ich noch nie probieren wollen.

OK, httpd wird wieder zur Applet liefernden busybox, wenn ein Softlink namens busybox auf httpd zeigt.
Auf Applet Softlink wird anscheinend nicht geprüft, es wird wohl argv[0] auf busybox geprüft und wenn busybox argv[1] als Applet gesucht/ausgeführt.
httpd free oder ähnliche Aufrufe führen nur zu einer Fehlermeldung von httpd.

Ach coco722, es muss nicht immer das Neueste sein.
Auch eine vollausgestattete 1.21 tut es, wenn die benötigten Funktionen denn auch drinne sind.
Zum Beispiel: httpd
Nur deshalb hab ich mir vor Jahren schon eine von busybox.net geladen und für eigene Webseiten benutzt.
...und sogar PHP Seiten mit zusätzlicher php-cgi Binary (statisch gelinkt ~8MB ) damit hingekriegt.
Kannst ja mal in Google suchen, mit: site:ip-phone-forum.de koyaanisqatsi httpd php-cgi

@coco722:

coco722 schrieb:

Schade, dass...

Zum Vergrößern anklicken....

Bitte streitet doch dort weiter, wo ihr angefangen habt...