Freetz-NG Firmware Flashvorgang schlägt fehl

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
So, schon habe ich das nächste Problem. Ich habe die 7.20+ Firmware für meine Fritzbox 7490 erfolgreich kompiliert. Nun habe ich versucht, die Firmware auf meine Fritzbox mit laufendem Freetz 113.07.12 rev69996 zu flashen, erhalte jedoch die untenstehende Fehlermeldung.

Code:
install: have Kernel 3.10.107 - set kversion '3.10' and FlashUpdateTool '/lib/modules/3.10.107/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=
ANNEX=A
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.07.12  new: xx.07.21
debug: curr: 113.07.12
debug: new: "XX.07.21"
major_currFWver=113
middle_currFWver=7
minor_currFWver=12
middle_newFWver=7
minor_newFWver=21
check Firmware Version: xx.07.21
DEBUG: 7 >= 7
DEBUG: 21 >= 12
Accept Firmware Version: xx.07.21
install: 3.10 check files...
read 0xfe9b3766 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xfe9b3766
Calculated checksum is FE9B3766
Saved checksum is FE9B3766
Checksum validation successful!
chksum for file /var/tmp/filesystem.image ok
size for file /var/tmp/filesystem.image ok
read 0xed8079d0 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xed8079d0
Calculated checksum is ED8079D0
Saved checksum is ED8079D0
Checksum validation successful!
chksum for file /var/tmp/kernel.image ok
size for file /var/tmp/kernel.image ok
install: 3.10 getting mtds to install...
install: --mtd------------------------------------------------
install: --assert---------------------------------------------
install: --addr+size------------------------------------------
install: kernel_start=0x00000000
install: kernel_size=4194304
install: kernel_image_size=2688008
install: filesystem_start=0x00400000
install: filesystem_size=50331648
install: filesystem_image_size=48406536
install: 3.10 writing commands to install...
update action flash at '/var/updatestore/update_action_flash'
Erase mtd partitions 0 and 1 ...
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x3000000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
Copy kernel image...
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] append 64504 Bytes
[main] written 0x20000 Bytes
[main] eof reached
[main] exit error 0
Clean up kernel image
Copy filesystem image ...
Copy filesystem ...
cp: write error: No space left on device
cp: write error: No space left on device
cp: write error: No space left on device
failed with error 0
... Copy filesystem done
give update_state=bad to /var/post_install
update abort - Flashcmd (silent) failed

Da steht was von "no space left on device", jedoch verstehe ich nicht wieso. Nachfolgend der Output nach dem erfolgreichen Erstellen des Images.

Code:
STEP 3: PACK/SIGN
  checking for left over version-control-system files
  integrate freetz info file into image
packing var.tar
  checking signature key files
    creating private signature key file
    creating public signature key file
    adding public signature key file
creating inner-filesystem image (SquashFS4-xz)
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 2.6 MB, max 4.0 MB, free 1.4 MB (1506304 bytes)
creating outer-filesystem image (SquashFS4-xz)
copying filesystem image
  filesystem image size: 46.2 MB, max 48.0 MB, free 1.8 MB (1925120 bytes)
adding checksum to kernel.image
adding checksum to filesystem.image
packing images/7490_07.21.all_freetz-ng-18157-b7e2f21_20210322-152421.image
  packed image file size: 49.4 MB (51845120 bytes)
signing packed .image file
  signed image file size: 49.4 MB (51845120 bytes)
source firmware: 7490_de-es-fr-it-pl 113.07.21 rev81779 {ALL} [PSQ19] (04.09.2020 08:53:45)
  source image file size: 32.9 MB (34488320 bytes)
done.

Da steht doch, dass ich 1.8 MB unter dem Limit bin. Und dann habe ich mir das Image angesehen, das derzeit auf der FB läuft. Das ist mit 50.2 MB deutlich grösser als das neue mit 49.4. Wieso also kann ich das Image nicht flashen?
 

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
489
Punkte für Reaktionen
99
Punkte
28
Bau doch erst einmal nur ein minimal-Image und versuche dieses zu flaschen.
 

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Das ist ja schon eine stark abgespeckte Variante gegenüber dem letzten Image, das derzeit auf der Box läuft. Ich habe diverse Funktionen/ Pakete entfernt, beispielsweise opendd, transmission, nzbget, ffmpeg... Ich habe nun zum Vergleich extra noch einmal die alte Version kompiliert. Nachfolgend der Output:

