[Info] Beispiel: 7490-Image(s) mit Telnet auf der Box entpacken für Untersuchung

Nur für Neugierige und (fast) ohne jede Fehlerbehandlung ... ein Shell-Skript (für die 7490 selbst, also auf der Box auszuführen), das aus einem ZIP-File oder einem "image"-File von AVM das Dateisystem und den Kernel extrahiert und die unter der Versionsnummer an einer anzugebenden Stelle im Filesystem (USB-Stick oder -HDD) ablegt. Das gibt es auch in einer 06.25-Version, beide brauchen ein passendes unsquashfs ... siehe unten.

Bitte lesen und verstehen, es ist nur ein schneller Hack (bzw. das, was ich selbst immer benutze und was nicht zur Veröffentlichung vorgesehen war) und absolut nicht "fail safe". Also eher als Anregung denn als Rezept auffassen ... es soll nur Leuten ohne Linux-System (mithin ohne Freetz zum Entpacken der neuen AVM-Version) auch einen Einblick in das Dateisystem ermöglichen:

http://yourfritz.de/7490/extract_06.35_filesystem
http://yourfritz.de/7490/extract_filesystem (für 06.2x-Images/Labor-Versionen)
EDIT:
http://yourfritz.de/7490/extract_7490_new_filesystem (für 06.3x-Versionen der 7490 - neuer Kernel - mit erweiterter Suche nach der Image-Datei -> Labor oder LabBeta)
/EDIT
http://yourfritz.de/7490/unsquashfs4 (Binary für 06.35-Images, unter /var/media/ftp/unsquashfs4 speichern oder den Pfad im Skript ändern)
http://yourfritz.de/7490/unsquashfs3 (Binary für 06.25-Images, unter /var/media/ftp/unsquashfs3 speichern oder den Pfad im Skript ändern)

Irgendetwas stimmt mit neueren AVM-Images aus der Labor-06.25-Reihe nicht (zumindest der 113.06.25-30758 vom FTP-Server) ... beim Entpacken mit dem tar der Busybox kommt eine Fehlermeldung "tar: short read". Ich habe die Ursache nur überwindlich erforscht (Ende-Marker - leerer Header am Schluß der Datei - ist nicht vorhanden), für mich war es ausreichend, daß ein Vergleich der SHA1-Hashes beim Auspacken mit und ohne Fehlermeldung (dann mit einem "normalen" tar auf einen ausgewachsenen Linux) für keine Datei in solch einem Image einen Unterschied feststellen konnte. Das "short read"-Problem ist auch nicht so ganz neu ... wer da genau Späne macht, ist egal - solange auch das letzte File "komplett" ist, was hier der Fall ist (/var/signature hat oktal eine Länge von 200 und die 128 Byte der Datei stimmen auch mit dem Inhalt aus dem tar-File überein). Da das "short read" auch keine Auswirkung auf den Exit-Code hat, kommt wohl auch die AVM-Firmware damit klar.

Benutzung:

extract_filesystem source dest

