[Frage] LCR mit Firmware 6.50

Ohne die ständigen Rückversicherungen weiter ... die mksquashfs.c_save-irgendwas ist einfach von make beim Cleanup vor dem erneuten Auspacken der Quellen gelöscht worden, das ist vollkommen normal - daher war die Sicherung der "originalen" Datei in diesem Verzeichnis wenig hilfreich und man braucht sie eigentlich weder für Vergleiche noch für das Wiederherstellen des vorherigen Zustands, weil man sie einfach erneut auschecken kann.

Nach dem jetzt fälligen Packen der Firmware durch "fwmod" (das neue mksquashfs wurde lt. Protokoll ja erzeugt) kann man noch einmal einen Kontrollblick in die erzeugte Image-Datei werfen (die "raw"-Version), wenn man das unbedingt will und sowohl den Superblock als auch den letzten Block prüfen ... ansonsten einfach installieren lassen und schauen, ob es geht.

Wenn man ständig irgendwelche alten Stände sichert und immer wieder von vorne nachsieht, ob das "patch"-Kommando auch tatsächlich das getan hat, was es mit "patching file ..." zum Ausdruck bringen wollte, dann blickt am Ende niemand mehr durch den Wust an Kommandos durch. Ich habe zwar mal bemerkt, daß das alles auf einmal ausgeführt und getestet werden soll/muß, dabei hatte ich aber mehr ein Szenario im Auge, wo man bis zu einem Fehler vorwärts arbeitet und dann von dort rückwärts nach der Ursache sucht. Das geht nicht immer (weil so ein Neustart eben auch Zwischenergebnisse "vernichtet"), aber wenn man vor lauter Prüfungen (die dann auch noch Phantomfehler aufzeigen anstelle von echten Problemen) gar nicht mehr durchsieht, ist das auch alles andere als hilfreich.

Die Zwischenstände auf dem Buildsystem bleiben ja auch dann erhalten, wenn die FRITZ!Box neu gestartet werden muß ... das kann man dann also immer noch alles prüfen (vorausgesetzt, die Kommandos werden ohne Fehlermeldungen abgearbeitet), wenn das Ergebnis erneut nicht das erwartete ist. Aber das hier wird irgendwie immer mehr das beliebte Gesellschaftsspiel "Ich packe meinen Koffer und nehme mit ..." - ich persönlich kriege jedenfalls langsam Knoten im Hirn, weil es eben immer noch nicht besser geworden ist mit der Lesbarkeit der ellenlangen Protokolle der Abarbeitung.

Wenn es nicht bald klappen sollte, würde ich doch darum bitten, da zwischen den einzelnen Kommandos jeweils einen neuen "CODE"-Block aufzumachen, dann kann man auch viel leichter sofort die Ausgabe jedes einzelnen Kommandos beim Kopieren in den Beitrag noch einmal selbst kritisch beäugen, ob das Ergebnis plausibel ist oder nicht.

Ich verstehe z.B. überhaupt nicht, warum da im ersten CODE-Block in #140 dasselbe Kommando beim vierten Aufruf (ohne daß man dazwischen etwas sehen kann) dann ein anderes Ergebnis liefert als bei den ersten dreien ... da stimmt entweder das Listing nicht oder es gibt doch den "deus ex machina", der die Ergebnisse nach Gusto beeinflußt.
Code:
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
-rw-r--r-- 1 frank frank 1403 Jun  9 22:37 check_7360v2_flash_problem_neu.patch
 
Ok. hab jetzt einfach weiter gemacht und ein neues Freetz-Image erstellt.
Code:
frank@frank-ThinkPad-X121e:~$ cd freetz-trunk
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ./fwmod -u -d unpacked_firmware FRITZ.Box_Fon_WLAN_7360.124.06.50.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...splitting kernel image
unpacking filesystem image
    Filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw is xz compressed (4:0)
    Parallel unsquashfs: Using 1 processor
    2487 inodes (2993 blocks) to write
    created 1915 files
    created 172 directories
    created 485 symlinks
    created 87 devices
    created 0 fifos
unpacking var.tar
done.

detected firmware 7360_de 124.06.50 rev32505 (25.02.2016 10:46:29)

