[Gelöst] FW 6.50 für 7490 in Trunk rev. 13490 - keine Auswahlmöglichkeit

[JohnDoe42]

Hallo zusammen,

nach einem Update auf die Trunk-Version 13490 hatte ich freudig gehofft, eine Image auf Basis von 113.06.50 erstellen zu können.
Leider existiert im menuconfig keine Auswahlmöglichkeit für die 06.50. Sollte ich noch etwas händisch anpassen ?
Grüße,

JD.

 

[gismotro]

Ist aktuell nur für Entwickler nutzbar.

 

[gismotro]

@Entwickler:

Läuft bei Euch schon Freetz auf der 7490 ? Bei mir bleibt die Box beim starten hängen.

Es wurde nur Freetz ohne addons aktiviert (Minimal-Image)

Edit: Wenn ich ein Freetz 6.30 flasche und dann per Freetz update kommt folgende Meldung:

update abort - missing Flashtool 'dd'

Ausführen des Firmware-Installationsskripts /var/install ...

install: have Kernel 2.6.32.61 - set kversion '2.6.32' and FlashUpdateTool '/lib/modules/2.6.32.61/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=
ANNEX=B
testing acceptance for device Fritz_Box_HW185 ...
korrekt install type: mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
device has installtype mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
OK - accept this update for device Fritz_Box_HW185 ...
testing acceptance for device Fritz_Box_HW185 done
curr: 113.06.30  new: xx.06.50
debug: curr: 113.06.30
debug: new: "XX.06.50"
major_currFWver=113
middle_currFWver=6
minor_currFWver=30
middle_newFWver=6
minor_newFWver=50
check Firmware Version: xx.06.50
DEBUG: 6 >= 6
DEBUG: 50 >= 30
Accept Firmware Version: xx.06.50
install: 2.6.32 check files...
read 0x0 MACIG 0x0
File doesn't contain the checksum, adding
[cs_calc_sum] sum 0x7f35553f
Calculated checksum is 7F35553F
[cs_set_sum] tagged 0
write 0x23de53c4, 0x3f55357f MAGIC 0xc453de23 
Adding failed
chksum for file /var/tmp/filesystem.image ok
size for file /var/tmp/filesystem.image ok
read 0x8ff24569 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x8ff24569
Calculated checksum is 8FF24569
Saved checksum is 8FF24569
Checksum validation successful!
chksum for file /var/tmp/kernel.image ok
size for file /var/tmp/kernel.image ok
install: 2.6.32 getting mtds to install...
install: --mtd------------------------------------------------
install: --assert---------------------------------------------
install: --addr+size------------------------------------------
install: kernel_start=0x00000000
install: kernel_size=4194304
install: kernel_image_size=2506248
install: filesystem_start=0x00400000
install: filesystem_size=50331648
install: filesystem_image_size=22820096
update abort - missing Flashtool 'dd'

ERLEDIGT – Rückgabewert des Installationsskripts: 6 (INSTALL_OTHER_ERROR)

Von /var/post_install generierter Inhalt:

Fehler: Nach-Installationsskript nicht gefunden oder nicht ausführbar.

 

[Tieflieger]

Ich denke fwmod pack nicht richtig nach den neuen System - hab dies schon bei den Ganzen Labors gehabt.

 

[JohnDoe42]

Hallo zusammen,

nachdem ich die 6.50 auswählbar gemacht habe, ergibt sich auch nach r13501 immer noch folgender Fehler beim Bauen:

STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
    Reading a different endian SQUASHFS filesystem on build/original/firmware/var/tmp/filesystem.image
    Filesystem on build/original/firmware/var/tmp/filesystem.image is (0:0), which is a later filesystem version than I support!
ERROR: modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image
make: *** [firmware-nocompile] Fehler 1

 

[PeterPawn]

http://freetz.org/ticket/2774

Der Stand der Anpassung an 06.50 ... da ist nichts davon zu lesen, daß es funktionieren sollte.

Schon der erste Fehler in #5 zeigt doch deutlich, daß da beim Auspacken vermutlich der zusätzliche 256-Byte-Header gar nicht entfernt wurde und damit als SquashFS-Superblock interpretiert wird (das ist jedenfalls die logischste Erklärung für Major/Minor "0:0"). Das sieht nach einem falschen Herangehen an ein SquashFS4-basiertes Image aus.

Also muß man wohl wenigstens noch in "fwmod" nachsehen, wie die alternative Image-Struktur aktiviert wird ... und das dann ebenso aktivieren wie die "Auswählbarkeit" der 06.5x.

