[Gelöst] 7490: Firmware-Update von 113.06.20 auf 06.23 klappt nicht

[elmicha]

Ich versuche, mit dem Freetz-Firmware-Update von 113.06.20 rev28568 devel-12571 auf den aktuellen Trunk mit 06.23 upzudaten.
Das scheint auch einwandfrei zu funktionieren - aber nach dem Booten ist weiterhin die alte Firmware drauf.
Ich hab "AVM-Dienste nicht stoppen" und "Einen Teil der AVM-Dienste stoppen" probiert. External-Datei habe ich auf der 7490 nicht.

Hmm - bei den Ausgaben sehe ich ein "Adding failed", und "read 0x0 MACIG 0x0" sieht auch verdächtig aus. Liegt es daran oder ist das normal?

Soll ich das Image jetzt mit ftp/ADAM2 flashen (ich erinnere mich, dass das immer ein grosser Spass war)?

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.20  new: xx.06.23
debug: curr: 113.06.20
debug: new: "XX.06.23"
major_currFWver=113
middle_currFWver=6
minor_currFWver=20
middle_newFWver=6
minor_newFWver=23
check Firmware Version: xx.06.23
DEBUG: 6 >= 6
DEBUG: 23 >= 20
Accept Firmware Version: xx.06.23
install: 2.6.32 check files...
read 0x0 MACIG 0x0
File doesn't contain the checksum, adding
[cs_calc_sum] sum 0xe17dd927
Calculated checksum is E17DD927
[cs_set_sum] tagged 0
write 0x23de53c4, 0x27d97de1 MAGIC 0xc453de23 
Adding failed
chksum for file /var/tmp/filesystem.image ok
size for file /var/tmp/filesystem.image ok
read 0xceeb7499 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xceeb7499
Calculated checksum is CEEB7499
Saved checksum is CEEB7499
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=1961736
install: filesystem_start=0x00400000
install: filesystem_size=50331648
install: filesystem_image_size=48586752
install: 2.6.32 writing commands to install...
install: check for old settings ...
set INFO led to blink (modul=7, state=4)