Code:
STEP 3: PACK
  checking for left over version-control-system files
  integrate freetz info file into image
packing var.tar
creating inner-filesystem image (SquashFS4-xz)
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 2.5 MB, max 4.0 MB, free 1.5 MB (1545216 bytes)
creating outer-filesystem image (Ext2FS)
copying filesystem image
  filesystem image size: 47.2 MB, max 48.0 MB, free 0.8 MB (795392 bytes)
adding checksum to kernel.image
adding checksum to filesystem.image
packing images/7490_07.12-freetz-master-20210307-8206a2c.de_20210322-223312.image
  unsigned image file size: 50.4 MB (52889600 bytes)
using unsigned image as the final one
done.

FINISHED

Wie gesagt, dieses Image ist deutlich grösser als das neue, lässt sich jedoch problemlos flashen. Beim neuen hingegen erhalte ich die Meldung, es sei kein Platz mehr vorhanden. Irgendwas ist hier faul.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,766
Punkte für Reaktionen
1,261
Punkte
113
dieses Image ist deutlich grösser als das neue, lässt sich jedoch problemlos flashen
Das KANN ja trotzdem gut sein. Denn daß dieses neue Image gar nicht an dieselben Stellen im Flash geschrieben werden KANN, wie das für das gerade laufende System, ergibt sich ja schon daraus, daß die Box weiterhin funktioniert.

Es gibt nun mal zwei "Sätze" von Partitionen (jeweils ein Kernel und ein Dateisystem), zwischen denen umgeschaltet werden kann und die Installation eines Updates (mit dem AVM-Skript, aus dem die Protokoll-Zeilen auch stammen) erfolgt immer in das gerade nicht genutzte "Set".

Die Größenangabe, auf die Freetz(-NG) beim Erstellen eines Images zurückgreifen kann, ist aber nur die "nominelle" ... diese ist auch nur dann tatsächlich verfügbar, wenn der NAND-Flash an dieser Stelle keine defekten Blöcke enthält. Ansonsten kann/wird sich die Kapazität der dort verwendeten YAFFS2-Partition entsprechend verringern (wenn ich die Fehlerbehandlung richtig im Kopf habe) - und dann kann es eben auch vorkommen (zumindest wäre das eine denkbare Erklärung), daß der Platz zum Kopieren nun doch nicht mehr reicht.

Angesichts der Blocksize von 0x20000 (das sind 128 KB) reichen bereits 8 defekte Blöcke aus, um die Kapazität um 1 MB zu verringern ... bei 16 defekten Blöcken würde also auch der vermeintlich noch "freie" Platz in der Partition nicht mehr ausreichen, um das neue Image speichern zu können.

Ob es solche defekten Blöcke gibt und wenn ja, wieviele es dann sind, kann man entweder den Meldungen beim Start des Systems entnehmen (verschiedene Flash-Chips werden da auch unterschiedlich behandelt - manche speichern die Nummern der bereits als defekt aussortierten Blöcke (in einer Bad Block Table - BBT) und manche nicht, dann muß bei jedem Start der komplette Flash gescannt werden) oder mit entsprechenden Tools (üblicherweise aus dem mtd-utils-Paket) auslesen.

Glücklicherweise gibt es aber bei AVM im FRITZ!OS auch noch einen viel bequemeren Weg ... unter dem Pfad /proc/avm/nandstat kann man sich eine Statistik der Zugriffe auf den NAND-Speicher ansehen und unter /proc/avm/mtd_bbt sogar einen Counter der "bad blocks" pro MTD-(NAND-)Partition. Wobei ich hier jetzt aus dem Kopf nicht mehr weiß, ob darin bereits die zuvor als "bad" markierten Blöcke mitgezählt werden oder ob das nur neu aufgetretene Probleme abbildet.