Es ist beileibe bei der 06.50 für die 7490 nicht mit einer abweichenden Quellenangabe für das originale Firmware-Image getan - da gehört noch einiges mehr dazu und das ist (meines Wissens) noch lange nicht fertig. Auch fehlen ja wohl noch die OpenSource-Pakete von AVM für die 113.06.50.

 

[JohnDoe42]

Okay, danke für den Tip. Ich werde vorbehaltlich Zeit heute mal in fwmod nachsehen, was dort passiert.
Grüße,

JD.

 

[er13]

nachdem ich die 6.50 auswählbar gemacht habe...

Ich werde vorbehaltlich Zeit heute mal in fwmod nachsehen, was dort passiert.

Um zu verhindern, dass die Leute ihre Zeit verschwenden...

Bei 6.5x reicht es NICHT irgendwelche OVERRIDE-Variablen zu setzen - es wird nichts funktionieren - man muss es wirklich im menuconfig angeboten bekommen und auswählen.

Ansonsten, was den Fortschritt angeht, so gilt immer noch die Aussage aus diesem Post.

6.5x sollte sich sowohl entpacken als auch wieder packen lassen, und zwar sowohl das originale als auch das von Freetz erzeugte Image (beides sowohl mit fwmod als auch mit tools/fwdu). Dieses "entpacken/packen lassen" sollte als "compile-tested only" verstanden werden, auf der Box wurde von mir (mangels Zeit, aus privaten Gründen) nichts getestet.

Da bei 7490.06.5x nicht nur das Packaging-Scheme, sondern auch noch der Kernel geändert wurden, wäre es wünschenswert, wenn man verschiedene Anpassungen separat testen würde. Ein guter Test dafür, ob das Packaging-Scheme richtig umgesetzt wurde, wäre "das Wiederbeleben von debug.cfg" gemäß dieser Anleitung (die Tatsache, dass es inzwischen andere Lösungen dafür gibt, sollte an der Stelle ignoriert werden, es soll wirklich nur als Test für die Korrektheit der Umsetzung des Packaging-Schemes verwendet werden).

 

[JohnDoe42]

6.5x sollte sich sowohl entpacken als auch wieder packen lassen, und zwar sowohl das originale als auch das von Freetz erzeugte Image (beides sowohl mit fwmod als auch mit tools/fwdu).

Es tut mir leid, aber auch r13503 führt bei meinem Bau auf den gleichen Fehler wie in #5. D.h. beim lediglichen Kompilieren, von einem Flashen und weiteren Testen bin ich folglich noch entfernt.

 

[PeterPawn]

@JohnDoe42:
In der Datei "tools/freetz_functions" fehlt in der Funktion "modunpack_autodetect_fs" bei den blkid-Aufrufen der Parameter "-p", damit da direkt die Datei gelesen wird.

Der Patch sähe so aus:

