[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Muß das unbedingt nach / entpackt werden, um nachher installieren zu können?
Ja, die AVM-Images enthalten die Verzeichnisse für var und var/tmp und das install-Skript greift mit absoluten Pfaden auf die kernel.image und filesystem.image zu:
Rich (BBCode):
[email protected]:~> wget http://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.12.image -O - -q | tar -x -O ./var/install | grep "/var/tmp/\(kernel\|filesystem\)\.image"
if [ -f /var/tmp/filesystem.image ] && [ $filesystem_size -ne 0 ] ; then
    if ! /var/chksum${CHKSUMEXT} /var/tmp/filesystem.image ; then
        echo "chksum for file /var/tmp/filesystem.image failed."
    echo chksum for file /var/tmp/filesystem.image ok
    filesystem_image_size="`ls -l /var/tmp/filesystem.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
        echo "Size of file /var/tmp/filesystem.image bigger than MTD-Size (${filesystem_image_size} > ${filesystem_size})."
    echo size for file /var/tmp/filesystem.image ok
if [ -f /var/tmp/kernel.image ] ; then
    if ! /var/chksum${CHKSUMEXT} /var/tmp/kernel.image ; then
        echo "chksum for file /var/tmp/kernel.image failed."
    echo chksum for file /var/tmp/kernel.image ok
    kernel_image_size="`ls -l /var/tmp/kernel.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
        echo "Size of file /var/tmp/kernel.image bigger than MTD-Size (${kernel_image_size} > ${kernel_size})."
    echo size for file /var/tmp/kernel.image ok
elif ! test -f "/var/tmp/kernel.image" ; then
elif ! test -f "/var/tmp/filesystem.image" ; then
    kernel_image_size="`ls -l /var/tmp/kernel.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
    filesystem_image_size="`ls -l /var/tmp/filesystem.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
    echo "/sbin/update_kernel -i /var/tmp/kernel.image  -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
    echo "cp /var/tmp/kernel.image /dev/mtdblock$var_kernel_mtdnr" >> /var/post_install
echo 'rm -f /var/tmp/kernel.image' >> /var/post_install
echo 'mount -t squashfs /var/tmp/filesystem.image /var/tmp/fs' >> /var/post_install
echo '    dd if=/var/tmp/filesystem.image of=/var/tmp/fsimage.ext2 bs=256 skip=1 conv=sync' >> /var/post_install
echo '    [ "$?" -eq 0 ] && mount -t ext2 /var/tmp/fsimage.ext2 /var/tmp/fs && rm -f /var/tmp/filesystem.image' >> /var/post_install
[email protected]:~>
Daher muß als Basisverzeichnis für das Entpacken die Wurzel angegeben werden - ansonsten muß man hinterher erst wieder "sortieren". Am Ende MÜSSEN die beiden Image-Files für das AVM-Skript am richtigen Ort liegen und auch das Programm zum Überprüfen der TI-Checksumme wird direkt unter /var/chksum gesucht, wie man oben sieht (Zeile 3 in der Ausgabe).

Muß hier die own_filesystem.spfs mit Prüfsumme sein?
Ja, sonst spielt das AVM-Skript nicht mit. Da ich hier dann auch auf die FRITZ!Box wechseln mußte, kam das Image vom NAS, wo man es irgendwie ablegen muß von extern (zur FRITZ!Box).

Hast du dafür einen Vorschlag?
Das geht tatsächlich wieder ziemlich einfach mittels unsquashfs ... allerdings auch nur mit der Version aus Freetz, die die notwendigen Patches von mir enthält: https://github.com/PeterPawn/YourFreetz/commit/9f89c498caef84fa8cc7c64730c670a71637b43f (bzw. die umgearbeiteten Änderungen von @er13).

Denn dazu braucht es die Option -scan, die erst einmal nach dem Offset des Superblocks innerhalb einer Datei sucht. Die offiziellen SquashFS-Tools kennen da zwar mittlerweile auch eine Option -offset für solch eine Verschiebung (https://github.com/plougher/squashfs-tools/commit/f72f32b0fe7929e71edd9e6589fa1fcec1d86adc#diff-64f9b9f920063cbf890d0a44d3c9ef17), aber dafür muß man die Verschiebung bereits kennen, während bei -scan eben nach der Signatur des SquashFS-Superblocks gesucht wird. Da das auch noch entsprechende Anzeigen/Ausgaben nach sich zieht, kann man damit die "Grenze" zwischen Kernel und Dateisystem in einem RAM-Image finden und dann beide mittels dd wieder voneinander separieren:
Rich (BBCode):
[email protected]:~> wget ftp://user:password@update.avm.de/labor/PSQ19-Labor/FRITZ.Box_7490-07.19-79496-LabBETA.image -O /tmp/avm.image -q
[email protected]:~> /home/GitHub/YourFritz/eva_tools/image2ram < /tmp/avm.image >/tmp/in-memory.image
[email protected]:~> /home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -scan -stat /tmp/in-memory.image
Found a valid superblock at offset 0x00290100 while scanning /tmp/in-memory.image.
Found a valid big endian SQUASHFS 4:0 superblock on /tmp/in-memory.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 30473.99 Kbytes (29.76 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 1
Number of inodes 105
Number of ids 1
Hier kann man also die Ausgabe von unsquashfs nach der Zeile durchsuchen (lassen) und die hexadezimale Angabe läßt sich auch ganz simpel wieder in einem dd-Kommando verwenden - wobei das hier alles ohne Fehlerbehandlung ist und man sich daher zuvor davon überzeugt haben sollte, daß es den Superblock tatsächlich gibt:
Rich (BBCode):
[email protected]:~> dd if=/tmp/in-memory.image of=/tmp/kernel.image bs=256 count=$(( 0x$(/home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -scan -stat /tmp/in-memory.image 2>&1 | sed -n -e "s|Found a valid superblock at offset 0x\([0-9A-Fa-f]*\)00 while.*\$|\1|p") ))
10497+0 records in
10497+0 records out
2687232 bytes (2.7 MB, 2.6 MiB) copied, 0.0823 s, 32.7 MB/s
[email protected]:~> dd if=/tmp/in-memory.image of=/tmp/fs.image bs=256 skip=$(( 0x$(/home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -scan -stat /tmp/in-memory.image 2>&1 | sed -n -e "s|Found a valid superblock at offset 0x\([0-9A-Fa-f]*\)00 while.*\$|\1|p") ))
121904+0 records in
121904+0 records out
31207424 bytes (31 MB, 30 MiB) copied, 0.896775 s, 34.8 MB/s
Da man hier auch davon ausgehen kann, daß der Superblock an einer 256-Byte-Grenze in der Datei beginnt (der hexadezimale Offset also immer "00" in den letzten zwei Stellen hat), kann man auch gleich mit Blöcken von 256 Byte arbeiten, das geht schneller. Wie genau man die "Filterung" mit dem sed jetzt macht bzw. wie exakt der Text verglichen werden soll, ist Geschmackssache - aber man sollte auch die richtige Zeile treffen und da reicht "offset" dann nicht zwingend aus als "Adresse" (bzw. wäre mir persönlich halt zuwenig).

Das hat jetzt nur einen Schönheitsfehler ... es funktioniert nur dann, wenn das verwendete Dateisystem auch tatsächlich ein SquashFS-Image ist. Handelt es sich tatsächlich um ein "ext2"-Image, das nur den "Pseudo-Header" für ein SquashFS-Image vorangestellt hat (256 Byte, wobei in den ersten vier Byte die Signatur "sqsh" steht), findet auch das gepatchte unsquashfs (absichtlich) keinen Superblock, weil eben der Rest in diesen 256 Byte nicht paßt. Das heißt also, daß man sich für die Versionen der AVM-Firmware, die bei den passenden Plattformen (iirc sind das nur VR9 und AR10, die da betroffen sind) mit einem "ext2"-Image arbeiten (das stellte AVM ja erst im Laufe der Labor-Reihe 07.19 wieder um), doch noch etwas anderes einfallen lassen muß.
Rich (BBCode):
[email protected]:~> wget http://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.12.image -O /tmp/avm.image -q
[email protected]:~> /home/GitHub/YourFritz/eva_tools/image2ram < /tmp/avm.image >/tmp/in-memory.image
[email protected]:~> /home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -k /tmp/in-memory.image
Unable to find something looking like a SquashFS superblock in /tmp/in-memory.image.
An einer 256-Byte-Grenze in der Datei steht - wie oben schon zu lesen - also ein "sqsh", gefolgt von 252 weiteren Byte, die nur binäre Nullen enthalten (das ist der Pseudo-Header). Es gilt also jetzt, die Verschiebung dieses 256-Byte-Blocks in der Datei zu finden. Hat man dafür ein passendes grep-Kommando zur Hand, ist das wieder easy - das grep aus der BusyBox nutzt einem hier aber nichts. Uns interessiert nur die erste Fundstelle (da der Kernel gepackt ist, taucht darin üblicherweise kein "sqsh" als Klartext auf - das wäre schon ein ziemlicher Zufall) und wenn man das nicht mit 1-Byte-Blöcken und damit extrem langsam kopieren will, sollte man die Verschiebung wieder durch 256 teilen:
Rich (BBCode):
[email protected]:~> grep -abo "sqsh" /tmp/in-memory.image
2649088:sqsh
23165384:sqsh
25126144:sqsh
[email protected]:~> printf "%u\n" "$(( $(grep -abo "sqsh" /tmp/in-memory.image | sed -n -e "1s|\([0-9]*\):sqsh|\1|p") / 256 ))"
10348
[email protected]:~> dd if=/tmp/in-memory.image of=/tmp/kernel.image bs=256 count=$(printf "%u\n" "$(( $(grep -abo "sqsh" /tmp/in-memory.image | sed -n -e "1s|\([0-9]*\):sqsh|\1|p") / 256 ))")
10348+0 records in
10348+0 records out
2649088 bytes (2.6 MB, 2.5 MiB) copied, 0.0787778 s, 33.6 MB/s
[email protected]:~> dd if=/tmp/in-memory.image of=/tmp/fs.image bs=256 skip=$(printf "%u\n" "$(( $(grep -abo "sqsh" /tmp/in-memory.image | sed -n -e "1s|\([0-9]*\):sqsh|\1|p") / 256 ))")
117008+0 records in
117008+0 records out
29954048 bytes (30 MB, 29 MiB) copied, 0.887396 s, 33.8 MB/s
Auch ohne passendes grep kann/muß man sich dann eben zu helfen wissen ... es gibt diverse andere Wege, die richtige Verschiebung zu ermitteln und notfalls durchsucht man selbst mit dd das Image nach dem Pseudo-Header (Achtung: Das mit dem for in dieser Form funktioniert nicht mit der BusyBox oder der dash, da muß man es "komplizierter" machen (für die Schleife).):
Rich (BBCode):
[email protected]:~> ( printf "sqsh"; for (( i=63; i>0; i-- )); do printf "\000\000\000\000"; done ) >/tmp/pseudo.hdr
[email protected]:~> hexdump -C /tmp/pseudo.hdr
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  |................|
*
00000100
[email protected]:~> time for (( blocks=$(( $(wc -c /tmp/in-memory.image | sed -n -e "1s|\([0-9]*\).*|\1|p") / 256 )), c=0; c<blocks; c++ )); do dd if=/tmp/in-memory.image bs=256 count=1 skip=$c 2>/dev/null | cmp -- /tmp/pseudo.hdr - 2>/dev/null 1>&2 && printf "\r%u\n" "$c" && break; printf "\r%u" "$c"; done
10348

real    0m36.637s
user    0m28.555s
sys     0m30.521s
Das dauert zwar (gefühlt eine halbe Ewigkeit), aber es findet den Block auch irgendwann ... nur würde ich hier den Wert von Hand in die dd-Kommandos einsetzen oder in einer Variablen zwischenspeichern - das muß man nicht mehr als einmal ausführen (lassen).

Es führen wieder mal viele Wege nach Rom und welchen man nimmt, hängt immer auch davon ab, was man als Werkzeug in seiner Wanderausrüstung mit sich herumträgt. Fast immer wird sich auch mit Vorhandenem ein Weg finden lassen - notfalls muß man eben doch Programme nachinstallieren.
 
Zuletzt bearbeitet:

Insti

Mitglied
Mitglied seit
19 Aug 2016
Beiträge
391
Punkte für Reaktionen
29
Punkte
28

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
Das geht tatsächlich wieder ziemlich einfach
Ja, das sehe ich, wenn du dazu über eine halbe Seite dieses Forums brauchst, um es zu erklären. ;)
Aber du hast das bestimmt schon oft gemacht, denn die EVA-Tools brauchen das IMO doch auch um die jeweiligen Daten in das richtige MTD zu schieben

Danke, ich habe es mit deiner Hilfe alles auf der FB nachmachen können, da ich auch dein spezielles unsquashfs4-le/be nutze, natürlich das für mips.
Sehr gestaunt habe ich, daß image2ram sofort ohne Probleme auf der FB lief.

Gestärkt mit so viel Wissen, will ich jetzt ein Update auf einer 7412 über VPN LAN2LAN wagen.
Die läuft noch immer mit 06.83 und ich will ihr endlich die letzte Release (nicht Kugel) 06.86 geben.
In der anderen Partition ist noch etwas uraltes, was vom gui_bootmanager nicht angezeigt wird, das sollte doch aber nicht stören. Oder?

7412:/var/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00020000 "reserved-kernel"
mtd1: 03000000 00020000 "reserved-filesystem"
mtd2: 00400000 00020000 "kernel"
mtd3: 03000000 00020000 "filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 011c0000 00020000 "nand-filesystem"
mtd6: 00040000 00020000 "urlader"
mtd7: 00400000 00020000 "nand-tffs"

Ich müßte hier also doch in die sonst so gefährliche mtd1 flashen. Oder?

Ich habe folgenden Plan:
1. nach mtd0 und mtd1 die originalen Dateien ohne Prüfsumme flashen.
(was passiert eigentlich wenn man es mit Prüfsumme macht?)
Noch mal prüfen ob alles richtig ist, aber wie?
Die mtd's runter laden und vergleichen, aber die sind doch dann viel größer, als die drauf geladenen Dateien.

2. mit install_inactive_rootfs die Modifizierungen aus modfs einspielen.

3. Dann erst linux_fs_start ändern und einen reboot machen.

Ist das alles richtig? Sollte das so gehen?
Ich frage jetzt lieber 3 mal vorher nach, eine geschrottete 7580 reicht mir.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Bei einer VR9-Box ist das mit dem "einfachen" Flashen etwas komplizierter - zumindest dann, wenn der Rest des Inhalts in der YAFFS2-Partition (das ist hier tatsächlich "mtd1" (EDIT: für linux_fs_start=0) und die Warnung davor, gilt eben nur für EVA - wobei man nicht müde werden sollte zu betonen, daß der "Blickwinkel" von Bootloader und laufendem System auf die MTD-Partitionen immer ein anderer ist und die Nummerierungen nichts miteinander zu tun haben. Wenn die wirklich mal identisch sein sollten, wären das uralte Boxen - obendrein vermutlich ausschließlich mit NOR-Flash. Das hat keinerlei System und damit ist die wichtigste Warnung an dieser Stelle, daß man diese Nummern nicht durcheinanderwerfen DARF.

Bei der Installation auf einer 7412 geht man so vor (eigentlich auf allen VR9-Boxen mit dem YAFFS2-Wrapper ... EDIT: Das gilt so aber auch wieder nur für VR9-Versionen mit "ext2"-Image, siehe weiter unten am Ende des Beitrag.):

1. Ermitteln und Notieren der Namen der Partitionen (Ziel sind die "reserved"-Partitionen)
2. update_kernel -i kernel.image -o /dev/mtdX
3. Mounten des "ext2"-Images aus der "filesystem.image" (genaueres weiter unten)
4. Mounten der Zielpartition
5. Kopieren aller Dateien aus dem "ext2"-Image in die Zielpartition - ggf. ohne die "filesystem_core.squashfs", wenn man die ohnehin ersetzen will
6. Dismounten der Zielpartition (da ist das "sync" zum "echten Schreiben" dann eingeschlossen)
7. Änderung von "linux_fs_start"

Das Kopieren aller Dateien kann man entweder mit dem cp-Kommando (Option -a) machen, wie AVM ... oder man nutzt ein tar, wo man dann die angesprochene Datei filesystem_core.squashfs ausklammern kann beim Kopieren. Wenn also das Verzeichnis, wo das "ext2"-Image gemountet wurde, /var/source und das Verzeichnis, wo die YAFFS2-Partition gemountet wurde, /var/target heißen (was beides dann absolute Pfade sein sollten), sieht das Kopieren mit allem so aus: cp -a /var/source /var/target und das Kopieren ohne das Wurzeldateisystem-Image so: tar -c -C /var/source --exclude filesystem_core.squashfs . | tar -x -C /var/target - letzteres ist eben vorzuziehen (funktioniert aber auch mit allen Dateien, dann läßt man eben das --exclude filesystem_core.squashfs weg), wenn man das Wurzeldateisystem ohnehin noch einmal austauschen will.

Erstens schont man den Flash-Speicher, weil er an diesen Stellen nicht beschrieben wird und damit nicht erneut gelöscht werden muß, wenn man das "richtige" Dateisystem hineinkopiert und zweitens erspart man sich weitere Komplikationen, wenn ein Kommando beim Kopieren erst mal die neue Datei sicher an der gewünschten Stelle anlegen und befüllen will, bevor es die alte löscht und die neue dann nur noch umbenennt, aber der freie Platz für diese "zweite Kopie" am Ort des Ziels nicht mehr vorhanden ist.

AVM verwendet nebenbei bemerkt die Option -R beim Kopieren mit cp, während ich -a präferiere, was automatisch die AVM-Option einschließt, aber die Dateiattribute mitkopiert (wenn möglich) - bei der Arbeit als "root" wird das i.d.R. ohnehin funktionieren (weil die Dateien an der Quelle auch alle "root" gehören), aber wenn's mal nicht klappen sollte, kriegt man so (mit -p in den Optionen, was bei -a das einzige ist, was sich ggü. -R wirklich ändert) wenigstens noch eine (Fehler-)Nachricht.

Nun noch einmal zum "ext2"-Image ... das ist - wie bekannt - ein Abbild einer "ext2"-Partition, dem nur noch der "Pseudo-Header" für ein SquashFS-Image vorangestellt wurde. Nur muß man jetzt eben auch dieses "ext2"-Image mounten und da das bei Images immer über ein Loopback-Device erfolgt, hängt die passende Vorgehensweise dabei auch immer davon ab, wie "schlau" das verwendete mount-Kommando ist (u.a., ob das selbst das Loopback-Device einrichten kann und das dann auch noch mit einem passenden Offset, um den Pseudo-Header zu ignorieren) oder was das losetup-Kommando kann (hier geht es darum, ob "wenigstens" dieses in der Lage ist, ein Image mit Offset zu laden) oder man muß am Ende sogar hingehen und diesen Pseudo-Header erst mal vom "ext2"-Image wieder entfernen - wobei das dann wieder viel Platz im Speicher bzw. einem Dateisystem benötigt, weil man die "neue Kopie" des Dateisystems (ohne den Pseudo-Header) erst mal zusammen mit der originalen Datei speichern muß, bevor man das Original anschließend entsorgen kann.

Auf einer FRITZ!Box kann aber das losetup-Kommando i.d.R. auch ein Image mit einem solchen Offset laden:
Rich (BBCode):
~ # losetup
BusyBox v1.27.2 multi-call binary.

Usage: losetup [-r] [-o OFS] {-f|LOOPDEV} FILE - associate loop devices
        losetup -d LOOPDEV - disassociate
        losetup -a - show status
        losetup -f - show next free loop device

        -o OFS  Start OFS bytes into FILE
        -r      Read-only
        -f      Show/use next free loop device
~ # tar -x -f /var/media/ftp/system/FB7490/firmware/FRITZ.Box_7490-07.12.image -O ./var/tmp/filesystem.image > /var/tmp/filesystem.image
~ # losetup -o 256 -r -f /var/tmp/filesystem.image
~ # losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 0 /var/media/ftp/YourFritz/bintools.custom
/dev/loop2: 256 /var/tmp/filesystem.image
~ # mkdir /var/source
~ # mount /dev/loop2 /var/source
~ # find /var/source -type f
/var/source/lib/libuClibc-1.0.14.so
/var/source/lib/ld-uClibc-1.0.14.so
/var/source/tmp/mtab
/var/source/etc/inittab
/var/source/filesystem_core.squashfs
/var/source/bin/busybox
/var/source/sbin/reboot
/var/source/sbin/flash_update
EDIT: Ich habe das gerade noch einmal geprüft ... das stimmt tatsächlich, daß ein vorhandenes losetup-Applet der BusyBox die notwendige Option für einen Offset schon seit Jahren kennt: https://git.busybox.net/busybox/commit/util-linux/losetup.c?id=83788da25055c4a2775c3d78a29255ee671141bb - nur nutzt das am Ende alles nichts, wenn es das Applet gar nicht in der BusyBox auf dem Gerät gibt. Und genau das ist offenbar bei AVM (schon immer) der Fall ... damit muß man bei originaler AVM-Firmware tatsächlich den mühsamen Weg des Abschneidens für den Pseudo-Header gehen. Nur in sehr alter Firmware (irgendwo in der Gegend von 06.3x) gibt es bei AVM ein losetup - allerdings nicht in der BusyBox als Applet, sondern die Version aus dem util-linux-Paket und daher kam auch mein Irrtum oben, daß es auf der Box ein solches Kommando geben müßte.

Verwendet man eine BusyBox von mir oder aus Freetz, kann man auch dem mount-Kommando direkt ein Offset mit auf den Weg geben, wobei beide Implementierungen dafür unterschiedliche Wege beschreiten (https://github.com/Freetz/freetz/blob/master/make/busybox/patches/411-mount_loop_offset_option.freetz.patch vs. https://github.com/PeterPawn/YourFreetz/blob/YourFritz/make/busybox/patches/412-mount_loop_offset_option.PeterPawn.patch - obwohl am Ende beide dieselben Parameter für den Benutzer bieten/nutzen). Damit reduziert sich das dann auf ein mount -o offset=256 -r /var/tmp/filesystem.image /var/source ... und das hat auch einen Vorteil beim "Aufräumen", weil alles andere bereits beim umount auch automatisch wieder abgeräumt wird, während man ansonsten das Loopback-Device noch selbst entladen muß.

Aber wie gesagt ... das geht nur mit einer angepaßten BusyBox - entweder aus Freetz oder aus YourFreetz (bzw. dann aus yf_bin) und daher sollte man den "harten Weg" auch kennen. Letztlich gehört der Vollständigkeit halber auch noch das dd if=/var/tmp/filesystem.image of=/var/tmp/fsimage.ext2 bs=256 skip=1 conv=sync dazu, was bei AVM dann verwendet wird, wenn der erste Versuch, die filesystem.image als SquashFS-Image zu mounten, fehlgeschlagen ist und man dadurch "erkannt" hat, daß es wohl doch ein "ext2"-Image ist. Dann muß man beim losetup natürlich auch den Dateinamen entsprechend ändern - wobei man hier dann auch wieder das originale mount aus der BusyBox nehmen kann, weil das ohne die Notwendigkeit eines Offsets auch wieder prima klarkommt - inkl. des automatischen Einrichtens und Abräumens der Loopback-Devices. Auf den benötigten Platz für die Kopie beim dd, habe ich schon hingewiesen.

Bleibt noch die Frage, wie man das mit dem Mounten der Zielpartition am besten macht. Zwar kann das YAFFS2 eine "beschreibbare" Partition im NAND-Flash bereitstellen (die VR9-Boxen verwenden das ja auch für den NAS-Speicher) und somit ist auch das "Überschreiben" alter Dateien möglich, aber besser ist es (auch gegen "orphans", die nicht von neueren Versionen überschrieben würden), wenn man den Inhalt der YAFFS2-Partition vor dem Mounten löscht - das geht genauso, wie weiter vorne im Thread für den Kernel und für UBI-Partitionen gezeigt (je nachdem, was man zur Verfügung hat an Werkzeugen).

Danach mountet man dann einfach (hier jetzt das Block-Device(!) für) die Partition mit Type "YAFFS2" und der Dateisystem-Treiber kümmert sich dann selbst darum, die notwendigen Strukturen für die Verwaltung wieder anzulegen ... es braucht also kein gesondertes "Formatieren" dieser Partition. Damit reduziert sich das (nach dem Löschen) wieder auf ein mount -t yaffs2 /dev/mtdblockX /var/target.

Und wenn man's erst mal begriffen und ein paar Mal selbst probiert hat, ist das tatsächlich auch "einfach" ... logischerweise kommt aber Routine erst mit Übung und - hier wirklich wieder wichtig - mit dem Erkennen und Begreifen der Unterschiede der Plattformen und des Vorgehens bei der Installation. Ein "so kenne ich das von anderen Boxen" kann hier sehr gefährlich sein und man sollte sich immer erst einmal überzeugen, daß die eigenen Annahmen auch stimmen, wenn man sie selbst nur "in Analogie" zu anderen Modellen getroffen hat. Ich werde nicht müde, das immer wieder zu betonen und der Blick in die Firmware (die man bei AVM leicht findet, selbst für die Cable-Modelle, wenn man sich etwas anstrengt) schafft in vielen Fällen da schon Klarheit. Ich persönlich würde jedenfalls nur dann von Hand in den Eingeweiden einer FRITZ!Box herumwühlen, wenn ich mir hinreichend sicher bin, daß ich auch die Bauchspeicheldrüse von der Gallenblase unterscheiden kann.

Und wenn ich - gerade hier in diesem Thread, den ich extra dafür auch aufgemacht habe - dann etwas ausführlicher "erkläre" und zeige, wie das geht und u.U. sogar noch, warum das so ist, dann auch in der Hoffnung, daß das hier der Platz für die Zusammenfassung sein möge (und nicht, weil es so kompliziert ist - schließlich kommt die Länge auch durch das Aufzeigen von Alternativen, weil das eben auch kein "Rezept" sein soll) ... bisher sind diese Erklärungsversuche halt über mehrere Threads verteilt und auch wenn ich nach wie vor der Ansicht bin, daß jeder vor einer eigenen Frage erst einmal suchen sollte, ob die nicht bereits (ausführlichst) beantwortet wurde, erkenne ich auch an, daß es mittlerweile deutlich schwerer geworden ist, noch die passenden Suchergebnisse zu erzielen.

Nur kann das ja am Ende nicht darin münden, daß man alles zig-fach wiederholt und erneut aufschreibt ... daher hier ggf. auch deutlich länger, als es für einen konkreten Fragesteller vielleicht erforderlich wäre - aber das immer mit der Hoffnung, damit auch die Zahl der "Nachfragen" (zumindest der "unqualifizierten", die auch nach dem Lesen dieses Threads noch "Wie geht das genau? Kannst Du mir das nicht mal aufmalen?" wissen möchten) so weit zu verringern, daß es nicht länger "nervt", weil man sich ständig wiederholen muß. Notfalls kann man jetzt eben auch einfach hierhin verweisen, falls mal wieder jemand den Thread nicht findet.

=====================================================================

EDIT:
(was passiert eigentlich wenn man es mit Prüfsumme macht?)
Nichts ... in den Partitionen stören die nicht, solange es nicht gerade diese 8 Byte sind, die nicht mehr hineinpassen. Nur beim Start aus dem RAM ist es wichtig, daß das Dateisystem an einer 256-Byte-Grenze liegt und das tut es - weil es ja an das obere Ende des Speichers geladen wird - mit seinem Anfang auch nur dann, wenn diese 8 Byte da nicht "dranbammeln" - ansonsten würde der Beginn ja auch 8 Byte vor einer 256-Byte-"Boundary" landen.

Ähnliches gilt für den Kernel, wobei ich bei dem gerade nicht sicher bin, ob der auch eine integrale Grenze benötigt für das erste Byte - wenn nicht, würde das Abschneiden am Dateisystem ggf. auch reichen, wenn alles andere mitspielt und sich nicht daran stört, daß der Kernel dann "nur" an einer 8-Byte-Boundary liegt. Das hängt auch immer von der Speicherverwaltung der Plattform ab ... der "setup code" des Kernels wird irgendwann ohnehin freigegeben, damit man den Speicher dann anderweitig nutzen kann (free_initmem()) und da das natürlich auch nur "seitenweise" erfolgen kann, wäre es auch nicht auszuschließen, daß der Init-Code und der "verbleibende Code" auf die Page-Größe ausgerichtet sind und dann sollte wohl auch der Kernel an einer passenden Grenze beginnen.

Wobei der ja ohnehin schon vom Bootloader von dort, wo man ihn per "STOR"-Kommando beim FTP hingeladen hat, gelesen und in die "unteren Adressen" (aka Kernel-Entrypoint) kopiert wird - es gibt also wieder mal gute Gründe, die auch gegen Probleme beim Vorhandensein der Prüfsumme am Kernel-Image im Speicher sprechen. Nur für das Dateisystem ist das eindeutig ... das muß an einer 256-Byte-Grenze liegen, damit der Parser im Kernel-Code die Signatur finden kann (in ifx_squashfs_parser_function() bzw. ifx_ext2fs_parser_function()).

Wobei die Prüfsumme an der filesystem.image bei den VR9-Boxen ja schon deshalb nicht interessiert (und das auch nicht kann), weil da ja gar nicht diese Image-Datei in die Flash-Partition geschrieben wird, sondern nur die darin enthaltenen Dateien (egal, ob das "ext2" oder "squashfs" ist).

=====================================================================

EDIT2:
Wobei mich das auch gleich wieder darauf aufmerksam macht, daß ich oben noch vergessen habe zu erwähnen, wie das bei VR9-Boxen mit SquashFS-Format für die filesystem.image geht - denn auch dort kann man ja nicht einfach das Image in die Partition kopieren. Da mountet man auch erst mal die filesystem.image und kopiert dann den Inhalt des Verzeichnisses, wohin man gemountet hat. Nur muß man hier eben nicht mit dem Offset für den Pseudo-Header arbeiten - damit funktioniert auch wieder das direkte Mounten mit dem BusyBox-Applet. Der einzige Unterschied besteht am Ende im Schritt 3 der Aufzählung oben - der reduziert sich auf das einzelne mount-Kommando (natürlich muß das Verzeichnis für's Mounten existieren, was ggf. weitere Kommandos braucht).

EDIT3:
Die mtd's runter laden und vergleichen, aber die sind doch dann viel größer, als die drauf geladenen Dateien.
Das stört spätestens dann nicht, wenn man einfach die Image-Datei und den Inhalt der Partition mittels cmp vergleicht - die kürzere der beiden "Dateien" bestimmt die Länge des Vergleichs und beim EOF für eine von beiden, während die andere noch Daten liefern würde, gibt es eine entsprechende Meldung.

EDIT4:
2. mit install_inactive_rootfs die Modifizierungen aus modfs einspielen.
Das Skript macht ja auch nichts anderes, als die richtige YAFFS2-Partition zu mounten und dann die filesystem_core.squashfs (oder die als erster Parameter spezifizierte Datei) dorthin zu kopieren. Wenn man das also zusammen mit dem Kopieren der anderen Dateien in die YAFFS2-Partition verwenden will, muß man das Ziel zuvor erst wieder dismounten, weil das Skript dieses ja selbst machen möchte. Da ist es ggf. dann wieder einfacher, nur die passende Datei selbst von Hand (und zwar wieder mittels cp) in die ohnehin noch gemountete Zielpartition zu kopieren und auf dieses Skript komplett zu verzichten.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
Danke für die ausgiebige Erklärung.
Ich lerne ja jeden Tag neue Befehle dazu. Letztens tichksum und diesmal losetup

Für die 7412 sind also folgende Befehle nötig:

1. Ermitteln und Notieren der Namen der Partitionen (Ziel sind die "reserved"-Partitionen)
cat /proc/mtd
# mtd0: "reserved-kernel"
# mtd1: "reserved-filesystem"

2. kernel updaten
# kernel.image-ohne-Prüfsumme nach /var/tmp/kernel.bin kopieren
update_kernel -i /var/tmp/kernel.bin -o /dev/mtd0
rm /var/tmp/kernel.bin
# wichtig, denn auf der 7412 wird jedes freie MByte gebraucht, besonders für die nächste große Datei

3. Mounten des "ext2"-Images aus der "filesystem.image"
Variante A:

# filesystem.image-mit-Prüfsumme? nach /var/tmp/filesystem.image kopieren
losetup -o 256 -r -f /var/tmp/filesystem.image <--- geht nicht, siehe Fragen
losetup -a # /dev/loopX auslesen
mkdir /var/source
mount /dev/loopX /var/source

#zum löschen:
losetup -d /dev/loopX

ODER
Variante B:
### die nehme ich ###
# filesystem.image-mit-Prüfsumme? nach /var/tmp/filesystem.image kopieren
mkdir /var/source
/var/media/ftp/mount -o offset=256 -r /var/tmp/filesystem.image /var/source

ODER
Variante C:
# vorher auf einer FB mit mehr RAM den "Pseudo-Header" entfernen
dd if=/var/tmp/filesystem.image of=/var/tmp/fsimage.ext2 bs=256 skip=1 conv=sync
# fsimage.ext2 nach /var/tmp/fsimage.ext2 kopieren
mkdir /var/source
/var/media/ftp/mount -r /var/tmp/fsimage.ext2 /var/source

4. Mounten der Zielpartition
# erst löschen
update_kernel -o /dev/mtd1
# dann mounten
mkdir /var/target # fehlte noch
mount -t yaffs2 /dev/mtdblock1 /var/target

5a. Kopieren aller Dateien aus dem "ext2"-Image in die Zielpartition - ggf. ohne die "filesystem_core.squashfs", wenn man die ohnehin ersetzen will
tar -c -C /var/source --exclude filesystem_core.squashfs . | tar -x -C /var/target

5b. Kopieren von "filesystem_core.squashfs"
# filesystem.modfs nach /var/tmp/filesystem_core.squashfs kopieren
cp /var/tmp/filesystem_core.squashfs /var/target

5c. Dismounten der Quellpartition
### Kann eventuell entfallen, da bald ein reboot gemacht wird ###
umount /var/source
rmdir /var/source
rm /var/tmp/filesystem.image
### der Speicher wird aber nicht wieder frei angezeigt bei free ???
### gab es da einen Befehl um den Cache zu löschen?

6. Dismounten der Zielpartition (da ist das "sync" zum "echten Schreiben" dann eingeschlossen)
umount /var/target

7. Änderung von "linux_fs_start"
echo linux_fs_start 1 > /proc/sys/urlader/environment
reboot


Folgende Fragen ergaben sich:
(das ist hier tatsächlich "mtd1" (EDIT: für linux_fs_start=0)
Bei mir ist aber linux_fs_start=1 und trotzdem ist mtd1 - "resserved-filesystem"
und die Warnung davor, gilt eben nur für EVA
??? Im CLI ist doch bei der 7530 auch mtd1 der urlader..

Warum geht das nicht? Ja, ich mache es zum Test auf der 7580
EDIT: selber gefunden, es mußte bei der 7580-07.12 (aus mir unerklärlichen Gründen) unbedingt das losetup von der busybox v1.31.0 sein, v1.24.2, v1.26.2 und v1.28.1 gingen nicht
Code:
7580# losetup -o 256 -r -f /var/tmp/filesystem.image
losetup: /var/tmp/filesystem.image: No such file or directory
7580# ls -l /var/tmp/file*
-rw-r--r--    1 root     root      17817608 Aug 21  2019 /var/tmp/filesystem.image
7580# losetup
BusyBox v1.26.2 (2017-01-10 16:11:14 UTC) multi-call binary.

Usage: losetup [-r] [-o OFS] {-f|LOOPDEV} FILE - associate loop devices
        losetup -d LOOPDEV - disassociate
        losetup -a - show status
        losetup -f - show next free loop device

        -o OFS  Start OFS bytes into FILE
        -r      Read-only
        -f      Show/use next free loop device


Zusatzfrage, da das losetup jetzt läuft:
Kann ich nicht das losetup und mount ohne -r (Read-only) machen?
Dann kann ich nach dem mounten die filesystem_core.squashfs löschen und durch die von modfs ersetzen.
Und dann gleich alles mit einmal kopieren
Geht das?
EDIT: das Löschen geht noch, aber das Ersetzen geht bei mir nicht, da meine modfs-Datei größer ist (ich packe da immer noch einige binarys mit rein, da der ftp bei der 7412 so klein ist und im filesystem noch genug Platz ist).
Aber ich könnte es löschen und danach mit cp -a alles kopieren.
Geht das?

2. Zusatzfrage:
Ich kann vor dem umount schon losetup -d machen und auch /var/tmp/filesystem.image löschen und sehe dann immer noch alles in /var/source. Ich hatte da eigentlich eine Fehlermeldung erwartet ala:
geht nicht, da noch gemountet
Was ist das dann für ein Zustand?
EDIT: Auch selber gefunden: Es wird selber ein LOOP-Device erzeugt.
 
Zuletzt bearbeitet:

Insti

Mitglied
Mitglied seit
19 Aug 2016
Beiträge
391
Punkte für Reaktionen
29
Punkte
28
Möchte mal die 7590 Firmware auf die 7580 installieren mit Änderungen wie in #101 beschrieben. Könnte bitte jemand bei der 7590 /proc/sys/urlader/environment auslesen und zur Verfügung stellen?
Danke schonmal.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Möchte mal die 7590 Firmware auf die 7580 installieren mit Änderungen wie in #101 beschrieben.
Inzwischen ist der - nachdem ich einen unnützen Beitrag gelöscht habe - um einen nach vorne gerutscht und nunmehr #100.

Ein Environment einer 7590 findet man hier auch mehr als einmal - man muß nur (richtig) suchen: https://www.google.com/search?q=site:ip-phone-forum.de+7590+environment

Aber das macht die Idee an sich auch nicht besser (sie bleibt furchtbar) ... denn das ist ein einziges Durcheinander, was dabei entsteht bzw. entstehen würde, weil die Firmware das - unabsichtlich - auch gleich wieder korrigiert.

Denn es ist ja nicht so, daß es die von Dir geänderte Anweisung: CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader nur ein einziges Mal in der Firmware - und zwar in der rc.conf - geben würde, wie ein einziger Blick in die (entpackte) Firmware verrät (ich nehme hier einfach mal die 07.14 für die 7530):
Rich (BBCode):
vidar:/home/FritzBox/FB7530/07.14 $ grep -r CONFIG_ENVIRONMENT_PATH
etc/profile:    if [ -e $CONFIG_ENVIRONMENT_PATH/environment ] ; then
etc/init.d/S01-head:export CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/S01-head:fw_info=`grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment`
etc/init.d/S01-head:p_test=`cat $CONFIG_ENVIRONMENT_PATH/environment | grep 'ptest'`
etc/init.d/S01-head:echo firmware_info `/etc/version` >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/S01-head:cat $CONFIG_ENVIRONMENT_PATH/environment >/var/env
etc/init.d/S42-ptest:export CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/S42-ptest:PTEST=`cat $CONFIG_ENVIRONMENT_PATH/environment | grep ptest | tr , ' '`
etc/init.d/S42-ptest:echo "ptest ${PTEST#ptest}" >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/S42-ptest:echo "ptest dectmode=${DECT_MODE}" >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/S42-ptest:echo "ptest " >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/S42-ptest:### echo "kernel_args " >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/rc.net:if [ "$CONFIG_ENVIRONMENT_PATH" ] ; then
etc/init.d/rc.net:   URLADERENVFILE=$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/E03-flash_update:CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/E03-flash_update:fw_info_ptest=`grep ptest $CONFIG_ENVIRONMENT_PATH/environment | tr , ' '`
etc/init.d/E03-flash_update:echo "ptest " > $CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/E03-flash_update:fw_info=`grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment`
etc/init.d/E03-flash_update:echo "firmware_info ${fw_info_new}" >$CONFIG_ENVIRONMENT_PATH/environment
etc/init.d/E03-flash_update:grep maca $CONFIG_ENVIRONMENT_PATH/environment > ${result_file}
etc/init.d/E03-flash_update:grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment >> ${result_file}
etc/init.d/rc.conf:CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/rc.conf:cat $CONFIG_ENVIRONMENT_PATH/environment >/var/env
etc/init.d/rc.conf:export CONFIG_ENVIRONMENT_PATH
etc/init.d/rc.conf:OEM_tmp=`cat $CONFIG_ENVIRONMENT_PATH/firmware_version`
etc/init.d/rc.conf:export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` ; # annex aus /proc nehmen, nicht von Config!
etc/init.d/rc.conf:export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` # annex aus /proc nehmen, nicht von Config!
bin/setfactorydefaults:echo country >$CONFIG_ENVIRONMENT_PATH/environment
bin/setfactorydefaults:echo language >$CONFIG_ENVIRONMENT_PATH/environment
bin/setfactorydefaults:fw_info=`grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment`
bin/setfactorydefaults:echo "$fw_info,recovered=3" >$CONFIG_ENVIRONMENT_PATH/environment
usr/bin/setcountry:            echo country $1 >$CONFIG_ENVIRONMENT_PATH/environment
usr/bin/setlanguage:    echo language $1 >$CONFIG_ENVIRONMENT_PATH/environment
Da wird also noch deutlich öfter diese Variable auf den richtigen Wert gesetzt und wie man auch sehen kann, gibt es offenbar in keinem Binary (und in keiner Library) eine Zeichenkette dieses Namens - damit darf man davon ausgehen, daß alle Zugriffe, die nicht aus irgendwelchen Shell-Skripten erfolgen, auch weiterhin auf das "richtige" Verzeichnis im "procfs" oder sogar direkt auf den TFFS-Treiber zugreifen, was auch die Suche nach "proc/sys/urlader" schnell zeigt:
Rich (BBCode):
vidar:/home/FritzBox/FB7530/07.14 $ grep -r "proc/sys/urlader"
Binary file sbin/wland matches
Binary file lib/libcmapi.so.1.0.0 matches
Binary file lib/libwland_hal.so.1.0.0 matches
Binary file lib/libavmcsock.so.2.0.0 matches
etc/check_reboot_for_update.sh:REBOOT_FOR_UPDATE=`cat /proc/sys/urlader/reboot_status`
etc/init.d/S01-head:export CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/S42-ptest:export CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/rc.net:elif [ -f /proc/sys/urlader/environment ] ; then
etc/init.d/rc.net:   URLADERENVFILE=/proc/sys/urlader/environment
etc/init.d/E03-flash_update:CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
etc/init.d/rc.conf:CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
bin/supportdata:cat /proc/sys/urlader/environment | sed "s/^wlan_key.*/wlan_key SECRET/" | sed "s/^tr069_passphrase.*/tr069_passphrase SECRET/" | sed "s/^webgui_pass.*/webgui_pass SECRET/"
bin/supportdata:echo -e "reset_status"=`cat /proc/sys/urlader/reboot_status`
bin/supportdata.argo:cat /proc/sys/urlader/environment | sed "s/^wlan_key.*/wlan_key SECRET/" | sed "s/^wlan_ssid.*/wlan_ssid SECRET/" | sed "s/^tr069_serial.*/tr069_serial SECRET/" | sed "s/^tr069_passphrase.*/tr069_passphrase SECRET/" | sed "s/^webgui_pass.*/webgui_pass SECRET/" | sed -e 's/\([0-9A-F][0-9A-F]:[0-9A-F][0-9A-F]:[0-9A-F][0-9A-F]\):[0-9A-F][0-9A-F]:[0-9A-F][0-9A-F]:[0-9A-F][0-9A-F]/\1:SECRET/'
bin/supportdata.argo:echo -e "reset_status"=`cat /proc/sys/urlader/reboot_status`
Binary file usr/bin/tr069fwupdate matches
Binary file usr/www/cgi-bin/firmwarecfg matches
Die Binärdateien sind also von einer Änderung in der rc.conf in diesem Punkt ohnehin nicht zu beeindrucken - und da entsteht dann auch das Chaos, was durch die Tatsache, daß ein Environment, was man direkt in das SquashFS-Image einpacken läßt, eben auch keine Schreibzugriffe mehr erlaubt, nur noch vergrößert wird.

Denn die sind bei einigen Variablen durchaus noch notwendig und auch wenn z.B. die /var/install aus einem originalen AVM-Image am Ende ohnehin wieder (dank des Exports in der S42-ptest) mit dem richtigen Pfad arbeiten würde (und man die bei geänderter Firmware ohnehin nicht braucht bzw. haben will, weil sie ja i.d.R. eine "originale" Firmware ohne eigene Modifikationen installiert), würde diese zumindest versuchen, das linux_fs_start am richtigen Ort zu ändern.

Glücklicherweise macht das mein BM auch, denn der hat für diesen Pfad eine eigene Konstante: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L96 - und hätte er die nicht und würde die Änderung an der Variablen sich tatsächlich durchsetzen können, anstatt durch die S42-ptest wieder ausgebremst zu werden, würde der BM auch nicht mehr funktionieren. Denn der Schreibzugriff zur Umschaltung von linux_fs_start muß natürlich am Ende im TFFS landen - nur dort hat ein neuer Wert dann auch Auswirkungen darauf, welches System der Bootloader beim nächsten Start auswählt.

Ein großer Teil der Firmware greift also auch nach der Idee aus #100 noch auf die "richtigen Werte" zu - anderes hat man hingegen mit so einer Änderung total verkorkst. So dürfte (rein aus dem Verfolgen der Abläufe) das Setzen der Sprache oder der Ländereinstellung (über /usr/bin/setlanguage bzw. /usr/bin/setcountry) oder auch das Löschen des NAS-Speichers beim Zurücksetzen auf die Werkseinstellungen (in /bin/setfactorydefaults) nicht länger funktionieren, da diese tatsächlich die (geänderte) rc.conf benutzen würden (per source (bzw. mit dem dot-Kommando für "include") und ich da nichts gelesen habe, daß/wie jemand dann /etc/urlader beschreibbar gemacht hätte bzw. wie er das machen würde.

Das endet also in einem einzigen Chaos, weil verschiedene Teile der Firmware die Informationen von verschiedenen Stellen lesen (wo diese dann ggf. auch noch unterschiedlich sind) und wenn das auch in einigen Aspekten funktionieren mag oder die Probleme sich bei bisher angestellten Tests (so es sie gab) noch nicht zeigten, so stellen sie sich doch - früher oder später - absehbar ein.

Wer so etwas tatsächlich machen will/muß, der sollte dann dafür sorgen, daß (unabhängig von den Nachteilen ständiger Schreibzugriffe auf den Flash-Speicher für das TFFS) gleich am Beginn die Werte im "procfs" passend überschrieben werden (selbst wenn das nicht persistent ist und einige Änderungen den Neustart damit nicht überleben) - denn dann werden sie auch von den anderen Teilen der Firmware (selbst von denen, die direkt auf den TFFS-Treiber zugreifen) wieder richtig ausgelesen. Nur die Zugriffe auf den FDT (über /proc/device-tree/chosen) sind davon unbeeinflußt - die gibt es bei AVM aber eigentlich auch nicht, wie man leicht feststellen kann:
Rich (BBCode):
vidar:/home/FritzBox/FB7530/07.14 $ grep -r "device-tree"
vidar:/home/FritzBox/FB7530/07.14 $
Es ist also - ich schreib's mal so deutlich - ziemlicher Blödsinn, meinen alten Vorschlag zum Ändern des Brandings über das export OEM jetzt einfach - ohne jede weitere Kenntnis von den Zusammenhängen in der Firmware - dahingehend zu erweitern, das alles auf diesem Wege "zu ändern".

Denn selbst das Ändern von OEM ist eigentlich kein "Königsweg" ... es gibt (mittlerweile oder schon immer, das weiß ich gar nicht mehr) immer noch Punkte, wo aus anderen (binären) Dateien weiterhin auf das originale firmware_version im Environment zugegriffen wird oder zumindest zugegriffen werden könnte. Auch für diese Stellen wäre das Schreiben des gewünschten Wertes bei jedem Start "sinnvoll" - der Nachteil sind dann entsprechend viele Schreibzugriffe, wobei sich das mittlerweile auch relativiert, wenn man das Schreiben von Statistiken durch das FRITZ!OS damit vergleicht.

Nur war das für den Zweck des "Debrandings" halt nicht erforderlich ... da ging es i.d.R. nur darum, im GUI passende Anzeigen und Bilder zu haben und die Funktionen, die von denen bei firmware_version=avm abweichen, wieder auf das "Original" zu setzen. All das konnte man i.d.R. mit diesem export OEM schon erreichen (erwiesenermaßen) - da machten die u.U. verbleibenden Zugriffe (in erster Linie bei den ISDN/POTS- und DECT-Funktionen und mittlerweile auch beim Mesh) nichts weiter aus.

Aber das jetzt zu verallgemeinern, ist Unsinn - das geht deutlich besser auf anderen Wegen und das "Einkompilieren" eines konkreten Environments in das eigene Image, macht letztlich alles das "kaputt", was bei AVM ja genau dazu dient, die Firmware eben nicht für jedes spezielle Gerät zu "paketieren", sondern eine Firmware für alle Geräte zu haben, die sich die "gerätespezifischen Information" aus einem Speicher ebendieses Gerätes zur Laufzeit besorgt. Selbst wenn man also der Ansicht wäre, man würde diese "Vorgaben" des Herstellers lieber zur Laufzeit selbst setzen, gäbe es noch jede Menge weitaus besserer Wege, wie man das umsetzen könnte. Einer davon wäre z.B. ein "alternatives Environment" in einem TFFS-Node mit einer ID < 100 (damit er beim Zurücksetzen auf die Werkseinstellungen in Ruhe gelassen wird), aus dem man dann - sehr früh im Startprozess, am besten gleich an erster Stelle - die gewünschten Werte ausliest, sie mit den vorhandenen vergleicht und die abweichenden ändert. Damit hat man dann sowohl die Werte, die sich persistent ändern lassen, als auch diejenigen, die immer wieder zurückgesetzt werden, erfaßt und erstere würden - dank des Vergleichs - nicht ständig neu geschrieben.

DAS wäre dann mal eine sinnvolle (und nach meiner Erfahrung auch funktionierende) Erweiterung der AVM-Firmware - die Idee, das Environment fest in das eigene Image zu integrieren, finde ich dagegen furchtbar. Spätestens wenn man zwei Geräte (aus derselben Modellreihe) hat, ist das dann doppelte Arbeit, die linear mit der Anzahl der Geräte steigt und praktisch bei jeder neuen Version erneut in Angriff zu nehmen wäre. Zwar gilt das mit dem "bei jeder neuen Version erneut" auch für meinen Vorschlag, aber das reduziert sich im besten Falle wieder auf das Hinzufügen einer einzelnen Datei zur Firmware, die vom Startprozess an der richtigen Stelle aufgerufen wird - und das ist dann für jede Version dasselbe und man muß auch das Image für jede Version nur einmal anpassen und nicht für jedes Gerät erneut.

===========================================================================

Und zur Absicht, die 7580 mit der 7590-Firmware als Alien zu betreiben ... ich habe es zwar nicht wirklich intensiv probiert, bin aber bei einigen - mehr nebenbei betriebenen - Versuchen Anfang Januar (als die 7580 keine Labor-Version kriegte) damit nicht so weitergekommen, daß ich das nun unbedingt weiter verfolgen/betreiben wollte. Das geht schon mit der anderen Hardware für die Ansteuerung der LEDs los ... und die GRX-Boxen werden eben auch nicht mehr nur über das "Urlader-Environment" gesteuert. Die haben ihren "flattened device tree" für die Hardware, der vom Bootloader zusammengestellt und an den Kernel übergeben wird - da spielt das TFFS nur noch eine Nebenrolle beim Zusammenstellen der Werte (unterhalb von "chosen").

Ich habe hier immerhin eine 7580, die mit einem USB-Serial-Adapter bestückt ist und wo ich die 7590-Firmware ins RAM laden und dort starten kann (was man als Erstes mal machen sollte und sie nicht gleich in den Flash-Speicher installieren) ... ich müßte jetzt die alten Protokolle erst raussuchen, aber wenn ich mich richtig erinnere, kam der Kernel nicht mal bis zum Laden des Root-FS und das wäre noch ein Zeitpunkt, wo das TFFS mit dem Urlader-Environment und darin ggf. vorzunehmende Änderungen noch gar keine (wirkliche) Rolle spielen.

Solange man sich nicht mit dem Kernel etwas intensiver beschäftigt hat (und u.a. auch mit dem "avm_kernel_config"-Bereich und seinem Inhalt), sollte man auch nicht die Kernel für verschiedene OS-Versionen mixen, selbst wenn diese ggf. auf derselben Version des Vanilla-Kernels beruhen - AVM ändert auch an den eigenen "Zugaben" bei den Treibern oft genug zwischen zwei FRITZ!OS-Versionen, so daß ein Betrieb eines Kernels mit dem Dateisystem einer anderen Version eher zufällig funktionieren würde.

Damit stünde man also ohnehin vor der Aufgabe, den 7590-Kernel auf der 7580 zum Laufen zu bringen ... ich habe es - wie gesagt - noch nicht wirklich intensiv probiert, aber der tumbe Versuch, ihn ins RAM zu laden und zu starten, schlug schon mal (damals zumindest) fehl bei mir.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
Und zur Absicht, die 7580 mit der 7590-Firmware als Alien zu betreiben
Ergänzend dazu von NDiIPP:
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Offenbar bin ich mal wieder jemandem auf die Zehen getreten, als ich es wagte, eine "schlechte Idee" als "ziemlichen Blödsinn" zu charakterisieren. Nach vorhergehenden Versuchen, die Variablen aus dem Urlader-Environment in der rc.conf per export zu überschreiben - und zwar mit den Namen, die sie im TFFS haben - war das schon die zweite Stelle, wo vollkommen falsche und unzulässige Abstraktionen aus den Ideen/Vorschlägen anderer abgeleitet wurden - bei der ersten wurde noch bis aufs Messer gestritten (nicht mit mir, aber ich habe das ja trotzdem gelesen), daß das (offensichtlich) genauso funktionieren würde und alle möglichen (imho auch falschen) Beweise dafür angeführt.

Nachdem nun aber die zweite Idee - und für mich ohne jede Verifikation, was das am Ende tatsächlich bewirkt bzw. was die Nebenwirkungen davon sind - auch gleich noch als Vorschlag in einen gepinnten Thread gewandert ist (https://www.ip-phone-forum.de/threads/anleitung-zum-Ändern-des-branding-bei-fritzbox-auch-für-daus.203652/post-2375329) und dort auch noch Beifall bekam, muß man einfach etwas dazu sagen (bevor es ein anderer nachmacht, ohne die Nebenwirkungen zu kennen) ... und wenn die "Arbeitsweise" die notwendige Gründlichkeit vermissen läßt, bevor man mit solchen Behauptungen "an die Öffentlichkeit" geht, gefährdet man eben nicht länger nur die eigenen Geräte, sondern auch die von anderen. Daß man sich dagegen dann wendet und die Schwachstellen so einer Lösung aufzeigt - notfalls auch mit drastischen Worten, wobei "ziemlicher Blödsinn" in meinen Augen noch lange kein Tort ist (EDIT: ich empfehle mal die boardeigene Suche danach) -, versteht sich für mich von selbst.

Ich weiß ja nicht, wie zartbesaitet hier mancher ist ... aber aus dem Alter, wo das Bild für die Mutti, selbst wenn's noch so erschreckend war und eher verstörend auf andere wirkte, automatisch am Kühlschrank landen mußte, sollten alle mittlerweile raus sein.

Ich weiß nicht, wie - bzw. eigentlich auch nicht warum - man eine wirklich schlechte Idee (und meine Ansicht, warum das so ist, belege ich ja auch noch und stelle sie nicht nur so in den Raum) nun irgendwie noch "gut" finden sollte, nur damit derjenige, der sie hatte (und hier ja offenbar auch andere zum Mitmachen "anstiften" wollte, mithin nicht nur eigenen Schaden davontragen kann, wenn's schlecht läuft), sich am Ende besser fühlt.

Auch wenn man nur einen Hammer haben mag, ist nicht alles am Ende ein Nagel ... wer sich einen Weg erarbeitet hat, kann nicht automatisch davon ausgehen, daß er damit auch andere kennt. Wer tatsächlich neue Ideen hat und diese mit anderen teilen will - gar kein Problem, das findet hier immer Beifall. Voraussetzung ist aber, daß das Geschriebene auch Hand und Fuß hat - ansonsten sollte man eben immer erst mal die Meinung von anderen (und nicht wieder unterstellen, ich meinte hier nur mich selbst) einholen, bevor man das zum Nachmachen empfiehlt. Schließlich können spätere Leser die Expertise, die hinter solchen Vorschlägen steht, nicht immer auf Anhieb einordnen und wenn jemand anderen solche "schlechten Vorschläge" (besser?) unterbreitet, muß er auch damit leben können, wenn jemand (begründete) Kritik daran äußert und damit auch weitere Leser vor dem Nachahmen warnt.

Bestes Beispiel für "zu kurz greifende Anleitungen" ist für mich immer wieder das bekannte YT-Video, in dem jemand zeigt, daß es doch ganz simpel ist, eine 6490 zu "entbranden" ... die Kommentare all derjenigen, bei denen das so eben nicht klappen konnte (weil der Autor nicht ausreichend Ahnung hatte, was es alles so gibt und auch die Besonderheiten, die vorliegen müssen, damit seine Anleitung funktioniert, nicht mit einem Wort erwähnte), sprechen für sich.

Bisher war das IPPF eigentlich immer ein Platz, wo man funktionierende Tipps kriegen konnte ... und ich würde gerne meinen Teil dazu beitragen, daß das auch so bleibt. Wenn ich dazu anderen auf die Füße treten muß (und absichtliche Beleidigungen sähen ganz anders aus und wären auch unmittelbar als solche zu erkennen), dann hält mich das auch nicht davon ab. Wenn hier jemand Kritik einstecken muß in der Sache, dann ist daran nicht das Board oder die hier Aktiven schuld ... und das IPPF ist auch kein Ponyschlecken.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
So, ehe mir noch mehr blöde Fragen einfallen, sage ich mal, daß ich mit #105 jetzt fertig bin.
Ja, es hat etwas länger gedauert, aber ich habe auch nicht immer die Muse mich mit solchen "abstrakten" Dingen zu beschäftigen.

Bitte schau noch mal drüber, ob alles richtig ist.

Hast du es schon mal probiert das mit den activen mtd's zu machen?
Stürzt da die FB sofort ab?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Ich habe keine "eingeübten" Namen für irgendwelche Dateien und wenn, wäre es vermutlich die Namen, die AVM auch verwendet im TAR-File.

Nur gibt es eben Situationen, wo es absehbar ist, daß man eine Datei mit einem bestimmten Namen noch ein oder zwei Male umformen muß ... dann brauchen die auch andere Namen. Ich habe solche "Beispiele" auch nicht publikationsreif in der Schublade, die werden "in-time" eingetippt und ausgeführt (man sieht's manchmal am Datum einer Datei in einer Liste) und dann in einen Beitrag übernommen.

Das letzte, worüber ich dabei nachdenke, sind die Namen der verwendeten Dateien ... und solange jeweils die "Herkunft" einer Datei auch noch aus dem Kontext des Code-Blocks ersichtlich ist, gehört das Verfolgen dieser Beziehungen für mich zum Verständnis des Gelesenen. Bitte nicht als Ausrede nehmen ... ist einfach so.

Es gibt eben keine "offizielle Dateierweiterung" (wenn man mal unterstellt, daß das "Brauch" wäre, Dateien entsprechend zu kennzeichnen für den Menschen und nicht nur, damit der richtige Interpreter verwendet wird) für Images des Linux-Kernels, weder mit noch ohne Prüfsumme. Es gibt noch nicht einmal irgendwelche einheitlichen Endungen, wenn das ein (originales) gepacktes File wäre - daher gibt es auch irgendwo eine "vmlinuz", die eigentlich mal eine "vmlinux.gz" war bzw. es dem Inhalt nach meist noch ist, wenn tatsächlich "deflate" verwendet wurde.

Und ob ich ein SquashFS-Image jetzt ".img" oder ".image" oder ".sqfs" nenne oder ".squashfs", wie AVM es (für das Root-FS bei VR9) macht, spielt doch eben auch absolut keine Rolle. Das hat mit dem Sinnzusammenhang des Erläuterten genauso viel zu tun wie die Frage, ob der Beitrag an einem Montag oder einem Donnerstag geschrieben wurde.

Auch ist die Verwendung der "Methoden" für das Kopieren von Dateien eben keine "Vorgabe" meinerseits, sondern nur ein Beispiel - wenn ich ein "dd" mal mit einer Blockgröße von 8 Byte betreibe (#5) und mal mit nur einem einzigen Block (in der Größe der gesamten Datei, vorausgesetzt meine Plattform hat genug Hauptspeicher für so große I/O-Buffer), dann muß ich natürlich auch die Blockanzahl passend berechnen (lassen(!), denn man kann das natürlich auch "ablesen" und von Hand berechnen - oder im Kopf ... nur paßt es dann bei der nächsten Firmware garantiert schon wieder nicht).

Letztlich hast Du dann auch #104 wohl falsch verstanden (mal abgesehen davon, daß in #105 noch Teile stehen, die ich beim ersten Lesen noch nicht sah und jetzt erst mal selbst lesen muß) - denn das, was Du da feststellst, ist genau eine Illustration dessen, was ich weiter oben in diesem Beitrag schrieb ... wo es "eindeutig" ist, verwende ich auch die Namen aus der "originalen Firmware" (und wie oft ich mittlerweile schon [ICODE]kernel.image[/ICODE] und [ICODE]filesystem.image[/ICODE] eingetippt habe, zähle ich lieber nicht) und genau ein solcher ist das kernel.image nun mal.

Die Schlußfolgerung, daß das ein Kernel ohne Prüfsumme sein müsse, ist absolut falsch und - angesichts der Tatsache, daß ich das noch einmal deutlich mit dem ersten "EDIT" herausgestellt hatte (zumindest dachte ich das und Du hast ja sogar geschrieben, daß Dich diese "Ergänzung" auch erreicht hätte bzw. Du ohnehin erst später liest) - auch überraschend. Wenn da eine Prüfsumme am Kernel hängt, ist sie eben da ... solange diese acht Byte nicht dazu führen, daß das Image jetzt zu groß für die Partition wird, juckt das niemanden.

Letztlich rührt dieser "Nicht-Vorwurf" (ich habe das also auch nicht so verstanden, ich nehme das eher als Aufforderung zur "Erklärung") vielleicht auch aus dem Mißverständnis, was ich meinerseits beabsichtige zu leisten - das sind eben keine "Rezepte" (#5 war da als "Batch" tatsächlich eine der ganz, ganz wenigen Ausnahmen, wie man leicht feststellen kann, wenn man meine bisherigen Beiträge liest :cool: ) zum Nachkochen, das sind immer nur Beispiele, die etwas illustrieren sollen und die setzen tatsächlich ein Mitdenken voraus (was ich auch keinem absprechen will, also auch mich bitte nicht falsch verstehen).

Denn was da eigentlich passiert, erläutere ich ja i.d.R. davor oder dahinter auch noch - auch wenn es schon mal vorkommt, daß ich irgendeine "Kontrolle" (z.B. eben einen Aufruf von cmp oder hexdump) nicht haarklein erläutere. Aber auch da gehe ich eben davon aus, daß sich der Leser bei einem unbekannten Kommando selbst informiert (dafür gibt es Suchmaschinen) und wenn es sich tatsächlich mal um ein Kommando oder einen Patch aus einer nicht ganz so einfach zu findenden Quelle handelt, gibt es bei mir i.d.R. auch den passenden Link zu dieser Quelle im Text.

Ich bin mir da also irgendwie auch keiner "Schuld" bewußt, daß ich irgendetwas auslassen oder einen Leser (gezielt) überfordern würde - nur ist das Modifizieren der Firmware eben auch kein Kindergarten und noch nicht mal Grundschule ... so etwas, wie "selbständiges Erarbeiten eines Themas anhand von (Sach-)Literatur" auf dem Gymnasium, sollte/muß man halt beherrschen, wenn man sich da heranwagen will.

Jeder, der da aussteigt, wäre halt "not my audience" und das ist - wenn man es genau überlegt - auch kein Beinbruch. Weder für mich, noch für ihn/sie - dann war das Thema vermutlich ohnehin nicht geeignet und es wurde wieder die eine oder andere unschuldige FRITZ!Box vor einem zu frühen Gang zum Schafott auf dem Wertstoffhof gerettet. Ich habe gar nicht den Anspruch (weder an mich, noch an diejenigen, die das lesen), damit bei allen "gut anzukommen" - ich bin bereit, Zusammenhänge (im Rahmen meiner Möglichkeiten) zu erläutern (so ich sie kenne und glaube verstanden zu haben), wenn es jemanden interessiert. Wenn nicht, kann ich damit auch leben ... siehe Signatur (und das steht da schon lange).
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
Schade, du hast es nun doch in die falsche Kehle bekommen.
Ich wollte nur erläutern, wo ich so meine Schwierigkeiten habe. und warum es deshalb manchmal länger dauert.

OK, ich lösche es wieder.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Schade, du hast es doch in die falsche Kehle bekommen.
Nein, habe ich nicht. Ich hätte Dir auch schreiben können, daß das pure Absicht ist, um die Leser zum Mitdenken "zu zwingen" - das wäre aber glatt gelogen gewesen. Ich habe mir darüber bisher nie wirklich Gedanken gemacht und selbst wenn ich das - nach Deinen Bemerkungen - jetzt tue, sehe ich keinen wirklich plausiblen Grund, das in der Zukunft zu ändern.

Es gibt keine einheitliche Benennung für solche Fälle/Beispiele und ich kann/werde da auch keinen "Standard" setzen - denn wenn ich es mir tatsächlich mal überlege, wo die Vor- und die Nachteile derartiger "Anstrengungen" liegen würden, sehe ich die Nachteile überwiegen (ich muß mehr denken beim Verfassen, das verlagere ich - nachvollziehbar? - lieber auf den/die Leser*innen) und letztlich fördert dieses "uneinheitliche Vorgehen" sogar meine eigene Argumentation (die ist auch keinesfalls neu und erst in #111 "erfunden"), daß ich keine "Anleitungen" veröffentliche, sondern Hilfen zur Selbsthilfe.

Der Nächste hat dann damit Probleme, wenn ich ein Image für die 7490 als "7490.image" benenne, obwohl er/sie das Ganze doch anhand einer 3490 nachmachen will und da paßt ja dann dieser Name überhaupt nicht zu seinem/ihrem Vorhaben - das kann doch nicht wirklich das Ziel sein.

Nochmal deutlich ... ich habe darüber bisher nicht nachgedacht und wenn ich es jetzt - auf Deine Anregung hin - tue, sehe ich mehr Gründe, die dagegen sprechen würden, als dafür, daß man sich hier eine "einheitliche Benennung" von Dateien zulegt.

Das heißt nicht, daß man die Namen "mutwillig" durcheinanderwerfen muß - wenn ich beim Extrahieren eines Dateisystem-Images aus einer AVM-Firmware die entstehende Datei kurz "avm.image" nenne, ist das reine Faulheit und der Tatsache geschuldet, daß ich die eben tatsächlich einzeln extrahiere (und zwar nach STDOUT) und ihr somit ohnehin einen Namen geben muß ... mache ich das Extrahieren für "alle Dateien" und direkt ins Dateisystem, behält sie halt ihren Namen, den sie von AVM erhalten hat. Nur KANN ich in vielen Beispielen gar nicht nach "/var/tmp/irgendwas" extrahieren lassen ... auf einem "normalen System" ist nämlich "/var" für den durchschnittlichen Benutzer (glücklicherweise) gar nicht beschreibbar - und anstatt dann Orgien mit Pfaden (unterhalb des dafür vorgesehenen temporären Speichers) und dem AVM-Namen "./var/tmp/filesystem.image" zu feiern, nenne ich das eben kurz - und im Kontext unmißverständlich - "avm.image", wenn ich das hinterher noch einige Male in anderen Kommandos verwenden muß.

Das ist auch nur ein weiteres Beispiel dafür, wie/warum ich halt unterschiedliche Namen verwende (was mir gerade so in den Sinn kommt und was m.E. den jeweiligen Inhalt charakterisiert) ... ich würde es noch verstehen, wenn sich jemand "aufregt" (und nein, ich habe das immer noch nicht falsch verstanden, aber irgendwie muß ich Deinen "Kommentar" nun mal nennen und ein von Dir erkanntes "perfektes Chaos" ist nun mal mehr Vorwurf als (neutraler) Kommentar - da macht's dann eben auch die Wortwahl, unabhängig von weiteren "Beschwichtigungen"), wenn ich alle Dateien mit "1.bin" und "2.bin" (usw.) bezeichnen würde und man dann immer erst "zurückblättern" muß, um die Nummer in den richtigen Kontext zu bringen.

Ich kann am Ende auch nichts dafür, daß bei AVM alles ".image" heißt ... angefangen beim TAR-File, bis hin zum Kernel, dem Dateisystem und ggf. auch noch einem Bootloader-Update. Das sind auch alles "Images" mit unterschiedlichen Inhalten und anderem Aufbau ... ich käme trotzdem nicht auf die Idee, mich bei AVM darüber zu beschweren, obwohl es mir bei Beschreibungen häufig zusätzliche Klarstellungen abverlangt, welches "Image" denn da gerade gemeint war/ist.

Bei mir ist aber linux_fs_start=1 und trotzdem ist mtd1 - "resserved-filesystem"
Mein Satz sollte aussagen: "mtd1 ist die Partition für das Dateisystem, wenn 'linux_fs_start' den Wert '0' hat." - vielleicht nicht klar genug formuliert, erscheint mir aber auf Anhieb nicht so beim nochmaligen Lesen.

===================== weiter im Text ======================

EDIT: selber gefunden, es mußte bei der 7580-07.12 (aus mir unerklärlichen Gründen) unbedingt das losetup von der busybox v1.31.0 sein, v1.24.2, v1.26.2 und v1.28.1 gingen nicht
Keine Ahnung, was da schiefläuft bei Dir, bei mir funktioniert die Version 1.27.2 auch auf einer 7580 ohne Probleme (extra auf demselben Gerät getestet - die Box hat eine originale 07.12 von AVM installiert und der Shell-Zugang erfolgt über die Serielle ... die Firmware ist also tatsächlich "original"):
Rich (BBCode):
Please press Enter to activate this console.
starting pid 21454, tty '/dev/ttyLTQ0': '-/bin/sh'


BusyBox v1.24.2 (2019-02-11 19:22:07 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/ttyLTQ0"
Serielles Terminal
disable start/stop characters and flowcontrol
# mount -o remount,exec /var/media/ftp/YourFritz
# /var/media/ftp/YourFritz/bin/busybox --help
BusyBox v1.27.2 (2018-01-25 21:08:38 CET) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  The shell in this build
        is configured to run built-in utilities without $PATH search.
        You don't need to install a link to busybox for each utility.
        To run external program, use full path (/sbin/ip instead of ip).

Currently defined functions:
        [, [[, addgroup, adduser, arp, arping, ash, awk, base64, basename, bbconfig, blkid, blockdev, brctl, bunzip2, bzcat, bzip2,
        cat, chat, chgrp, chmod, chown, chpst, chroot, cksum, clear, cmp, comm, conspy, cp, cpio, crond, crontab, cryptpw, cut,
        date, dd, delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname, dos2unix, dpkg,
        dpkg-deb, du, dumpleases, echo, egrep, env, envdir, envuidgid, ether-wake, expand, expr, factor, fallocate, false, fatattr,
        fdisk, fgconsole, fgrep, find, findfs, flash_eraseall, flash_lock, flash_unlock, flashcp, flock, fold, free, fsck, fsync,
        ftpd, ftpget, ftpput, fuser, getopt, grep, groups, gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid, hostname, httpd,
        i2cdetect, i2cdump, i2cget, i2cset, id, ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, inotifyd, insmod, install,
        iostat, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, ipneigh, iproute, iprule, iptunnel, kill, killall, killall5, klogd, less,
        ln, logger, login, logname, logread, losetup, ls, lsmod, lsof, lspci, lsusb, lzma, makedevs, makemime, md5sum, microcom,
        mkdir, mkdosfs, mkfifo, mkfs.vfat, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more, mount, mountpoint, mpstat, mv,
        nanddump, nandwrite, nbd-client, nc, netstat, nice, nl, nmeter, nohup, nproc, nsenter, nslookup, ntpd, od, openvt,
        partprobe, passwd, paste, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, pmap, poweroff, printenv,
        printf, ps, pscan, pstree, pwd, pwdx, rdate, rdev, readlink, realpath, reboot, reformime, renice, reset, rev, rm, rmdir,
        rmmod, route, rpm, rpm2cpio, run-parts, runsv, runsvdir, rx, sed, sendmail, seq, setconsole, setlogcons, setpriv,
        setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, shuf, slattach, sleep, smemcap, softlimit, sort,
        split, ssl_client, start-stop-daemon, stat, strings, stty, stun-ip, sum, sv, svc, svlogd, swapoff, swapon, switch_root,
        sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch,
        tr, traceroute, traceroute6, true, truncate, tty, tunctl, tune2fs, ubiattach, ubidetach, ubimkvol, ubirename, ubirmvol,
        ubirsvol, ubiupdatevol, udhcpc, udhcpc6, udhcpd, udpsvd, uevent, umount, uname, unexpand, uniq, unix2dos, unlink, unlzma,
        unshare, unxz, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, watch, watchdog, wc, wget, which, whois, xargs, xxd,
        xzcat, yes, zcat, zcip
# /etc/version
153.07.12
# /var/media/ftp/YourFritz/bin/busybox wget http://ftp.avm.de/fritzbox/fritzbox-7412/deutschland/fritz.os/FRITZ.Box_7412-06.86.image -O - -q | tar -x -C / ./var/tmp/filesystem.image
# ls -l /var/tmp/filesystem.image
-rw-r--r--    1 root     root      17817608 Aug 21  2019 /var/tmp/filesystem.image
# /var/media/ftp/YourFritz/bin/busybox losetup -o 256 -r -f /var/tmp/filesystem.image
# /var/media/ftp/YourFritz/bin/busybox losetup -a
/dev/loop0: 256 /var/tmp/filesystem.image
Was will ich damit zeigen? Es mag sein, daß es bei Dir Probleme gab ... diese können auch an der Version liegen. Aber es gibt auch Versionen < 1.31.0, mit denen das problemlos funktioniert - immerhin kann/muß man dieses Vorgehen schon seit 06.36 (Labor vor 06.5x) wählen und da gab es 1.31.0 bei der BusyBox noch gar nicht.

Kann ich nicht das losetup und mount ohne -r (Read-only) machen?
Dann kann ich nach dem mounten die filesystem_core.squashfs löschen und durch die von modfs ersetzen.
Und dann gleich alles mit einmal kopieren
Geht das?
Das ist bei mir Absicht - das kann aber jeder machen, wie er/sie will. Nur ist das "ext2"-Image eben von der Größe her exakt so berechnet (das basiert ja auf einer "Image-Datei" und deren Größe ist so berechnet, daß die Daten da hineinpassen, aber nicht "auf Zuwachs" vorbereitet), daß Schreiboperationen in dieser Datei eher schwierig sind ... abgesehen davon, ist es eben sogar wieder "allgemeiner" nutzbar als "Anleitung" (auch wenn es keine sein will), wenn man YAFFS2-Inhalt und künftiges Root-FS (also die filesystem_core.squashfs) getrennt kopiert.

Denn es ist denkbar, daß man letztere auch einzeln aktualisiert, wenn man etwas ändern will - letztlich ist es ja auch genau das, was install_inactive_rootfs macht (aber ohne die YAFFS2-Partition neu zu formatieren), hier wäre ggf. ein vorheriges Löschen noch angebracht, wenn der Platz für das neue Root-FS nicht noch frei ist, was mit steigender Größe des AVM-Images immer unwahrscheinlicher wurde.

Auch wenn man eigene Zusätze in dieser Partition installiert hat (das "implant_siab"-Zeugs legt die Dateien ja auch in dieser Partition ab), ist es nicht immer schlau, sie neu zu formatieren und letztlich ändert sich der Inhalt - abseits des Root-FS - eben nur dann, wenn man tatsächlich eine neue AVM-Version installieren will (und selbst dann ist das nicht zwingend) ... das ist ähnlich wie beim Kernel.

Es ist also (bei vielen) deutlich öfter notwendig, nur die einzelne Datei in das YAFFS2 zu kopieren, als alle auf einen Schlag - mithin ist es auch nur schwer einzusehen, warum man zuvor die Dateien alle im "ext2"-Image "versammeln" sollte, um sie dann auf einmal zu kopieren. Und selbst wenn man das machen wollte ... dann kopiert man eben die Dateien aus dem gemounteten "ext2"-Image (das gilt natürlich ebenso, wenn das wieder ein SquashFS-Image ist, wobei sich da eben die Frage, ob man da die filesystem_core.squashfs auch hineinkopiert in das Image, gar nicht stellt, weil das per se ein "read-only"-Dateisystem ist) erst einmal an eine andere Stelle (da, wo das neue Root-FS schon liegt - als Beispiel) und von dort dann alles auf einmal in die YAFFS2-Partition.

Aber ich könnte es löschen und danach mit cp -a alles kopieren.
Geht das?
Ja, siehe oben. Aber warum sollte man das machen? Mir fehlen dafür die "Gründe" und wie oben auch schon angemerkt, stellt sich die Frage nach dem Wechsel von AVM auf SquashFS (irgendwann in der 07.19-Reihe) ohnehin nicht mehr für die Boxen, die noch neue Firmware erhalten werden. Das eine ist also eine Vorgehensweise, die nur unter bestimmten Voraussetzungen klappt - der andere Weg ist universeller und funktioniert immer (bei den richtigen Modellen).

Es wird selber ein LOOP-Device erzeugt.
Jein ... das zuvor eingerichtete Loop-Device bleibt erhalten und wird einfach nicht "entladen". Existiert die Datei nicht mehr, klappt auch das "losetup" (weder ex- noch implizit) nicht mehr.

Das sind aber zwei unabhängige "Subsysteme", die hier jeweils den Blick auf die Daten haben ... und das Laden eines Images in ein Loopback-Device "sperrt" nicht den Zugriff von anderen auf die Image-Datei. Auch ein Zugriff über andere Mechanismen bleibt möglich ... so kann man z.B. sogar per dd die Datenblöcke der Image-Datei überschreiben, was natürlich die dort enthaltene Dateisystem-Struktur dann zerstört. Im schlechtesten Falle kommt dann der Kernel zu der Feststellung, daß es einen "fatal I/O error" an dieser Stelle gibt und verfällt in Panik. Daß bei Linux auch konkurrierende Zugriffe auf dieselben Daten über verschiedene Mechanismen möglich sind, ist bekannt und eine der Stärken (oder auch Schwächen, je nach Standpunkt) von Linux (gilt aber für andere OS ebenso).

??? Im CLI ist doch bei der 7530 auch mtd1 der urlader..
Deshalb schreibe ich ja auch, daß der jeweilige Blick ein anderer ist. Und ich glaube auch nicht, daß die Nummerierung bei der 7520/7530 tatsächlich identisch ist im Bootloader und im laufenden System, selbst wenn da die eine oder andere Partition auch mal dieselbe Nummer haben sollte. Oder bei welcher FRITZ!Box hast Du das TFFS im laufenden System schon mal in "mtd3" und "mtd4" gesehen bzw. wo gäbe es denn die Partition "mtdnand", in die bei Boxen mit NAND-TFFS "vom Bootloader" geschrieben wird, wirklich? Das hat nichts miteinander zu tun und was in einer Partition tatsächlich steht und welche Nummer die hat, hängt immer auch davon ab, in welcher Reihenfolge (unter einem Linux-Kernel) diese MTD-Partitionen registriert wurden. Wenn man eine Box aus dem RAM startet, kommen da tatsächlich zwei Partitionen hinzu und da diese "zuerst" angemeldet werden, kriegen sie vom Kernel auch die ersten beiden Indizes.

Hier kann man das mal am Beispiel einer 7590 sehen: https://www.ip-phone-forum.de/threads/freetzen-einer-7590-mit-fw-7-12.306572/post-2369945 (im zweiten Anhang)
Code:
+ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 014ee000 00000200 "rootfs_ram"
mtd1: 00488a00 00000200 "kernel_ram"
mtd2: 00800000 00020000 "kernel"
mtd3: 00100000 00020000 "urlader"
mtd4: 00400000 00020000 "nand-tffs"
mtd5: 00800000 00020000 "reserved-kernel"
mtd6: 1eb00000 00020000 "ubi"
und auch hier wäre es falsch, daraus jetzt die Schlußfolgerung abzuleiten, bei einer 7590 wäre die "urlader"-Partition im laufenden System immer "mtd3". Genau WEIL das so eben nicht funktioniert, gibt es ja die Möglichkeit, den Partitionen Namen zu geben und sie daran zu identifizieren und nicht an ihren Nummern.

Und zum Abschluß noch die Frage, was beim Schreiben in die aktiven Partitionen passiert ... beim Kernel eigentlich nichts, denn der wird normalerweise direkt in den Speicher geladen und entpackt - danach gibt es eigentlich keine Zugriffe mehr auf die entsprechenden Flash-Partitionen (die ohnehin dann wieder "on the fly" die Dekompression ausführen müßten).

Beim Dateisystem ist das etwas komplizierter ... einerseits darf das laufende System dann nicht mehr zu viel aus dem Flash lesen wollen und andererseits muß man ihm i.d.R. noch etwas Zeit lassen, die Daten auch final in den Flash zu schreiben und nicht nur in irgendwelchen internen Puffern zu halten bzw. letztlich auch die Verwaltungsstrukturen für die Partition (beim YAFFS2 auf VR9-Systemen) noch so zu ändern, daß die neuen Daten beim nächsten Start auch genutzt werden. Beim Schreiben mit Journal wird ja erst mit dem letzten Schreibzugriff der neue Zustand dann auch zementiert und die meisten Flash-Dateisysteme arbeiten auch so, weil man dort immer mal mit einem unerwarteten Stromausfall rechnen muß und dann nicht das gesamte Dateisystem geschrottet werden darf.

AVM steht/stand bei den Boxen mit nur einem System im Flash ja vor demselben Problem ... der Neustart unmittelbar im Anschluß ist unumgänglich, aber wie kriegt man das System jetzt dazu, die Schreiboperationen für den Flash-Speicher noch sauber zum Ende zu bringen, ohne weitere Daten von dort lesen zu wollen, weil noch andere Prozesse laufen. Am Ende stammt auch die Vorgehensweise, die Installation der neuen Firmware nicht direkt aus der /var/install zu machen, sondern die dazu notwendigen Kommandos an die /var/post_install anzufügen (bei den meisten Modellen jedenfalls), noch aus der Zeit dieser Systeme ... dieses Skript wird eben erst dann ausgeführt, wenn man das System ohnehin herunterfahren und neu starten will.

Also hat man sich einen Kernel-Treiber gebastelt (ich nehme jedenfalls an, daß die Idee von AVM stammt, ggf. ist sie auch "nur" von irgendjemandem kopiert, der Treiber ist aber aller Voraussicht nach von AVM), den man ziemlich am Ende dieser Datei lädt und der dann die notwendigen Operationen für das Flashen (welche das sind, kriegt er über Parameter "gesagt") ausführt, ohne daß da weitere Prozesse dazwischenfunken können - am Ende startet der wohl auch gleich noch das System neu. Wie man das mittlerweile beim Update der Boxen macht, die ähnlichen Aufbau haben (bei AVM wohl als "non-mirror" gehandelt), weiß ich gar nicht aus dem Stand ... der Installationsprozess beim (Online-)Update einer 4040 sollte da aber Klarheit bringen können.

Man hat also beim direkten Schreiben des Dateisystems das Problem, daß der Schreibprozess noch laufen soll, aber möglichst keine anderen - den "spontanen Neustart" dann hinzulegen, auch ohne weitere "sync"-Aktionen (die bei einem r/o-Dateisystem aber ohnehin nicht erfolgen), ist über "/proc/sysrq-trigger" problemlos möglich. Man braucht nur mal ein "echo b >/proc/sysrq-trigger" auf der Box ausführen und sie startet prompt neu - ohne sich um Nichtigkeiten wie das "richtige Herunterfahren" zu kümmern. Nur muß man eben zu diesem Zeitpunkt bereits dafür gesorgt haben, daß alle Daten auch wirklich geschrieben wurden ... und ein "unterbrechungsfreies Arbeiten" für diesen Schreibprozess paßt nicht so ganz zu einer aktiven Console-Session, erst recht nicht, wenn diese über das Netzwerk abgewickelt wird (was dann ja noch viel mehr Aktivitäten mit sich bringt).

Wenn man das also machen will (und sich der Risiken bewußt ist), dann sollte man zuvor per Skript so ziemlich alles das abräumen, was ansonsten noch läuft ... und man sollte die notwendigen Kommandos in einer einzigen Zeile zusammengefaßt haben bzw. ein Shell-Skript, in dem man sie aufgeführt hat, definitiv im RAM (also im "tmpfs") haben - am besten auch noch die (statisch gelinkte) BusyBox für die Shell-Instanz, in der man das ausführt (damit keine Zugriffe auf das alte SquashFS-Image notwendig werden).

Dann mountet man die aktive Wrapper-Partition als "beschreibbar" (unter /wrapper ist sie "read-only" gemountet, es reicht also ein mount -o remount,rw /wrapper und man muß sich nicht darum kümmern, welche MTD-Partition das nun ist), löscht die alte filesystem_core.squashfs (das sollte funktionieren) und kopiert die neue Datei (auch die sollte schon im "tmpfs" liegen und nicht mehr vom USB-Speicher o.ä. kommen, weil man den am besten zuvor mit prepare_fwupgrade ohnehin schon totgelegt hat) in die Partition. Anschließend noch ein sync hinterher, um event. Schreibpuffer (für die YAFFS2-Partition) zu leeren und dann kann man das "b" schreiben lassen.

Wenn alles glatt geht, startet danach das System mit der eben ersetzten Image-Datei als Root-FS - aber es bestehen eben Risiken, weshalb ich das nicht als "reguläres Update" betreiben würde, selbst wenn man immer in der anderen Partition ein "Rückfall-System" haben möchte (was verständlich ist, aber auch den Flash-Speicher für das andere über Gebühr beansprucht, weil nicht mehr nur jedes zweite Update dort landet).

Die kleine Mühe des Umschaltens auf ebendieses "Rückfall-System" zur Installation des anderen, kann man (fast immer) auf sich nehmen. Sollten die vorhandenen Einstellungen nicht zwischen den beiden Versionen kompatibel sein, muß man eben seine eigenen Sicherungen verwalten und jeweils "einspielen" (aber ohne den Import von AVM) - das ist der Haken an der Sache, wenn man eine zu große Lücke zwischen dem aktiven und dem inaktiven System in der Box hat.

Bei Boxen mit UBI-Layer geht das theoretisch ebenso - wobei hier die Anzahl der freien PEBs meist sogar ausreicht, um die alten Daten nicht überschreiben zu müssen - trotzdem sollte/darf natürlich nicht mehr auf den Flash zugegriffen werden zum Lesen von älteren Daten, wenn die LEBs inzwischen schon umgemappt wurden. Schreibzugriffe auf das Root-FS spielen bei SquashFS-Images ja ohnehin keine Rolle, daher muß man sich bei denen auch nicht um das Schreiben von Puffern kümmern.

Wer tatsächlich immer dasselbe "Reserve-System" in der Box aufheben möchte, sollte üblicherweise dann doch wieder zum Start aus dem RAM greifen (wenn er dafür nicht die Box erst fünf Treppen raufschleppen muß aus dem Keller) ... auch hier gibt es das Problem ja dann nicht, weil die Flash-Partitionen in diesem Falle gar nicht (für den Betrieb) gemountet sind und man sich um parallele Lesezugriffe keine Gedanken machen muß.

Ich hatte das mit dem Flashen des aktiven Systems bei den Geräten "with mirror" eigentlich auch nur mal so aus Spaß an der Freude und aus Interesse, wie "auffällig" ein Angriff am Ende wäre, getestet ... wenn man keine Spuren hinterlassen will als Angreifer, wird man es auch vermeiden wollen, auf ein anderes System umzuschalten und eher versuchen, das bereits laufende nach dem Neustart zu übernehmen bzw. "übernommen zu haben".
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
So, für heute habe ich genug ... schönes Restwochenende. Oben gibt es noch ein paar Ergänzungen in Reaktion auf #105 - das hatte ich halt noch nicht gelesen bis vorhin.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
So, für heute habe ich genug ...
Entschuldige bitte, ich wollte dir den Sonntag nicht verderben.

Was ich gerade noch festgestellt habe an der 7412 und 7272:
Alle VR9 Boxen mit ext2 haben standardmäßig:
/dev/loop0: 0 /filesystem_core.squashfs
Ist das richtig verallgemeinert?

Bisher habe ich das noch nie bemerkt, da es den losetup Befehl standardmäßig auf den heutigen FB nicht gibt und ich ihn auch nicht kannte.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Mann, seid doch nicht immer solche Mimosen ... wenn es so einfach wäre, mir irgendeinen Tag zu verderben, würde ich hier gar nicht mehr auftauchen.

Ich hatte nur oben noch so manches ergänzt (mit Ansage) und wollte irgendwie dafür sorgen, daß diese Tatsache erkannt und das als "neu" berichtet wird von Xenforo.

Mehr was das nicht ... ich bin doch kein Teenie-Girl (weder vor noch nach dem Bindestrich).

Ist das richtig verallgemeinert?
Das ist falsch verallgemeinert :) ... das gilt sogar (beim derzeitigen Aufbau) unabhängig von der Frage, ob da "ext2" oder "squashfs" für die "filesystem.image" von AVM verwendet wird.

Das (künftige) Root-Dateisystem wird hier (wenn es diesen YAFFS2-Wrapper gibt, der als "erstes Root-FS" verwendet wird) immer als Image gemountet (dabei wird dann auch das Loop-Device eingerichtet vom "mount") und im Anschluß mittels "pivot_root" gegen die YAFFS2-Partition "ausgetauscht".

Die Kommandos dazu findet man in der "/etc/inittab" ... am besten sogar in "/wrapper/etc/inittab", weil das tatsächlich die Datei ist, die da verwendet wurde, denn das YAFFS2 landet nach dem "pivot_root" ja in diesem Verzeichnis.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83
Ich habe heute die neue Inhaus für die 7530 so wie in #97 installiert.
Hat wunderbar geklappt und ging schnell ohne erst einen Switch anzubauen.

Das nächste mal probiere ich die Variante aus dem RAM.


BTW: Deine binarys in yf_bin/squashfs/armv7l/ laufen nicht auf meiner 7520/30:
Code:
7520+10:$(pwd)# ls -l /var/un*
-rwxr-xr-x    1 root     root        174980 Dec 31  2019 /var/unsquashfs4-le
7520+10:$(pwd)# /var/unsquashfs4-le
-sh: /var/unsquashfs4-le: not found
Sieht aus, als gäbe es die Datei nicht, sie ist aber da.
Komisch. Hast du da eine Lösung?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Hast du da eine Lösung?
Nicht wirklich.

Diese Tools sind dynamisch gelinkt und zwar gegen die "glibc", die beim Raspbian zum Einsatz kommt - nur dafür brauche ich sie bisher, weil ich keine FRITZ!Box mit ARMv7-CPU habe. Ich wollte nur den Besitzern eines RasPi auch eine direkte Möglichkeit geben, ohne selbst zu bauende Binaries gleich loszulegen.

Für die/auf den IPQ-Boxen bräuchte man entweder statisch gelinkte Binaries (das EABI5 müßte passen, da sollte es keine Überraschungen geben), so wie für die MIPS-Plattformen und Puma6/ATOM (in i686) oder man müßte sie sich für die IPQ-Boxen auch wieder "für's Target" mit Freetz (oder einer anderen Toolchain) für die passende C-Library bauen lassen.

Ob man das auf den IPQ-Boxen mit passenden Symlinks für den Loader doch noch hinbekommen kann (wenn die notwendigen Funktionen auch in der uClibc-ng 1.0.14 von AVM verhanden sind - sofern die in der Labor-Reihe auch noch verwendet wird bei den IPQ-Boxen), kann ich - mangels Gerät - nicht probieren.

Aber hier ist das, was an Libraries für diese Binaries gebraucht würde:
Rich (BBCode):
[email protected]:~ $ ldd /home/GitHub/yf_bin/squashfs/armv7l/unsquashfs4-avm-le
        linux-vdso.so.1 (0xbef2d000)
        /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6fae000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f6c000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6eea000)
        libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6ebf000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d71000)
        /lib/ld-linux-armhf.so.3 (0xb6fc3000)
[email protected]:~ $
Man könnte also versuchen, die notwendigen Symlinks für die Libraries zu erzeugen und auf die jeweiligen Dateien der uClibc-ng verweisen zu lassen - einfacher ist es allerdings, sich die passenden Tools zu erstellen. Die notwendigen Optionen, um das auch in Freetz (für die Target-Tools) statisch linken zu lassen, sind schon längere Zeit vorhanden.

Die Struktur in "squashfs" in "yf_bin" erhebt auch keinerlei Anspruch auf Vollständigkeit - da ist nur das vertreten, was ich bei mir auch brauchen würde bzw. was ich - dank Gerät - auch testen konnte.

Aber wenn das "uname -m" auf der 7530 auch ein "armv7l" liefert, ist das tatsächlich ein zusätzliches Problem für "Automatismen" ... u.U. wäre dann das Nachdenken über statisch gelinkte Versionen für diese Plattform auch wieder sinnvoll. Das ist ohnehin die Hölle ... die Versionen für "i686" sind mit dem Befehlssatz für ATOM-Cores übersetzt und verwenden daher Instruktion, die es bei anderen x86-Prozessoren nicht unbedingt gibt. Das ist ein "bekanntes Problem" ... nur trifft es mich selbst eben auch eher selten, was den "Leidensdruck" an dieser Stelle entsprechend niedrig hält.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Ich habe mal die SquashFS-Tools für "armv7l" auch mit der Freetz-Toolchain (genauer mit meinem Fork) gebaut und statisch gelinkt. Die funktionieren bei mir auf den RasPis und sollten jetzt auch auf einer Box mit einem IPQ401x laufen.

Parallel dazu habe ich noch das schon länger nicht funktionierende Wrapper-Skript für die SquashFS-Tools angepaßt ... man muß nicht länger selbst den Pfadbestandteil, der sich aus dem $(uname -m) ergibt, angeben, sondern kann einfach (Bsp.) bin/squashfs/unsquashfs4-be (ausgehend von der Basis des YourFritz-Klons, ansonsten ohne bin, wenn man yf_bin direkt geklont hat) benutzen und das Skript sucht sich dann schon die richtigen Binaries, vorausgesetzt, die Architektur ist vorhanden/unterstützt.

Gleichzeitig habe ich mal ein paar vorübersetzte Binaries für "armv7l" (i.d.R. statisch gelinkt, also ohne Abhängigkeiten von der verwendeten C-Library und meistens auch über mehrere Modelle/Kernelversionen lauffähig) in yf_bin/target hinzugefügt - derzeit unterhalb von 4.4.60 (als Kernelversion), weil sie mit der Freetz- (bzw. YourFreetz-)Toolchain für die 7530 erzeugt wurden. Getestet ist da aber (auf dieser Plattform) nur wenig (ich habe sie mal auf RasPis angeworfen, wo das Sinn ergab), da ich keine passende Box habe.