Auch wenn es sehr mühsam ist wegen der schlechten Lesbarkeit, wenn da viele Befehle und ihre Ausgaben in einem gemeinsamen Code-Block stehen ... ich sehe da keine wirklichen Probleme.
Was noch auf-(und mir dann wieder ein-)fällt ist der Unterschied, daß beim AVM-Image anstelle der Timestamp für das Erstellen der SquashFS-Images eben noch einmal die Länge des SquashFS-Images am Offset 8 steht (hatten wir irgendwann früher ja mal). Zwar ist in den Quelltexten für den SquashFS-Treiber da kein Unterschied zu sehen zwischen der 7490 und der 7360 (das hatte ich ja früher schon geprüft), vielleicht passen aber auch die veröffentlichten Quellen gar nicht zu dem Kernel, den AVM da wirklich verwendet.
Das wäre eine weitere Idee (und die berühmte Ausnahme von der Regel, daß man nicht im Superblock herumpfuscht), da noch einmal von Hand ebenfalls die Länge von Offset 28 (da ist es ein 64-Bit-Wert, an Offset 8 nur 32) zur Probe einzutragen. Zwar kann die AVM-Firmware ja das Filesystem offensichtlich auch mounten, wenn da tatsächlich ein Zeitstempel steht (das mksquashfs aus den Tools schreibt dort einen hinein), aber auch bei den SquashFS-Images für andere Boxen steht bei AVM an Offset 8 noch einmal diese Länge (gerade noch einmal bei der aktuellen Labor-Version der 7490 geprüft).
Am Ende interessiert ja tatsächlich das Datum der Erstellung des SquashFS-Images natürlich niemanden und wenn jemand bei AVM mal "quick&dirty" irgendwas fixen wollte, wäre so ein "Mißbrauch" ja auch denkbar.
Die Frage, warum man da dann nicht gleich die Länge ab 0x2C auslesen konnte, stelle ich gar nicht erst ... auch die Spekulation, daß diese "Besonderheit" zur Abwehr von Änderungen mit den inzwischen verfügbaren SquashFS-Tools4 auch für das von AVM geänderte Format dienen könnte, stelle ich nicht an, das wäre mir zuviel Verschwörungstheorie.
Das kann einerseits "vollkommen harmlos" sein und nur ein unbeabsichtigter Fehler oder es handelt sich um irgendeine Änderung, die dann nur bei NOR-Modellen zum Tragen kommen soll, oder, oder, oder ... es ist der letzte Unterschied in den Images, der mir noch auffällt.
Ich würde ja noch einen Test empfehlen, bei dem das von Freetz erstellte SquashFS-Dateisystem mal auf der 7360 in einer originalen Firmware-Version 06.50 gemountet wird, das geht aber wohl nicht so ohne weiteres ... allerdings würde der Shell-Code in /etc/hotplug/udev-mount-sd tatsächlich auch ein SquashFS-Image in einer Partition(!) auf einem USB-Stick als solches erkennen und dann ggf. mounten oder eben auch nicht:
Code:
case $filesystem_type in
swap)
echo "MOUNT: try to add swap" >/dev/console
if mkswap $DEVNODE ; then
swapon $DEVNODE
echo "MOUNT: swap added" >/dev/console
FAIL_EVENT=0
fi
;;
[COLOR="#FF0000"]squashfs)
echo "MOUNT: mount -t 'squashfs' $DEVNODE $MNTPATH" >/dev/console
if mount -t squashfs -o ro $DEVNODE "$MNTPATH"; then
new_filesystem=true
fi
;;
[/COLOR]vfat)
echo "MOUNT: mount -t 'vfat' $DEVNODE $MNTPATH" >/dev/console
if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK $DEVNODE "$MNTPATH"; then
new_filesystem=true
fi
;;
ntfs)
echo "MOUNT: mount -t 'ntfs' $DEVNODE $MNTPATH" >/dev/console
if test -x /bin/ntfs-3g ; then
ntfs-3g $DEVNODE "$MNTPATH" -o $READMODE,locale=de_DE.UTF-8,$FMASK,$DMASK,big_writes
local NTFS_RET=$?
case "$NTFS_RET" in
0 )
new_filesystem=true
;;
12 ) # NTFS_VOLUME_NOT_NTFS
## ignore - not formatted with NTFS
;;
15 ) # NTFS_VOLUME_UNCLEAN_UNMOUNT
## need option -o force, but we don't do this, because its not safe!
eventadd 144 "$MNTNAME"
## no fail event later on
FAIL_EVENT=0
led-ctrl filesystem_mount_failure
;;
* )
## NTFS mount error
eventadd 145 "$MNTNAME" $NTFS_RET
## no fail event later on
FAIL_EVENT=0
led-ctrl filesystem_mount_failure
;;
esac
else
echo "ntfs not yet ready -> mount later" > /dev/console
FAIL_EVENT=0
fi
;;
ext2|ext3|ext4)
echo "MOUNT:mount -t 'extX' $DEVNODE $MNTPATH" >/dev/console
if mount -t $filesystem_type $DEVNODE "$MNTPATH"; then
new_filesystem=true
chmod 777 "$MNTPATH"
fi
;;
*)
echo "MOUNT: unknown filesystem type $filesystem_type on device $DEVNODE" >/dev/console
test -z "$filesystem_type" && FAIL_EVENT=0
;;
esac
Das wäre im Moment der einzige Weg (abseits vom "Einbruch" in die Firmware 06.50 über eine Lücke, bei dem man dann doch wieder eine Shell startet), den ich mir als Test für die Akzeptanz eines mit Freetz erzeugten SquashFS-Images noch vorstellen könnte - das ist aber auch wieder nicht unbedingt trivial, so einen USB-Stick zu erstellen (wenn etwas nicht wie erwartet laufen sollte) und man sollte am besten eine andere FRITZ!Box (z.B. eine 7490 mit modfs) erst einmal zur Hand haben, um die korrekte Funktion des Sticks mit dem SquashFS-Image in der Partition zu testen.
Wobei eigentlich der passende Partition-Typ (0x83) schon ausreichen sollte und dann kann man einfach (notfalls zeichenorientiert mit "cat") das Image in das passende Blockdevice (/dev/sd
irgendwas) für die Partition schreiben - also auch wieder keine wirkliche "rocket science", aber man muß schon wissen, was man da macht.
Und ein wirklich allerletzter Test wäre dann noch das Entfernen der überflüssigen Nullen am Ende des Images, zwischen dem Ende des SquashFS-Dateisystems und der TI-Prüfsumme (die dann natürlich nicht mehr stimmt, also muß das Auffüllen dort vorher verhindert werden). Ich weiß jetzt nicht genau, wie da das Padding erfolgt (ich rechne mit "conv=sync" bei irgendeinem "dd"-Aufruf o.ä.), aber da könnte man auch noch einmal ansetzen und nachsehen, wie man das verhindern könnte. Das AVM-Image endet zwar (ich nehme mal an zufällig) an einer 16-Byte-Grenze, aber das wäre nun in diesem Kontext etwas "vollkommen Krummes", genauso wie das Ende auf "6" oder "a".