--- tools/freetz_functions      (revision 13504)
+++ tools/freetz_functions      (working copy)
@@ -309,9 +309,9 @@

 modunpack_autodetect_fs()
 {
-       if $BLKID -O 256 "$2" 2>/dev/null | grep -q 'TYPE="ext2"'; then
+       if $BLKID -p -O 256 "$2" 2>/dev/null | grep -q 'TYPE="ext2"'; then
                modunext2 "$@"
-       elif $BLKID -O 0 "$2" 2>/dev/null | grep -q 'TYPE="squashfs"'; then
+       elif $BLKID -p -O 0 "$2" 2>/dev/null | grep -q 'TYPE="squashfs"'; then
                modunsqfs "$@"
        else
                error 1 "modunpack_autodetect_fs: failed to detect file system type of '$2'"

Ist allerdings ebenfalls ungetestet ... das überlasse ich Dir.
Irrtum meinerseits, eigentlich sollte das mit dem blkid-Applet der Busybox auch so funktionieren ... siehe #12.

 

[gismotro]

Es tut mir leid, aber auch r13503 führt bei meinem Bau auf den gleichen Fehler wie in #5. D.h. beim lediglichen Kompilieren, ....

Build läuft bei mir ohne Probleme, flashen geht auch, aber danach startet die Box nicht mehr.

 

[PeterPawn]

Ich habe gerade noch einmal nachgeschaut, es wird ja das blkid-Applet aus der Busybox verwendet von Freetz/fwmod, das braucht/kennt die p-Option gar nicht.

Das heißt aber, daß bei JohnDoe42 etwas anderes beim Auspacken schiefgehen muß oder daß die "freetz_functions"-Datei einen anderen Inhalt hat - denn offenbar wird ja anstelle von "modunext2" das "modunsqfs" aufgerufen, was erst für das innere Dateisystem der Fall sein dürfte, der Fehlermeldung nach aber bereits für das äußere erfolgt:

ERROR: modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image

Entweder da wird (wie bei mir) ein anderes blkid-Kommando gefunden oder ich kann mir nicht erklären, warum bei einem validen AVM-Image 06.50 bei Offset 256 in der filesystem.image kein ext2-Superblock gefunden und damit der falsche Zweig zum Entpacken gewählt wird.

EDIT: Also das Auspacken funktioniert mit einem testweise frisch ausgecheckten Trunk bei mir ebenfalls.

@JohnDoe42: Setz doch mal in die Datei "tools/freetz_functions" am Beginn von "modunpack_autodetect_fs" noch ein "set -x" ein, damit dort mal die Bash-Protokollierung aktiviert wird und poste das Ergebnis ab "modunpack_autodetect_fs" mal hier.

@gismotro:
Hast Du mal das fertige Image von Hand auseinander genommen und versucht, das Filesystem direkt zu mounten? Oder mal den Kernel als Datei mit dem Inhalt seiner MTD-Partition verglichen? Wie sieht denn die Ausgabe von /var/install beim Update aus?

 

[gismotro]

Nein, habe ich alles noch nicht gemacht.

 

[PeterPawn]

Nein, habe ich alles noch nicht gemacht.

Ich habe mal aus Spaß mit fwmod entpackt, manuell etwas geändert (den Symlink für Telnet) und wieder gepackt. Anschließend von Hand installiert (Kernel und Filesystem zu Fuß in ihre jeweiligen Partitionen, beim Filesystem natürlich mit "cp" in ein frisches yaffs2) und dann dieses System mal angestartet ... läuft bei mir - aber ist eben die originale Firmware und kein Build. Damit funktioniert aber wohl Entpacken und Packen wie erwartet ... mit dem originalen AVM-Skript /var/install habe ich allerdings die Installation nicht getestet, aber eigentlich alles von Hand ausgeführt (außer Checksummen-Vergleich), was das Skript auch macht.

 

[JohnDoe42]

@JohnDoe42: Setz doch mal in die Datei "tools/freetz_functions" am Beginn von "modunpack_autodetect_fs" noch ein "set -x" ein, damit dort mal die Bash-Protokollierung aktiviert wird und poste das Ergebnis ab "modunpack_autodetect_fs" mal hier.

Gerne:

STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
+ /home/john/freetz-trunk-7490/tools/blkid -O 256 build/original/firmware/var/tmp/filesystem.image
+ grep -q 'TYPE="ext2"'
+ /home/john/freetz-trunk-7490/tools/blkid -O 0 build/original/firmware/var/tmp/filesystem.image
+ grep -q 'TYPE="squashfs"'
+ modunsqfs build/original/filesystem_core build/original/firmware/var/tmp/filesystem.image
+ local STATUS
+ '[' 2 -ge 2 ']'
+ /home/john/freetz-trunk-7490/tools/unsquashfs4-lzma-avm-be -no-progress -processors 1 -exit-on-decomp-error -dest build/original/filesystem_core build/original/firmware/var/tmp/filesystem.image
+ grep -v '^$'
+ sed -e 's/^/    /g'
    Reading a different endian SQUASHFS filesystem on build/original/firmware/var/tmp/filesystem.image
    Filesystem on build/original/firmware/var/tmp/filesystem.image is (0:0), which is a later filesystem version than I support!
+ STATUS=1
+ '[' 1 -gt 0 ']'
+ error 1 'modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image'
+ local err_no=1
+ '[' 1 -eq 0 ']'
+ shift
+ echoX -c -p 'ERROR: ' 'modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image'
+ local indent no_indent prefix no_newline bold unbold colour uncolour
+ OPTIND=0
+ getopts :i:p:lnbc opt
+ case $opt in
+ colour='\033[33m'
+ uncolour='\033[m'
+ getopts :i:p:lnbc opt
+ case $opt in
+ prefix='ERROR: '
+ getopts :i:p:lnbc opt
+ shift 3
+ '[' ']'
+ echo -e '\033[33mERROR: modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image\033[m'
ERROR: modunsqfs: Error in build/original/firmware/var/tmp/filesystem.image
+ exit 1
make: *** [firmware-nocompile] Fehler 1

 

[PeterPawn]

Führe mal bitte die Kommandos

tools/blkid --help
tools/blkid -O 256 build/original/firmware/var/tmp/filesystem.image

im Trunk-Verzeichnis einzeln aus ... die Ausgabe des zweiten sollte - beim blkid-Applet der 1.23.2 - eigentlich so aussehen:

build/original/firmware/var/tmp/filesystem.image@256: TYPE="ext2"

Offenbar ist das bei Dir aber nicht der Fall, also ist entweder das blkid-Kommando ein anderes (daher das --help beim ersten Kommando) oder das Firmware-Image ist das falsche. Da kriegst Du durch ein

~/trunk$ hd -n 2048 build/original/firmware/var/tmp/filesystem.image
00000000  73 71 73 68 00 00 00 00  00 00 00 00 00 00 00 00  |sqsh............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  d8 00 00 00 44 56 00 00  00 00 00 00 7f 07 00 00  |....DV..........|
00000510  09 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000520  c8 1c 00 00 c8 1c 00 00  48 00 00 00 00 00 00 00  |........H.......|
00000530  3d d2 66 56 00 00 14 00  53 ef 01 00 00 00 00 00  |=.fV....S.......|
00000540  3d d2 66 56 00 00 00 00  00 00 00 00 00 00 00 00  |=.fV............|
00000550  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800

heraus, was dann die o.a. Anzeige zur Folge haben sollte.

 

[JohnDoe42]

blikd --help (wobei "--" schon einen Fehler wirft):

john@pc-john:~/freetz-trunk-7490/tools$ blkid --help
blkid: invalid option -- '-'
blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)
Usage:
 blkid -L <label> | -U <uuid>

 blkid [-c <file>] [-ghlLv] [-o <format>] [-s <tag>] 
       [-t <token>] [-w <file>] [<dev> ...]

 blkid -p [-s <tag>] [-O <offset>] [-S <size>] 
       [-o <format>] <dev> ...

 blkid -i [-s <tag>] [-o <format>] <dev> ...