Auf alle Fälle sollte man also zunächst mal abklären, ob nicht doch am Ende defekte Blöcke im NAND-Flash die Ursache dafür sind, daß hier beim Kopieren der Platz in der (neuen) YAFFS2-Partition nicht ausreicht. Die Annahme, daß das in jedem Falle passen MÜSSE, weil das größere Image zuvor sich ja ebenfalls installieren ließ, ist jedenfalls eine Milchmädchen-Rechnung - das würde nur dann als Schlußfolgerung zulässig sein, wenn die Installation tatsächlich auch in dieselben Flash-Partitionen erfolgte, wie beim "alten" Image und das ginge nur, wenn man einen zusätzlichen Zwischenschritt (mit einem "abgespeckten" Image im Set MTD0/MTD1, was da dann auch hineinpaßt) einlegte.
 

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Danke für deine Rückmeldung. Jedoch scheint mir auch das nicht die Erklärung zu sein, denn gemäss cat /proc/avm/mtd_bbt gibt es in mtd0 - mtd5 keine "bad blocks". Aber zumindest habe ich wieder einmal etwas gelernt.

Code:
[email protected]:/proc/avm# cat mtd_bbt
mtd0: 0 bad blocks
mtd1: 0 bad blocks
mtd2: 0 bad blocks
mtd3: 0 bad blocks
mtd4: 0 bad blocks
mtd5: 0 bad blocks
[email protected]:/proc/avm#

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Es gibt nun mal zwei "Sätze" von Partitionen (jeweils ein Kernel und ein Dateisystem), zwischen denen umgeschaltet werden kann und die Installation eines Updates (mit dem AVM-Skript, aus dem die Protokoll-Zeilen auch stammen) erfolgt immer in das gerade nicht genutzte "Set".
Nur um allfällige Missverständnisse auszuräumen, ich nutze zum Flashen selbstverständlich die Freetz Weboberfläche und deren Updatefunktion. Aber ich nehme an, dass die ebenfalls auf dem "AVM Script" basiert.
 
Zuletzt bearbeitet von einem Moderator:

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
489
Punkte für Reaktionen
99
Punkte
28
Poste mal bitte deine .config.
Dann baue ich das mal mit meiner VM und versuche meine 7490 damit zu bestücken.

Edit: Also an der Fw an sich liegt es nicht:

1616572342908.png
 
Zuletzt bearbeitet:

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Danke für deine Bemühungen. Im Anhang findest du die .config, welche ich für den Bau des Images benutzt habe:
 

Anhänge

  • config.txt
    93.6 KB · Aufrufe: 2
  • Like
Reaktionen: gismotro

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
489
Punkte für Reaktionen
99
Punkte
28
Code:
ERROR: Build failed.
make: *** [make/lynx/lynx.mk:46: source/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/lynx-2.8.9rel.1/lynx] Error 1
[email protected]:~/74$
So, downgrade ist drauf:
1616660606449.png

Jetzt kommt der Bau nach deiner .config:

Mit der .config läßt sich aktuell kein Image bauen:

1616682747741.png

Ich teste aber weiter.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: altae

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Ist der SSL Support für Lynx eventuell noch eingeschaltet? Damit hatte ich auch Probleme. Falls ja, deaktiviere den SSL Support oder lass Lynx ganz weg, dann sollte es durchlaufen.
 
  • Like
Reaktionen: gismotro

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
489
Punkte für Reaktionen
99
Punkte
28
Ist der SSL Support für Lynx eventuell noch eingeschaltet? ...
Ja, das war es. Mit der Änderung läßt sich das Image bauen.

Edit: Box läßt sich aber nicht flaschen.

1616701970651.png
Ich probiere Morgen weiter.

Edit 2: Hast Du es mal mit der aktuellen Labor versucht zu bauen und zu flashen ?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,766
Punkte für Reaktionen
1,261
Punkte
113
Mache mal bitte ein find build/modified/filesystem.outer/ -ls | wc -l im Verzeichnis mit dem Checkout (nach dem Build).

Sind das mehr als 100-120 Dateien, habe ich eine Idee, woran es liegen KÖNNTE.

BTW ... in der AVM-Firmware sieht das so aus:

Rich (BBCode):
vidar:/home/GitHub/YourFritz/toolbox $ ./inspect_image /home/FritzBox/FB7490/firmware/FRITZ.Box_7490-07.21.image
inspect_image, version 0.8

Copyright (C) 2018-2020 P.Hämmerlein ([email protected])

This script is a part of the YourFritz project from https://github.com/PeterPawn/YourFritz.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details.

--------------------------------------------------------------------------------------------------

Device uses NAND flash for kernel and a wrapper partition for filesystem image.
The wrapper partition uses YAFFS2 format on the device and SquashFS format for installation.
SquashFS version used: 4
SquashFS compression used: xz
SquashFS byte order used: big

