Ja, das ist sicherlich die richtige Einstellung ... aber ich gestatte mir trotzdem noch den Hinweis, daß es im Nachhinein nichts mehr hilft, wenn man sie für das neue Image jetzt "richtig" setzt. Bei der Installation eines neuen Freetz-Images kommt die bisher in der Box enthaltene Busybox zum Zuge ... man müßte also erst noch ein "altes" Freetz-Image mit einer Busybox mit "conv"-Option auf die Box bringen, bevor man von einer 06.30-basierten Version auf die 06.50 updaten kann. Da ist dann das Auslassen der Option beim Kopieren sinnvoller, weil es diesen zusätzlichen Schritt nicht erfordert. Diese "conv=sync"-Option wird in der Hilfe folgendermaßen beschrieben:
Code:
sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs
Es wird also jeder Block der Eingabe, der kleiner als die Blocklänge dort ist ("bs" setzt sowohl "ibs" als auch "obs" auf denselben Wert), mit NUL-Bytes auf die gewünschte Blocklänge bei der Ausgabe (das wäre dann "obs") aufgefüllt. Nachdem da kein Magnetband o.ä. verwendet wird (wo so eine variable Blocklänge tatsächlich vorkommen könnte), betrifft das also maximal den letzten Block einer solchen Kopieraktion, wenn die originale Dateilänge kein Vielfaches der Blocklänge sein sollte. Das ist - nach allem, was ich auf die Schnelle ansehen konnte - aber nicht der Fall ... es wäre aber auch extrem überraschend. So eine "filesystem.image" besteht eben aus einem ext2-Dateisystem-Image und einem vorangestellten Dummy-Header von 256 Byte Länge (der ja genau mit dem dd-Kommando "weggeschnitten" werden soll).
Nun ist es bei ext2 aber das Problem, daß das Dateisystem selbst nur Blocklängen von 1024, 2048 oder 4096 Byte kennt. Wenn AVM also eine Datei "filesystem.image" in die eigene Firmware packt, bei der die Dateilänge inkl. dieses Dummy-Headers ein Vielfaches von 4096 ist:
Code:
~/trunk$ printf 0x%X $(stat -c %s build/original/firmware/var/tmp/filesystem.image)
0x1592000
- die Länge endet auf dreimal Null, ist also durch 2**12 teilbar -, dann kann man nur vermuten, daß damit ein Auffüllen des letzten Blocks auf die korrekte Blocklänge erfolgen soll. Schaut man sich dann ein originales Image an:
Code:
~/trunk$ sudo losetup -o 256 -f --show build/original/firmware/var/tmp/filesystem.image
/dev/loop0
~/trunk$ sudo dumpe2fs /dev/loop0 | grep "Block size"
dumpe2fs 1.42.9 (4-Feb-2014)
Block size: 1024
~/trunk$ sudo losetup -d /dev/loop0
müßte die Datei eigentlich auch nach dem Abschneiden des Dummy-Headers ("bs=256 skip=1" heißt ja, daß da die ersten 256 Byte (= 1 Block) der Eingabedatei zu überspringen sind):
Code:
~/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
eine Dateilänge haben, die in Vielfaches der Blocklänge von 1024 Byte ist. Das hat sie aber mit dem Wert "0x1591F00" nicht (Vielfache von 1024 enden auf 000, 400, 800 oder C00) ... da hilft auch keine "conv=sync"-Option beim "dd". Die bringt also gar nichts und verhindert durch ihr Fehlen bei der Busybox von Freetz (bei der von AVM ist sie wohl dabei, sonst hätte man das dort sicherlich schon eher bemerkt) nur die korrekte Funktion. Wenn man wirklich "auffüllen" will, braucht das einen zweiten "dd"-Aufruf mit einer Blocklänge von 1024, der dann tatsächlich den letzten Block nach den 768 in der Eingabe vorhandenen Bytes mit weiteren 256 Bytes NUL auffüllen würde.
Es schadet also gar nicht, diese Option einfach zu entfernen aus dem Aufruf ...
EDIT: ... und das "gekürzte" Dateisystem-Image braucht auch nicht auf ein Vielfaches irgendeiner "erase size" aufgefüllt zu werden, denn das wird ja gar nicht direkt in den Flash geschrieben, es wird schön Datei für Datei aus dem ext2-Dateisystem in das yaffs2-basierte Dateisystem der Flash-Partition kopiert.
)