Options:
 -c <file>   cache file (default: /etc/blkid.tab, /dev/null = none)
 -d          don't encode non-printing characters
 -h          print this usage message and exit
 -g          garbage collect the blkid cache
 -o <format> output format; can be one of:
               value, device, list, udev, export or full; (default: full)
 -k          list all known filesystems/RAIDs and exit
 -s <tag>    show specified tag(s) (default show all tags)
 -t <token>  find device with a specific token (NAME=value pair)
 -l          look up only first device with token specified by -t
 -L <label>  convert LABEL to device name
 -U <uuid>   convert UUID to device name
 -v          print version and exit
 -w <file>   write cache to different file (/dev/null = no write)
 <dev>       specify device(s) to probe (default: all devices)

Low-level probing options:
 -p          low-level superblocks probing (bypass cache)
 -i          gather information about I/O limits
 -S <size>   overwrite device size
 -O <offset> probe at the given offset
 -u <list>   filter by "usage" (e.g. -u filesystem,raid)
 -n <list>   filter by filesystem type (e.g. -n vfat,ext3)

Daher ist die Ausgabe von

blkid -O 256 build/original/firmware/var/tmp/filesystem.image

bei mir auch leer ... (?)

hd -n 2048 build/original/firmware/var/tmp/filesystem.image:

john@pc-john:~/freetz-trunk-7490$ hd -n 2048 build/original/firmware/var/tmp/filesystem.image
00000000  73 71 73 68 00 00 00 00  00 00 00 00 00 00 00 00  |sqsh............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  d8 00 00 00 44 56 00 00  00 00 00 00 7f 07 00 00  |....DV..........|
00000510  09 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000520  c8 1c 00 00 c8 1c 00 00  48 00 00 00 00 00 00 00  |........H.......|
00000530  3d d2 66 56 00 00 14 00  53 ef 01 00 00 00 00 00  |=.fV....S.......|
00000540  3d d2 66 56 00 00 00 00  00 00 00 00 00 00 00 00  |=.fV............|
00000550  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800

 

[PeterPawn]

Falsches "blkid"-Kommando ...

make tools-distclean
make tools

wobei auch ein generelles "make distclean" wahrscheinlich kein Fehler wäre. Bei Deinem "blkid" ist eben genau das weiter oben beschriebene fehlende "-p" das Problem (die zweite dritte Form des Aufrufs in der Kurzhilfe).