>>>>> Output of 'extract_version_values' <<<<<
Model="Fritz_Box_HW185"
Product="FRITZ!Box 7490"
Date="04.09.2020 14:53:45"
Version="113.07.21"
Subversion="-81779"
Buildnumber="81779"
Buildtype="1"
Brandings="1und1 avm avme"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490"
KernelVersion="3.10.107"
LibraryProject="uClibc-ng"
LibraryVersion="1.0.31"
LibraryIdent="uClibc-ng-1.0.31"
BootType="systemd"
PublicKey1="00cbdcfcc6ac9a1657a1c6f197e3056f1d68b8bb7deb480249e5f0ded677c54fde10be5a14b1e6a395483bd4bee608c09d385b1e90564ca84b9272926c45bfd328d7da876567e3e15f719800a53ecc21af583431d0c40806ca89f6f958e188ec69572df09e24de71eaa0782c01877158f286afd95037e7eb059367c466095944e1"
PublicKey2="00c381540e8255baf78d29b7ac182e088cf8f2f4f418c186e927510cb469b5c16b6d161e6b0354c199d9721a5fda037047d4ec6f6e6bfc02ce5335023b24e757b7d8241e91f39fa43381b7b028ef65007e97593fe1b86d406767db7984fa7d780178ae2cfea9dc9ab7656692e643755397dd49ffdd2eb4abfc9cacc0bd6746fcdb"
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
>>>>> ================================== <<<<<

The unpacked filesystem structure may be found at:

/tmp/tmp.Q5Er87gTTO/5029_inspect_image/fs


The content of the extra YAFFS2 partition may be found at:

/tmp/tmp.Q5Er87gTTO/5029_inspect_image/wrapper
Please use another terminal session to inspect or backup data from the location above.

If you've done with it and want to continue, the whole working directory

/tmp/tmp.Q5Er87gTTO/5029_inspect_image

gets deleted - any possibly open file(s) within, will lead to an orphaned directory, which has to be removed manually.

Do you want to continue/exit? Enter 'x' / 'q' (eXit/Quit): ^Z
[1]+  Stopped                 ./inspect_image /home/FritzBox/FB7490/firmware/FRITZ.Box_7490-07.21.image
vidar:/home/GitHub/YourFritz/toolbox $ find /tmp/tmp.Q5Er87gTTO/5029_inspect_image/wrapper -ls | wc -l
104
vidar:/home/GitHub/YourFritz/toolbox $ fg
./inspect_image /home/FritzBox/FB7490/firmware/FRITZ.Box_7490-07.21.image
q

vidar:/home/GitHub/YourFritz/toolbox $
Bei AVM landen also in der YAFFS2-Parfition insgesamt nur 104 Dateien - ich bin gespannt, wieviele es bei Freetz/Freetz-NG sind.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: gismotro

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Hallo,

die Meldung "no space left on device" und dass sie von cp kommt machte mich auch erst mal stutzig.
Das Ziel muss also ein Dateisystem sein, und klar, es ist yaffs2 und man muss mit Dateisystemverlusten rechnen.

Die Berechnung in Freetz(ng) hinkt also, genau wie die von AVM im install Script, da sie diese Verluste vergisst.
Die lassen sich nicht so einfach vorhersagen.

Die wohl genaueste Methode wäre aus den yaffs2utils ein Testimage mit mkyaffs2 zu bauen um es zu messen.
Oder eeben mit solcher Fehlermeldung leben. Bad Blocks lassen sich zudem nicht vorhersagen...

Man könnte zumindest bei yaffs2 als Ziel mit einer Warnung aufklären in Freetz dass die "Luft" nach oben nicht stimmt.

EDIT:

Es ist ja das outer dateisystem das kopiert wirdm, mit immer gleicher Dateianzahl.
Da könnte man die Verluste also einmalig erfassen und einkalkulieren.
Aber 1.8MB scheint mir schon eine Menge Schankverlust zu sein..,
 
Zuletzt bearbeitet:

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Vor allem, wir reden hier von zwei verschiedenen Geräten, welche mit dem selben Image denselben Fehler zeigen. Da scheint es mir doch sehr fraglich zu sein, den Fehler beim Dateisystem zu suchen. OK, es ist theoretisch möglich, dass eine Box von derart massivem Speicherplatzverlust in Folge defekter Blöcke betroffen ist. Aber beide Geräte? Hier ist der gemeinsame Nenner doch das Image und nicht der Speicher der Geräte.
 

