OK, das ist mal wieder mal das "übliche" Problem mit zwei auseinanderdriftenden Forks, die sich ein Support-Forum teilen wollen oder sollen - in diesem Falle verbunden mit einem Patch, den ich nicht auf dem Schirm hatte. Andererseits betone ich ja häufig genug, daß ich mich nur für einen Fork interessieren kann und will und nicht für zwei, die sich (ob absichtlich oder unausweichlich, spielt inzwischen auch keine Rolle mehr) immer weiter voneinander entfernen.
Bei Freetz-NG wurde das Problem durch diesen Patch bereits vor langer Zeit (fast ein ganzes Jahr) behoben, wohl als es die
ersten 07.08-Laborversionen gab, wo das von AVM geändert wurde:
https://github.com/Freetz-NG/freetz...142fc60#diff-055eab39c53879deff31d14614e68b15
Bei Freetz hingegen ist dieselbe Datei seit 10 Jahren nicht geändert:
https://github.com/Freetz/freetz/blob/master/make/mod/files/root/usr/bin/prepare-downgrade und dort tritt dann auch das von mir beschriebene Problem weiterhin auf.
Wenn das in Freetz-NG bereits zuvor geändert wurde (damit stimmt dann mein letzter Absatz in #6 für Freetz-.NG eben nicht - habe ich korrigiert), verstehe ich den zwischenzeitlichen Patch für die DOCSIS-Boxen erst recht nicht mehr ... dann paßt bei der 6490/6590/6430 ja nur die Anzeige an dieser Stelle nicht:
https://github.com/Freetz-NG/freetz...es/root/usr/lib/mww/do_update_handler.sh#L236 - und das ist es auch, was ich für die Puma6-Boxen immer beschrieben habe.
Dort wird bereits in der "/var/install" (am Ende, ab Zeile 616 in der 07.12) die neue Version in die alternativen Partitionen geschrieben und auch "linux_fs_start" wird dort schon umgeschaltet (Zeile 812) ... da stimmt also die angezeigte Beschreibung im Freetz-GUI nicht.
Das kannst Du ja auch mal ausprobieren ... wenn das jetzt auch noch funktioniert in Freetz-NG (mit dem derzeitigen Stand), dann leiste ich Abbitte. Ich beobachtete den Fork aber am Beginn auch nicht wirklich aktiv (der Patch war ja praktisch unmittelbar nach dem Eröffnen des Forks und da gab es viel dicke Luft - obendrein mußte man sich mit einem uralten SVN und Trac auseinandersetzen, wenn man da lesen wollte) und da mag mir noch so manche andere, frühe Änderung entgangen sein, zumal einiges auch wieder revidiert wurde und man leicht den Überblick verlieren konnte - außerdem fehlen da wirklich aussagekräftige Beschreibungen, was mancher Commit nun eigentlich bezwecken soll und man sucht/liest sich immer einen Wolf.
Ich weiß schon, warum ich normalerweise sehr exakt darauf achte, mich nur mit Freetz-Problemen zu befassen (und hier meine ich das GitHub-Repo, auf dem auch mein eigener "YourFreetz"-Fork basiert, denn da weiß ich einigermaßen Bescheid), wenn jemand Hilfe braucht und warum ich da meist deutlich differenziere.
===================================================================
Aber Du wirst in dem angezeigten File "/var/post_install" (das zeigt Dir ja das GUI zwischendrin noch an, wenn das Update gestartet wurde) auch im Freetz-NG-GUI nichts finden, daß da erst irgendetwas in die eMMC-Partitionen geschrieben wird - das ist eben schon erfolgt zu diesem Zeitpunkt. Und selbst wenn Du an dieser Stelle dann den Stecker ziehst (dann wird die "/var/post_install" halt auch nicht abgearbeitet) oder die Dateien wie angegeben löschst, wirst Du beim nächsten Start von der neu installierten Version begrüßt.
Mehr ist es aber auch nicht, was an der Installation für die Puma6-Boxen "besonders" ist - ich habe nie behauptet, daß die Installation an sich (also das Kopieren und die Umschaltung) nicht funktionieren würde. Es gibt zwar noch eine "race condition" in der "/var/install" von AVM bei den Puma6-Boxen, aber die betrifft nur den Fall des "forced update" (aka altes Downgrade bei AVM), wenn die Einstellungen von "/var/install" über "clear_id" gelöscht werden, während der "ctlmgr" noch läuft und u.U. beim Beenden dann die Dateien gleich noch einmal neu schreibt. Aber m.W. kann man dieses "/var/install -f" nur noch über X_AVM-DE_DoManualUpdate auf den TR-06x-Schnittstellen ausführen (oder über CVC-Dateien) ... wenn überhaupt, das habe ich länger nicht geprüft. Früher war das mal die "normale Reaktion" auf ein Downgrade per AVM-GUI.
Wenn bei Freetz-NG nun die "Downgrade"-Option schon seit fast einem Jahr korrekt arbeitet, dann kann man da halt das GUI für ein Update verwenden, auch beim Downgrade ... nur ohne Prüfung, ob das ein "tampered file" ist oder nicht (wäre über EVA aber auch nicht anders, nur das AVM-GUI checkt die Signatur). Solange also in Freetz (oder Freetz-NG) kein Aufruf von "/var/install -f" enthalten ist, stimmen nur - diesmal aber tatsächlich bei beiden, ich habe extra noch einmal nachgesehen - die Texte für die Puma6-Modelle an der Stelle nicht, wo die "/var/install" zuvor aufgerufen wurde.
Aber da muß man eigentlich nur den ganzen Sermon einfach weglassen ... ändern kann der Benutzer ab da nichts mehr, außer ggf. "linux_fs_start" wieder zurückzusetzen. Allerdings könnte man dann bei Freetz-NG auch gleich noch die gecachten Daten zu den installierten Versionen (aus der "system_lfs.cgi") löschen, denn diese Angaben stimmen nach der ausgeführten Installation auch nicht länger - unabhängig davon, ob die letzte Auswertung nun schon 9 Minuten her ist oder nicht.