source kann eine URL sein (HTTP(S), FTP) oder ein (lokaler) Dateiname, als Ausgangsformat wird sowohl ein ZIP-File als auch ein "image"-File (umbenanntes tar-File) akzeptiert. Das "richtige" File in einem ZIP-Paket wird anhand des "Labor" im Namen erkannt, das geht bei "LabBETA" o.ä. schief die neuere Version (s. #1) kann auch mit "LabBeta" umgehen.

Aus dem Netz geladene Zwischendateien werden wieder gelöscht, lokale Quellen bleiben unangetastet.

Als dest ist ein beschreibbares Verzeichnis anzugeben (irgendwo auf einem Stick oder einer HDD, NAND-Flash ist sehr langsam (IO-Mode)), dort wird ein Verzeichnis 113.06.xx-xxxxx in Abhängigkeit von der Version der bearbeiteten Firmware erzeugt. Die Unterverzeichnisse "kernel" und "yaffs2" unterhalb dieses Verzeichnisses enthalten das, was der Name impliziert, das "filesystem_core.squashfs"-File wird aus yaffs2 gelöscht, denn es liegt ja ausgepackt vor. Bitte nicht übersehen, daß das pro Firmware-Version final ca. 75 MB sind (und das mit nur zwei Brandings, sonst entsprechend noch mehr) und der Platz im NAND-Flash (neben dem Geschwindigkeitsproblem) dafür eher nicht die richtige Stelle sein dürfte (ab mehr als zwei oder drei Versionen). Zwischenzeitlich wird auch noch der Platz für das SquashFS (bis zu ca. 23 MB) zusätzlich benötigt, bis die "filesystem_core.squashfs" wieder gelöscht wurde.

Besitzer anderer Modelle (NAND) können das auch verwenden, vorher gut prüfen und am besten ohnehin (gilt auch für 7490) erst einmal mit "sh -x" aufrufen und auf Fehler prüfen, bevor man es "blind" verwendet.

splenditnet schrieb:

Ist das Format des Kernel.image Files zwischen NAND- und NOR-Boxen unterschiedlich ?

Zum Vergrößern anklicken....

Ja, bei NOR-Boxen werden der eigentliche Kernel und das Root-Filesystem in einer gemeinsamen Datei hintereinander gespeichert, deshalb ist die Größe von filesystem.image auch 0 Byte ... es steht beides zusammen in der kernel.image-Datei.

Damit braucht es ein spezielles unsquashfs für diese Dateien oder man splittet vorher in Kernel und SquashFS-Image (z.B. mit "dd", die SquashFS-Signatur im Superblock ist leicht zu finden: "sqsh" oder "hsqs" an einer 256-Byte-Boundary).

Ich habe vor exakt drei Monaten mal einen Patch für das unsquashfs3 im Freetz-Trac veröffentlicht, mit dem man sich ein unsquashfs bauen konnte, das sowohl für NOR-Boxen (Ausnahme 6810/6842) mit LZMA-Kompression und NAND-Boxen mit ZIP-Kompression für das SquashFS klarkommt und auch gleich noch in der Lage ist, einen Kernel in der Datei für NOR-Boxen zu übergehen und das SquashFS-Image in der Datei zu lokalisieren.

Das habe ich allerdings nicht auf dem Server bereitgestellt, dort sollte das "normale" unsquashfs liegen, das auch nur für BE-Boxen taugt.

Frage: Gibt es eine Möglichkeit ohne Freetz-Linux-Environment das Kernel.image file auf einer NOR-Box auszupacken ?

Zum Vergrößern anklicken....

Die Frage ist also ganz klar mit "ja" zu beantworten, solange Du an ein passendes "unsquashfs" gelangen kannst. Ich sehe mir das mal an und schaue, ob ich ein Binary auf der Basis meines Patches bereitstellen kann ... allerdings verwende ich im Moment nur x86, VR9 und Vx180 - eine ARM-Version hätte ich noch.

Vielleicht findet sich ja jemand, der schon eine AR9-basierte Freetz-Installation hat und Dir das mal schnell übersetzt? Es braucht eigentlich nur einen zusätzlichen Patch für lzma465 (Ticket 2730) und den Patch für die squashfs-tools aus SquashFS 3.4 (Ticket 2731). Da das nie aufgenommen wurde (dafür war es auch nicht unbedingt gedacht, sollte mehr eine Anregung sein), ist aber nicht mehr gesichert, daß sich der Patch 1:1 anwenden läßt, falls/wenn dort zwischenzeitlich Änderungen erfolgt sind.

Ansonsten gibt es m.W. auch im Freetz-Trunk im Moment kein unsquashfs für Version 3 mit LZMA-Komprimierung, das sich für das Target übersetzen läßt. Dort ist wohl auch nur die Version für den Build-Host vorhanden.

Korrektur in extract_06.35_filesystem auf dem Server ... jetzt setzt das Skript entweder auf das losetup der Busybox (bzw. nutzt nur noch die dort verfügbaren Möglichkeiten, u.a. gibt es kein "--show") oder nimmt den steinigen Weg über "dd", wenn es kein "losetup" auf der Box gibt.

@lp10000:
Korrigiert, falsche Permissions für den Apache-User.

lp10000 schrieb:

Und kann man den unter dest entpackten Verzeichnisbaum dann denn auch irgendwie (mit einfachen Mitteln) auf diese Box flashen?

Zum Vergrößern anklicken....

Hast Du das hier mal gelesen? Wenn Du wegen einer NOR-Box fragst, lautet meine Antwort "Nein" (auch wenn die nicht 100%ig richtig ist, will ich Diskussionen darüber aus dem Weg gehen).

Ansonsten ist das vermutlich genau das, was Du meintest ...