Die überlebt aber ein Update auch nicht ... das habe ich zwar auch mal gebaut, aber noch nicht "freigegeben", weil AVM mittlerweile auch an der "/var/install" und "/var/post_install" herumprökelt, um das mit dem "SILENT MODE" für die Updates auf die Kette zu kriegen. Außerdem war mir eine Änderung, die sich selbst in der Firmware "festkrallt", irgendwie immer zu nahe am "Wurm", der sich selbst weiterverbreitet (hier halt in die andere Partition).
@Jack Sabbath:
Das ist dann auch genau der Weg, den man da mit einer eigenen Erweiterung gehen könnte. Die "/var/post_install" steht in der Datei "/var.tar" in der AVM-Firmware und wird beim Start nach "/var" (das ist die einzige Stelle in der Firmware, wo ein (internes) Dateisystem mit Schreibzugriff gemountet ist) entpackt. Die wird dann (über die "/etc/inittab") beim Shutdown der Box ausgeführt und wenn es ein Firmware-Update von AVM gibt, dann schreibt ein dort enthaltenes Skript die für das Update notwendigen Kommandos an das Ende dieser Datei. Damit hat man üblicherweise einen relativ sicheren Marker dafür, ob da ein Update erfolgte (bzw. eigentlich noch erfolgen soll) oder nicht ... man muß nur die Dateigröße überprüfen oder man sucht sogar gezielt nach entsprechenden Kommandos (sicherer).
Diese Überprüfung kann man jetzt durch (automatisches) Editieren der "/var/post_install" an deren Anfang schreiben ... dafür reicht ja eine einzelne Zeile, die ein eigenes Shell-Skript aufruft, das dann diese Überprüfungen vornimmt und ggf. sogar noch dafür sorgt, daß die später von den AVM-Kommandos installierten Images bereits die eigene Erweiterung beinhalten (so müßte/würde man das auf anderen Boxen machen, die direkt ein SquashFS-Image als Root-FS verwenden). Dieser Prozess ist aber für verschiedene Plattformen auch unterschiedlich, weil die tatsächliche Installation (also das Schreiben der neuen Daten in den Flash oder den eMMC-Speicher) zu anderen Zeitpunkten erfolgt - bei VR9 wird da tatsächlich erst beim Shutdown in den Flash geschrieben.
Daher muß man hier wieder dafür sorgen, daß man sich entweder direkt an den Anfang der "post_install" klemmt, weil man da noch - nach den eigenen Aktionen, die auch eine "Erweiterung" um einen Aufruf nach dem Flash-Schreiben von AVM (mittels "cp -R" als Kommando) beinhalten müssen - die Gelegenheit hat, die Abarbeitung einer noch einmal modifizierten "post_install" mittels "exec" erneut in die Wege zu leiten, nachdem man eigene Aktionen (den ersten Teil der notwendigen Schritte) ausgeführt hat - das verringert die Chancen, daß doppelt ausgeführte Aktionen in der "/var/post_install" zu Problemen führen, wenn man die bei einem späteren Stand der Abarbeitung noch einmal modifizieren würde (es ist "undefined", wie eine Shell auf eine nachträgliche Änderung eines von ihr gerade ausgeführten Skripts reagiert).
Oder man muß hingehen und die "filesystem.image" mit der eigenen Erweiterung neu zusammenpacken - das braucht dann das passende "mksquashfs" in der eigenen Erweiterung und braucht entsprechend lange, was zu diesem späten Zeitpunkt auch keine wirklich gute Idee ist, weil u.a. auch jeder Swap-Space schon Geschichte wäre, da der USB-Stack (üblicherweise) schon gestoppt wurde - das ist auf anderen Modellen ziemlich das Einzige, was bleibt und so ist es dort tatsächlich deutlich komplizierter, weil man am besten schon lange vor dem Shutdown dann die neuen Image-Dateien verändert, was eine kompliziertere "Erkennung" der Update-Situation erforderlich macht.
Für diesen konkreten Fall mit einer 7490 und eher "schmalen" Änderungen, die auch nicht ins SquashFS-Image Einzug halten müssen/sollen, ist es also tatsächlich das Beste, wenn man sich hinter das "cp -R" klemmt (aber vor das "umount" für das YAFFS2-FS) und dort einfach noch einmal ein eigenes Skript für die Übernahme der eigenen Erweiterung nach "/var/tmp/fs_mtd" (da ist die Wrapper-Partition des neuen Systems dann gerade gemountet) aufruft.
Ab 07.19-Labor bzw. 07.21-Release, ist das dann wieder alles ganz anders ... ab jetzt wird - zumindest für "SILENT_UPDATE", was bei AVM wohl eher ein "blind update" ist, denn da wird halt nichts signalisiert mit den LEDs zum Zeitpunkt der tatsächlichen Installation - die neue Firmware sofort installiert (die Kommandos dazu werden in die Datei "/var/updatestore/update_action_flash" geschrieben und diese dann aufgerufen aus der "/var/install" heraus) und nur der Neustart auf später verschoben, während die "/var/post_install" auch schon durch die "/var/install" präpariert wird - ggf. werden ein paar notwendige Änderungen an den Einstellungen auch noch bis zum Neustart verschoben, damit das laufende System noch mit den alten arbeiten kann.
Hier kann/muß man sich einfach nur selbst darum kümmern, daß die (neue) Wrapper-Partition noch einmal gemountet wird, bevor man die eigene Erweiterung dort hineinkopieren kann - den Skript-Aufruf dazu kann man wieder getrost (beim Start der eigenen Erweiterung) an das Ende der "/var/post_install" schreiben (da braucht es dann die "frühe Prüfung" auch nicht), weil die "/var/install" die ohnehin fortschreibt und es hier kein "cp -R" durch die "/var/install" mehr gibt, nach dem man erst selbst aktiv werden kann. Da die neue Firmware schon in den Partitionen steht, kann man sie auch schon früher abändern.
Ab dieser Version stimmt dann auch die bisher in Freetz zu findende Aussage, daß man die Installation einfach "ungeschehen" machen könne, wenn man einen irregulären Neustart ausführt, bei dem die "/var/post_install" nicht abgearbeitet wird (meinetwegen per "Power Off"), für die anderen Modelle mit diesem Mechanismus nicht länger - aber auch da kriegt man dann deutlich mehr Zeit und Gelegenheit (wenn die Updates jetzt "planbar" sind), die bereits installierte, neue Firmware noch einmal zu überschreiben, während das System ansonsten noch voll funktionsfähig ist.
Denn das war eines der größten Probleme bei diesem Vorgehen bisher ... wurde ein Update gestartet, wurden auch die meisten FRITZ!OS-Prozesse schon vor diesem Update heruntergefahren und man mußte entweder auf sie verzichten (das betraf bei bestimmten Update-Formen auch die Internet-Verbindung) oder man mußte sie erst mühsam neu starten. Das schränkte die Möglichkeiten (bis hin zum Nachladen von zusätzlichen Programmen, die man noch in das Image einbauen lassen will, aus dem Internet) erheblich ein und ein aufgesetzter Watchdog für das Ende des Updates (falls sich das irgendwo aufhängt) mußte auch erst eingeschläfert werden oder man mußte innerhalb der vorgegebenen Zeit fertig werden.
Eigentlich hatte ich das Prinzip auch schon mal vor ein paar Jahren gezeigt, da ging es noch um eine 6490:
https://github.com/PeterPawn/YourFritz/tree/master/autoupdate - in "update_system" wird ein (möglicher) Aufruf eines zweiten Skripts am Anfang der "/var/post_install" gezeigt (hier verhindert dann eine Datei als Semaphore den zweiten Aufruf des eigenen Skripts, wenn die "/var/post_install" erneut abgearbeitet wird) und in "run_update" wird (aus dem Kopf erzählt, steht bestimmt irgendwo in der Datei) geprüft, ob es ein Update gibt, was zu installieren wäre und wenn das der Fall ist, wird es eben gemacht. Das ist zwar von den Aktionen her leicht etwas anderes, aber die Prinzipien (Absichern gegen doppelte Ausführung, Prüfen auf notwendige Aktionen, ggf. Ausführen derselben) sind sich schon ziemlich ähnlich - auch wenn's hier eben nicht um die eigene Reproduktion der Software (und damit einen "Wurm") ging.