FINISHED
frank@frank-ThinkPad-X121e:~/freetz-trunk$ sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
> if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
> mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
> if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
> . /var/flash/debug.cfg\
> fi\
> fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"
frank@frank-ThinkPad-X121e:~/freetz-trunk$ [ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ./fwmod -p -d unpacked_firmware FRITZ.Box_Fon_WLAN_7360.124.06.50.image
detected firmware 7360_de 124.06.50 rev32505 (25.02.2016 10:46:29)

STEP 3: PACK
WARNING: Modifications (STEP 2) and this step should never
         ever be run with different configurations!
         This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
  checking for left over Subversion directories
packing var.tar
creating filesystem image
  SquashFS block size: 64 kB (65536 bytes)
merging kernel image
  kernel image size: 17.7 MB, max 31.4 MB, free 13.6 MB (14310590 bytes)
  Aproximately maximal time for the answering machine: 115 min, 32 sec (6932 sec)
packing unpacked_firmware/7360_v2_-.de_20160609-233539.image
  image file size: 18.4 MB
done.

FINISHED
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ./fwmod -u -d test_unpack_2 unpacked_firmware/7360_v2*.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...splitting kernel image
unpacking filesystem image
    Filesystem on test_unpack_2/original/kernel/kernelsquashfs.raw is xz compressed (4:0)
    Parallel unsquashfs: Using 1 processor
    2488 inodes (2994 blocks) to write
    created 1915 files
    created 172 directories
    created 486 symlinks
    created 87 devices
    created 0 fifos
unpacking var.tar
done.

detected firmware 7360_de 124.06.50 rev32505 (25.02.2016 10:46:29)

FINISHED
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/original/filesystem/usr/sbin/telnetd
lrwxrwxrwx 1 frank frank 17 Jun  9 23:35 unpacked_firmware/original/filesystem/usr/sbin/telnetd -> ../../bin/busybox
frank@frank-ThinkPad-X121e:~/freetz-trunk$ grep debug.cfg unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/original/kernel/ test_unpack_2/original/kernel/
test_unpack_2/original/kernel/:
insgesamt 18168
drwxr-xr-x 3 frank frank     4096 Jun  9 23:36 .
drwxr-xr-x 5 frank frank     4096 Jun  9 23:36 ..
-rw-r--r-- 1 frank frank  2505984 Jun  9 23:36 kernel.raw
-rw-r--r-- 1 frank frank 16082498 Jun  9 23:36 kernelsquashfs.raw
drwxr-xr-x 3 frank frank     4096 Jun  9 23:35 var.tar

unpacked_firmware/original/kernel/:
insgesamt 18176
drwxr-xr-x 3 frank frank     4096 Jun  9 23:34 .
drwxr-xr-x 5 frank frank     4096 Jun  9 23:34 ..
-rw-r--r-- 1 frank frank  2505984 Jun  9 23:34 kernel.raw
-rw-r--r-- 1 frank frank 16091024 Jun  9 23:34 kernelsquashfs.raw
drwxr-xr-x 3 frank frank     4096 Jun  9 23:34 var.tar
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/original/firmware/var/install test_unpack_2/original/firmware/var/install
-rwxr-x--- 1 frank frank 39356 Jun  9 23:35 test_unpack_2/original/firmware/var/install
-rwxr-x--- 1 frank frank 39356 Feb 25 10:46 unpacked_firmware/original/firmware/var/install
frank@frank-ThinkPad-X121e:~/freetz-trunk$ diff unpacked_firmware/original/firmware/var/install test_unpack_2/original/firmware/var/install
frank@frank-ThinkPad-X121e:~/freetz-trunk$

#123
Code:
frank@frank-ThinkPad-X121e:~$ cd freetz-trunk
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/7360_v2*.image
-rw-r--r-- 1 frank frank 19293696 Jun  9 23:36 unpacked_firmware/7360_v2_-.de_20160609-233539.image
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/original/kernel/ unpacked_firmware/modified/kernel test_unpack_2/original/kernel/
test_unpack_2/original/kernel/:
insgesamt 18168
drwxr-xr-x 3 frank frank     4096 Jun  9 23:36 .
drwxr-xr-x 5 frank frank     4096 Jun  9 23:36 ..
-rw-r--r-- 1 frank frank  2505984 Jun  9 23:36 kernel.raw
-rw-r--r-- 1 frank frank 16082498 Jun  9 23:36 kernelsquashfs.raw
drwxr-xr-x 3 frank frank     4096 Jun  9 23:35 var.tar

unpacked_firmware/modified/kernel:
insgesamt 18168
drwxr-xr-x 3 frank frank     4096 Jun  9 23:35 .
drwxr-xr-x 5 frank frank     4096 Jun  9 23:36 ..
-rw-r--r-- 1 frank frank  2505984 Jun  9 23:35 kernel.raw
-rw-r--r-- 1 frank frank 16082498 Jun  9 23:36 kernelsquashfs.raw
drwxr-xr-x 3 frank frank     4096 Jun  9 23:35 var.tar

unpacked_firmware/original/kernel/:
insgesamt 18176
drwxr-xr-x 3 frank frank     4096 Jun  9 23:34 .
drwxr-xr-x 5 frank frank     4096 Jun  9 23:34 ..
-rw-r--r-- 1 frank frank  2505984 Jun  9 23:34 kernel.raw
-rw-r--r-- 1 frank frank 16091024 Jun  9 23:34 kernelsquashfs.raw
drwxr-xr-x 3 frank frank     4096 Jun  9 23:34 var.tar
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/original/firmware/var/tmp/ unpacked_firmware/modified/firmware/var/tmp/  test_unpack_2/original/firmware/var/tmp/
test_unpack_2/original/firmware/var/tmp/:
insgesamt 18164
drwxr-x--- 2 frank frank     4096 Jun  9 23:36 .
drwxr-x--- 3 frank frank     4096 Jun  9 23:35 ..
-rw-r--r-- 1 frank frank        0 Jun  9 23:36 filesystem.image
-rw-r--r-- 1 frank frank 18588482 Jun  9 23:36 kernel.image

unpacked_firmware/modified/firmware/var/tmp/:
insgesamt 18164
drwxr-x--- 2 frank frank     4096 Jun  9 23:36 .
drwxr-x--- 3 frank frank     4096 Jun  9 23:35 ..
-rw-r--r-- 1 frank frank        0 Jun  9 23:36 filesystem.image
-rw-r--r-- 1 frank frank 18588490 Jun  9 23:36 kernel.image

unpacked_firmware/original/firmware/var/tmp/:
insgesamt 18172
drwxr-x--- 2 frank frank     4096 Feb 25 10:46 .
drwxr-x--- 3 frank frank     4096 Feb 25 10:46 ..
-rw-r----- 1 frank frank        0 Feb 25 10:46 filesystem.image
-rwxr-x--- 1 frank frank 18597008 Jun  9 23:34 kernel.image
frank@frank-ThinkPad-X121e:~/freetz-trunk$

Code:
frank@frank-ThinkPad-X121e:~/freetz-trunk$ mkdir FB7360v2_0650_untar
frank@frank-ThinkPad-X121e:~/freetz-trunk$ cd FB7360v2_0650_untar
frank@frank-ThinkPad-X121e:~/freetz-trunk/FB7360v2_0650_untar$ tar tvpf ../FRITZ.Box_Fon_WLAN_7360.124.06.50.image
drwxr-x--- 0/0               0 2016-02-25 10:46 ./var/
-r--r----- 0/0           35208 2015-09-15 16:01 ./var/flash_update_2.6.28.ko
-r-xr-x--- 0/0          283844 2015-10-20 16:19 ./var/regelex
-rwxr-x--- 0/0           39356 2016-02-25 10:46 ./var/install
-r--r----- 0/0           55992 2016-01-26 15:10 ./var/flash_update_3.10.ko
-rwxr-x--- 0/0            2795 2016-02-25 10:46 ./var/info.txt
drwxr-x--- 0/0               0 2016-02-25 10:46 ./var/tmp/
-rw-r----- 0/0               0 2016-02-25 10:46 ./var/tmp/filesystem.image
-rwxr-x--- 0/0        18597016 2016-02-25 10:46 ./var/tmp/kernel.image
-r-xr-x--- 0/0          278552 2015-10-20 16:19 ./var/chksum
-rw-r----- 0/0             128 2016-02-25 10:46 ./var/signature
frank@frank-ThinkPad-X121e:~/freetz-trunk/FB7360v2_0650_untar$ tar xvpf ../FRITZ.Box_Fon_WLAN_7360.124.06.50.image
./var/
./var/flash_update_2.6.28.ko
./var/regelex
./var/install
./var/flash_update_3.10.ko
./var/info.txt
./var/tmp/
./var/tmp/filesystem.image
./var/tmp/kernel.image
./var/chksum
./var/signature
frank@frank-ThinkPad-X121e:~/freetz-trunk/FB7360v2_0650_untar$ hexdump -C ./var/tmp/kernel.image | grep -B 10 -A 20 sqsh
00263b90  53 a2 34 f5 e3 af c2 ab  37 f2 ee af 65 43 10 89  |S.4.....7...eC..|
00263ba0  56 0c 51 30 5e 8f 34 1e  89 2b f0 e9 1a 5f 30 d1  |V.Q0^.4..+..._0.|
00263bb0  26 7d 0c d4 a8 3e c6 ad  c0 4d 11 7e c1 15 15 48  |&}...>...M.~...H|
00263bc0  45 82 4d a1 e7 24 0a 82  1c 29 92 17 a5 4b 8c 12  |E.M..$...)...K..|
00263bd0  62 ee 46 94 3f a3 a2 6e  d7 16 fa 15 22 a5 f3 d9  |b.F.?..n...."...|
00263be0  2a 2b 5d 0f 70 dc ab 34  8a 86 e6 aa e1 69 35 d0  |*+].p..4.....i5.|
00263bf0  1b da 35 ce 98 57 89 bb  6c 7e 6f e1 c1 52 53 ce  |..5..W..l~o..RS.|
00263c00  6c 00 00 00 00 30 78 00  80 ff ff ff ff ff ff ff  |l....0x.........|
00263c10  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00263d00  73 71 73 68 00 00 0a 63  00 f5 87 90 00 01 00 00  |sqsh...c........|
00263d10  00 00 01 08 00 04 00 10  02 c0 00 01 00 04 00 00  |................|
00263d20  00 00 00 00 58 5a 06 f2  00 00 00 00 00 f5 87 90  |....XZ..........|
00263d30  00 00 00 00 00 f5 87 88  ff ff ff ff ff ff ff ff  |................|
00263d40  00 00 00 00 00 f4 a6 de  00 00 00 00 00 f5 01 9a  |................|
00263d50  00 00 00 00 00 f5 72 c8  00 00 00 00 00 f5 87 6a  |......r........j|
00263d60  fd 37 7a 58 5a 00 00 01  69 22 de 36 03 c0 91 a3  |.7zXZ...i".6....|
00263d70  01 80 80 04 21 01 08 00  01 15 bb 20 e0 ff ff 51  |....!...... ...Q|
00263d80  89 5d 00 3f 91 45 84 68  34 8a 09 0a 40 62 ae 9e  |.].?.E.h4...@b..|
00263d90  29 20 b2 fa 62 08 8c ff  f9 ac 4c 26 17 2e be e9  |) ..b.....L&....|
00263da0  d0 13 6e 83 63 f4 1d 20  35 28 19 1a bd 23 f9 6e  |..n.c.. 5(...#.n|
00263db0  db c2 8a 00 f3 19 d9 05  24 c5 22 37 09 a0 6b 96  |........$."7..k.|
00263dc0  2a f2 46 55 4a fc 0c 67  73 a6 fc 88 6e b1 d7 8a  |*.FUJ..gs...n...|
00263dd0  1f b2 de 81 ed 4e bf a2  96 da 51 b5 33 75 f2 b2  |.....N....Q.3u..|
00263de0  92 e3 ee 99 0d e0 02 2b  7d 83 de 81 c3 71 c5 35  |.......+}....q.5|
00263df0  31 be 66 91 c6 3d 53 76  d5 c0 e6 9e f4 c9 14 fd  |1.f..=Sv........|
00263e00  a5 82 c4 70 9e 56 32 04  f0 fc 5e c8 0c b4 23 85  |...p.V2...^...#.|
00263e10  2a c4 45 73 e7 9e d8 5b  09 f9 9d 06 6c ed eb 2f  |*.Es...[....l../|
00263e20  c2 c3 6a f2 1b 1c 13 ec  8b 76 19 a7 ed 7f 14 cf  |..j......v......|
00263e30  d7 ea 64 e0 59 6e 4c b2  5c 2d b3 77 6e 7e 08 5a  |..d.YnL.\-.wn~.Z|
00263e40  9c ad e1 72 38 3b d3 10  b2 21 2c 24 a0 61 ae ae  |...r8;...!,$.a..|
frank@frank-ThinkPad-X121e:~/freetz-trunk/FB7360v2_0650_untar$ hexdump -C ./var/tmp/kernel.image | grep -B 10 -A 20 "23 de 53 c4"
011bc3f0  7d 78 41 7b 2a a4 26 55  da d2 b4 ba e1 7e cb 74  |}xA{*.&U.....~.t|
011bc400  41 f4 17 4a 51 2b 34 09  e6 7c 58 cb 1a 8a 56 99  |A..JQ+4..|X...V.|
011bc410  2a fe 78 87 8a 43 ab e9  29 a4 62 39 c9 be 0c 07  |*.x..C..).b9....|
011bc420  aa 1d f1 9d 3d e6 94 d0  b1 ba 23 1e 90 24 84 f8  |....=.....#..$..|
011bc430  fd fd c5 93 ac 6e e3 78  54 5e 7a 17 61 16 3a 15  |.....n.xT^z.a.:.|
011bc440  20 48 5f 65 d6 be 96 f2  ae 69 7c 00 00 00 02 83  | H_e.....i|.....|
011bc450  28 62 00 01 aa 09 98 26  00 00 3d 77 f6 32 3e 30  |(b.....&..=w.2>0|
011bc460  0d 8b 02 00 00 00 00 01  59 5a 00 00 00 00 00 f5  |........YZ......|
011bc470  72 d0 00 00 00 00 00 f5  7b 4a 00 00 00 00 00 f5  |r.......{J......|
011bc480  82 98 04 80 00 00 00 00  00 00 00 00 00 f5 87 82  |................|
011bc490  23 de 53 c4 d5 2d 0d f6                           |#.S..-..|
011bc498
frank@frank-ThinkPad-X121e:~/freetz-trunk/FB7360v2_0650_untar$

Code:
frank@frank-ThinkPad-X121e:~$ cd freetz-trunk
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la unpacked_firmware/7360_v2*.image
-rw-r--r-- 1 frank frank 19293696 Jun  9 23:36 unpacked_firmware/7360_v2_-.de_20160609-233539.image
frank@frank-ThinkPad-X121e:~/freetz-trunk$ cd Freetz_FB7360v2_0650_untar
bash: cd: Freetz_FB7360v2_0650_untar: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ mkdir Freetz_FB7360v2_0650_untar
frank@frank-ThinkPad-X121e:~/freetz-trunk$ cd Freetz_FB7360v2_0650_untar
frank@frank-ThinkPad-X121e:~/freetz-trunk/Freetz_FB7360v2_0650_untar$ tar tvpf ../unpacked_firmware/7360_v2*.image
drwxr-xr-x root/root         0 2016-06-09 23:35 ./
drwxr-x--- root/root         0 2016-06-09 23:35 ./var/
-rwxr-x--- root/root      2795 2016-06-09 23:35 ./var/info.txt
-rw-r----- root/root       128 2016-06-09 23:35 ./var/signature
-r-xr-x--- root/root    283844 2016-06-09 23:35 ./var/regelex
-rwxr-x--- root/root     39356 2016-06-09 23:35 ./var/install
-r--r----- root/root     55992 2016-06-09 23:35 ./var/flash_update_3.10.ko
-r-xr-x--- root/root    278552 2016-06-09 23:35 ./var/chksum
-r--r----- root/root     35208 2016-06-09 23:35 ./var/flash_update_2.6.28.ko
drwxr-x--- root/root         0 2016-06-09 23:36 ./var/tmp/
-rw-r--r-- root/root  18588490 2016-06-09 23:36 ./var/tmp/kernel.image
-rw-r--r-- root/root         0 2016-06-09 23:36 ./var/tmp/filesystem.image
frank@frank-ThinkPad-X121e:~/freetz-trunk/Freetz_FB7360v2_0650_untar$ tar xvpf ../unpacked_firmware/7360_v2*.image
./
./var/
./var/info.txt
./var/signature
./var/regelex
./var/install
./var/flash_update_3.10.ko
./var/chksum
./var/flash_update_2.6.28.ko
./var/tmp/
./var/tmp/kernel.image
./var/tmp/filesystem.image
frank@frank-ThinkPad-X121e:~/freetz-trunk/Freetz_FB7360v2_0650_untar$ hexdump -C ./var/tmp/kernel.image | grep -B 10 -A 20 sqsh
00263b90  53 a2 34 f5 e3 af c2 ab  37 f2 ee af 65 43 10 89  |S.4.....7...eC..|
00263ba0  56 0c 51 30 5e 8f 34 1e  89 2b f0 e9 1a 5f 30 d1  |V.Q0^.4..+..._0.|
00263bb0  26 7d 0c d4 a8 3e c6 ad  c0 4d 11 7e c1 15 15 48  |&}...>...M.~...H|
00263bc0  45 82 4d a1 e7 24 0a 82  1c 29 92 17 a5 4b 8c 12  |E.M..$...)...K..|
00263bd0  62 ee 46 94 3f a3 a2 6e  d7 16 fa 15 22 a5 f3 d9  |b.F.?..n...."...|
00263be0  2a 2b 5d 0f 70 dc ab 34  8a 86 e6 aa e1 69 35 d0  |*+].p..4.....i5.|
00263bf0  1b da 35 ce 98 57 89 bb  6c 7e 6f e1 c1 52 53 ce  |..5..W..l~o..RS.|
00263c00  6c 00 00 00 00 30 78 00  80 ff ff ff ff ff ff ff  |l....0x.........|
00263c10  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00263d00  73 71 73 68 00 00 0a 64  00 00 00 00 00 01 00 00  |sqsh...d........|
00263d10  00 00 01 08 00 04 00 10  03 40 00 01 00 04 00 00  |.........@......|
00263d20  00 00 00 00 51 36 07 1b  00 00 00 00 00 f5 66 42  |....Q6........fB|
00263d30  00 00 00 00 00 f5 66 3a  ff ff ff ff ff ff ff ff  |......f:........|
00263d40  00 00 00 00 00 f4 a6 f6  00 00 00 00 00 f4 fa 72  |...............r|
00263d50  00 00 00 00 00 f5 66 2c  ff ff ff ff ff ff ff ff  |......f,........|
00263d60  fd 37 7a 58 5a 00 00 01  69 22 de 36 03 c0 91 a3  |.7zXZ...i".6....|
00263d70  01 80 80 04 21 01 08 00  01 15 bb 20 e0 ff ff 51  |....!...... ...Q|
00263d80  89 5d 00 3f 91 45 84 68  34 8a 09 0a 40 62 ae 9e  |.].?.E.h4...@b..|
00263d90  29 20 b2 fa 62 08 8c ff  f9 ac 4c 26 17 2e be e9  |) ..b.....L&....|
00263da0  d0 13 6e 83 63 f4 1d 20  35 28 19 1a bd 23 f9 6e  |..n.c.. 5(...#.n|
00263db0  db c2 8a 00 f3 19 d9 05  24 c5 22 37 09 a0 6b 96  |........$."7..k.|
00263dc0  2a f2 46 55 4a fc 0c 67  73 a6 fc 88 6e b1 d7 8a  |*.FUJ..gs...n...|
00263dd0  1f b2 de 81 ed 4e bf a2  96 da 51 b5 33 75 f2 b2  |.....N....Q.3u..|
00263de0  92 e3 ee 99 0d e0 02 2b  7d 83 de 81 c3 71 c5 35  |.......+}....q.5|
00263df0  31 be 66 91 c6 3d 53 76  d5 c0 e6 9e f4 c9 14 fd  |1.f..=Sv........|
00263e00  a5 82 c4 70 9e 56 32 04  f0 fc 5e c8 0c b4 23 85  |...p.V2...^...#.|
00263e10  2a c4 45 73 e7 9e d8 5b  09 f9 9d 06 6c ed eb 2f  |*.Es...[....l../|
00263e20  c2 c3 6a f2 1b 1c 13 ec  8b 76 19 a7 ed 7f 14 cf  |..j......v......|
00263e30  d7 ea 64 e0 59 6e 4c b2  5c 2d b3 77 6e 7e 08 5a  |..d.YnL.\-.wn~.Z|
00263e40  9c ad e1 72 38 3b d3 10  b2 21 2c 24 a0 61 ae ae  |...r8;...!,$.a..|
frank@frank-ThinkPad-X121e:~/freetz-trunk/Freetz_FB7360v2_0650_untar$ hexdump -C ./var/tmp/kernel.image | grep -B 10 -A 20 "23 de 53 c4"
011ba2a0  7e 9d 77 0c d8 dd 58 81  f7 a8 ad 49 b7 f4 3c 06  |~.w...X....I..<.|
011ba2b0  95 5a 31 20 25 2d 80 93  13 22 a2 a0 64 20 2a 7e  |.Z1 %-..."..d *~|
011ba2c0  f4 b3 5d d2 42 b4 40 b7  db 02 2d a3 bd a1 2e 7e  |..][email protected]....~|
011ba2d0  dd 57 53 0c bf 37 09 4c  31 fa 7d cd 2c 2a 04 24  |.WS..7.L1.}.,*.$|
011ba2e0  f7 a5 cd 39 e1 2f 92 81  00 03 56 6f 36 1a 3f 19  |...9./....Vo6.?.|
011ba2f0  96 6d a6 27 c5 75 73 19  64 a4 d0 c4 6f b5 d1 35  |.m.'.us.d...o..5|
011ba300  c6 6e 47 18 0a 0b 00 f8  11 cf bd 6c db ec 00 00  |.nG........l....|
011ba310  a3 b3 5f ef 00 01 c8 0a  80 21 00 00 49 ca 88 a0  |.._......!..I...|
011ba320  3e 30 0d 8b 02 00 00 00  00 01 59 5a 00 00 00 00  |>0........YZ....|
011ba330  00 f5 60 be 04 80 00 00  00 00 00 00 00 00 00 f5  |..`.............|
011ba340  66 34 23 de 53 c4 4b 3f  08 d1                    |f4#.S.K?..|
011ba34a
frank@frank-ThinkPad-X121e:~/freetz-trunk/Freetz_FB7360v2_0650_untar$

Weg 3 muss ich morgen machen, schaffe ich heute nicht mehr.
elsterkrug
 
@Peter: bin etwas irritiert über den Teil:
Code:
     set_progressbar_state(FALSE);
+    sBlk.mkfs_time = (unsigned int) sBlk.bytes_used;
     write_filesystem_tables(&sBlk, nopad)
sBlk.bytes_used wird doch erst in write_filesystem_tables(..) gesetzt, confused...:confused:

Edit: und (vermutlich weniger von Bedeutung) warum "(unsigned int)", wenn mkfs_time ein "int" ist und bytes_used bzw. bytes ein "long long"?
 
Zuletzt bearbeitet:
Hallo Riverhopper, hallo Peter Pawn, hallo er13,
es läuft. Konnte es doch nicht lassen und habe den Post noch abgearbeitet. 6.50 ist drauf und Telnet ist aktiv und der LCR läuft schon. Ob er einen Neustart übersteht oder ich da noch was machen muss (und euch evtl. fragen) sehe ich morgen.
Vielen, vielen vielen vielen Dank für eure Hilfe. Ohne euch hätte ich das nie hinbekommen. Ich weiß, ich bin hier nur der "Befehlsempfänger" gewesen und konnte nichts beitragen. Vielen Dank für eure Geduld und euer großes Wissen. Toll, dass es so ein Forum gibt und Leute wie euch, die Laien wie mir hier helfen.
Also nochmals vielen Dank und gute Nacht.
 
@elsterkrug: Wenn ich mich in Bezug auf mkfs_time in #143 nicht getäuscht habe, dann lag es ausschließlich an "-nopad".

@all: Habe dennoch beide Änderungen in Freetz aufgenommen: r13749 und r13750.

Danke an PeterPawn für Vorlagen!
 
@er13:
Ich denke mal, ein "long long" ist für die Dateisystemgröße (die je eigentlich immer > 0 sein sollte oder wir haben am Ende (auch wenn das in der Algebra wieder etwas anderes wäre und Descartes im Grabe rotiert) "imaginäre Daten") ohnehin eine schlechte Wahl und die Definition des Superblocks für ein SquashFS3-Image in squashfs-compat.h gibt an dieser Stelle auch noch ein "unsigned int bytes_used_2;" vor ... ausgehend davon, daß die Verwendung des Timestamp-Feldes ein Relikt aus der SquashFS3-Zeit ist, erschien mir diese Wahl wohl logischer, auch wenn ich gar nicht lange darüber nachgedacht habe.

Zwar erfolgt da jetzt keine weitere Arithmetik mit diesen Zahlen und damit stellt sich die Frage nach entsprechenden Auswirkungen nicht, aber ich hätte hier auch im Kernel einen "unsigned long long int" (oder auch "unsigned long long") nach C99 verwendet, denn negative Dateisystemgrößen sollten nicht auftreten und auch wenn sicherlich 64 Bit noch genug Raum lassen, bevor da das "sign bit" benötigt wird, ist es eine Frage des Prinzips. Außerdem war das nur ein "dirty hack" - unabsichtlich habe ich mir ja die Chance für eine Korrektur erhalten, denn ...

Du hast natürlich vollkommen recht, was das Kopieren aus dem statischen "bytes" in den Superblock in write_filesystem_tables() angeht (das ist wirklich blamabel, was ich da gemacht habe) - so kann das nicht funktionieren und das tut es ja dem Hexdump oben nach auch nicht ... also noch einmal anders (nicht unbedingt besser):
Code:
commit 652216ca351a3764d2fe8049b5550e739222ec69
Author: PeterPawn <[email protected]>
Date:   Fri Jun 10 01:58:17 2016 +0200

    2nd try to fix the flash_update.ko problem for 7360v2/06.50

diff --git a/fwmod b/fwmod
index 2d88d43..13c97ed 100755
--- a/fwmod
+++ b/fwmod
@@ -239,6 +239,8 @@ if [ "${FREETZ_SQUASHFS_VERSION}" -lt 4 ]; then
        else
                MKSQUASHFS_OPTIONS+=" -le"
        fi
+else
+       [ "${FREETZ_AVM_HAS_UPDATE_FILESYSTEM_IMAGE}" == "y" ] || MKSQUASHFS_OPTIONS+=" -nopad"
 fi
 if [ "${FREETZ_SQUASHFS_VERSION}" -eq 3 -a "${FREETZ_AVM_SQUASHFS_COMPRESSION}" == "lzma" ]; then
        MKSQUASHFS_OPTIONS+=" -lzma1"
diff --git a/tools/make/squashfs4-host/patches/999-try_to_fix_bytes_used_2.patch b/tools/make/squashfs4-host/patches/999-try_to_fix_bytes_used_2.patch
new file mode 100644
index 0000000..93840b8
--- /dev/null
+++ b/tools/make/squashfs4-host/patches/999-try_to_fix_bytes_used_2.patch
@@ -0,0 +1,21 @@
+--- squashfs-tools/mksquashfs.c.org    2016-06-10 01:29:26.504343342 +0200
++++ squashfs-tools/mksquashfs.c        2016-06-10 01:40:38.036314879 +0200
+@@ -4461,6 +4461,18 @@
+                       sBlk->lookup_table_start);
+
+       sBlk->bytes_used = bytes;
++
++#ifndef NO_DUP_SIZE_IN_SUPERBLOCK
++      // make the uint value at superblock offset 8 (it was the field 'bytes_used_2' up
++      // to version 3 of SquashFS) contain the 32 bit value of images size again, it's
++      // only a try to fix an uncommon flash problem on 7360 with FRITZ!OS 06.50
++      //
++      // casting the original (signed) 64 bit value to a 32 bit value should
++      // truncate the high order part and a even if the target in a SQFS4 SB
++      // is an 'int', we do not use the value in any further calculations
++      //
++      sBlk->mkfs_time = (unsigned int) bytes;
++#endif
+
+       sBlk->compression = comp->id;
+
Damit wird jetzt tatsächlich der Wert mit der Größe des Images zweimal geschrieben:
Code:
00000000  73 71 73 68 00 00 0e 18  [COLOR="#FF0000"]01 a2 a2 8b[/COLOR] 00 01 00 00  |sqsh............|
00000010  00 00 01 24 00 04 00 10  03 40 00 01 00 04 00 00  |...$.....@......|
00000020  00 00 00 00 73 d2 0c 0b  [COLOR="#FF0000"]00 00 00 00 01 a2 a2 8b[/COLOR]  |....s...........|
00000030  00 00 00 00 01 a2 a2 83  ff ff ff ff ff ff ff ff  |................|
00000040  00 00 00 00 01 a1 9b ff  00 00 00 00 01 a2 14 3b  |...............;|
00000050  00 00 00 00 01 a2 a2 75  ff ff ff ff ff ff ff ff  |.......u........|
00000060  fd 37 7a 58 5a 00 00 01  69 22 de 36 03 c0 d8 a3  |.7zXZ...i".6....|
und an der Verwendung der "nopad"-Option kann eigentlich auch nicht so viel daneben gehen. Wobei ich keine Lust habe, mir einen Trunk für die 7360 zuzulegen und daher die Änderung in "fwmod" meinerseits ungetestet bleibt.

Ob die bedingte Übersetzung da überhaupt sinnvoll ist oder nicht und wie die Einstellung sonst noch heißen könnte, ist mir Bummi ... da bin ich leidenschaftslos, denn es soll eigentlich nur der PoC sein, ob die Vermutung stimmen könnte.

Also ... hier war es mein Fehler, der Patch für "mksquashfs.c" war einfach dämlich, der neue im Anhang macht es (getestet) besser.

Den jetzt dann mit "patch -p1 <dateiname" auf das (originale) Trunk-Verzeichnis angewendet (also noch ein "svn checkout fwmod" vorher und den alten Patch ebenfalls vorher mit "rm tools/make/squashfs4-host/patches/999*" wieder entfernen), dann ein "make squashfs4-host-dirclean", gefolgt von "make tools" und dann kann direkt erneut das "fwmod -p" ausgeführt werden, der Rest ist eher brotlose Kunst bei dieser ganzen Geschichte. Auf die "kernel.image" aus dem resultierenden TAR-Image (die muß man auch nicht noch einmal auspacken, die steht noch im Verzeichnis, aus dem das Packen erfolgte) dann noch einmal die Kommandos zum Hexdump angewendet (die für das AVM-Image braucht es jetzt nun wirklich nicht mehr, die gibt es schon viele Male in diesem Thread und das sollte sich auch kaum noch ändern) und dann einfach ganz normal mit dem GUI von einer 06.30 aus das neue Image hochladen ... erst dann, wenn das auch nicht geht (die Box wird ja dabei nicht verändert, wenn ich es richtig verstehe, damit ist der gesamte Aufwand nur der zusätzliche Neustart), dann macht es wieder Sinn, die Änderungen noch einmal im Einzelnen zu prüfen.

Diese ganzen Überprüfungen in Einzelschritten sind ja sehr nützlich, wenn man etwas Bestimmtes sucht ... hier fördern sie nur ein "mechanisches Vorgehen" (ich habe gar keine Ahnung, was der vertagte "Weg3" am Ende sein mag).

Ich bin auch nicht gegen systematische Überprüfungen ... ganz im Gegenteil, aber dann automatisiert man solche formalen Abläufe (meinetwegen in Form eines fortgeschriebenen Shell-Skripts) und führt die nicht immer wieder aufs Neue von Hand aus - spätestens bei der dritten Wiederholung hätte ich persönlich die Nase voll und ob man nun diese Kommandolisten per C&P von hier kopiert oder einfach ein aktuelles Shell-Skript von hier lädt und ausführt, macht dann auch wieder einen Unterschied im Aufwand beim Testen.

- - - Aktualisiert - - -

EDIT:
Ich war kurz weg und habe die zusätzlichen Beiträge erst nachträglich gesehen.

@er13:
Du kannst ja mal darüber nachdenken, ob man sich nun an das AVM-Format an Offset 8 anlehnt (auch die filesystem_core.squashfs-Dateien der NAND-Modelle haben da noch einmal die Länge) oder lieber am offiziellen Superblock festhält (auch wenn der Code zum Lesen ja ohnehin eine Modifikation des offiziellen Standes ist).

Was ich noch nicht so richtig verstehe ... woher weiß der flash_update.ko denn nun, bis wohin das Image gehen muß? Ich würde hier dann doch eher auf eine Plausibilitätsprüfung der Art "start + bytes_used_2 <= filesize" tippen, die natürlich ein Timestamp-Wert heutzutage nicht mehr bestehen kann. Aber auch das würde dann wieder eine Kenntnis des Aufbaus des Images in flash_update.ko erfordern ... daß der bei Angabe von "crc=1" noch einmal die TI-Prüfsumme checkt, glaube ich sofort, aber da würde ich auch eher etwas in der Art von "seek(fd, 8, SEEK_END" vor dem Lesen der Prüfsumme erwarten als die Suche (und Plausibilitätsprüfungen) vom Beginn des Images an und irgendwie müßte der ja dann den Superblock doch gefunden haben (selbst wenn er da von 0x2c bzw. 0x28 die Länge lesen sollte).

Na ja, Hauptsache es ist nun klar (so 100% ist das ja auch nicht, was es nun ist und was man künftig dann beachten muß oder irre ich mich?), wo das Problem liegt/lag ... dann kann hier ja ein großer Haken ran.

BTW/OT: Hast Du Lust, Dir meinen Freetz-Fork mal beim OpenSSL-Paket anzusehen? Ich habe/brauche ein statisch gelinktes openssl-Binary in Version 1.0.2 in modfs (LTS, die 1.0.1 ist in 6 Monaten auch tot) und würde da gerne (wenn der Freetz-Trunk es hergibt) auf den "Sonderweg" verzichten wollen ... vor allem bringt es ja nichts, wenn ich die Fähigkeit zur Erstellung des statischen Binaries (sind knapp 2 MB) bei mir wieder so implementiere, daß es in Freetz dann wieder ganz anders aussieht (und die make-Macros da sind Dein Reich). Diese letzte Änderung (also nur "-static" für das Linken in "apps", der Rest kann/soll ruhig bei "shared" und "PIC" bleiben, die Libs brauchen ja auch noch diverse andere Pakete) habe ich auch noch nicht eingecheckt - nur das Entfernen von "ccgost" (ist aus dem Master inzwischen auch raus, siehe mein letzter Commit dazu mit dem Link in die Mailing-Liste) habe ich noch gepusht.

Ich wäre (naheliegenderweise) auch dafür, daß von SVN auf git (bzw. sogar GitHub) umgestellt wird, dann wird das Unterbreiten von solchen Vorschlägen (inkl. Annehmen oder Ablehnen) wieder leichter - auch wenn es manchmal in den Fingern juckt, werde ich keinen Trac-Account mehr einrichten für mich.
Schon die Möglichkeit der Diskussion bis zu einzelnen Zeilen bei einem Commit gefällt mir eben bei GitHub wesentlich besser und es ist auch für Dritte besser/leichter nachzuvollziehen, was da abgelaufen ist - ja sogar das "Zusammensuchen" des eigenen Trunks ggf. aus mehreren Repos mit unterschiedlichen Ständen/Änderungen wäre für die Benutzung bei vielen sicherlich von Vorteil. Die Diskussion dazu ist aber wohl wieder eingeschlafen ... angesichts der (doch tiefgreifenden) Änderungen bei den neueren Versionen sehe ich ein wenig die Gefahr, daß es mit Freetz nicht mehr so richtig weitergeht. Alleine die Arbeit an den ganzen Patches, die etwas am (alten) GUI geändert haben, ist so ein Berg an Aufgaben, daß den ein Einzelner einfach nicht stemmen kann.
 
Hallo Riverhopper, hallo Peter Pawn, hallo er13,
es läuft. Konnte es doch nicht lassen und habe den Post noch abgearbeitet. 6.50 ist drauf und Telnet ist aktiv und der LCR läuft schon.

Halleluja!!!
das Abenteur "Weltraum-Expedition" (aka telnetd und debug.cfg per Freetz für FB7360 FW 6.50 zurückholen) konnte im Teamwork auch von Mitstreitern ohne "rocket science" Kenntnisse erlangt werden;-)

tolle Leistung und Dank an alle Mitwirkende!!!

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