altae

Neuer User
Mitglied seit
5 Jun 2016
Beiträge
18
Punkte für Reaktionen
2
Punkte
3
Ja, das war es. Mit der Änderung läßt sich das Image bauen.

Edit: Box läßt sich aber nicht flaschen.

Anhang anzeigen 110751
Ich probiere Morgen weiter.

Edit 2: Hast Du es mal mit der aktuellen Labor versucht zu bauen und zu flashen ?

Nein, von der Labor Variante lasse ich generell die Finger, das ist mir zu instabil. Die Fritzbox soll schlussendlich zuverlässig funktionieren. Aber ich kann es ja testweise mal versuchen. Jedoch sicher nicht mehr heute.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,766
Punkte für Reaktionen
1,261
Punkte
113
Hmm ... das sind wieder zu wenige, als daß es direkt eine Erklärung liefern könnte.

Bei YAFFS2 werden die Daten in "chunks" gespeichert (bei der 7490 mit einer Größe von 2 KB) und jede Datei benötigt für ihren "payload" dann die entsprechende Anzahl dieser "chunks" - das ist praktisch wie bei jedem anderen Dateisystem auch (daß da immer komplette "Blöcke" benötigt werden), wenn das nicht gerade selbst komprimiert. Zusätzlich wird aber für JEDE Datei noch ein "chunk" als Object-Header benötigt, selbst für jeden Symlink, jedes Device-File (Block oder Character) und jeden FIFO. Damit belegen dann aber Dateien, die in einem SquashFS-Image nur wenige Byte für den Inode brauchen, in einer YAFFS2-Partition alleine für die Metadaten der Datei (Datum, Größe, Typ, etc.) schon diese 2 KB ... das kann dann (wenn man z.B. überflüssige Device-Files in das "äußere" Dateisystem mit einpackt) auch ganz schnell zu einem erheblichen Platzbedarf führen.

Außerdem kommt dann eben noch hinzu, daß bei der Installation der Inhalt des äußeren SquashFS-Images kopiert wird und der ist - in der filesystem.image - eben auch noch einmal (etwas) komprimiert ... üblicherweise ergibt sich auch schon bei der Addition der Dateigrößen aller "regular files" in der filesystem.image ein größerer Wert, als die Dateigröße der Image-Datei.

Daher war das auch bei AVM schon immer nicht wirklich ein "size for file /var/tmp/filesystem.image ok" (wie es im Installationsprotokoll steht), sondern immer nur der Vergleich der Größe der Image-Datei mit einem - auch in der Installationsdatei enthaltenen und gar nicht von der tatsächlichen Partitiongröße abgeleiteten - Wert und nur wenn da das Image schon größer wäre, gäbe es eine Fehlermeldung.

Bisher hat AVM damit aber auch noch keine Probleme gekriegt, weil die Größendifferenz zwischen der filesystem-Partition und der filesystem.image immer ausreichend bemessen war ... erst mit dem Zusammenfassen der deutschen und der internationalen Firmware ist die ja überhaupt auf mehr als 50% der 48 MB gewachsen.

Aber die "Berechnung" in Freetz/Freetz-NG war eben schon immer nur eine Milchmädchen-Rechnung ... egal, ob das äußere Dateisystem SquashFS-Format hat oder doch "ext2" - wobei bei letzterem (weil das auch nicht komprimiert, wie das YAFFS2) die Differenz zwischen "Inhalt" und "Image" auch geringer ausfällt.

