[Frage] Update von Freetz abbrechen

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
687
Punkte für Reaktionen
4
Punkte
18
Hallo zusammen,

wenn ich über die Freetz Oberfläche ein FW-Update hochgeladen habe, kann soviel ich weiß, die finale Installation ja noch abgebrochen werden, solange man die Box nicht neu gestartet hat.
Welche Dateien müssten dazu gelöscht werden, damit das sicher funktioniert?
Genügt es, die Dateien
  • /var/install
  • /var/tmp/kernel.image
  • /var/tmp/filesystem.image
zu löschen?

Ich hab das in all den Jahren noch nie gebraucht, und möchte nichts übersehen.

Danke und viele Grüße
maceis
 
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).
 
Zuletzt bearbeitet:
Weil das bei den Cable-Boxen (ab 6490 zumindest) schon immer so war, daß da direkt in den Flash geschrieben wurde (bei den Puma-Boxen ja sogar in eMMC anstelle von (raw) NAND) und diese "letzte Chance", es sich anders zu überlegen, da nie bestand - also bringt es auch nichts, den Inhalt der "/var/post_install" anzuzeigen, nachdem die "/var/install" abgearbeitet wurde.
 
  • Like
Reaktionen: gismotro
Ah, okay, Danke. Das wusste ich nicht.
 
Hi Peter,

mal eine Frage die damit im Zusammenhang steht, wenn man ein Freetz Image auf einer 7590 installiert, wird ja zunächst das neue Image, z.B. in die Reserve Patition (linux_fs_start=0) geschrieben und wenn das neue Image erfolgreich bootet wird, dann auch die momentane Partition (linux_fs_start=1) mit dem neuen Image beschrieben.

Nun führte das neue installierte Image (linux_fs_start=0) nach 2 Minuten zum Reboot und ich konnte manuell via Freetz-System Page "Firmwarepartition wechseln" auf das alte Image (linux_fs_start=1) umschalten, womit das funktionierende Image dann wieder bootete.

Wie kann ich nun, wenn ich das alte Image nicht mehr habe, das alte Image (linux_fs_start=1) auch auf die Reserve (linux_fs_start=0) schreiben?

Gruß, Dirk
 
wenn das neue Image erfolgreich bootet wird, dann auch die momentane Partition (linux_fs_start=1) mit dem neuen Image beschrieben.
Diese Annahme ist falsch ... das ältere System bleibt einfach unangetastet und wird erst beim nächsten Update (dann eben auch mit der nächsten Version) überschrieben - nur deshalb funktioniert ja auch eine Auswahl zwischen zwei Systemen (wie z.B. hier: https://github.com/PeterPawn/YourFritz/tree/master/bootmanager) dauerhaft.

Wenn sich das Thema "Gleiches System in beiden Partition-Sets" damit noch nicht erledigt haben sollte, kann man tatsächlich manuell (so man Shell-Zugriff hat, was bei Freetz ja anzunehmen wäre) beide System "angleichen" ... ich sehe aber keinen plausiblen Grund, warum man das machen sollte (außer ggf., wenn man einen solchen "Umschalter" hat und verhindern will, daß man - immerhin aber "bewußt" - auf ein nicht funktionierendes System wechselt).
 
... wird ja zunächst das neue Image, z.B. in die Reserve Patition (linux_fs_start=0) geschrieben
Nein. Es wird in das gerade inaktive Partitionsset geschrieben.

und wenn das neue Image erfolgreich bootet wird, dann auch die momentane Partition (linux_fs_start=1) mit dem neuen Image beschrieben.
Nein. Die neue Firmware bleibt in dem Partitionsset, in welches sie geschrieben wurde. Im anderen Partitionsset bleibt die alte Firmware (bis zum nächsten Update).

Wie kann ich nun, wenn ich das alte Image nicht mehr habe, das alte Image (linux_fs_start=1) auch auf die Reserve (linux_fs_start=0) schreiben?
Weshalb würde man das tun wollen?

Edit:
Zu langsam. Hatte Beitrag #7 von @PeterPawn noch nicht gesehen.
 
Danke, dann ist alles klar, dann bleibt nur noch die Frage, ob man die Partition auch unabhängig von der Freetz-System Page "Firmwarepartition wechseln" zur alten Partiton wechseln kann, wenn das Image nicht funktioniert?
Das wäre ja dann ein Recovery-Tool Light, falls ein Update nicht klappt.
 
dann bleibt nur noch die Frage, ob man die Partition auch unabhängig von der Freetz-System Page "Firmwarepartition wechseln" zur alten Partiton wechseln kann, wenn das Image nicht funktioniert?
Selbstverständlich:
https://github.com/PeterPawn/modfs/blob/master/BOOTSELECTION.ger
(Dieser Link muss sich ja mittlerweile so in meine Zwischenablage "eingebrannt" haben, dass ich gar nicht weiß, ob ich den da überhaupt noch herausbekomme... Gefühlt ist damit beinahe schon jedes zweite Thema hier im Forum "geflutet" worden.)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.