@NDiIPP:
Die Ziffer im "recovered=X" stimmt nicht so ganz ("/var/install" setzt - wie "factory_defaults" - dort eine "3"), der Rest ist schon davon abhängig, wie genau die Installation erfolgt.
Solange das aus der "/var/install" heraus stattfindet (die ja aus einem laufenden System arbeitet), wird die UBI-Partition gar nicht neu formatiert.
In der "E03-flash_update" sähe das so aus, aber die kommt eben auch nur zum Zuge, wenn das System aus dem RAM arbeitet und das (aktive und genutzte) Dateisystem dann eben genau nicht in der UBI-Partition liegt:
Code:
85 check_and_setup_ubi_volumes() {
86 echo "[ubi] set up ubi volumes start"
87 cat /proc/mtd
88 if [ "${1}" = "force" ] ; then
89 mtd_ubi_nr=`cat /proc/mtd | grep '^mtd.*\"ubi\"' | sed 's/:.*//' | sed 's/^mtd//'`
90 if [ -n "${mtd_ubi_nr}" ] ; then
91 echo "[ubi] format ubi volumes in /dev/mtd${mtd_ubi_nr} ..."
92 ubidetach -p /dev/mtd${mtd_ubi_nr}
93 ubiformat /dev/mtd${mtd_ubi_nr} -y -q
94 ubiattach -p /dev/mtd${mtd_ubi_nr}
95 echo "[ubi] format ubi volumes done"
96 fi
97 fi
98 #### the sizes for GRX5, reduced by 8M (bootcore), should be generated from memorylayout (ToDo)
99 echo "[ubi] set up ubi volumes"
100 udevadm trigger
101 ubimkvol /dev/ubi0 -N avm_filesys_0 -s 44MiB
102 ubimkvol /dev/ubi0 -N avm_filesys_1 -s 44MiB
103 ubimkvol /dev/ubi0 -N avm_config -s 2MiB
104 ubimkvol /dev/ubi0 -N avm_userdata -m
105 echo "[ubi] set up ubi volumes done"
106 cat /proc/mtd
107 ubinfo -a
108 }
Von der "/var/install" aus einem Firmware-Image aus, wird aber nur mittels "update_kernel" (das kann auch - entgegen seines Namens - beliebige MTD-Partitionen beschreiben) der neue Kernel und das neue Dateisystem geschrieben, bevor "linux_fs_start" umgeschaltet wird.
Code:
553 # Delete mtds
554 echo "echo Erase mtd partitions '$var_kernel_mtdnr' and '$var_fs_mtdnr' ..." >>/var/post_install
555 if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_kernel_mtdnr" ] ; then
556 echo "/sbin/update_kernel -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
557 echo "/sbin/update_kernel -o /dev/mtd$var_fs_mtdnr" >>/var/post_install
558 else
559 echo "echo mtd $var_kernel_mtdnr erase all > /proc/mtd" >>/var/post_install
560 echo "echo mtd $var_fs_mtdnr erase all > /proc/mtd" >>/var/post_install
561 fi
562 # ---
563 # Copy kernel image
564 echo 'echo Copy kernel image...' >> /var/post_install
565 if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_kernel_mtdnr" ] ; then
566 echo "/sbin/update_kernel -i /var/tmp/kernel.image -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
567 else
568 echo "cp /var/tmp/kernel.image /dev/mtdblock$var_kernel_mtdnr" >> /var/post_install
569 fi
570 echo '[ $? -ne 0 ] && echo failed with error "$?" && update_state=bad' >> /var/post_install
571 echo 'echo Clean up kernel image' >> /var/post_install
572 echo 'rm -f /var/tmp/kernel.image' >> /var/post_install
573 # ---
574 # Copy filesystem image
575 #### no wrapper
576 echo 'echo Copy filesystem image ...' >> /var/post_install
577 if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_fs_mtdnr" ] ; then
578 echo "/sbin/update_kernel -i /var/tmp/filesystem.image -o /dev/mtd$var_fs_mtdnr" >>/var/post_install
579 else
580 echo "cp /var/tmp/filesystem.image /dev/mtdblock$var_fs_mtdnr" >> /var/post_install
581 fi
582 echo '[ $? -ne 0 ] && echo failed with error "$?" && update_state=bad' >> /var/post_install
583 echo 'echo ... Copy filesystem done' >> /var/post_install
584 # ---
585 # set urlader field 'linux_fs_start'
586 echo 'if [ "$update_state" = "good" ] ; then' >> /var/post_install
587 echo ' echo Setting linux_fs_start mirror...' >> /var/post_install
588 # toggle
Sollen hier (also aus der "/var/install") auch die Einstellungen gelöscht werden, erfolgt das - anders als das Beschreiben der Flash-Partitionen, was als Kommando an die "/var/post_install" angehangen wird und damit erst beim Herunterfahren der Box ausgeführt wird - direkt schon in der "/var/install", indem die TFFS-Nodes in einer Schleife mittels "clear_id
minor" (was der eine oder andere vielleicht noch vom Zurücksetzen des "Vom Hersteller ... Änderungen"-Flags kennt) gelöscht werden.
----------------------------------------------------------------------------------------------------------
Ich bin ohnehin der Ansicht, daß AVM hier noch die eine oder andere Race-Condition in der "/var/install" hat ... denn wie man jetzt verhindern will, daß der "ctlmgr" seinerseits einfach noch einmal geänderte Dateien, die er bisher nur im Speicher hält, in die frisch gelöschten Nodes schreibt (eine gerne genommene "Falle" beim manuellen Ändern von solchen Dateien), habe ich noch nicht herausfinden können und schließlich macht AVM das "Gerät ist leer" bei Start ja eigentlich am Inhalt der "ar7.cfg" fest.
So manches Phänomen nach einem Update habe ich früher auch diesem Umstand zugeschrieben und m.E. wurde AVM hier bisher nur "gerettet" vor einer deutlich höheren Anzahl von Problemen bei den Kunden, weil genau dieser Downgrade-Teil in den letzten Jahren überwiegend stillgelegt war ... damit wurde das Löschen da nicht ausgeführt und die neu hinzugekommenen Schreibvorgänge in alle möglichen Konfigurationsdateien (denn die haben ja auch zugenommen - bis hin zur "userstat.cfg" für die Budgetierung) machten das nicht gleich wieder rückgängig. Denn wenn ich mich nicht vollkommen vertue, schreibt der "ctlmgr" eben beim Beenden noch alles das raus, was er bisher nur im Speicher hat ... da der beim Neustart aber auch "normal" versucht wird zu beenden, ist so eine Schreiboperation (nach ausreichender Laufzeit der Box) fast zwangsläufig noch zu erwarten.
----------------------------------------------------------------------------------------------------------
Wie auch immer ... jedenfalls wird dieses Löschen dann eben schon direkt in der "/var/install" ausgeführt (damit auch schon vor dem Punkt, wo in Freetz noch behauptet wird, das könnte alles wieder rückgängig gemacht werden, wenn man die "/var/post_install" nicht ausführt:
https://github.com/Freetz/freetz/bl...es/root/usr/lib/mww/do_update_handler.sh#L219) und für das Löschen des NAS-Speichers beim nächsten Neustart das "recovered=3" gesetzt.
Aber beim nächsten Start läuft das System dann eben auch aus der UBI-Partition (bzw. der Kernel-Partition im Flash) und nicht aus dem RAM ... das wird in der "E03-flash_update" als erstes getestet und wenn das so sein sollte, kommt dieses Skript nie an der oben gezeigten Stelle mit dem "ubiformat" vorbei.
Hier kann man also "Entwarnung" geben ... auch wenn ich mir ziemlich sicher bin, daß (sollte das Löschen der Einstellungen so bleiben, wie es derzeit in der "/var/install" erfolgt) es bei diesem Downgrade noch die eine oder andere Überraschung geben wird - denn wenn der "ctlmgr" tatsächlich noch die "ar7.cfg" aus irgendeinem Grunde neu schreibt, nachdem sie in "/var/install" gelöscht wurde, findet das eigentliche Laden der Standardangaben in der "/etc/init.d/S08-tffs" nicht mehr statt, denn das wird durch diesen Code dann einfach abgebrochen:
Code:
## In state of factory defaults ar7.cfg is always empty
if ! checkempty /var/flash/ar7.cfg ; then
echo "P-Defaults: do nothing"
return
fi
Ist die "ar7.cfg" also nicht leer, sind die dort hinterlegten alten Einstellungen (die der "ctlmgr" dann wieder geschrieben hat vor dem letzten Reboot) wieder da und alle anderen (die eben nicht neu geschrieben wurden vor dem Restart und jetzt aber auch nicht auf die Standardwerte gesetzt werden, weil diese Initialisierung abgebrochen wird) sind praktisch "undefiniert". Ich wäre sehr verblüfft, wenn eine solchermaßen mißhandelte Box dann einwandfrei funktioniert, wenn man sie von diesem Punkt an neu konfigurieren will und keine Sicherung einspielt (das würde dann wieder die ansonsten "leeren" Dateien auch wiederherstellen).
Das ganze Cachen im TFFS3-Treiber (in der "tffs_cache.c") hat AVM m.E. auch erst eingebaut, als der Downgrade schon nicht mehr "en vogue" war (und der Client-Server-Teil für die Puma-Boxen dazu kam im TFFS-Treiber) ... ebenso große Teile des "lazy writings" bzw. eigentlich ist ja der gesamte TFFS3-Treiber erst so richtig "gereift", nachdem das Downgrade übers GUI deaktiviert wurde, auch wenn erste Ansätze in der 06.5x zu sehen waren, iirc. Das ist also vermutlich alles andere als gründlich getestet ... ich wage mal die Prognose, daß AVM hier in nicht allzu ferner Zukunft sich noch einmal mit der "/var/install" für Downgrades befassen muß (oder man macht das dann einfach so lange, bis es irgendwann mal klappt, weil der "ctlmgr" die "ar7.cfg" eben nicht mehr überschreibt).
Ich sehe jedenfalls bisher keinen "Mechanismus", mit dem der "ctlmgr" beim Downgrade angewiesen würde, VOR dem Löschen der TFFS-Nodes noch irgendwas zu schreiben bzw. alles im (Schreib-)Cache zu vergessen ... davon, daß diese Schreiboperationen ansonsten generell asynchron laufen (es gibt einen Kernel-Thread für diese Aufgaben), kann man sich auch in der eigenen Box überzeugen:
Code:
root@FB7490:~ $ cat /proc/tffs
TFFS
mount=mtd7
mount=mtd8
request=1
mode: read/write: shared
thread state=idle
root@FB7490:~ $
und das ist auch in den GRX-Modellen (hier eine 7580) nicht anders:
Code:
# cat /proc/tffs
TFFS
request=4
mode: read/write: shared
thread state=idle
#
