Das gilt mittlerweile für die neuen Versionen der AVM-Firmware ohnehin nicht mehr - sofern dort ein "SILENT_UPDATE" vorgesehen ist, werden alle notwendigen Aktionen für das Update nicht länger nur zur "/var/post_install" hinzugefügt und damit erst beim Neustart wirksam (was man dann mit dem Ersetzen der modifizierten "/var/post_install" durch den originalen Inhalt aus der "/var.tar"-Datei noch erfolgreich verhindern konnte), sondern direkt bei der Ausführung der "/var/install" in eine (temporäre) Datei geschrieben, die dann auch umgehend von "/var/install" aufgerufen wird.
Damit sind die Änderungen (inkl. der Umschaltung von "linux_fs_start") dann auch schon am Ende der "/var/install" erfolgt und da ist nichts mehr mit "Abbrechen" - das geht nur durch Verhindern der Ausführung der "/var/install" oder durch Änderungen an deren Inhalt. Beides ist derzeit weder in Freetz noch in Freetz-NG vorgesehen - zumindest wäre auch bei Freetz-NG der Inhalt des Formulars im GUI (
https://github.com/Freetz-NG/freetz.../root/usr/mww/cgi-bin/update/firmware.cgi#L50) noch falsch, falls es da doch irgendwelche Anpassungen gab, die mir entgangen sind.
Wobei generell das Vorgehen bei der Installation in Freetz nicht mehr "identisch" ist mit dem bei AVM - denn auch wenn es früher bei AVM Usus war, die "/var/post_install" erst einmal komplett zu löschen und nach der "/var/install" nur noch die Kommandos zum Flashen in der Datei stehen zu haben, ist das schon sehr lange nicht mehr so und damit ist eigentlich schon das Löschen der "/var/post_install" in Freetz (hier exemplarisch in Freetz-NG:
https://github.com/Freetz-NG/freetz...es/root/usr/lib/mww/do_update_handler.sh#L185) die erste Abweichung.
Bei den NOR-Boxen mit einem einzigen System machte das auch noch Sinn - da wurde als letzte Aktion in der "/var/post_install" ohnehin ein Treiber geladen, der den gesamten Rest des Systems anhielt und nur noch die gewünschten Inhalte in den Flash schrieb, bevor er das System "gewaltsam" neu startete und zwar ohne eine "graceful termination". Da gab es aber auch noch lange nicht so viele Stellen in der Firmware, wo beim Beenden von Diensten zusätzliche Daten (bis hin zu den Statistiken der Internet-Nutzung bei limitierten Benutzern) gesichert werden mußten/sollten und so ist der Verzicht auf die 152 Zeilen des Inhalts der "/var/post_install", die vor den anderen Kommandos, die von der "/var/install" dort angefügt werden, zur Ausführung kämen, auch ein vollkommen unnötiges Risiko für "Abweichungen", die auch ganz schnell zum Fehler werden können.
Denn schlauer wäre es hier sicherlich allemal, wenn man (um gegen doppelte Ausführung abgesichert zu sein, was Sinn machen kann) hier nicht einfach nur die Datei löscht, sondern sie aus der "/var.tar" restauriert - zumal AVM mittlerweile diesen Inhalt sogar zweimal (einmal als "post_install" und einmal als "post_install.template") in der "/var.tar" hinterlegt. Dieses TAR-File wird (iirc) auch noch von Freetz(-NG) geändert - ich weiß nicht, ob dabei mittlerweile auch die Existenz dieser zwei Files berücksichtigt wird bzw. ob sich mal jemand die Mühe machte zu erkunden, welche dieser beiden Dateien denn von AVM bei anderen Gelegenheiten als dem Systemstart (wo die "/var.tar" dann entpackt wird) verwendet wird und ob/wann dieses zweite File mit dem ".template" als Suffix verwendet wird, um die "/var/post_install" an anderer Stelle zu restaurieren.
Aber egal, wie es bei der Behandlung der "/var/post_install" auch aussehen mag ... in der Freetz-Installation ist zwischen dem Stoppen der Dienste über "prepare_fwupgrade" und dem Aufruf der "/var/install" kein weiterer "Abbruch" vorgesehen und so stimmt die Beschreibung des Update-Vorgangs ab 07.19 (bzw. seit der Einführung dieses "SILENT_UPDATE"-Features, die erst im Laufe der Laborreihe zur 07.19 erfolgte) ohnehin nicht mehr.
Ja, es könnte sogar zu weiteren Problemen beim Freetz-Update kommen, denn wenn man dabei die Option "Einen Teil der AVM-Dienste stoppen (bei Remote-Update)" ausgewählt hatte, wird ja u.a. auch diese Zeile aktiviert:
https://github.com/Freetz-NG/freetz...es/root/usr/lib/mww/do_update_handler.sh#L160 und das bedeutet, daß die Ausführung der "/var/install" (und zwar inkl. des Schreibens in den Flash bei den neueren Versionen) innerhalb von 30 Sekunden
abgeschlossen sein muß, weil danach die Box "zwangsgestartet" wird.
Gibt es irgendwelche Probleme beim Schreiben in den Flash (z.B. beim Verifizieren der geschriebenen Daten und einer anschließenden Reorganisation durch den UBI-Layer), darf das auch nicht länger dauern ... eine (für mich) sehr kühne Annahme, die ich selbst erst dann treffen würde, wenn ich das mindestens einmal für alle "in Frage kommenden" Modelle auch gründlich ausgestoppt hätte - und auch dann nur mit einem entsprechenden Sicherheitsaufschlag bei der eingeräumten Zeitspanne. Diese "Nachbildung" eines Watchdogs ist jedenfalls für meine Begriffe zu simpel - sie mag sogar in 95 von 100 Fällen funktionieren, aber "sauber" wäre in meinen Augen anders und die fünf Fälle, wo es Probleme gibt, sind dann wieder diejenigen, die hier (oder anderswo) aufschlagen und denen man erst mal gar nicht glauben mag, weil das ja bei allen anderen auch funktioniert. Solche "versteckten" Fallen sind jedenfalls mit das "Unfeinste" (quasi ein "dirty workaround"), was man als Developer einbauen kann (meiner Ansicht nach).