#! /bin/sh
echo $0: start
sleep 1
killall run_clock
if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
if ps | grep -v grep | grep -q telnetd ; then killall telnetd ; fi
echo skip deleting language from env
echo MODE=update > /dev/avm_power
echo "disable" > /dev/watchdog
echo still running:
ps
lsmod
sleep 1
update_state=good
echo Erase mtd partitions '2' and '3' ...
/sbin/update_kernel -o /dev/mtd2
/sbin/update_kernel -o /dev/mtd3
echo Copy kernel image...
/sbin/update_kernel -i /var/tmp/kernel.image  -o /dev/mtd2
[ $? -ne 0 ] && echo failed with error "$?" && update_state=bad
echo Copy filesystem image ...
mkdir -p /var/tmp/fs
mkdir -p /var/tmp/fs_mtd
mount -t squashfs /var/tmp/filesystem.image /var/tmp/fs
mount -t yaffs2 /dev/mtdblock3 /var/tmp/fs_mtd
var_mount_squashfs=`mount | grep "/var/tmp/fs type squashfs"`
var_mount_mtd=`mount | grep /dev/mtdblock3`
[ -z "$var_mount_squashfs" ] && echo failed to mount filesystem.image && update_state=bad
[ -z "$var_mount_mtd" ] && echo failed to mount /dev/mtdblock3 && update_state=bad
if [ "$update_state" = "good" ] ; then
    echo Copy filesystem ...
    cp -R /var/tmp/fs/* /var/tmp/fs_mtd
    [ $? -ne 0 ] && echo failed with error "$?" && update_state=bad
    echo ... Copy filesystem done
fi
if [ "$update_state" = "good" ] ; then
    echo Setting linux_fs_start mirror...
    echo linux_fs_start 1 > /proc/sys/urlader/environment
else
    echo Setting linux_fs_start skipped due to errors...
fi
umount /var/tmp/fs
umount /var/tmp/fs_mtd
rmdir /var/tmp/fs
rmdir /var/tmp/fs_mtd
exit 0

 

[PeterPawn]

Das sieht alles vollkommen normal aus bis hierher. Jetzt muß sich nur noch jemand finden, der /var/post_install im Rahmen eines Reboots auch ausführt und dann erst könnte man sehen (sollte aber sogar aus einer Telnet-Session (mit "setconsole") heraus funktionieren, da der Telnet-Daemon nicht zu den vorher beendeten Diensten zählt), was bei der Abarbeitung von post_install passiert.

Du könntest auch mit dem Shell-Skript aus diesem Thread mal nachsehen (man muß ja nichts ändern), welche Systeme bei Dir in den beiden Partitionen enthalten sind und ob (wenn ja, mit welchem Wert) Dein Urlader-Environment die Variable "linux_fs_start" enthält. Nach dem Inhalt von post_install zu urteilen, fehlt die Variable entweder oder sie hat den Wert "0", der nach erfolgreichem Update durch "1" ersetzt werden soll (Zeile 38 in post_install).

Ansonsten kann - bei unglücklich gewählten Dateinamen oder schlampigem Script-Code, der nicht hinter sich aufräumt - ja z.B. eine Datei /var/tmp/fs (oder auch /tmp/fs, ist dieselbe Stelle im FS) durchaus dazu führen, daß das Update in 'post_install' nicht ausgeführt werden kann.

Theoretisch (wenn Du dann einfach den Stecker anschließend ziehst, obwohl theoretisch auch die doppelte Ausführung von post_install nicht schaden dürfte) kannst Du auch /var/post_install direkt in einer Telnet-Session aufrufen - je nach Bedarf auch mit Shell-Debug (sh -x /var/post_install) - und dabei das Ergebnis beobachten. Anders als bei NOR-Flash-Modellen ist das ja nicht das "finale Laden" eines Kernel-Modules zum Flashen, sondern es werden ganz "normale" Shell-Befehle/Binaries verwendet.

 

[elmicha]

Danke für die ausführlichen Infos!

"sh -x /var/post_install" nach dem Upload zeigt, wo das Problem ist:

...
+ echo Copy filesystem image ...
Copy filesystem image ...
+ mkdir -p /var/tmp/fs
+ mkdir -p /var/tmp/fs_mtd
+ mount -t squashfs /var/tmp/filesystem.image /var/tmp/fs
+ mount -t yaffs2 /dev/mtdblock3 /var/tmp/fs_mtd
+ mount
+ grep /var/tmp/fs type squashfs
+ var_mount_squashfs=/dev/loop1 on /var/tmp/fs type squashfs (ro,relatime)
+ mount
+ grep /dev/mtdblock3
+ var_mount_mtd=/dev/mtdblock3 on /var/tmp/fs_mtd type yaffs2 (rw,relatime)
+ [ -z /dev/loop1 on /var/tmp/fs type squashfs (ro,relatime) ]
+ [ -z /dev/mtdblock3 on /var/tmp/fs_mtd type yaffs2 (rw,relatime) ]
+ [ good = good ]
+ echo Copy filesystem ...
Copy filesystem ...
+ cp -R /var/tmp/fs/bin /var/tmp/fs/core /var/tmp/fs/dev /var/tmp/fs/etc /var/tmp/fs/filesystem_core.squashfs /var/tmp/fs/lib /var/tmp/fs/proc /var/tmp/fs/sbin /var/tmp/fs/tmp /var/tmp/fs/var /var/tmp/fs_mtd
cp: write error: No space left on device
cp: write error: No space left on device
+ [ 1 -ne 0 ]
+ echo failed with error 0
failed with error 0
+ update_state=bad
+ echo ... Copy filesystem done
... Copy filesystem done
+ [ bad = good ]
+ echo Setting linux_fs_start skipped due to errors...
Setting linux_fs_start skipped due to errors...
+ umount /var/tmp/fs
+ umount /var/tmp/fs_mtd
+ rmdir /var/tmp/fs
+ rmdir /var/tmp/fs_mtd
+ exit 0

Da ist das Filesystem ein bisschen zu gross. Wenn ich die beiden von Hand mounte, sieht's eigentlich so aus, als ob es passen müsste:

/dev/loop1               47488     47488         0 100% /var/tmp/fs
/dev/mtdblock3           49152     49152         0 100% /var/tmp/fs_mtd

Vermutlich habe die beiden Filesysteme unterschiedliche Blöckgrössen, so dass es trotzdem nicht passt?

STEP 3: PACK
  checking for left over Subversion directories
  integrate freetz info file into image
packing var.tar
creating filesystem image
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 1.9 MB, max 4.0 MB, free 2.1 MB (2232576 bytes)
copying filesystem image
  filesystem image size: 46.3 MB, max 48.0 MB, free 1.7 MB (1740800 bytes)
packing images/7490_06.23-freetz-devel-12871.de_20150118-163917.image
  image file size: 48.9 MB
done.

FINISHED

Na gut, dann muss ich wohl ein paar "das könnte man ja mal gebrauchen"-Sachen rausschmeissen, oder wieder mit External anfangen.

Edit: aha, damit hat's jetzt geklappt:

STEP 3: PACK
  checking for left over Subversion directories
  integrate freetz info file into image
packing var.tar
creating filesystem image
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 1.9 MB, max 4.0 MB, free 2.1 MB (2232576 bytes)
copying filesystem image
  filesystem image size: 43.4 MB, max 48.0 MB, free 4.6 MB (4775936 bytes)
packing images/7490_06.23-freetz-devel-12871.de_20150118-165708.image
  image file size: 46.0 MB
done.

FINISHED

 

[PeterPawn]

Edit: aha, damit hat's jetzt geklappt:

Im yaffs2-Teil liegen ja neben der Datei filesystem_core.squashfs noch eine Busybox, zwei Libraries, ein weiteres Binary und eine inittab für die Busybox (die mtab dürfte keinen Block zur Speicherung benötigen).

root@FB7490:~ $ find /wrapper/ -type f -exec ls -la '{}' \;
-rw-r-----    1 root     root             0 Dec 12 14:29 /wrapper/tmp/mtab
-rwxr-x--x    1 root     root          6470 Dec 12 14:29 /wrapper/sbin/flash_update
-rwxr-xr-x    1 root     root         31600 Dec 12 14:29 /wrapper/lib/ld-uClibc-0.9.33.2.so
-rwxr-xr-x    1 root     root        686304 Dec 12 14:29 /wrapper/lib/libuClibc-0.9.33.2.so
-rw-r-----    1 root     root           361 Dec 12 14:28 /wrapper/etc/inittab
-rwxr-x---    1 root     root        449244 Dec 12 14:28 /wrapper/bin/busybox
-rwx------    1 root     root      22683648 Dec 19 08:41 /wrapper/filesystem_core.squashfs

Allerdings habe ich keine Ahnung, wie es beim yaffs2 mit der Speicherung von "fragments" gelöst ist (also Dateien, die einen Block nur zu einem sehr geringen Teil belegen) und was da tatsächlich als Blockgröße verwendet wird (imho wäre die Verwendung der "erase_size" die logischste Variante) - mir fehlt auch der Antrieb es zu ergründen.

Aber wenn da tatsächlich die Blockgröße an die Größe eines zusammenhängend zu löschenden NAND-Blocks angepaßt ist (erase_size ist 0x20000, also 128 KB) und Fragmente nicht gesondert behandelt werden, dann nehmen die oben gelisteten Files schon 14x 128 KB zusätzlich ein (1,75 MB) und Du bist mit einiger Wahrscheinlichkeit (ein wenig Platz werden Verwaltungsstrukturen auch noch benötigen) nur ziemlich knapp über diese Grenze gekommen bei Deinem ersten Image. Ich würde mal tippen - wenn es jemand bis auf Blockgröße herausgefunden hat, kann er ja mal etwas dazu schreiben, das könnte man dann tatsächlich auch in Freetz als Warnung einbauen -, daß da so ca. 2 MB schon frei bleiben sollte, also ein "inneres"Filesystem-Image für eine 7490 die Grenze von 46 MB nicht überschreiten sollte. Im Moment checkt Freetz halt gegen die 48 MB der Partitiongröße. Vielleicht sollte man das tatsächlich als Ticket mal einstellen, dann aber bitte auch mit der richtigen Lösung (also nach Suche in den yaffs2-Quellen, wie das wirklich läuft, meine Ausführungen sind nur Annahmen, das habe ich deutlich geschrieben), damit man das korrekt berechnen kann. Das gilt dann sicherlich auch nicht nur für die 7490 (es geht ja nicht um den NAND-Flash unter /var/media/ftp), sondern für viele (alle?) Modelle mit NAND-Flash für das Root-Filesystem.