Allerdings wird beim aktuellen SVN-Stand dann der 3.10.73-Kernel (vanilla) ausgewählt und versucht zu bauen, dem fehlen aber einige notwendige Patches in make/linux/$FREETZ_KERNEL_VERSION - u.a. schon beim make-Target "vmlinux.eva_pad" - die sind nur bis 2.6.32.61 vorhanden.

Die ganzen Patches jeweils anzupassen auf die neue Kernelversion (und das - zumindest vorläufig - noch ohne AVM-Änderungen auf der Basis des Vanilla-Kernels und bei einem kompletten Versionswechsel des Kernels) ist ziemlicher Aufwand ... als Build-System würde ich Freetz derzeit also noch nicht empfehlen, die Tools zum Aus- und Einpacken werden mit den o.a. Kommandos aber vermutlich richtig gebaut.

Vorläufig würde ich "normale" Pakete noch auf der Basis von 06.30 erzeugen (und damit mit dem 2.6.32-Kernel, die uClibc hat sich ohnehin nicht geändert) - solange die keine Kernel-Strukturen kennen müssen oder sich diese Strukturen nicht geändert haben, sollte das die erzeugten Binaries nicht tangieren. Der Busybox z.B. ist es tatsächlich egal (nach dem, was ich bisher testen konnte), wenn die für eine 06.30 erzeugte Datei auf der 06.50 verwendet wird und auch den SquashFS-Tools (bei "modfs" getestet) ist es vollkommen schnuppe, die funktionieren unter 06.30 (und damit Kernel 2.6.32) genauso wie unter 06.50 (Kernel 3.10.73).

EDIT: Wobei ich gerade sehe, daß Du beim Aufruf von "blkid" ja keinen Pfad zum "tools"-Unterverzeichnis angegeben hast, damit wird der normale Suchpfad des Build-Hosts verwendet und da ist das falsche "blkid"-Kommando ja vorprogrammiert ... eigentlich kannst Du den Text in diesem Beitrag also komplett vergessen - rufe mal testweise einfach noch das richtige "blkid" (eben aus "tools" im Trunk-Verzeichnis) auf. Daß man sich in das Verzeichnis hineinmanövriert und dort nur den Kommandonamen eingibt, hilft nur dann etwas, wenn da irgendwo in der PATH-Variablen auch das aktuelle Verzeichnis (".") enthalten ist (und zwar vor den anderen Verzeichnissen, sonst wird dort das "blkid" immer noch eher gefunden), ansonsten braucht es auch im aktuellen Verzeichnis den Aufruf "./blkid".

 

[mrspeccy]

Ich weiß nicht so recht, wo ich mein Feedback hinterlassen soll - im Freetz-Ticket oder hier? Ich habe auch ein Freetz-Image für die 7490 auf Basis der FW 6.50 gebaut. Keine Kompilationsprobleme. Auch der Versuch des Flashens über das existierende Freetz-Interface (auf Basis der 6.30) wird ohne Fehlermeldung abgeschlossen ("INSTALL SUCCESS") und resultiert wie gewohnt in einem Neustart. Jedoch bootet die Box danach immer noch mit der 6.30, d. h. die neue Firmware wird nicht wirklich geflasht.

 

[PeterPawn]

die neue Firmware wird nicht wirklich geflasht.

Ausgabe des /var/install-Aufrufs?

EDIT: Und bei Dir wurde der 3.10.73-Kernel ohne Probleme übersetzt? Das erstaunt mich etwas ...

Nach den Angaben im "config"-Verzeichnis in r13504 sollte eigentlich dieser Kernel automatisch ausgewählt werden:

config FREETZ_TYPE_FIRMWARE_06_5X
        bool "FRITZ!OS 06.5x - HIGHLY EXPERIMENTAL"
        select [COLOR="#00FF00"]FREETZ_AVM_VERSION_06_5X[/COLOR]
        depends on FREETZ_AVM_HAS_FIRMWARE_06_5X && FREETZ_SHOW_ADVANCED
[...]
config [COLOR="#0000FF"]FREETZ_AVM_VERSION_06_5X_MIN[/COLOR]
        bool
        default y if \
                [COLOR="#00FF00"]FREETZ_AVM_VERSION_06_5X[/COLOR]
        default n
[...]
config [COLOR="#FF0000"]FREETZ_KERNEL_VERSION_3_10_73[/COLOR]
        bool
        default y if \
                (FREETZ_TYPE_7490 && [COLOR="#0000FF"]FREETZ_AVM_VERSION_06_5X_MIN[/COLOR])
        default n

und in "make/linux/patches" fehlt die 3.10.73 ja noch komplett (s. #18).