Wie die einzelnen Partitionen mit YAFFS2-FS aussehen, kann man sich unter /proc/yaffs anzeigen lassen - wenn auch "hintereinander", was ich hier mal in eine Anzeige nebeneinander umgewandelt habe:
Rich (BBCode):
~ # j=1; l=0; for i in $(sed -n -e "/^Device/=" /proc/yaffs); do [ $l -eq 0 ] && l=$i && continue; sed -n -e "$(printf "%u,%u w /var
/file%s\n" "$l" "$(( i - 2 ))" "$j")" /proc/yaffs; j=$(( j + 1 )); l="$i"; done; sed -n -e "$(printf "%u,%s w /var/file%s\n" "$i" "\
$" "$j")" /proc/yaffs; for f in $(seq 1 $j); do sed -e "s| [0-9]\{1\}\$|&\t|" -e "/^Device/s|\$|\t|" /var/file$f | expand -t 8 | cut
-c -28 >/var/expanded$f; done; paste /var/expanded*; rm /var/expanded* /var/file*
Device 0 "filesystem"           Device 1 "config"               Device 2 "nand-filesystem"      Device 3 "reserved-filesyste
start_block.......... 0         start_block.......... 0         start_block.......... 0         start_block.......... 0
end_block............ 383       end_block............ 15        end_block............ 3247      end_block............ 383
total_bytes_per_chunk 2048      total_bytes_per_chunk 2048      total_bytes_per_chunk 2048      total_bytes_per_chunk 2048
use_nand_ecc......... 1         use_nand_ecc......... 1         use_nand_ecc......... 1         use_nand_ecc......... 1
no_tags_ecc.......... 1         no_tags_ecc.......... 1         no_tags_ecc.......... 1         no_tags_ecc.......... 1
is_yaffs2............ 1         is_yaffs2............ 1         is_yaffs2............ 1         is_yaffs2............ 1
inband_tags.......... 0         inband_tags.......... 0         inband_tags.......... 0         inband_tags.......... 0
empty_lost_n_found... 1         empty_lost_n_found... 1         empty_lost_n_found... 1         empty_lost_n_found... 1
disable_lazy_load.... 0         disable_lazy_load.... 0         disable_lazy_load.... 0         disable_lazy_load.... 0
refresh_period....... 500       refresh_period....... 500       refresh_period....... 500       refresh_period....... 500
n_caches............. 10        n_caches............. 10        n_caches............. 10        n_caches............. 10
n_reserved_blocks.... 5         n_reserved_blocks.... 5         n_reserved_blocks.... 5         n_reserved_blocks.... 5
always_check_erased.. 0         always_check_erased.. 0         always_check_erased.. 0         always_check_erased.. 0

data_bytes_per_chunk. 2048      data_bytes_per_chunk. 2048      data_bytes_per_chunk. 2048      data_bytes_per_chunk. 2048
chunk_grp_bits....... 0         chunk_grp_bits....... 0         chunk_grp_bits....... 0         chunk_grp_bits....... 0
chunk_grp_size....... 1         chunk_grp_size....... 1         chunk_grp_size....... 1         chunk_grp_size....... 1
n_erased_blocks...... 127       n_erased_blocks...... 14        n_erased_blocks...... 2400      n_erased_blocks...... 136
blocks_in_checkpt.... 1         blocks_in_checkpt.... 0         blocks_in_checkpt.... 0         blocks_in_checkpt.... 0

n_tnodes............. 1167      n_tnodes............. 0         n_tnodes............. 4200      n_tnodes............. 1138
n_obj................ 108       n_obj................ 79        n_obj................ 579       n_obj................ 112
n_free_chunks........ 8247      n_free_chunks........ 948       n_free_chunks........ 153656    n_free_chunks........ 8707

n_page_writes........ 0         n_page_writes........ 76        n_page_writes........ 595       n_page_writes........ 317
n_page_reads......... 14789     n_page_reads......... 153       n_page_reads......... 1509      n_page_reads......... 459
n_erasures........... 0         n_erasures........... 2         n_erasures........... 12        n_erasures........... 10
n_gc_copies.......... 0         n_gc_copies.......... 76        n_gc_copies.......... 467       n_gc_copies.......... 317
all_gcs.............. 0         all_gcs.............. 16        all_gcs.............. 96        all_gcs.............. 68
passive_gc_count..... 0         passive_gc_count..... 16        passive_gc_count..... 96        passive_gc_count..... 68
oldest_dirty_gc_count 0         oldest_dirty_gc_count 0         oldest_dirty_gc_count 7         oldest_dirty_gc_count 5
n_gc_blocks.......... 0         n_gc_blocks.......... 1         n_gc_blocks.......... 7         n_gc_blocks.......... 9
bg_gcs............... 0         bg_gcs............... 1         bg_gcs............... 7         bg_gcs............... 9
n_retired_writes..... 0         n_retired_writes..... 0         n_retired_writes..... 0         n_retired_writes..... 0
n_retired_blocks..... 0         n_retired_blocks..... 0         n_retired_blocks..... 0         n_retired_blocks..... 0
n_ecc_fixed.......... 0         n_ecc_fixed.......... 0         n_ecc_fixed.......... 0         n_ecc_fixed.......... 0
n_ecc_unfixed........ 0         n_ecc_unfixed........ 0         n_ecc_unfixed........ 0         n_ecc_unfixed........ 0
n_tags_ecc_fixed..... 0         n_tags_ecc_fixed..... 0         n_tags_ecc_fixed..... 0         n_tags_ecc_fixed..... 0
n_tags_ecc_unfixed... 0         n_tags_ecc_unfixed... 0         n_tags_ecc_unfixed... 0         n_tags_ecc_unfixed... 0
cache_hits........... 0         cache_hits........... 0         cache_hits........... 0         cache_hits........... 0
n_deleted_files...... 0         n_deleted_files...... 0         n_deleted_files...... 0         n_deleted_files...... 0
n_unlinked_files..... 0         n_unlinked_files..... 0         n_unlinked_files..... 208       n_unlinked_files..... 0
refresh_count........ 0         refresh_count........ 1         refresh_count........ 1         refresh_count........ 1
n_bg_deletions....... 0         n_bg_deletions....... 0         n_bg_deletions....... 0         n_bg_deletions....... 0
~ #
(Hier ist die "reserved-filesystem"-Partition von mir zusätzlich gemountet, normalerweise hat die 7490 nur drei YAFFS2-Partitionen aktiv.)

