Ich bin selber Informatiker
Dann solltest Du ja auch Dokumentationen lesen können ... wie der Build-Prozess abläuft, sieht man auch spätestens dann, wenn man den (mit passendem Info-Level) einmal selbst ablaufen läßt und der Weg dorthin, ist m.E. ausreichend ausführlich beschrieben.
Welche Lua- und ggf. JS-Dateien beim Reset über die Weboberfläche eine Rolle spielen (Tipp dazu: die Firmware verwendet eine "feste" URL als Sprungverteiler für die allermeisten Aktionen), findet man am ehesten mit den Developer-Tools eines aktuellen Browsers heraus. Spätestens dann, wenn man die dabei übermittelten Parameter ermittelt hat und mit deren Namen mittels
grep in der entpackten Firmware sucht (ob man dazu dann unbedingt Freetz(-NG) braucht, steht noch einmal auf einem anderen Blatt - es geht hier ja erst mal um die Analyse und Freetz macht schon noch deutlich mehr und vieles anders, als die originale AVM-Firmware), findet man auch die passenden Lua-Files.
Da das auch noch (zumindest in Teilen) von der tatsächlich verwendeten Firmware-Version abhängig ist, wo sich manche Funktion befindet und was da zu ändern wäre (die Versionsnummer der 6490-Firmware wurde bisher ja auch noch verschwiegen), bringt irgendeine "pauschale" Aussage in diesem Punkt ohnehin nichts.
Die Firmware wandelt sich jedenfalls mit jeder weiteren Version immer mehr in Richtung einer "Single-Page Application", bei der serverseitig jede Menge Lua-Code im Spiel ist (die neuesten Inhouse-Versionen zeigen sogar, daß ein zuvor nur angedeutetes serverseitiges Framework als REST-Interface immer mehr Form annimmt - in
/usr/rest_api, wenn auch wohl die nächste Version immer noch aus "voll ausimplementierten" Spezial-Seiten bestehen wird), der in Form von Objekten in
/usr/lua zu finden ist (ein weiterer Teil sind Glue-Libraries, die Infos aus den proprietären Binärkomponenten über Lua-Interfaces zugänglich machen) und praktisch alles das, was clientseitig innerhalb der "Hauptseite" zu erledigen ist, über ein JS-Framework implementiert wurde.
Die Frage, die Du Dir stellen solltest, ist also nicht die, ob Dir jemand genau sagen kann (will), wo Du da was ändern sollst ... Du müßtest Dir halt die Firmware entpacken und Dir darin dann die Mechanismen durch Analyse der Sourcen erschließen. Wie das Entpacken funktioniert, ist hier im Board mehrfach beschrieben - bei der 6490 muß man dann halt noch beachten, auf welchem Core das GUI letztlich implementiert ist, denn auch das hat sich mit der 06.8x dann geändert. Sogar die passenden Werkzeuge findet man (auch ohne eine Freetz-Toolchain bemühen zu müssen) für x64-Linux in Form von vorkompilierten Programmen.
Ob man das dann lieber mit Freetz macht (und das System dabei deutlich weiter verändert, als nur die gewünschten Funktionen auszubauen - wobei man auch das Wiederherstellen von Einstellungen dann nicht außer acht lassen darf, denn das ist - bei leeren bzw. "standardmäßigem" Inhalt der Sicherungsdatei - auch nicht viel anders als ein Löschen von Einstellungen) oder eben doch "von Hand" und sich dabei auf die selbstgemachten Änderungen beschränkt, ist letztlich wieder nur Geschmackssache.
Da dürfte ein "Plan", wie man dabei tatsächlich vorgehen will, viel mehr wert sein ... denn vermutlich wird es niemandem "aus dem Stand" gelingen, die erforderlichen Änderungen auf einen Schlag exakt so vorzunehmen, wie sie notwendig wären (weder von der korrekten Syntax noch vom Umfang her, denn es gibt da durchaus denkbare Seiteneffekte) - daher wäre es schlauer, man schafft sich erst einmal einen Shell-Zugang zum korrekten Core, auf dem das GUI arbeitet (dazu muß man auch nur ein einziges SquashFS-Image erstellen und flashen und nicht gleich alle vier Partitionen für ein komplettes Set) und mit diesem kann man dann nach Herzenslust an den eigenen Änderungen arbeiten - wenn man die Dateien z.B. durch ein
bind-Mount beschreibbar gemacht hat.
Etwas umzusetzen, was tatsächlich den Umfang der Planungen aus #1 hat und das nur durch das ständige neue Erstellen und Flashen kompletter Images, halte ich jedenfalls für das deutlich falsche Herangehen an ein solches Problem - selbst wenn man irgendwann mal mit dem eigenen Signieren von Images beginnen sollte und damit nicht mehr jede Änderung der Firmware über den Bootloader erfolgen müßte.
Mit einer Shell hat man da ebenfalls (wenn man sich zuvor eingelesen und die Mechanismen auch wirklich verstanden hat) deutlich mehr Optionen und auch den Einbau einer GUI-Möglichkeit zur Umschaltung auf das alternative System (um mal etwas Eigenwerbung zu betreiben) sollte man hier in Erwägung ziehen ... eben weil man von dem einen System aus durch simples Kopieren der Image-Datei in die passende Partition schon den gesamten notwendigen "Installationsprozess" erledigt hätte und da nicht jedesmal eine komplette Installation ablaufen lassen muß, nur um irgendwelche Text-Dateien (etwas anderes sind die Lua- und JS-Files ja nicht) zu ändern, weil die vorhergehende Änderung fehlerhaft/nicht vollständig war.
