[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Wollte den OpenWrt-Patch in Freetz aufnehmen, habe aber festgestellt, dass dies keine Lösung ist. Der OpenWrt-Patch behandelt e4defrag - dieses wird zum einen in Freetz gar nicht übersetzt und zum anderen hat rein gar nichts mit mke2fs zu tun.

Die Stelle, die zum Referenzieren von fallocate64 in mke2fs führt, ist diese hier (bei LFS enabled ist fallocate ein Alias für fallocate64). Dieser Aufruf von fallocate erfolgt jedoch mit Mode ungleich 0, daher kann dieser Aufruf von fallocate nicht durch ein posix_fallocate-Aufruf ersetzt werden (wie in der OpenWrt-Lösung vorgeschlagen wird). Die Frage ist, in wieweit unix_discard für mke2fs überhaupt relevant ist und ob man mit diesem "goto unimplemented, return EXT2_ET_UNIMPLEMENTED"-Fallback bei mke2fs leben könnte. Es scheint ein legitimer Fallback zu sein, denn FALLOC_FL_PUNCH_HOLE (eines der Mode-Flags beim fallocate-Aufruf) ist erst seit 2.6.38 (XFS) bzw. 3.0 (ext4) (s. man 2 fallocate) vorhanden und auf einer Box mit Kernel 2.6.32 funktioniert mke2fs ohne Probleme. Daher könnte man sich diesen Aufruf gewissermaßen auch "sparen" (als eine Alternative zum statischen Linken), indem man einfach den Fallback erzwingt, dies wiederum indem man die Variablen ac_cv_func_fallocate=no bzw. ac_cv_func_fallocate64=no exportiert (z.B. über $(PKG)_CONFIGURE_ENV += ...).

Eine weitere Alternative (wenn man auf den Aufruf nicht verzichten möchte), bestünde darin, den Syscall direkt aufzurufen (i.e. an der libc vorbei) - fallocate ist seit der Kernel Version 2.6.23 enthalten:
Code:
/* sowas in der Art */
error = syscall(SYS_fallocate, fd, mode, offset, length);
 
@er13:
Danke für die Suche (ich hatte beim OpenWRT-Patch die Hoffnung, daß er auf eine Lib wirkt, die auch bei e2fsck/mke2fs benutzt wird - aber zugegebenermaßen mich auch nicht wirklich vertieft) ... ich habe es ja anders (und recht "dirty") gelöst - das komplett statische Linken macht zwar die Dateien leicht größer, dafür klappt es auf (fast) jeder Konfiguration dann mit der Ausführung. Für Freetz stellt sich das Problem ja nicht, da ist dann ein fallocate64() (auch ohne posix_) in der libc vorhanden ... und warum das beim "usage screen" nicht schon aufgefallen ist, habe ich auch gar nicht erst versucht zu ergründen.


-Was mich viel mehr interessieren würde: Ich habe im ersten Anlauf mal mehrfach versucht, das Linken bei den e2fsprogs nachzuvollziehen und habe absolut keine Stelle gefunden - außer das Loader-(Text-)File für libgcc_s.so -, wo diese dusslige Referenz auf die gcc_s beim statischen Linken (mit -static als Linker-Flag) herkommen könnte, die mich ziemlich genervt hat, bis ich eine Lösung gefunden hatte.

Alles, was ich versucht habe (-nostdlib/-nodefaultlib als Linker-Flag, direktes Einbeziehen der libgcc_pic.a per l-Option, damit event. Symbole zuerst von dort aufgelöst werden und einiges mehr), war nicht wirklich von Erfolg gekrönt, "ld" wollte (als Folge des Linker-Aufrufs über gcc) immer unbedingt eine Library "gcc_s" sehen, die beim statischen Linken ja dann auf "libgcc_s.a" hinausläuft und nicht existiert.

Ohne die dreckige Lösung mit dem Symlinken der PIC-Version der statischen gcc-Library (weil der Rest der e2fsprogs auch PIC erzeugt hatte) vor dem configure habe ich das einfach nicht auf die Reihe bekommen in der Freetz-Toolchain.

Es waren zwar nur zwei Stellen, wo die Library eingebunden werden sollte (ich vermute mal - ohne mich vergewissert zu haben - wegen "stack unwinding" o.ä.) und eine davon ist noch ein kleines Test-Programm für die libuuid ... aber e2fsck ist davon eben auch betroffen und das brauchte ich/wollte ich haben/verwenden können, falls mal ein ext2-Image im r/w-Mode nicht richtig ausgehangen wurde und damit am Ende als "dirty" nicht richtig gemountet werden kann beim nächsten Start.

Am Ende bin ich irgendwie mehr und mehr zu der Überzeugung gelangt, daß vermutlich aus der libgcc_s gar kein Code wirklich gelinkt werden sollte - ich tippe inzwischen darauf, daß da nur beim rekursiven Auflösen aller Symbole aus allen Libs auch auf diese Library zugegriffen werden soll und dazu muß die halt vorhanden sein. Am Ende wird dann wohl gar nichts aus dieser Lib eingebunden. Da ich einfach nichts gefunden hatte, was von dort geladen werden mußte, war es auch kein möglicher Weg, die entsprechenden Symbole einfach unaufgelöst zu lassen.

Nun kenne ich mich in der Freetz-Toolchain nicht genug aus um da einschätzen zu können, woher da z.B. die ldconfig-Einstellungen kommen. Vielleicht findest Du ja einen besseren Weg, wie man die e2fsprogs wirklich komplett statisch bauen könnte, auch ohne den Hack mit dem Symlinken bzw. vielleicht hast Du ja noch eine Idee, wie man die erzeugten Symlinks beim Aufräumen (bzw. sicherlich beim "install" für das Paket) wieder abräumen kann - damit die nicht bei weiteren Paketen event. störend wirken, denn ich habe natürlich nur das Paket e2fsprogs gezielt mit "precompiled" erstellt und die Binaries aus dem Staging-Directory gefischt. Wahrscheinlich wäre es (sollte es beim Symlinken bleiben) am einfachsten, die Kommandos zum Entfernen gleich beim Erstellen der Symlinks in eine kleine Shell-Datei im Source-Verzeichnis des Pakets zu schreiben und diese dann aufzurufen im Rahmen von "BINARY_INSTALL".

- - - Aktualisiert - - -

Kann mal bitte jemand irgendetwas in diesem Thread schreiben? Ich brauche einen anderen Beitrag nach meinem letzten, denn ich hätte gerne einen etwas längeren Text (mit der Beschreibung für mod_custom_images) als "frischen" Beitrag eingestellt.
 
Zuletzt bearbeitet:
Moins

:?:
Kann mal bitte jemand irgendetwas in diesem Thread schreiben?
Die letzten zwei Beiträge sind sehr informativ :silly:
 
mod_custom_images - Erweitern von FRITZ!OS um eigene Software-Pakete

Da das neue Skript mit dem Namen "mod_custom_images" seinerseits selbst eher ein Framework ist als eine Modifikation mit einem konkreten Ergebnis, will und werde ich der Beschreibung dieser Erweiterung etwas mehr Platz einräumen bzw. von Beginn an versuchen, die Erklärungen wieder in die Hauptteile "Installieren", "Benutzen", "technischer Hintergrund" aufteilen, damit das etwas übersichtlicher bleibt und jeder nur die Informationen lesen muß (jedenfalls im akuten Fall, wenn es ums "Nachschlagen" geht), die er von Fall zu Fall braucht.

Was soll das überhaupt, brauche ich das?

Diese Modifikation fügt ein Shell-Skript mit dem Namen E99-custom in das Verzeichnis mit den Start-Dateien des FRITZ!OS (/etc/init.d) ein.

Mittels dieses Skriptes, das dann von der originalen Firmware am absoluten Ende des Start-Prozesses aufgerufen wird, kann man seine eigenen Erweiterungspakete für die Firmware - die als Dateisystem-Image vorliegen müssen, damit sie hier verwendet werden können - in das Dateisystem der FRITZ!Box einhängen lassen und über die - ebenfalls in diesen Images liegenden - zusätzlichen Shell-Skripte seine eigenen Dienste starten oder andere Veränderungen vornehmen.

Am Ende ist es nicht viel anders als der Plugin-Mechanismus, dem AVM auch bei der deutschen Labor-Firmware für die 7390 ja gerade neues Leben einhaucht - nur daß bei AVM noch eine Prüfung der Signatur solcher Plugins erfolgt, die hier (zumindest vorläufig) noch entfällt.

OK, wenn ich das nun wohl brauche bzw. "haben will", wie kriege ich das dann in mein FRITZ!OS?

Das ist natürlich zunächst mal wieder ein modscript für modfs ... neben der Vorlage für dieses Skript (Datei files/E99-custom) enthält die neue Version auch noch zwei zusätzliche Programme für die Verwaltung von ext2-/ext3-Dateisystemen, die man ggf. zum Erstellen eigener Images ganz gut gebrauchen kann, wenn man das nicht auf einem "ausgewachsenen System" machen will.

Die Modifikation beschränkt sich eigentlich auf das Kopieren der Vorlage in das Zielverzeichnis im neuen Dateisystem und auf das Editieren der rc.tail.sh in der letzten Zeile (dazu gleich mehr).

Für den Aufruf dieser Datei sorgt dann jedenfalls schon die originale AVM-Firmware, denn sie führt alle dort liegenden Dateien aus, wenn deren Namen einem bestimmten Schema entsprechen. Damit dieser Mechanismus allerdings auch für ein Skript funktioniert, dessen Name mit E9 beginnt (das ist dann wirklich der krönende Abschluß der Initialisierung, hier ist alles andere bereits fertig, solange es sequentiell erfolgt), muß das Beenden der Abarbeitung von /etc/init.d/rc.S in der Datei /etc/init.d/rc.tail.sh durch die Zeile "exit 0" am Ende verhindert werden, da alle Exx-Dateien erst nach den Sxx-Dateien an der Reihe sind und diese rc.tail.sh aus der letzten zu startenden Sxx-Datei mit dem Namen S99-tail aufgerufen wird. Das erfolgt einfach durch das Auskommentieren dieser Zeile, damit irgendwelche anderen Skripte zumindest noch ihren "anchor" finden, falls sie nach diesem exit suchen oder davon ausgehen, daß die letzte Zeile in dieser Datei zumindest nichts anderes mehr aufruft. Das modscript für das Einbinden der rc.user (mod_rc_tail_sh) fügt seine zusätzliche Zeile z.B. vor der letzten Zeile dort ein.

Dieses Setzen der Abarbeitung ganz an das Ende des Startprozesses ist jedenfalls pure Absicht ... es gibt sicherlich je nach Verwendungszweck so einer Erweiterung bessere Punkte, wo man in die Firmware eingreifen könnte (z.B. das Ereignis, daß ein USB-Gerät verfügbar ist oder wenn die FRITZ!Box "online geht"), aber ich habe es oft genug gesehen, daß durch falsch erstellte Erweiterungen (selbst noch in der debug.cfg, wo beim originalen Aufruf - wie ihn auch Freetz wieder reaktiviert - eben keinesfalls ein exit vorhanden sein darf/sollte, weil dann die danach liegenden Kommandos in der rc.tail.sh nicht mehr ausgeführt werden) am Ende schwer zu lokalisierende Folgefehler entstehen (z.B. die Abarbeitung der rc.S nie wirklich beendet wird) und das läßt sich auf diesem Weg vermeiden. Für eine sichere Feststellung, ob die FRITZ!Box bereits online ist, ein USB-Speicher verfügbar ist oder nicht, usw., ist es ohnehin erforderlich, daß sich jede Erweiterung selbst davon überzeugt, denn durch den Ausfall eines Einwahlserver o.ä. kann das ja jederzeit genauso auftreten, wie der Benutzer einfach einen USB-Stick abgezogen haben kann und dann spielt der Zeitpunkt, wann solche Erweiterungen zum Zuge kommen, plötzlich keine Rolle mehr.

So ... jetzt habe ich das in meinem System, aber es passiert nichts. Was mache ich falsch?

Ganz kurz: nichts.

Ohne die passenden Images (oder mit passenden Einstellungen im Urlader-Environment trotz eventuell vorhandener Images) macht dieses Skript praktisch gar nichts ... und das ist auch gut so.

Erst dann, wenn man - aus welcher Quelle auch immer, zum notwendigen "Grundvertrauen" in das Gute im Menschen, wenn man Binärpakete von Fremden benutzt, habe ich oft genug meinen Senf abgegeben - eines oder mehrere passende Images irgendwo auf der Box abgelegt hat, erst dann kann die Modifikation wirklich etwas bewirken.

Dann durchsucht das Skript beim Start die Verzeichnisse, für die es konfiguriert wurde (der Standard wäre das Durchsuchen von /wrapper und /var/media/ftp, das läßt sich aber notfalls auch verändern, wenn man das Skript schon im seinem SquashFS-Image hat und es dort nicht mehr beschreibbar ist, dazu kommen wir später) nach Dateien, die auf die Erweiterung .custom enden.

Kurze Anmerkung: Alles, was man ggf. vor dem Schreiben von E99-custom in das Dateisystem beim modfs noch anpassen könnte, kommt später ... jetzt geht es erst einmal darum, wie sich das Skript verhält, wenn man es 1:1 übernimmt.

Es wird also nach Dateien mit der Erweiterung .custom gesucht und jede dieser Dateien wird dann als ein Dateisystem-Image angesehen und es wird versucht, sie in das Dateisystem der FRITZ!Box einzuhängen.

Gelingt das, werden alle Dateien innerhalb des Verzeichnisses etc/init.d in diesem Image gesucht und für jede dieser Dateien ein Kommando zum Aufruf in ein temporäres Shell-Skript geschrieben, das am Ende der Abarbeitung von E99-custom dann alle zusätzlichen Start-Skripte auf einen Schlag startet und parallel abarbeitet.

Hilfe! Kann ich das auch von Fall zu Fall beeinflussen? Ich habe ein falsches Paket erstellt und nun hängt mein System bei jedem Start.

Genau für solche Notfälle berücksichtigt das Skript den Inhalt von /proc/cmdline ... dieser wiederum kann recht einfach auch "von außen" beeinflußt werden, denn er enthält u.a. den Inhalt der Variablen "kernel_args" aus dem Urlader-Environment.

Wie man diese Variable jetzt aus einem laufenden FRITZ!OS heraus ändert (über das Schreiben in /proc/sys/urlader/environment) oder in einer FTP-Sitzung mit dem Bootloader EVA einen neuen Wert schreibt (mittels SETENV), ist oft genug thematisiert worden.

Die Variable, nach der das Skript dort sucht, muß mit der Zeichenkette custom= beginnen, die möglichen Angaben dahinter werden gleich erläutert. Entscheidend für solche Notfälle wäre aber der Wert custom=off, dessen Auftreten jede weitere Abarbeitung der E99-custom zum frühestmöglichen Zeitpunkt beendet.

Über diese Variable kann man aber auch die Verzeichnisse neu definieren, in denen nach Erweiterungsdateien gesucht wird, einzelne Erweiterungspakete ausschließen oder - am ehesten beim Test eigener neuer Images nützlich - den Start von Erweiterungspaketen ausführlich protokollieren lassen (Option -x beim Start der Shell).

Der grundsätzliche Aufbau des Wertes der Variablen richtet sich dabei nach folgender Notation (an EBNF angelehnt):
Code:
custom        = "custom=", [ off_value | kvset ];
kvset         = key_value_set, { ( ",", key_value_set ) };
key_value_set = key, "(", value, ")";
value         = package_list | search_path;
package_list  = package, { ( ":", package ) };
search_path   = directory, { ( ":", directory ) };
package       = <string>; (terminal, but limited by existing subdirectories)
filename      = package, { ( "_" | option ) };
option        = [ "tmpfs" | [ "rw | "ro" ] | "gz" ];
key           = "path" | "ignore" | "debug";
off_value     = "off";
Wenn man also die Suche nach Erweiterungsdateien auf die Verzeichnisse /var/media/ftp und /var/media/ftp/my_usb_stick beschränken will (was bei einer 7390 z.B. eine Möglichkeit wäre, denn auch dort funktioniert das Skript weiterhin, auch wenn man sich einen anderen Weg überlegen muß, wie man das System dazu bringt, E99-custom zu starten - solange man das nicht einfach aus der debug.cfg heraus selbst macht) und gleichzeitig das Initialisieren von Paketen mit den Namen openvpn und dropbear unterbinden will, dann sähe die Variable z.B. so aus:
Code:
custom=path(/var/media/ftp:/var/media/ftp/my_usb_stick),ignore(openvpn:dropbear)
Wer den Term filename in der o.a. Syntax-Beschreibung sieht, stellt ja schnell fest, daß der eigentlich gar nicht dazugehört ... denn in der custom-Variablen soll er gar nicht auftauchen, dort ist nur der Paketname gefragt. Aber diese möglichen Bestandteile eines Dateinamens für ein Erweiterungspaket bieten dann die Möglichkeit, das Einhängen (Mounten) des Dateisystems in gewissen Grenzen zu beeinflussen. Welche das sind und was man dabei beachten sollte, versuche ich bei den Erklärungen zum Aufbau und zum Erstellen eines eigenen Images zu beleuchten.

Wie baue ich mir mein eigenes Image?

So ein Image ist eigentlich schnell erstellt. Man legt sich an einer beschreibbaren Stelle im Dateisystem ein leeres Verzeichnis als Basis für das künftige Image an und kopiert in die Unterverzeichnisse (die man darin wieder anlegt) alles an Dateien (Binaries, Libraries, Einstellungen), was man so für die gewünschten Aufgaben braucht.

Zwar sind bis zu 16 loop-Devices tatsächlich nutzbar (wenn man die dev-Nodes selbst anlegt), aber die AVM-Firmware erstellt von sich aus nur 8 Loop-Devices (loop0 bis loop7) und sie benötigt - je nach Box und Firmware-Version - selbst freie Loop-Devices (wo z.B. das Skript /sbin/start_plugin.sh bei der 7390 auch nur bis 7 zählen mag) für das Mounten des root-Dateisystem, das Mounten von einem oder mehreren Plugins und das Mounten des Dateisystem-Images beim Firmware-Update. Ich würde also eher nicht hingehen und mehr als fünf Erweiterungspakete getrennt mounten lassen ... es ist ja auch relativ leicht, mehrere Software-Pakete zu einem gemeinsamen Erweiterungspaket zusammenzupacken.

Genau aus diesem Grund startet E99-custom auch wirklich jedes Skript, das es im Unterverzeichnis etc/init.d des neu gemounteten Images finden kann ... den Namen des Verzeichnisses habe ich der Einfachheit halber beibehalten (dann muß man nicht raten, wo die Dateien zu finden sein könnten), denn das (alte) Verzeichnis etc/init.d kennt eigentlich jeder Linux-Benutzer aus den seligen Zeiten vor dem systemd.

Wenn man also 5 verschiedene Software-Pakete für fünf verschiedene Daemons in ein gemeinsames Image geschoben hat, bietet sich die Verwendung von fünf getrennten Start-Skripten eher an, als diese in eine gemeinsame Datei zu überführen.

Wie so ein Start-Skript aussehen könnte (gerade auch, wenn es um die "Kommunikation" mit E99-custom geht), habe ich in einer Vorlage für so eine Datei mal angedeutet.

Der Grund, warum ich nicht einfach die ganzen Angaben für das Skript in Environment-Variablen übergebe, ist das Fehlen genau dieser Variablen bei späteren Aufrufen eines solchen Skriptes (z.B. bei der Rekonfiguration von Diensten oder bei der Abfrage des Status) und da anhand dieser Variablen diverse Entscheidungen getroffen werden können/müssen (z.B. eben, ob Änderungen an einem beschreibbaren Image irgendwie wieder mittels gzip gepackt und persistent am originalen Ort gespeichert werden sollten), die auch noch bei späteren Aufrufen relevant sind, habe ich mich dazu entschlossen, diese Übergabe lieber über eine kleine Text-Datei unterhalb von /var zu realisieren, die jedes dieser Start-Skripte (auch bei späteren Aufrufen und ohne Hinweis im Environment, zu welchem Paket man selbst gehört) leicht anhand des eigenen Dateinamens finden kann.

Der Rest in der Vorlage ist eher Standardkost ... wie das für ein eigenes Image konkret aussehen kann, kommt später noch, wenn ich das Erstellen anhand eines Beispiels genauer beschreibe.

Ist jedenfalls dieses Verzeichnis dann erst einmal komplett, packt man es entweder mit dem passenden mksquashfsX-Programm aus dem modfs-Archiv zusammen oder man erstellt sich ein leeres ext2/3-Image, mountet dieses irgendwo und kopiert den Verzeichnisinhalt in dieses Image (über dessen Mountpoint), bevor man das Dateisystem-Image wieder aushängt.

Hier kommt dann auch wieder der oben vertagte Aufbau des Dateinamens so einer Image-Datei ins Spiel ... dieser besteht ja aus dem Paketnamen und einigen Anweisungen, wie so ein Image beim Mounten zu behandeln ist. Diese ganzen Bestandteile werden jeweils durch Unterstriche voneinander getrennt und alles vor dem ersten Unterstrich wird dem Namen zugeschlagen. Die zusätzlichen Optionen, die in so einem Dateinamen noch enthalten sein können, wären dann:

  1. tmpfs -> das sorgt dafür, daß die Image-Datei nicht an ihrem Ursprungsort gemountet wird, sondern sie wird vorher ins tmpfs kopiert; das kostet nicht nur zusätzlichen Platz im tmpfs (Hauptspeicher), es bietet auch die Möglichkeit, im laufenden System diese ursprüngliche Datei einfach auszutauschen, ohne die Dienste anhalten zu müssen und das in Benutzung befindliche Dateisystem-Image erst einmal aushängen zu müssen
  2. gz -> zusätzlich zu tmpfs, sorgt diese Option dafür, daß beim Kopieren ins tmpfs die Datei mit gunzip dekomprimiert wird
  3. ro oder rw -> gibt den gewünschten Modus beim Mounten an; fehlt die Angabe, wird anhand des Dateisystem-Typs und der Zugriffsmöglichkeiten am Ort des Images entschieden, ob Schreibzugriff möglich ist, das gilt aber auch für die explizite Angabe von rw als Option, daß diese nur berücksichtigt wird, wenn es möglich ist
Auch die Quelle so eines Images sollte man bei der Entscheidung, wie es einzubinden ist, noch berücksichtigen. Liegt die Datei auf einem USB-Stick, kann es zu Problemen beim Neustart der FRITZ!Box führen, wenn man ein Image von dort einhängt. Der Code zum Stoppen des USB-Subsystems weiß nichts davon/rechnet nicht damit, daß da noch ein solches Loop-Device gemountet sein könnte (jedenfalls bisher nicht, mal sehen ob sich das mit den Plugins wieder ändert) und damit hängt dann ggf. das Stoppen des USB-Hosts schon fest. Vor diesem Problem steht man naturgemäß nicht, wenn man das Paket vor dem Mounten ins tmpfs kopieren läßt, dann kann der USB-Speicher bleiben, wo er will.

Eine Image-Datei (ext2) für das Paket dropbear, die vor dem Mounten ins tmpfs ausgepackt werden soll und danach aber (prophylaktisch) nur r/o eingebunden werden soll, hieße also: dropbear_gz_tmpfs_ro.custom - wobei die Reihenfolge der Optionen hinter dem Paketnamen wahlfrei ist, bei widersprüchlichen Angaben (ro_rw_tmpfs) ist das Verhalten undefiniert.

Da der Paketname unmittelbar in den Namen des Mountpoints einfließt (/var/$package), kann es nicht zwei Pakete mit demselben Namen geben. Hier wird ein einzelnes Paket gewinnen, auch da ist aber das Verhalten, welches das am Ende ist, per se undefiniert und man sollte sich auf nichts verlassen.

Was sollte ich bei der Auswahl des Dateisystemtyps für mein Image berücksichtigen?

Es werden vom originalen Skript nur drei Dateisystem-Typen unterstützt: ext2, ext3 (das ist ja auch nur ein ext2-Dateisystem mit Journal) und das - jeweils zum Kernel passende - squashfs. Man muß sich also irgendwie eine Image-Datei in einem passenden Format erstellen.

Welches Dateisystem man dabei wählt, hängt von einigen Faktoren ab, die vielleicht am besten mit einem kleinen Vergleich der wichtigsten Eigenschaften für den angepeilten Einsatzzweck verdeutlichen kann:

Gesichtspunktext2ext3squashfs
änderbarja, wenn es an einer Stelle liegt, wo generell Schreiben möglich istja, wenn es an einer Stelle liegt, wo generell Schreiben möglich istnein
Platzbedarf der Image-Datei1:1 die (vorher festgelegte) Größe der Image-Datei beim Mounten, kann optional im Dateisystem trotzdem komprimiert werdenwie ext2, zusätzlich ist aber immer etwas weniger Platz im Image frei verfügbar, weil das Journal auch Platz brauchtdie Daten werden - je nach SquashFS-Version - leicht (zlib) bis richtig heavy (lzma2) komprimiert und nehmen nur den Platz ein, der tatsächlich benötigt wird
unempfindlich gegen plötzliche Neustarts, wenn beschreibbarneinja, auf Kosten von Speicherplatz und I/O-Durchsatz, weil die zusätzlichen Schreiboperationen für das Journal ja auch erfolgen müssen ... allerdings sollten Schreibzugriffe auf solche Images (egal wo die liegen mögen) eher selten passieren
gar nicht beschreibbar, damit stellt sich die Frage nicht

Zum Punkt Platzbedarf noch die Anmerkung, daß ja so ein ext2-/ext3-Image immer vor dem Erstellen des Dateisystems in dieser Image-Datei schon auf die max. mögliche Größe zugeschnitten werden muß ... wer also 30 MB zusätzlichen Platzbedarf hat, der kriegt so eine Image-Datei nicht einmal mit "gut zureden" dann noch in der wrapper-Partition unter. Um auch an dieser Stelle eine (leichte) Kompression zu ermöglichen, bietet das Skript auch die Möglichkeit (s.o.), eine mit gzip komprimierte Image-Datei vor dem Mounten in das tmpfs zu kopieren und dabei zu dekomprimieren, dabei entsteht natürlich auch wieder eine Datei der ursprünglichen Größe, was im tmpfs bei Boxen mit weniger Hauptspeicher (die 128 MB-Modelle) ja auch nicht das Gelbe von Ei ist (Ostern war erst, da ist diese Phrase noch präsent). Das ist also ein Balance-Akt zwischen freiem Platz im Hauptspeicher und freiem Platz an der Stelle, wo das Image persistent gespeichert ist.

Zusätzlich kommt dann ja noch bei einigen (denkbaren) Paketen die Notwendigkeit dazu, spezielle Einstellungen für diese Box in einer Art und Weise zu verwalten, daß die einen Neustart überleben. Nun gibt es ja in so einer Box (auch abhängig von der verbauten Hardware) jede Menge denkbare Stellen, wo man solche Einstellungen ablegen könnte.

  1. TFFS-Node analog zum Vorgehen von Freetz, da werden diese Daten dann nicht gesichert, aber zumindest auch nicht gelöscht beim Werksreset, wenn man unter 100 bleibt
  2. TFFS-Node, der von AVM als Datei in die Sicherung/Wiederherstellung einbezogen wird ... die /var/flash/calllog wäre meines Wissens so eine Möglichkeit - sie wird immer noch gesichert (getestet) und wiederhergestellt (ungetestet) - sogar netterweise als Binärdatei - und ansonsten ignoriert neuere Firmware den Inhalt dieser Datei komplett; allerdings riskiert man bei diesem Vorgehen, daß AVM bei irgendeinem Update diese Sicherung/Wiederherstellung einstellt und dann schaut man in die Röhre
  3. Sicherung als Datei in der yaffs2-Partition unter /var/flash - diese existiert nur bei NAND-Modellen und hat m.W. bei diesen Modellen den Namen config (auch bei der 7412, wo sie aber nicht verwendet wird); der Platz dort ist allerdings begrenzt (~ 1 MB steht zur Verfügung), jedoch ist das im Vergleich zur max. Größe im TFFS (da sind 32 KB komprimiert die Obergrenze, weil die Längen nur als 2-Byte-Integer gespeichert sind) ja immer noch riesig
  4. Sicherung als Datei in der yaffs2-Partition unter /wrapper - da ist einerseits viel Platz, andererseits werden sie auch dort dann nicht (mit den AVM-Dateien zusammen) gesichert (wie im Punkt zuvor natürlich auch nicht)
  5. Sicherung als Datei in der yaffs2-Partition, die bei allen NAND-Modellen (und der 7390) unter /var/media/ftp gemountet ist, viel Platz (mind. 15 MB gesamt, selbst bei Boxen mit nur 128 MB NAND-Flash), keine automatische Sicherung
Bei einer beschreibbaren Image-Datei kommt dann noch die Möglichkeit hinzu, die Einstellungen direkt dort in der Image-Datei zu verwalten ... allerdings setzt das voraus, daß die Image-Datei unkomprimiert an einer Stelle im Dateisystem gespeichert wurde, wo sie veränderbar ist. Zwar erfüllt der Speicher unter /var/media/ftp diese Anforderungen, aber die dazu notwendige unkomprimierte Speicherung des Images ist eigentlich eher ein "no-go" an dieser Stelle.

Ein "Spezialfall" ist dann noch die Verwendung der yaffs2-Partition unter /var/flash, um dort anstelle eines char-Devices für einen TFFS-Node eine reguläre Datei anzulegen, die wieder mehrfach so groß sein kann wie ein TFFS-Node und trotzdem ganz normal bei Sichern/Wiederherstellen gelesen und geschrieben wird.

Alles in allem spricht also wirklich wenig für die dauerhafte(!) Verwendung eines beschreibbaren Images, max. noch dann, wenn es eigentlich vom USB-Speicher kommt (was dann wieder andere Probleme mit sich bringen kann, aber das ist ein anderes Thema). Ich verwende(te) das meist auch nur, wenn es um das Bauen neuer Images geht/ging, weil man eben solange ändern kann, bis es endlich alles läuft und dann kann man immer noch ein SquashFS-Image mit maximaler Platzersparnis daraus machen.

Auch bei der Verwendung von Images, die über mehrere Modelle benutzbar sein sollen, ist (und war) die Verwendung von SquashFS nicht immer der beste Weg, weil es mit dem neuen Kernel zwar einen fundamentalen Unterschied gibt (SquashFS3 vs. SquashFS4), aber auch früher schon unterschiedliche Kompressionsverfahren (NAND-Modelle nur mit zlib, NOR-Modelle mit lzma) verwendet wurden. Zwar konnten die NAND-Modelle (zumindest die 7490) auch die lzma-Kompression der NOR-Modelle mounten (oder es war umgekehrt, ist halt lange her und selten genutzt, hatte ich aber auch hier mal irgendwo im IPPF geschrieben), aber die Gegenrichtung funktioniert(e) dann meist ohnehin nicht mehr und so ist ein ext2-Image an dieser Stelle der kleinste gemeinsame Nenner, auf den sich alle (halbwegs aktuellen) Boxen automatisch verstehen. Je nach Hauptspeicherausbau und verfügbarem Platz im persistenten Speicher kann es dann immer noch Sinn machen, das fertige Image mit gzip vor der Speicherung dort zu komprimieren, dann braucht es halt zwingend den Platz im tmpfs für die entpackte Version, bevor da irgendetwas gemountet werden kann.

Geht das auch weniger trocken/technisch ... hast Du nicht mal ein Beispiel zur Hand?

Nun kann man das ja auch mal praktisch angehen ... wir bauen uns jetzt aus den bereits andernorts von mir veröffentlichten Komponenten (modfs-Archiv und modfs-Starter-Archiv, zzgl. der Vorlage für das Start-Skript) ein funktionierendes Image zusammen, das über die E99-custom bei jedem Systemstart wieder einen ShellInABox-Daemon aktiviert.

Zuerst bereiten wir dazu unsere Umgebung vor ... und wir beginnen an der Stelle auch tatsächlich mit der Vertreibung aus dem Paradies, damit es eine kontrollierte Umgebung wird. Natürlich kann jeder, der sich damit auskennt, das entsprechend seinen eigenen Bedürfnissen abändern.

bold sind eigene Eingaben ... die Ausgaben weichen ggf. ab, z.B. beim Prompt zur Eingabe.

Zuerst wechseln wir in das Verzeichnis /var/media/ftp und legen uns dort ein Verzeichnis für modfs an, bevor wir die Dateien von yourfritz.de laden und entsprechend entpacken.
Code:
root@FB7490:~ $ [B]cd /var/media/ftp[/B]
root@FB7490:/var/media/ftp $ [B]mkdir modfs[/B]
root@FB7490:/var/media/ftp $ [B]cd modfs[/B]
root@FB7490:/var/media/ftp/modfs $ [B]wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar xv[/B]
bin/
bin/212
bin/VR9/
bin/VR9/e2fsck
bin/VR9/mke2fs
bin/VR9/unsquashfs4
bin/VR9/unsquashfs3
bin/VR9/mksquashfs4
bin/VR9/mksquashfs3
bin/VR9/busybox
bin/VR9/busybox.config
bin/.gitattributes
bin/193
bin/203
bin/175
bin/185
files/
files/E99-custom
files/128MB_ext3.gz
locale/
locale/en
locale/de
modscripts/
modscripts/mod_enable_telnet
modscripts/mod_leddisplay
modscripts/mod_show_vpn_on_overview
modscripts/template
modscripts/yourfritz_hooks
modscripts/mod_mount_by_label
modscripts/mod_prefer_fonnumber_name
modscripts/gui_boot_manager_v0.2
modscripts/mod_show_name
modscripts/mod_default_show_mac
modscripts/edit_rcuser
modscripts/mod_rc_tail_sh
modscripts/dectcmds.modscript
modscripts/mod_custom_images
modscripts/mod_profile
modscripts/copy_binaries
modscripts/gui_boot_manager_v0.1
README.ger.outdated
README.outdated
LICENSE
BOOTSELECTION.ger
modfs
root@FB7490:/var/media/ftp/modfs $ [B]cd ..[/B]
root@FB7490:/var/media/ftp $ [B]wget -qO- http://yourfritz.de/inject_shellinabox_vr9_nand_sqfs4.tar | tar -O -xv ./var/tmp/filesystem.image >/tmp/siab.image[/B]
root@FB7490:/var/media/ftp $ [B]modfs/bin/VR9/unsquashfs4 -dest myimage -linfo /tmp/siab.image[/B]
Filesystem on /tmp/siab.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
5 inodes (24 blocks) to write

drwxr-xr-x root/root                59 2015-12-16 07:28 myimage
drwxr-xr-x root/root                30 2015-12-15 10:23 myimage/bin
-rwxr-xr-x root/root            917748 2015-12-15 10:23 myimage/bin/busybox
drwxr-xr-x root/root                29 2015-12-15 13:05 myimage/etc
drwxr-xr-x root/root                32 2015-12-15 13:37 myimage/etc/init.d
-rw-r--r-- root/root               727 2015-12-15 13:37 myimage/etc/init.d/rc.custom
drwxr-xr-x root/root                47 2015-12-15 10:27 myimage/lib
-rwxr-xr-x root/root              9298 2015-12-15 10:27 myimage/lib/libprivatekeypassword.so
drwxr-xr-x root/root                26 2015-12-15 10:24 myimage/usr
drwxr-xr-x root/root                61 2015-12-15 10:24 myimage/usr/bin
-rwxr-xr-x root/root              4688 2015-12-15 10:24 myimage/usr/bin/privatekeypassword
-rwxr-xr-x root/root            339964 2015-12-16 06:57 myimage/usr/bin/shellinaboxd

created 5 files
created 7 directories
created 0 symlinks
created 0 devices
created 0 fifos
Nun entfernen wir das im modfs-Starter-Image enthaltene Start-Skript und ersetzen es durch das besser auf die Verwendung mit E99-custom zugeschnittene aus dem GitHub-Repository. Da es ohne passendes wget auf der FRITZ!Box nicht funktioniert, diese Datei von github.com zu laden, greifen wir wieder auf die Kopie auf yourfritz.de zurück.
Code:
root@FB7490:/var/media/ftp $ [B]rm myimage/etc/init.d/rc.custom[/B]
root@FB7490:/var/media/ftp $ [B]wget -qO- http://yourfritz.de/rc.template >myimage/etc/init.d/rc.shellinaboxd[/B]
Nachdem wir nun die Zutaten beisammen und das Gemüse ordentlich geputzt haben, geht es an die Zubereitung ... dazu ist es erst einmal notwendig, die Datei myimage/etc/init.d/rc.shellinaboxd mit einem Editor zu bearbeiten. Wie man das macht, ist jedem selbst überlasssen, die FRITZ!Box bietet mit AVM-Firmware nur den Editor vi dafür an. Das Ergebnis nach dem Editieren sollte dann so aussehen, die Änderungen ggü. der originalen rc.template sind grün hervorgehoben:
Code:
#! /bin/sh
#####################################################################################
#                                                                                   #
# initialization script template - try to keep it independent from fixed path and   #
# file names to make it reusable from different image sources and with different    #
# image filesystem types                                                            #
#                                                                                   #
#####################################################################################
my_script="$0"
if [ ${#PKG_NAME} -gt 0 ]; then # environment variable set, no need to grab it
        my_package="$PKG_NAME"
else # grab the package name from our mountpoint ... it's the part before "/etc/"
        my_package="${my_script%/etc/*}"
        my_package="${my_package##*/}"
fi
my_name="${my_script##*/}"
my_environ="${my_script%%/$my_package/*}/${my_package}.${my_name}.environ"
my_check="$(sed -n -e "s|^PKG_\([^_]*\)_SCRIPT=\"$my_script\"\$|\1|p" $my_environ)"
if [ x$my_check != x$my_package ]; then
        echo "Unable to find environment file." 1>&2
        exit 1
fi
#####################################################################################
#                                                                                   #
# our service definitions                                                           #
#                                                                                   #
#####################################################################################
my_service="[COLOR="#008000"]shellinaboxd[/COLOR]"
my_display="[COLOR="#008000"]Shell in a Box[/COLOR]"
my_executable="[COLOR="#008000"]/usr/bin/shellinaboxd[/COLOR]"
my_pidfile="[COLOR="#008000"]/var/run/${my_service}.pid[/COLOR]"
my_executable_params="[COLOR="#008000"]--user=0 --group=0[/COLOR]"
[COLOR="#008000"]my_executable_params="$my_executable_params --cert-from-box"
my_executable_params="$my_executable_params --background"
my_executable_params="$my_executable_params --pidfile=$my_pidfile"
my_executable_params="$my_executable_params --no-sni"
my_executable_params="$my_executable_params --disable-ssl-menu"
my_executable_params="$my_executable_params --service=/:0:0:\$CFG_HOMEDIR:\$CFG_LOGIN"
my_executable_params="$my_executable_params --port=\$CFG_PORT"[/COLOR]
#####################################################################################
#                                                                                   #
# our configuration variables, feel free to set them from other sources             #
#                                                                                   #
#####################################################################################
[COLOR="#008000"]CFG_PORT=8010
CFG_HOMEDIR=/var/media/ftp
CFG_LOGIN=/sbin/ar7login[/COLOR]
#####################################################################################
#                                                                                   #
# internal subfunctions                                                             #
#                                                                                   #
#####################################################################################
#                                                                                   #
# securely read the settings from our environment file - read each single expected  #
# item instead to source the file without any knowledge, what it contains           #
#                                                                                   #
#####################################################################################
secure_load_environment_file()
{
        local envfile="$1" package="$2" var val
        local vars="SCRIPT IMAGE MOUNTEDIMAGE MOUNTPOINT MOUNTMODE IMAGE_FSTYPE IMAGE_IS_VOLATILE"
        for var in $vars; do
                val=$(sed -n -e "s|^PKG_${package}_${var}=\"\(.*\)\"\$|\1|p" $envfile)
                echo "PKG_${var}=\"${val}\""
        done
}
#####################################################################################
#                                                                                   #
# start our service(s)                                                              #
#                                                                                   #
#####################################################################################
start_service()
{
        export LD_LIBRARY_PATH="${PKG_MOUNTPOINT}/lib:$LD_LIBRARY_PATH"
        eval $PKG_MOUNTPOINT$my_executable $my_executable_params
}
#####################################################################################
#                                                                                   #
# stop our service(s)                                                               #
#                                                                                   #
#####################################################################################
stop_service()
{
        local pid=$(cat $my_pidfile 2>/dev/null)
        if [ ${#pid} -gt 0 ]; then
                if [ -d /proc/$pid ]; then
                        kill $pid
                        wait $pid
                fi
        fi
        rm $my_pidfile 2>/dev/null
}
#####################################################################################
#                                                                                   #
# end of internal subfunctions                                                      #
#                                                                                   #
#####################################################################################
#                                                                                   #
# load our environment file                                                         #
#                                                                                   #
#####################################################################################
tf=/tmp/$$_$(date +%s).source
secure_load_environment_file "$my_environ" "$my_package" >$tf
source $tf
rm $tf 2>/dev/null
#####################################################################################
#                                                                                   #
# check our parameters                                                              #
#                                                                                   #
#####################################################################################
op="$1"
shift
case "$op" in
        start)
                start_service $*
                ;;
        stop)
                stop_service $*
                ;;
        restart)
                stop_service $*
                start_service $*
                ;;
        *)
                echo "Unknown parameter '$1' specified." 1>&2
                exit 1
                ;;
esac
exit 0
EDIT: Und da mir noch aufgefallen ist, daß das neue Image unsinnigerweise auch noch eine (schon ältere) Busybox enthält (das modfs-Starter-Image ist eben schon älter und ich habe kein Interesse daran, es zu aktualisieren), sparen wir gleich noch 2/3 des Platzes, den das Image ansonsten belegen würde und entfernen vor dem Einpacken mit einem kühnen rm myimage/bin/busybox noch dieses Relikt, bevor wir fortfahren. /EDIT
Jetzt packen wir uns das ganze Verzeichnis myimage zu einer SquashFS-Imagedatei zusammen, diese erzeugen wir gleich in /var/media/ftp, was ja von E99-custom mit Standardeinstellungen auch durchsucht wird. Den Namen wählen wir dabei so, daß die Datei vor dem Mounten erst ins tmpfs kopiert wird, damit können wir die originale Image-Datei jederzeit durch eine neue ersetzen.
Code:
root@FB7490:/var/media/ftp $ [B]modfs/bin/VR9/mksquashfs4 myimage shellinaboxd_tmpfs.custom[/B]
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on shellinaboxd_tmpfs.custom, block size 65536.
[===========================================================-] 24/24 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 517.44 Kbytes (0.51 Mbytes)
        41.43% of uncompressed filesystem size (1249.06 Kbytes)
Inode table size 278 bytes (0.27 Kbytes)
        59.15% of uncompressed inode table size (470 bytes)
Directory table size 206 bytes (0.20 Kbytes)
        76.01% of uncompressed directory table size (271 bytes)
Number of duplicate files found 0
Number of inodes 12
Number of files 5
Number of fragments 1
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 7
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
Das sollte bereits ausreichen, damit unsere neue Image-Datei beim nächsten Start der FRITZ!Box als Erweiterungspaket erkannt und behandelt wird. Will man die Datei lieber in der wrapper-Partition ablegen, führt man noch die folgenden Kommandos aus:
Code:
root@FB7490:/var/media/ftp $ [B]mount -o remount,rw /wrapper/[/B]
root@FB7490:/var/media/ftp $ [B]cp -a shellinaboxd_tmpfs.custom /wrapper/[/B]
root@FB7490:/var/media/ftp $ [B]mount -o remount,ro /wrapper/[/B]

Wo sollte ich denn meine eigenen Image-Dateien am besten speichern?

Jeder der bisher von mir beschriebenen möglichen Ablageorte für Image-Dateien hat seine Vor- und Nachteile. Welchen man also am Ende wählt, hängt auch davon ab, was man erreichen will und wie man sich insgesamt seinen Umgang mit der FRITZ!Box vorstellt.

Die folgenden Plätze kommen für die Image-Dateien selbst in Frage, für die Einstellungen steht das ja schon etwas weiter vorne:

/wrapper
Das dort liegende yaffs2-Dateisystem steht nur auf FRITZ!Boxen zur Verfügung, die ihr Dateisystem im NAND-Flash verwalten (und dann noch "hot-flash capable" sind, also zwei Systemversionen verwenden) ... also im Prinzip genau auf den Modellen, für die modfs auch funktioniert. Allerdings sind die Partitionen von AVM mit 48 MB für das Dateisystem recht üppig dimensioniert, in einer unmodifizierten Firmware für die 7490 sind derzeit weniger als 50% dieser Partition belegt. Das bietet zwar jede Menge sinnvoll nutzbaren Speicherplatz, allerdings gibt es eben pro Systemversion eine eigene Partition und nach der Umschaltung auf das andere System oder nach einem Update (bei dem das yaffs2-Dateisystem ebenfalls neu geschrieben wird), sind die eigenen Image-Dateien dann auch wieder weg. Dafür kann man eben für jedes System eigene Versionen von Images verwenden, wenn man ab und an mal zwischen den vorhandenen Systemen umschaltet (z.B. wäre ein System mit einer VPN-Lösung über einen Anbieter oder mit Software für's Onion-Routing in der einen und mit einem "normalem" FRITZ!OS in der anderen Partition denkbar).

/var/media/ftp
Das unter diesem Pfad eingebundene yaffs2-Dateisystem gibt es auch nur bei den NAND-Modellen bzw. bei der 7390 (wo sogar mehr Platz verfügbar ist, weil die System-Partitionen nicht im NAND-Flash liegen bei diesem Modell). Dafür steht dieses Dateisystem in beiden möglichen Systemversionen eines solchen Gerätes zur Verfügung und es wird auch bei einem Update nicht in Mitleidenschaft gezogen. Genauso wie /wrapper bei passenden Modellen ist dieser Speicher auch immer vorhanden, egal was der Benutzer anstellt (im Gegensatz zu einem USB-Storage-Device). Jedoch wird auch hier beim nächsten Start nach dem Zurücksetzen auf Werkseinstellungen oder nach Recovery der komplette Inhalt des Dateisystems gelöscht, damit natürlich auch dort abgelegte Erweiterungspakete.

zusätzlicher Speicherplatz auf einem USB-Gerät, erreichbar unterhalb von /var/media/ftp/irgendwas
Dieser Speicher steht eben nur dann zur Verfügung, wenn das betreffende USB-Gerät auch vorhanden ist und mit etwas Pech braucht es auch länger, entsprechende USB-Volumes einzubinden. Das würde dann dazu führen, daß (die originale) E99-custom schon abgearbeitet wurde, wenn das Volume verfügbar wird. Dagegen werden hier keinerlei Vorkehrungen getroffen, daher ist so ein USB-Speicher auch nicht unbedingt der ideale Ablageort für Erweiterungspakete, zumindest nicht als primäre Quelle. Auch erfordert die Einbeziehung solcher Verzeichnisse (deren Namen eben variieren) dann entweder bereits im Vorfeld Änderungen an der E99-custom (Variable custom_sources) oder man muß wirklich die custom-Variable im Urlader-Environment bei der kernel_args-Einstellung setzen. Dafür ist dieser Speicher dann sogar gegen Werkseinstellungen und Recovery immun.

Ich selbst benutze eine Mischung aus der Speicherung in /wrapper und /var/media/ftp (daher auch diese Voreinstellung in der E99-custom, auch in dieser Reihenfolge, weil ein Paket in /wrapper dabei vor einem in /var/media/ftp gefunden wird und ja nur ein Paket gleichen Namens initialisiert wird), wobei eben in /var/media/ftp die Pakete liegen, die für beide Systeme verwendet werden sollen und in /wrapper die systemspezifischen.

Einstellungen (der Teil ist in der hier veröffentlichten Version noch recht unterentwickelt) speichere ich in einer Datei (komprimiertes tar-Archiv), die ich anstelle der Datei (bzw. des char-Devices) /var/flash/calllog als reguläre Datei oder als Symlink auf einen passenden Speicherort einbinde (das erfordert noch eine passende Vorbereitung bei jedem Start oder eine Änderung des Startprozesses von AVM, damit das char-Device nicht mehr angelegt wird und ggf. eine reguläre Datei desselben Namens gelöscht wird).

Damit lassen sich auch die Einstellungen für Erweiterungen ganz normal über das AVM-GUI sichern, auch in weit größerem Umfang, als es bei einer Speicherung in einem TFFS-Node überhaupt möglich wäre. Auch der Export von 2 MB in einer solchen Einstellungsdatei ist kein wirkliches Problem (ergibt halt ein recht großes export-File), beim Wiederherstellen mußte ich das noch nie versuchen, weil ich es immer von Hand gemacht habe bzw. ohnehin dann nur einzelne Einstellungen dort wiederherstellen wollte und das kann natürlich das AVM-GUI dann auch nicht, das schreibt entweder alles oder gar nichts.

Eigentlich soll diese Modifikation (also mod_custom_images gesamt) so etwas wie der nächste Schritt auf dem Weg zu einer wirklich dynamischen Verwaltung solcher Erweiterungspakete inkl. einer passenden HTML-Oberfläche für diese Zwecke sein, damit man dann nicht mehr zu einem Shell-Zugang greifen muß, um (vorgefertigte) Erweiterungspakete zu "installieren".
 
Zuletzt bearbeitet:
@er13
Was mich viel mehr interessieren würde: Ich habe im ersten Anlauf mal mehrfach versucht, das Linken bei den e2fsprogs nachzuvollziehen und habe absolut keine Stelle gefunden - außer das Loader-(Text-)File für libgcc_s.so -, wo diese dusslige Referenz auf die gcc_s beim statischen Linken (mit -static als Linker-Flag) herkommen könnte

Du darfst das Linker-Options-Compiler-Flag -static nicht mit dem Linker-Flag -static verwechseln. Ich kann problemlos (ohne jegliches Tricksen bzw. Workarounden) alle e2fsprogs komplett statisch linken, wenn ich die folgende Änderung vornehme (bei Bedarf könnte ich im Freetz-menuconfig eine Option dafür einbauen):
Code:
--- make/e2fsprogs/e2fsprogs.mk    (revision 13674)
+++ make/e2fsprogs/e2fsprogs.mk    (working copy)
@@ -121,7 +121,7 @@
 $($(PKG)_LIBS_BUILD_DIR) $($(PKG)_BINARIES_BUILD_DIR): $($(PKG)_DIR)/.configured
     $(SUBMAKE1) -C $(E2FSPROGS_DIR) \
         EXTRA_CFLAGS="-ffunction-sections -fdata-sections" \
-        EXTRA_LDFLAGS="-Wl,--gc-sections" \
+        EXTRA_LDFLAGS="-Wl,--gc-sections -static" \
         INFO=true \
         V=1 \
         all \

Das von Dir beschriebene Problem kann ich nachstellen, indem ich statt -static an derselben Stelle -Wl,-static schreibe. Das Linker-Options-Compiler-Flag -static macht nämlich etwas mehr als nur -static an den Linker weiterzuleiten. Oder um genauer zu sein, macht es deutlich weniger im Vergleich zu dem Fall, wenn diese Option nicht angegeben ist, es leitet zwar nur -static an den Linker weiter, leitet dafür aber keine dynamic-linking-related-options weiter. Was genau da weitergeleitet wird, wird zur Übersetzungszeit des Compilers festgelegt - s. für weitere Details den gcc-Quellcodebaum und konkret folgende Verzeichnisse an ${GCC_ROOT}/gcc/config bzw. ${GCC_ROOT}/gcc/config/mips. Der für diesen Fall interessante Teil ist in dem c-Define namens GNU_USER_TARGET_LINK_SPEC definiert (alle Angaben von mir auf Basis von gcc-4.8.x, müsste für gcc-4.9.x genauso heißen, für gcc-4.6.x/4.7.x heißt der entsprechende Define einfach nur LINK_SPEC.

Nebenbei bemerkt (hab's gestern vergessen) - in der Release-Version von uClibc-0.9.33.2 ist weder posix_fallocate noch fallocate enthalten. Der einzige Grund, warum es in der AVM-uClibc posix_fallocate gibt, ist die Tatsache, dass Buildroot-2014.08 (die von AVM für alle Kernel-3.10.x basierten Firmwares verwendete Buildroot-Version) diesen posix_fallocate-Patch enthält und eben keinen für fallocate.
 
Du darfst das Linker-Options-Compiler-Flag -static nicht mit dem Linker-Flag -static verwechseln.
Am Ende läuft es also auf einen Unterschied in den Defaults hinaus, die der gcc an den Linker übergibt und auf die Frage, ob der Compiler zusätzlichen Code für statische Binaries erzeugt oder nicht.

Ich habe aber auch total geschlafen und bin fälschlicherweise davon ausgegangen, daß die EXTRA_LDFLAGS tatsächlich erst beim Linken im gcc-Aufruf enthalten wären in den Makefiles von e2fsprogs und dann dürfte es keinen Unterschied mehr machen, weil der gcc ja keinen neuen Object-Code mehr erzeugt, wenn er nur als "wrapper" für den GNU-Linker verwendet wird.

Aber beim genauen Hinsehen sind diese Flags tatsächlich schon beim Compilieren in der Parameterliste und dann wird der gcc sicherlich irgendwelche zusätzlichen Prologe erzeugen und in die Object-Files ausgeben, denn hier soll ja auch noch "position independent code" erzeugt werden und da können schon mal einige Vorbereitungen nach dem Laden des Codes notwendig werden, damit diese Beliebigkeit bei den Adressen auch dann noch funktioniert, wenn keine einfache relative Adressierung mit Hardware-Möglichkeiten mehr machbar ist. Bei der Verwendung von dynamischen Bibliotheken übernimmt dann sicherlich der Loader die entsprechenden Arbeiten, um auch PIC in den geladenen Bibliotheken entsprechend vorzubereiten bzw. diese Funktionen stecken in den Initialisierungen der Bibliotheken.

er13 schrieb:
bei Bedarf könnte ich im Freetz-menuconfig eine Option dafür einbauen
Ad libitum ... ich habe aufgrund Deines Hinweises die Änderungen an e2fsprogs.mk teilweise rückgängig gemacht (die zwei folgenden Commits) und bei der nächsten Gelegenheit tausche ich die Binaries dann auch noch wirklich aus.

Mir (und jemandem, der auf der Basis irgendwelcher Patches meinerseits die Programme selbst kompilieren will) macht es die Sache natürlich jedesmal einfacher, wenn Du einen Vorschlag im Freetz-Trunk umsetzt, der ansonsten einen zusätzlichen Patch erfordern würde. Ich bemühe mich ja auch, das in einer Form zu machen, die tatsächlich konfigurierbar bleibt (hier eben das Einfügen der Option in die Config.in, anstatt nur platt die .mk zu patchen) ... solange es also Freetz nicht entscheidend verändert und Du es für vertretbar hältst, bin ich für jede Übernahme oder eine vergleichbare Umsetzung (die macht dann nur minimale Anpassungen bei mir notwendig, wenn ich von ihr profitieren will) dankbar.

Gerade auch bei ShellInABox und event. stunnel fände ich das sogar extrem hilfreich ... aber das setzt wiederum privatekeypassword voraus. Das wären dann aber praktisch auch schon alle Patches, die für veröffentlichte Sachen (die sich ja meist um modfs und CKonsorten drehen, daher mache ich das auch so ausführlich hier im modfs-Thread) erforderlich wären und die überhaupt einen Unterschied in Binaries für/von modfs ggü. dem Trunk ausmachen.

Wobei mir dabei noch zwei Sachen einfallen ... der Patch für das cksum-Applet, der irgendwo im Upstream mal in der Pipeline war bei der Busybox, hat es nun wohl doch nicht geschafft. Damit nehme ich seit der 1.24.1 wieder meinen alten Patch für den alternativen CRC32-Modus dazu, das ist ja der, den man für AVM's Export-Dateien braucht. Wenn Du den dann (gerne auch mit nur einem einzigen Parameter, der l + p gleichzeitig bewirkt, das war ja irgendwann auch mal eine Frage, ob ich konkrete Anwendungen der anderen beiden Fälle der vier möglichen Permutationen kennen würde) noch in die Busybox aufnimmst, reduziert sich der derzeitige Unterschied zum Freetz-Trunk auf die Einführung der konfigurierbaren Verzeichnisse für tabsets und terminfo bei ncurses - das wird derzeit aber ohnehin nicht gebraucht, solange es keine Binaries mit ncurses-Abhängigkeiten gibt im modfs-Kontext.

Das war der eine Punkt ... beim anderen ist es mehr eine Frage. Wenn ich das richtig sehe, verwendet Freetz (zumindest erscheint es anhand der Optionen beim Aufruf von gcc so) auch bei VR9-Modellen "24kc" für die Einstellungen zur Übersetzung und Optimierung. Der VR9 kann aber "34kc" und auch wenn ich nicht genug über die tatsächlichen Fähigkeiten des (ja sehr flexibel zu realisierenden) MIPS-Cores im VR9 weiß (kennt jemand ein echtes Datenblatt oder gar ein Handbuch mit dem "instruction set"?), sind ja ein paar prinzipielle Änderungen von 24Kc nach 34Kc erfolgt (Multicore, 9-stufige statt 8-stufiger Pipeline, TCs und VPEs), von denen bei einer Optimierung des Code vielleicht ja doch Gebrauch gemacht werden könnte. Ich weiß natürlich auch nicht genau, was solche Optimierungen am Ende bringen (bzw. ob sie überhaupt etwas bringen), aber wenn da nicht in Wirklichkeit der gcc in der Freetz-Toolchain automatisch aus "arch=24kc" dieselben Instruktionen und Optimierungen ableitet wie aus "arch=34kc", verschenkt das m.E. Potential. Gibt es irgendeinen (mir unbekannten) Grund, warum da die Freetz-Toolchain mit der älteren Architektur arbeitet?
 
Zuletzt bearbeitet:
Na wenn's jetzt nicht ohne Anleitung meinerseits geht, wann dann ... wobei ich den Vorlauf schon recht erstaunlich finde. Die 0.3.2 ist vom 15.02., der Artikel vom 04.04. (der sich auf die 0.3.1 bezieht) - das sind sieben Wochen.

Aber bei der Gelegenheit gleich noch der Hinweis, daß es (allerdings nicht unter dem "current version link", sondern nur direkt unter http://yourfritz.de/modfs-0.3.5.tgz) die neue (im Test befindliche) Version gibt.

Neben den getauschten Binaries (mit 34kc, aber das macht fast nichts aus bei der Größe und eine Hardware-FPU hat der VR9 dann offensichtlich doch nicht), die jetzt mit den Änderungen von er13 an der Toolchain erzeugt wurden, gibt es ein neues Modscript, das dazu dient, vor dem Neustart des Systems oder beim "eject" über das GUI das Swappen auf das spezifische oder auf alle USB-Geräte abzuschalten.

Damit bleibt dann die 7490 (zumindest meine) auch nicht mehr hängen beim Neustart nach der Verwendung von "modfs" ... bisher wurden bei mir dann Teile von dsl_monitor ausgelagert, wenn es notwendig war und wenn das USB-Subsystem abgeschossen wurde, dann kam es zu Paging-Fehlern (genauer Lesefehlern) beim Herunterfahren von DSL.

Veröffentlicht wird die 0.3.5 noch nicht, erst will ich noch die E99-custom bzw. die "mod_custom_images" um das Stoppen der dort gelagerten Dienste beim Herunterfahren erweitern.

Die Links von der PC-Welt zeigen (nach Redirect) tatsächlich auf yourfritz.de ... das heißt dann wohl, daß ich die einfrieren werde, damit das nicht irgendwann ins Leere läuft, aber da bin ich tatsächlich dankbar, daß die nicht einfach irgendwohin kopiert wurde und dann von dort angeboten werden (die Lizenz gibt das logischerweise her). Das macht es dann leichter, ggf. neue Versionen dort einzubauen.

Die kleinen Fehlerchen (der Zusammenhang zwischen Flash-Speicher und "beide Systeme" stimmt ja nicht so ganz: "Allerdings muss im Flash-Speicher der Fritzbox ausreichend Platz für beide Firmware-Versionen sein." - für beide Firmware-Versionen haben alle "hot-flash capable" Boxen genug Platz, nur für das Entpacken des Dateisystems zur Modifikation nicht, weil das > 65 MB werden und die kleinen nur max. 22 MB unter /var/media/ftp haben) würde ich in meiner Pedanterie natürlich noch korrigieren - aber das grenzt bei mir dann auch schon an Autismus. Wobei ich schon hoffe, daß niemand die Zeile mit dem wget kopiert und dabei nicht bemerkt, daß da einiges am Ende fehlt - das ist etwas unglücklich gelaufen beim "Setzen" bzw. da stimmen die CSS-Attribute irgendwie nicht so richtig.
 
Zuletzt bearbeitet:
Zum Thema FREETZ_LIBRARY_PATH und den Änderungen, die @er13 im Trunk vor einiger Zeit vorgenommen hatte, muß man vielleicht noch etwas anmerken (ich wurde im IRC danach gefragt) ... besonders im Zusammenhang mit dem "Bauen" eines Images für "mod_custom_images". Wer diese Absicht nicht hat, braucht auch nicht weiter zu lesen ...

-Zwar funktioniert das Setzen von DT_RPATH beim Linken der Binaries mit der Freetz-Toolchain einwandfrei, das bringt aber nur dann etwas, wenn man auch eine passende Übersetzung der uClibc verwendet.

Beim AVM-Original ist beim Build der uClibc die Option LDSO_RUNPATH nicht gesetzt, damit durchsucht die ld-uclibc.so von AVM auch nicht die dort in den dynamischen Headern einer Binärdatei angegebenen Verzeichnisse. Wer also davon profitieren will, braucht schon noch den Austausch der uClibc-Dateien im Root-Filesystem ... oder er muß auf anderen (traditionellen) Wegen dafür sorgen (LD_LIBRARY_PATH oder LD_PRELOAD), daß da eine ld-uclibc.so verwendet wird, die auch wirklich RPATH/RUNPATH berücksichtigt. Dann kann man aber auch gleich die richtigen Verzeichnisse in LD_LIBRARY_PATH aufführen, wurde mir dann entgegengehalten und das ist bis zu einem gewissen Punkt auch wirklich so. Wenn man also nur von RPATH profitieren will, muß man die uClibc-Bibliotheken auch ersetzen ... und auch der alleinige Austausch der ld-uclibc.so ist keine richtig gute Idee, weil der Rest der Libs auch noch zum Loader passen sollte.

Wegen der abweichenden ld-uClibc bei AVM funktioniert es auch nicht, den Standardpfad in Freetz zu verwenden (/usr/lib/freetz), sich dann dort die Bibliotheken herauszusuchen, die man für seine Programme braucht und diese dann einfach in ein Verzeichnis /usr/lib/freetz in seinem Zielsystem beim "modfs" (oder jeder anderen Art der Modifikation, z.B. auch beim "fwmod -u" + "fwmod -p") abzulegen. Solange da weiterhin die AVM-Version der ld-uclibc.so erhalten bleibt, nutzt der in den Freetz-Binaries hinterlegte RPATH /usr/lib/freetz auch absolut nichts ... der wird schlicht ignoriert bei der Suche nach "shared libraries" und man muß dann doch wieder über LD_LIBRARY_PATH/LD_PRELOAD (die berücksichtigt die AVM-Version dann auch wieder, obwohl auch dieses optional ist) die richtige Suchreihenfolge sicherstellen.

Bei den Versionen des Loaders wird dann also in dieser Reihenfolge nach "shared libraries" vom DSO-Support gesucht:

1. Nur Freetz: Verzeichnisse im Inhalt des Headers DT_RPATH in der ausführbaren binären Datei (LDSO_RUNPATH=y)
2. AVM und Freetz: Verzeichnisse in LD_LIBRARY_PATH, wenn die Umgebungsvariable gesetzt ist (LDSO_LD_LIBRARY_PATH=y)
3. Nur Freetz: Verzeichnisse im Inhalt des Headers DT_RUNPATH in der ausführbaren binären Datei (LDSO_RUNPATH=y)
4. AVM und Freetz: das Verzeichnis, in dem sich ld-uclibc.so selbst befindet (LDSO_SEARCH_INTERP_PATH=y)
5. AVM und Freetz: Verzeichnisse /lib und /usr/lib

Auch wenn dabei ein Verzeichnis mehrfach durchsucht werden müßte, habe ich auf Anhieb kein "Gedächtnis" beim "search_for_named_library()" gesehen ... was nicht heißt, daß es nicht trotzdem vorhanden sein könnte. Die Schritte 1 und 3 schließen sich gegenseitig aus, denn das Attribut DT_RUNPATH wird vom Linker nur anstelle des DT_RPATH geschrieben (wenn man -enable-new-dtags beim Linken verwendet, was m.W. Freetz nicht macht). Damit ist der entscheidende Unterschied (deshalb wurde RUNPATH auch mal eingeführt), daß die eine Variante vor LD_LIBRARY_PATH zur Anwendung kommt und die andere danach.

Aber aus der o.a. Reihenfolge und auch dem Blick in ldso.c der uClibc kann man dann folgendes "lernen":

1. Es macht keinen (oder wenig) Sinn, einen LD_LIBRARY_PATH zu setzen, der auf die Verzeichnisse /lib und /usr/lib (in dieser Reihenfolge und bei Verwendung der AVM-Version) endet, denn die würden dann mehrfach durchsucht, solange die Bibliothek nicht gefunden wird.
2. Eine leere, aber existierende Variable LD_LIBRARY_PATH wird trotzdem noch als "." angesehen, d.h. das aktuelle Verzeichnis (CWD) wird durchsucht.
3. Beim Zusammenbau von LD_LIBRARY_PATH-Variablen in Shell-Skripten muß man etwas Vorsicht walten lassen ... die einzelnen Verzeichnisse werden ja bekanntlich durch Doppelpunkte getrennt und - anders als es sicherlich viele annehmen würden - wenn zwei dieser Trennzeichen aufeinander folgen (weil die eigentlich als Wert dazwischen gedachte Variable vielleicht nicht gesetzt ist), dann wird an dieser Stelle ebenfalls das aktuelle Verzeichnis durchsucht, genauso wie bei einem Trennzeichen am Beginn oder am Ende des Wertes der Variablen. Die Angabe "/var/myimage/lib::/lib:/usr/lib:" sucht also in 8 Verzeichnissen (bzw. 8x in 4 Verzeichnissen) nach einer Bibliothek, bevor sie als "nicht gefunden" angesehen wird ... wobei man das Verzeichnis aus Schritt 4 oben nicht mit dem CWD verwechseln darf ... das kann zwar theoretisch auch dasselbe Verzeichnis sein, aber auch ein anderes.

Wenn man sich also ein Image zusammenbauen will (für E99-custom/mod_custom_images), das (dynamisch gelinkt ist und) eigene Bibliotheken mitbringt und mit der AVM-Version der uClibc arbeitet, dann gibt es mehrere Wege, die dort enthaltenen Libraries in die Suche einzubeziehen ... und zwar nur für die im Image enthaltenen Programme.

Ein allgemeines Setzen von LD_LIBRARY_PATH auf einen festen Pfad würde das (ab "export") ja für alle im Anschluß gestarteten Programme ebenfalls setzen (z.B. wenn das Paket eigentlich einen SSH-Server beinhaltet und der dann sein Environment an die Sitzungen "vererbt").

Da ist es dann das einfachste, die Bibliotheken gar nicht von den Binärdateien für die Programme zu trennen und einfach alles in ein gemeinsames Verzeichnis zu packen ... dann noch LD_LIBRARY_PATH auf einen leeren Wert gesetzt (das ist recht neutral und schadet in den wenigsten Fällen ... aber auch da ist ":" eben die Angabe, die das aktuelle Verzeichnis zweimal durchsucht, richtig wäre hier "") und vor dem Aufruf eines Programms aus so einem Image das aktuelle Verzeichnis so wechseln, daß der Aufruf aus dem Programmverzeichnis heraus erfolgt. Dann werden auch die entsprechenden Bibliotheken gefunden, wenn man die AVM-Version der uClibc verwendet.

Hat man ein Image mit mehr als einem "Paket" und demzufolge Bibliotheken, die tatsächlich von mehreren Programmen benutzt werden sollen und wo man trotzdem nicht alle Programme in ein gemeinsames Verzeichnis mit den Bibliotheken kippen will (auch dann, wenn man ggf. verschiedene Versionen einer Bibliothek braucht), dann reicht auch ein Symlink im Verzeichnis des Programms auf das richtige Verzeichnis.

Ein Beispiel wäre ein Image, das sowohl OpenSSH als auch OpenSSL und meinetwegen noch einen Apache2-Server enthält, die natürlich alle eine libssl.so und eine libcrypto.so benutzen wollen ... im Idealfall dieselbe (aber eine andere, als die AVM-Komponenten sie brauchen, weil es da immer noch ein paar Rudimente aus finsterer Vergangenheit gibt und die natürlich immer nur so aktuell wie die AVM-Firmware ist) und mit etwas Pech (oder auch absichtlich) auch eine andere Version.

Hier macht sich das mit der LD_LIBRARY_PATH-Variablen für das aktuelle Verzeichnis dann wieder gut ... man legt einfach in das Verzeichnis des Programmes mit der abweichenden Bibliothek einen anderen Symlink und kann trotzdem mit der einheitlichen Variablen arbeiten (die man dann so früh wie möglich exportiert, damit beim spawn() für weitere Prozesse diese Variable vererbt wird).

Auf diesem Weg kann man auch bei den "custom images" mit variablem Mountpoint (und damit variablem Pfad, den man in LD_LIBRARY_PATH setzen müßte - s. das Beispiel für rc.shellinaboxd weiter vorne, was unter bestimmten Umständen - nämlich dann, wenn LD_LIBRARY_PATH vorher leer ist - ein mehr oder weniger falsches Resultat liefert, da dann zwischen den Verzeichnissen "$PKG_MOUNTPOINT/lib" und "/lib" (in Schritt 4 der o.a. Liste) eben noch das aktuelle Verzeichnis durchsucht wird, weil LD_LIBRARY_PATH dann mit dem Doppelpunkt endet) die Suche nach Bibliotheken vereinfachen.

EDIT:
Richtig(er) müßte die Funktion start_service aus dem rc.template also eher so aussehen:
Code:
start_service()
{
        export LD_LIBRARY_PATH="${PKG_MOUNTPOINT}/lib${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH"
        eval $PKG_MOUNTPOINT$my_executable $my_executable_params
}
... ich werde das entsprechend korrigieren in den Dateien für den Download.
 
Zuletzt bearbeitet:
Schade das man kein image was mit Freetz bearbeitet wurde mit dem dual boot unter neustart der fritzbox versehen kann. Und ein image was ich mit modfs gemacht habe kann ich nicht mit freetz benutzen
 
@Master SaMMy:
Kann man schon ... mußt halt nur das entsprechende "modscript" etwas abändern (damit die Parameter wieder passen) oder sogar nur in die fwmod_custom den passenden Aufruf des Skripts mit den richtigen Parametern einbauen. Der ganze Rest (vom Erzeugen der Datei "guibootmanager" bis zur Änderung an der AVM-Lua-Datei) erfolgt ja direkt in der Skriptdatei - da ist nichts Geheimnisvolles dabei.

Die Integration in die fwmod_custom sollte nun wirklich "easy" sein ... andere "Hindernisse" bei der Verwendung dieses "Teilaspektes" (als konkrete Anwendung hat die Modifikation mit "modfs" an sich auch nur peripher zu tun) sehe ich irgendwie nicht. Aber ich verwende auch keine Freetz-Images ... und grau ist bekanntlich alle Theorie.
 
Traue mich garnicht zu fragen aber wie und was muss ich änderen in den datei.
Das mit dem Fragen ist ja kein Problem (das ist tatsächlich mal etwas, was nicht bereits abgehandelt wurde und wo man folglich auch wenig bis nichts finden kann bei der Recherche) ... die Antwort kann aber nicht "allgemeingültig" sein, dafür sind die denkbaren Rahmenbedingungen wieder zu vielfältig.

Gesetzt den Fall, wir reden hier vom Freetz-Trunk (in aktueller Version) und über die "guibootmanager"-Modifikation, sähe das in etwa so aus (im Trunk-Verzeichnis):
Code:
wget -qO - http://yourfritz.de/modfs.tgz | tar -x -v -z -O modscripts/gui_boot_manager_v0.2 >guibootmanager.mod
zum Download und Extrahieren des "modscripts". Anschließend editiert man die Datei "fwmod_custom" und ändert in der Funktion "all" die Zeile "dummy=0" in
Code:
TARGET_BRANDINGS="all" ../../tools/busybox ash ../../guibootmanager.mod "de" ./filesystem "auto" "install"
ab.

Das sollte es schon gewesen sein (für dieses Skript, das keine Funktionen aus der Box beim Ausführen der Modifikation benötigt, bei anderen wird das ggf. umfangreicher bei den "Vorbereitungen") und im Rahmen des "make" wird dann auch das Skript mit ausgeführt, das (Theorie, ich habe nur den Erfolg in den Dateien überprüft und kein derartiges Image installiert und gestartet) die entsprechenden Änderungen an den beiden Dateien (usr/www/all/system/reboot.lua und usr/bin/guibootmanager) vornimmt. Damit sollte auch das Freetz-Image die Umschaltung enthalten.
 
Zuletzt bearbeitet:
Cool Danke das hat geklapt!!! Ich benutze Freetz auch nur aus dem grund wegen Dropbear. Habe mir dann gedacht teste das gleich auch mal mit der MAC adresse unter Heimnetz das ging leider nicht aber ist nicht so schlimm. Aber vielleicht Baust du wann ja auch die Dropbear mit in dein tool ein. Und noch mal vielen dank PeterPawn
.
 
Ich bin gerade erst auf modfs gestoßen. Coole Sache! Laufen die Binaries auf einer 6360? Die sollte ja auch Dual Boot können.
 
Nein, die hat einen ARM-Prozessor und außerdem ist es dort nicht trivial, überhaupt erst einmal bis zum ersten Shell-Prompt zu gelangen. Dann ist sie (trotz "hot-flash capabilities") mit NOR-Flash ausgestattet, dort ist das Schreiben also nicht nur über das Löschen und Neumounten der yaffs2-Partition möglich.

Zwar habe ich für ältere Firmware-Versionen der 6360 sogar mal einen PoC für den Telnet-Zugang hier irgendwo veröffentlicht, das qualifiziert dieses Modell aber noch lange nicht wirklich für die Verwendung mit "modfs" - zumal auch weder auf GitHub noch auf yourfritz.de die Binaries für die HWRevision 157 dabei sind und schon die Frage, woher man das zu modifizierende Dateisystem bei der 6360 nehmen soll (na gut, das aktuelle könnte man verwenden), bliebe mangels verfügbarer Firmware von AVM (zumindest teilweise) unbeantwortet.
 
Ich habe ein altes Image, bei dem telnet geht (gebastelt aus "FRITZ.Box_6360_Cable.85.06.04.image").

Mein Plan:
- Das alte Image zurückspielen
- Das aktuelle Image auf dem zweiten Flash-Baustein mit modfs modden
- Den zweiten Flash-Baustein per Adam/FTP aktivieren und rebooten

Dazu müsste ich mir leider vorher eine Build-Umgebung für den Puma bauen, um die nötigen Binaries zu erzeugen. :( Das Wochenende ist gerettet! :)
 
@survivorx:
So könnte das tatsächlich gehen ... die OpenSource-Pakete für die 6360 gibt es m.W. sogar bei AVM zum Download: ftp://ftp.avm.de/develper/opensrc/fritzbox6360-source-files-05.29.tar.gz - zumindest die Toolchain für den ARM-Prozessor sollte man auch mit der älteren Version so bauen können, daß die erzeugten Compiler in der Lage sind, die notwendigen Pakete (SquashFS-Tools3 in erster Linie) für das Zielsystem dann zu übersetzen.

Allerdings kann man dann natürlich auch einfach ein externes System nehmen und dort das Image modifizieren ... für das Entpacken und Packen des Images ist es ja egal, welche Prozessorarchitektur da verwendet wird, solange die "endianess" des Zielsystems stimmt. Das so modifizierte Image kann man dann über Telnet wieder auf das Zielsystem bringen ... Vorgehen ist etwas abhängig vom Modell.
 
Ja, mein Problem ist, dass ich das aktuelle Image nicht gesichert bekomme, weil im Adam/FTP das Kommando nicht geht. Aber... ich glaube, ich habe irgendwo eine Anleitung zum Sichern des Images auf einen tftpd gefunden, wenn man Telnet hat. Ist denn die Image-Datei, die ruKernelTool braucht, einfach mtd1 und "/data" hintereinander weg? Davon habe ich einfach (noch) zu wenig Plan.

Edit: Hab's gefunden http://www.wehavemorefun.de/fritzbox/Firmware-Wiederherstellung

Danke!
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
244,696
Beiträge
2,216,706
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.