Da sieht man zumindest die verwendete Chunk-Size, die Anzahl der Blöcke (ein Block sind dann 64 Chunks) und ein paar "Statistiken" für den Zugriff - und die Anzahl der "reserved blocks" (für "no more space left"-Szenarien) ebenso wie die max. für Checkpoints verwendeten Blöcke, die bereits beim Übersetzen des FS-Treibers festgelegt werden:
C:
/* Default: 10 */
/* Meaning: set the count of blocks to reserve for checkpointing */
#define CONFIG_YAFFS_CHECKPOINT_RESERVED_BLOCKS 10
Man könnte also auch - mit einer gewissen Unsicherheit allerdings, die hat man wg. möglicherweise defekter NAND-Blöcke aber ohnehin - durch "Berechnen" eine halbwegs plausible Vorhersage treffen, ob die Daten in eine "wrapper"-Partition passen sollten oder nicht ... aber besser ist es allemal, man geht da gar nicht erst "bis zum Anschlag" und läßt per se schon 10% o.ä. frei - das hieße dann, daß die Dateigrößen in der Partition kumuliert nicht über 44 MB liegen sollten.

EDIT: Ich habe eben mal in ein älteres Build-Verzeichnis (113.07.12) geschaut und da liegen dann (basierend auf meinem Fork YourFreetz, der sich ja deutlich weniger vom originalen Freetz unterscheidet als Freetz-NG) immerhin schon 365 Dateien ... weil auch alle Symlinks in /usr/bin und /usr/sbin erstellt wurden und die sind dann auch in der Image-Datei zu finden. Da macht also Freetz-NG irgendetwas mittlerweile anders (ich habe aber keinen Bock, die Stelle bzw. den Commit dazu jetzt zu suchen, weil das praktisch aussichtslos ist), wenn die Anzahl der Inodes in der äußeren Image-Datei so gering ist. Ich glaube mich irgendwo tief im Hinterkopf zu erinnern, daß es in Freetz-NG eine Einstellung gibt, ob die AVM-Dateien in "wrapper" (das sind dann auch die C-Library und die BusyBox) ersetzt werden sollen oder nicht ... ich rate mal, daß das üblicherweise auf n steht und daß bei y dann ähnliche Ergebnisse dabei herauskommen, wie bei Freetz (und YourFreetz, wo das aber nicht interessiert).
 
Zuletzt bearbeitet:

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Also ich hab mal verglichen bei ner freetz-ng 7490.

Das filesystem.image: 33161224
Die Belegung der Partition: /dev/root 49152 34472 14680 70% /wrapper => 34472 * 1024 = 35299328 bytes
Differenz: 2138104 bytes, etwa 2088 kB, etwa 2 MB Verlust durch yaffs2

die 2088 kB abzuziehen dürfte genau sein für firmware mit Wrapper, da die Dateianzahl konstant ist (wasnoch zu prüfen wäre).
Ich hab auf boxmatix noch keine Vergleichslisten der Wrapper-Linuxe.
 
Zuletzt bearbeitet:

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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