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

[PeterPawn]

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]

Hallo PeterPawn,
ich habe eine Frage zu kernel.image:
Ist das Format des Kernel.image Files zwischen NAND- und NOR-Boxen unterschiedlich ?

Hintergrund: das Auspacken eines kernel.image Files mit den Skriptsequenzen aus http://yourfritz.de/7490/extract_filesystem
kann man das kernel.image aus Fritz-File auf

tar xf $image -O ./var/tmp/kernel.image >$basedir/rootfs_tmp/kernel/kernel.image

hat bei mir mit NOR-Box nicht funktioniert:

# ls -la FRITZ.Box_7330.107.06.30.image
-rwxrwxrwx 1 root root 15687680 Jul 20 19:43 FRITZ.Box_7330.107.06.30.image
# tar tvpf FRITZ.Box_7330.107.06.30.image
drwxr-x--- 0/0 0 2015-07-13 15:40:52 ./var/
-rw-r----- 0/0 43120 2014-09-08 14:10:59 ./var/flash_update_2.6.28.ko
-rwxr-x--- 0/0 285000 2014-09-08 14:15:37 ./var/regelex
-rwxr-x--- 0/0 38774 2015-07-13 15:40:52 ./var/install
-rwxr-x--- 0/0 2795 2015-07-13 15:40:52 ./var/info.txt
drwxr-x--- 0/0 0 2015-07-13 15:40:52 ./var/tmp/
-rw-r----- 0/0 0 2015-07-13 15:40:52 ./var/tmp/filesystem.image
-rw-r----- 0/0 343631 2015-07-13 15:40:29 ./var/tmp/System.map.lzma
-rw-r----- 0/0 14632661 2015-07-13 15:40:52 ./var/tmp/kernel.image
-rw-r----- 0/0 53520 2015-05-06 13:36:30 ./var/flash_update_2.6.32.ko
-rwxr-x--- 0/0 278960 2014-09-08 14:15:37 ./var/chksum
-rw-r----- 0/0 128 2015-07-13 15:40:52 ./var/signature
#
# tar tvpf FRITZ.Box_7330.107.06.30.image
SNIP
# cd var
# cd tmp
# ls -la
drwxrwxrwx 2 root root 4096 Jul 22 21:03 .
drwxrwxrwx 3 root root 4096 Jul 22 21:04 ..
-rwxrwxrwx 1 root root 343631 Jul 13 15:40 System.map.lzma
-rwxrwxrwx 1 root root 0 Jul 13 15:40 filesystem.image
-rwxrwxrwx 1 root root 14632661 Jul 13 15:40 kernel.image
# tar tvpf kernel.image
tar: invalid tar magic
# file kernel.image
-sh: file: not found
#

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

Gruß
Splenditnet

 

[PeterPawn]

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

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 ?

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.

 

[PeterPawn]

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]

Verfügbarkeit von http://yourfritz.de/7490/unsquashfs4

http://yourfritz.de/7490/unsquashfs4 …

Ich hätte es mir gerne geholt, aber:

$ wget http://yourfritz.de/7490/unsquashfs4
--2015-08-02 14:00:48--  http://yourfritz.de/7490/unsquashfs4
Resolving yourfritz.de... 85.214.20.177
Connecting to yourfritz.de|85.214.20.177|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2015-08-02 14:00:49 ERROR 403: Forbidden.

 

[PeterPawn]

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

 

[lp10000]

fein, fein!

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

Danke schön!

 

[lp10000]

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

Wenn man da vorher z.B. noch den telnetd-Link geflickt
oder dieses oder jenes Tool untergebracht hat könnte das ja durchaus nützlich und gewinnbringend sein.

 

[PeterPawn]

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

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 ...

 

[lp10000]

Hast Du das hier mal gelesen?

Ich fand den Titel für mich bisher nicht zielführend – also zu etwas, was ich mir als mein Ziel vorstellen konnte.
Nach deinem persönlichen Hinweis habe ich es selbstverständlich (in Auszügen) gelesen.
Und insbesondere habe ich README.ger und README gelesen
und modscripts/mod_enable_telnet entdeckt.

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

Ja, das ist wirklich genau, was ich meine.

Und ich werde heute noch modfs_with_0635 auf meiner 7490 ausführen.


Wenn ich gelegentlich wieder ordentlich bei Kasse bin, magst du mir dann eine "angemessene" Rechnung stellen?
Ehrlich!
Deine Arbeit ist wirklich Gold wert.
(Zumindest in einem gewissen Rahmen.)
Auf 'ne Weiße (etc.) in einem Biergarten deiner Wahl kann ich dich aber schon in der Zwischenzeit einladen.

Aber erstmal eine ganz großes "Danke-Schön"!


Ich fass es nicht – ich komm ohne freetz aus und komme wohl trotzdem ans Ziel – das ist erstaunlich.
(Ich hatte den Eindruck gewonnen, eine freetz-Installation könnte mir den Rest an mentaler Gesundheit rauben.)

Update 2015-08-04:
Eine 7490 (offline) ließ sich problemlos mit modfs behandeln.
Die zweite 7490 (eigentlich VDSL-online, mit FRITZ!Fons dran etc.) brauchte erst das "prepare_fwupgrade start_tr069", dann lief modfs auch problemlos.