[Info] Boot-Manager - Umschalten zwischen den zwei Systemen in einer (passenden) FRITZ!Box

[NDiIPP]

Übergeben die tatsächlich einen FDT beim Start?

Da es (7580 @1.3082 @FRITZ!OS 7.12) /proc/device-tree/chosen gibt und eine Abfrage von bspw. "/proc/device-tree/chosen/bootloaderVersion" (welche ja bei deinem Bootmanager als entsprechender Check verwendet wird) auch die Bootloader-Version liefert, war ich bisher davon ausgegangen. Liege ich damit falsch?

Hat mal jemand einen Bootloader-Dump einer 7580 mit einer alten Version, wo die Änderung noch möglich ist/war?

Hast eine PN.

Gerne auch noch ein Listing von "/proc/device-tree", da wird der FDT im laufenden System zugänglich gemacht.

Im Anhang von einer 7580 @1.3082:

 

[PeterPawn]

Dann werde ich mal meine Theorie prüfen anhand des Dumps (geladen habe ich ihn also) ... kennt irgendjemand auch noch eine IPQ40x9-Box mit einem Bootloader, der die persistente Änderung von "firmware_version" zuläßt bzw. kennt irgendjemand eine Puma6-Box, bei der das nicht funktioniert?

Wenn nicht, würde ich nur bei MIPS-Boxen nach dem Bereich mit den Finalisierungsdaten im Bootloader suchen und bei den anderen Modellen einfach feste Annahmen treffen.

 

[eisbaerin]

Ich habe noch einmal gründlichst alle möglichen Fehler bei mir geprüft, aber da sollte nichts sein.
Die reboot.* sind ja auch zwischen der 7490 und der 7520/30 gleich.

wurde es von mir auch mit 07.19 getestet und zwar auf einer 7490, bei der es möglich ist, das Branding permanent zu ändern.

Mit welcher FW hast du das zuletzt gemacht?
Ich habe da einen Verdacht:
AVM hat doch kürzlich die Auswahlfenster vergrößert und damit anders programmiert. (z.B. bei der 7530 ab 07.19-78907-Inhaus oder 07.19-78989-LabBETA)
Könnte es damit zusammenhängen?
Weil ich ja genau dann das weiße Fenster bekomme, wenn die OEM-Auswahl erscheinen soll.
Ich vermute, daß da jetzt deine geänderten reboot.* nicht mehr kompatibel sind.

EDIT:
Meine add_to_system_reboot.sh ist vom 27.05.2020 und 15.303 Byte groß.
Sollte doch die aktuelle sein.

 

[PeterPawn]

Denkbar, daß AVM da noch einmal geändert hat, wobei "allgemeine Änderungen" am Erscheinungsbild eigentlich fast immer eher über CSS erfolgen und da würde ich - rein vom Gefühl her, ohne das genauer angesehen zu haben - auch die Änderung von Größen und Erscheinungsbild von HTML-Elementen wie SELECT-Boxen einordnen.

Die 7490-Version, mit der es offenbar noch funktioniert, sieht man ja im Screenshot weiter vorne (77415) ... die ist tatsächlich mittlerweile 8 Wochen alt und stammt noch aus der Zeit, wo ich "modfs" generell an die neue Labor-Reihe angepaßt habe.

Seitdem habe ich keine weitere AVM-Firmware mehr installiert/getestet, weil mir das ziemlich auf den Geist geht und ich nicht wirklich bereit bin, für AVM den Beta-Tester zu geben, solange nicht klar ist, wie "stabil" die gerade neu erschienene Version hinsichtlich ihres Aufbaus nun ist - da weiß ich mit meiner Zeit Besseres anzufangen. Deshalb schaue ich immer nur "drauf" (und auch das lange nicht auf jede Version, schon gar nicht immer auf die Inhouse-Varianten) ... bis es eine Firmware bei mir tatsächlich zur Installation auf einer Box schafft, sind noch einige Hürden zu nehmen.

Ich hatte ja auch (absichtlich) seit Januar gewartet (da gab's den letzten größeren Umbau, der mir aufgefallen ist) und erst Mitte April dann mit der "offiziellen" Labor-Version die Änderungen am "modfs" vorgenommen ... ggf. war auch das dann noch "zu früh", wenn's wirklich an der Firmware liegen sollte.

Es ist also durchaus denkbar, daß AVM da mittlerweile wieder etwas geändert hat - was sagt denn der JS-Debugger zu dem Fehler, der bei Dir offensichtlich die Anzeige verhindert? Wenn ich die Dateien "reboot.js" und "reboot.lua" aus den Versionen 77415 und 79325 (das ist die aktuelle - alles 7490) vergleiche, finde ich darin keinen Unterschied.

Wenn es also Änderungen bei AVM gab, dann eher am "JS framework" in den Dateien "avmcore.js" und/oder "avmcontent.js" und wenn die sich tatsächlich auf meine Erzeugung von HTML-Elementen auswirken (die ich ja absichtlich mit denselben Funktionen wie die AVM-Programmierer umsetze, weil man davon ausgehen kann, daß Änderungen durch AVM so erfolgen, daß da auch die Leute bei AVM nicht ständig alles umstellen müssen auf neue Konstrukte), dann müßte das für andere Seiten/JS-Code-Files ja auch gegolten haben.

Die letzten Änderungen an der "add_to_system_reboot.sh" hatten nur etwas mit Freetz-NG zu tun bzw. mit einem neuen OS für den Build-Host, wo die "in-place"-Option des "sed" nicht funktioniert, solange ein aktives SELinux nicht berücksichtigt wird. Der andere Punkt, der Ende Mai noch Eingang fand, soll(te) die HTML-Erzeugung per JS gegen fehlende JSON-Daten "immunisieren" und eine passende Fehlernachricht ausgeben.

Ansonsten ist der verwendete JS-Code mittlerweile 8 Wochen alt ... sollte AVM tatsächlich noch Änderungen vorgenommen haben, die sich auf den per Patch hinzugefügten Code auswirken, müßte man also zunächst mal einfach feststellen, wo es knallt - und das zeigt eben der einfache Blick in den JS-Debugger bereits, dazu muß ich nicht erst bei mir eine neue Version installieren, wenn Du das Problem bei Dir bereits hast.

 

[eisbaerin]

Wenn ich die Dateien "reboot.js" und "reboot.lua" aus den Versionen 77415 und 79325 (das ist die aktuelle - alles 7490) vergleiche, finde ich darin keinen Unterschied.

Da ist ja im Original auch kein Auswahlfenster vorhanden.
Da müßte man IMO eine Seite mit Auswahlfenster vergleichen.

der einfache Blick

Aber nur mit deinem geschulten Auge. Ich sehe da nix oder weiß nicht mal wo ich da genau schauen soll.

Kannst du mir da bitte helfen. Ich nutze FF unter Win10, kann aber auch was anderes installieren, wenn das für dich leichter ist.

Ich kann dir auch einen Zugriff auf die Box freischalten.

 

[PeterPawn]

Drücke einfach mal die F12 im Browser, wenn Du auf der "Neustart"-Seite bist. Dann notfalls noch einmal "reload" für die Seite (auf das "Neustart" in den "Tabs" klicken) und dann sollte sich im Developer-Fenster oben rechts eine Fehlermeldung (iirc in roter Schrift) zeigen, wenn es zu einer Exception kommt (die für mich die einzige Erklärung wäre, warum nichts angezeigt wird).



Gleichzeitig wird im mittleren Teil dann das JS-File angezeigt, in dem die Exception aufgetreten ist ... im AVM-Original ist das schlecht zu lesen, deshalb klickst Du dann unter der Datei auf das "{ }" - damit wird der Code neu formatiert und dennoch sollte die Anweisung, die zur Exception führte, hervorgehoben und zentriert sein im Fenster darüber.

Es ist wirklich ganz einfach ... zumindest die "Suche" nach der Fehlermeldung und der Stelle im Code, wo das Problem auftritt.

 

[eisbaerin]

Jo, danke, mit deinem Bild ging es jetzt, nachdem ich alle Einstellungen so vorgenommen habe.

Nach Ausnahmefehler angehalten
TypeError: sb.options is undefined

und Zeile 7 ist rot:

function buildBootmanager(data){function gv(src,id){var r=src.filter(function(e){return e.id===id});if(r.length>0)return r[0].value};function nl(frag,cnt=1){while(cnt--){html2.add(frag,html2.br())}};var m=data.filter(function(d){return d.name==="messages"})[0].obj;var v=data.filter(function(d){return d.name==="values"})[0].obj;var r=html2.fragment();if(v.length==0){html2.add(r,html2.h3({},gv(m,"nodata")));return r}html2.add(r,html2.h3({},gv(m,"headline")));nl(r);var ct=html2.span();var at=html2.span();var cs=gv(v,"current_switch_value");html2.add(ct,html2.strong({style:gv(m,"style_caption")},gv(m,"currsys")));html2.add(ct,html2.printf(gv(m,"switchvalue"),cs));nl(ct,2);html2.add(ct,html2.printf(gv(m,"version"),gv(v,"active_version"),gv(v,"active_date")));if(gv(v,"active_modified_at")){nl(ct);html2.add(ct,html2.printf(gv(m,"modified"),gv(v,"active_modified_at"),gv(v,"active_modified_by")))}nl(ct,2);html2.add(at,html2.strong({style:gv(m,"style_caption")},gv(m,"altsys")));html2.add(at,html2.printf(gv(m,"switchvalue"),cs?((parseInt(cs)+1)%2).toString():"0"));nl(at,2);var inactive=gv(v,"inactive_version");if(inactive!="missing"){if(inactive.length>0){html2.add(at,html2.printf(gv(m,"version"),gv(v,"inactive_version"),gv(v,"inactive_date")));if(gv(v,"inactive_modified_at")){nl(at);html2.add(at,html2.printf(gv(m,"modified"),gv(v,"inactive_modified_at"),gv(v,"inactive_modified_by")))}}else{gv(m,"altinv").split("\n").forEach(function(l){html2.add(at,l);nl(at)})}}else{html2.add(at,gv(m,"altmiss"))}nl(at,2);var radios=html2.radios({name:'linux_fs_start',selected:(gv(v,"system_is_switched")=="true"?'alternative':'running'),attr:{disabled:(inactive=="missing"?true:false),onClick:onChangeLinuxFsStart},options:[{value:'running',text:ct},{value:'alternative',text:at,}]});html2.add(r,radios);html2.add(r,html2.h4({},gv(m,"brndhead")));var cb=gv(v,"switch_branding_support");if(cb=="false"){html2.add(r,html2.span({},gv(m,"brndunsupp")));html2.add(r,html2.hiddenInput({name:"alternative_branding",value:gv(v,"current_branding")}))}else{var rb=html2.span({id:"running_branding",style:(gv(v,"system_is_switched")=="true"?'display: none':'')});if(cb=="both_fixed"||cb=="running_fixed"){html2.add(rb,html2.printf(gv(m,"brndcurrfixed"),html2.strong({},gv(v,"current_branding"))));html2.add(r,html2.hiddenInput({name:"running_branding",value:gv(v,"current_branding")}))}else{if(gv(v,"active_brandings").split(" ").length>1){html2.add(rb,html2.printf(gv(m,"brndmulti"),html2.strong({},gv(v,"current_branding"))));nl(rb);var sb=html2.selectBox({id:"uiRunningBranding",name:"running_branding"});gv(v,"active_brandings").split(" ").forEach(function(o){sb.options.add(html2.option({value:o,selected:gv(v,"current_branding")==o?true:false},o))});html2.add(rb,html2.label({for:"uiRunningBranding",style:gv(m,"style_sblbl")},gv(m,"brndset")));html2.add(rb,sb)}else{html2.add(rb,html2.printf(gv(m,"brndcurrsingle"),html2.strong({},gv(v,"current_branding"))));html2.add(r,html2.hiddenInput({name:"running_branding",value:gv(v,"current_branding")}))}}html2.add(r,rb);var ab=html2.span({id:"alternative_branding",style:(gv(v,"system_is_switched")=="true"?'':'display: none')});if(inactive!="missing"){if(inactive.length>0){if(cb=="both_fixed"||cb=="alternative_fixed"){html2.add(ab,html2.printf(gv(m,"brndaltfixed"),html2.strong({},gv(v,"inactive_brandings"))));html2.add(r,html2.hiddenInput({name:"alternative_branding",value:gv(v,"alternative_branding")}))}else{if(gv(v,"inactive_brandings").split(" ").length>1){html2.add(ab,html2.printf(gv(m,"brndmulti"),html2.strong({},gv(v,"current_branding"))));nl(ab);var asb=html2.selectBox({id:"uiAlternativeBranding",name:"alternative_branding",style:gv(m,"style_selbrand")});gv(v,"inactive_brandings").split(" ").forEach(function(o){asb.options.add(html2.option({value:o,selected:gv(v,"current_branding")==o?true:false},o))});if(asb.selectedOptions.length==0){asb.options.forEach(function(o){if(o.value==gv(v,"current_branding"))o.selected=true})}html2.add(ab,html2.label({for:"uiAlternativeBranding",style:gv(m,"style_sblbl")},gv(m,"brndset")));html2.add(ab,asb)}else{html2.add(ab,html2.printf(gv(m,"brndaltsingle"),html2.strong({},gv(v,"inactive_brandings"))));if(gv(v,"inactive_brandings")==gv(v,"current_branding")){html2.add(ab,gv(m,"brndaltnochg"))}else{html2.add(ab,html2.printf(gv(m,"brndaltset"),html2.strong({},gv(v,"current_branding"))));nl(ab);html2.add(ab,html2.printf(gv(m,"brndaltnew"),html2.strong({},gv(v,"inactive_brandings"))))}html2.add(r,html2.hiddenInput({name:"alternative_branding",value:gv(v,"inactive_brandings")}))}}}else{html2.add(ab,gv(m,"brndaltinv"))}}html2.add(r,ab)}return r}

Hier ist die 2. Zeile rot, eigentlich Zeile 206:

   gv(v, 'active_brandings').split(' ').forEach(function (o) {
            sb.options.add(html2.option({
              value: o,
              selected: gv(v, 'current_branding') == o ? true : false
            }, o))
          });

Reicht das?

 

[PeterPawn]

Versuche es mal bitte mit dem Patch im Anhang (für die "add_to_system.sh") - natürlich bevor sie aufgerufen wird ("patch -p1 < file" ... wenn das aktuelle Verzeichnis das YourFritz-Repo ist).

AVM hat für die "neue" SELECT-Box tatsächlich ein neues Objekt kreiert, was die "options"-Collection nicht mehr kennt. Nach dem Blick in die "avmcore.js" sollte die "alte" SELECT-Box unter dem Namen "selectBoxPlain" weiterhin existieren (die hat auch die "options"-Collection, wie man sieht:

) und der Patch stellt lediglich auf deren Verwendung anstelle von "selectBox" um.

Wobei das für mich ein weiteres, deutliches Zeichen ist, daß man bei AVM mittlerweile vor lauter Langeweile schon gar nicht mehr weiß, was man noch implementieren soll, bevor man die Version endlich freigibt.

Ich verstehe ja, daß das in der Zeit des Lockdowns nicht sinnvoll/vertretbar war ... aber irgendwann muß man jetzt wohl auch mal den Mut zusammennehmen. Wenn's am Ende noch austauschbare Hintergrund-Bilder oder gar "Themes" für's GUI gibt, überschätzt man meiner Ansicht nach die Bedeutung dieser Oberfläche und die Häufigkeit ihrer Benutzung beim "durchschnittlichen Kunden" deutlich.

EDIT1:
Korrektur ... warte mal noch ... die "neue" "selectBox" hat ja doch eine "options"-Eigenschaft, wie ich gerade sehe. Das hätte mich auch verwundert ... also muß es irgendwo noch eine andere Ursache geben für die Ansage, daß "sb" keine "options"-Property hat. U.U. ist das auch darauf zurückzuführen, daß "sb" gar nicht erst erzeugt wird - wobei das eine andere Fehlermeldung zur Folge haben sollte (schon davor).

Da werde ich um den eigenen Test wohl doch nicht herumkommen ...

EDIT2:
So sah die "alte" SELECT-Box in der "avmcore.js" aus und wenn ich das richtig lese, wurde die tatsächlich zur "selectBoxPlain". Damit sollte der Patch auch funktionieren.

 

[eisbaerin]

Ja, danke, es geht wunderbar! Du bist der Größte!

"patch -p1 < file" habe ich nicht gemacht, einfach die eine Zeile per Hand getauscht.

Natürlich auch die FW nicht komplett neu gebaut und geflasht (der Flash muß geschont werden), sondern nur die reboot.js übermountet.

Bild folgt:

 

[PeterPawn]

Dann danke für die Info.

Ich werde das in der nächsten Version von "add_to_system.sh" dann entsprechend berücksichtigen - ob mit oder ohne Unterstützung der "alten" 07.19-Lösung, weiß ich noch nicht genau.

Vermutlich baue ich das auch zeitnah und als Update für "modfs" ein ... das betrifft ja dann all diejenigen, die den Boot-Manager in aktuelle Labor-Firmware integrieren wollen und da verzichte ich erst mal auf die Erweiterungen mit dem variablen OEM.

Beim Untersuchen, wie das am besten einzubauen wäre, kam ich dann nämlich wieder zum TFFS (und einer neuen Variablen "SoftwareFeatures" im Urlader-Environment, über die man u.a. die Sprache und das Land "voreinstellen" kann bei der neuen Firmware) und zu weiteren Änderungen von AVM, die erst mal "aufgezeichnet" und an den richtigen Stellen eingearbeitet werden müssen. Daher dauert das mit dem variablen OEM auch noch - macht ja keinen Sinn, da etwas anzubieten, was sich nächsten Monat auch wieder ändert oder was allzu sehr von der jeweiligen Firmware-Version abhängt (wenn man auch ältere Versionen "beglücken" will mit dieser neuen Funktion).

 

[eisbaerin]

Daher dauert das mit dem variablen OEM auch noch

Stört mich nicht, bei mir geht es ja.

Obwohl ich es in der GUI nicht unbedingt brauche, da ich es über die featovl in wenigen Sekunden mache.
Und mit der neuen Variablen ist es bei mir auch nur noch ein Befehl/Skript.
Aber, da hast du Recht, das ist nichts für die Allgemeinheit und schon gar nicht für den DAU.

BTW: Ich baue die FW immer noch auf meiner 7580 im RAM, die hat doch sonst den ganzen Tag nichts zu tun.
Natürlich mußte ich dafür dein Script etwas verändern und andere binarys verwenden.

 

[lubi]

Ja, ich danke auch. Ich teste die Labor-Firmware unter "modfs". Nach der von Dir angegebenen Änderung der "add_to_system.sh" ist auch das Umschalten über die Weboberfläche unter "System - Sicherung - Neustart" bei den aktuellen Labor-Firmwaren wieder möglich.

 

[PeterPawn]

"modfs" auf die Zwischenversion aktualisiert, getestet mit Labor-Version vor und nach der AVM-Änderung von "selectBox":

 

[prisrak1]

gibts ein Befel über Telnet um System zu wechseln, wenn Boot-Manager in aktuellen System nicht eingebaut wurde? Im Freetz gehts gerade auch nicht. Es war eine Test Freetz-Version.

Das mit dem FTP und SETENV linux_fs_start 0/1 kann ich ja ausführen, aber dafür muß die Box mit Lan am Laptop angeschlossen sein. Somit wäre ein Befehl über Telnet für diesen Zweck besser geeignet, denn diese F!B hängt im anderem Geschoss im Hausnetz. Beim Testen der verschiedenen Images würde ich sie gerne am Platz belassen und nicht jedes Mal runterschleppen wollen.

 

[lubi]

Umschaltung auf 2. OS (von 1 nach 0) "> " ist Eingabe-Prompt

> cat /proc/sys/urlader/environment | grep linux
linux_fs_start 1
> echo linux_fs_start 0 > /proc/sys/urlader/environment
> cat /proc/sys/urlader/environment | grep linux
linux_fs_start 0
> reboot

 

[prisrak1]

BTW: Ich baue die FW immer noch auf meiner 7580 im RAM ..

das ist doch eine super Idee! Bei mr läuft der Laptop machmal Stundenlang. Wie geht man da vor? wie in freetz-linux?

 

[PeterPawn]

Wie geht man da vor? wie in freetz-linux?

Das bezieht sich nicht auf den Bau einer kompletten Freetz-Version, sondern nur auf das Ändern der AVM-Firmware mit "modfs". Ich wage mal die Prognose, daß selbst die Boxen mit 512 MB RAM nicht in der Lage sind, die Toolchain für Freetz zu kompilieren - ggf. klappt noch das Übersetzen einzelner Pakete direkt auf der Box. Wobei auch dazu halt die passende Infrastruktur auf der Box vorhanden sein sollte ... von "autoconf" bis "pkgconfig" und den Header-Files - die Toolchain-Dateien für die Target-Box kann man aber tatsächlich von Freetz bauen lassen. Nur den Transfer auf das Zielsystem und die passende Zusammenstellung aller benötigten Dateien dort, muß man schon "von Hand" ausführen. Das ist damit auch eher etwas "Hardcore" bzw. für eigene Programme auf der Box, die man nicht erst lange mit 'configure' an die Plattform anpassen muß und wo man die Kommandos zur Übersetzung per Batch-Skript oder von Hand eingeben kann - es fehlt nämlich schon das 'make'-Kommando (außer man baut auch das selbst, dafür gibt's in Freetz auch ein Package).

Es wird also eher ein Wunschtraum bleiben, ein Freetz-Image direkt auf der FRITZ!Box selbst zu erstellen ... bei "modfs" klappt das auch nur deshalb, weil die Tools bereits vorübersetzt sind und die Änderungen an der Firmware sich auf Patches bzw. das Hinzufügen weiterer, vorkompilierter Programme beschränken.

 

[eisbaerin]

Dank der guten Vorarbeit, läuft es auch mit der 7.20 auf der 7590:

 

[PeterPawn]

Ist das Ändern des Brandings wieder das selbst eingebaute oder hast Du tatsächlich eine 7590 mit einer EVA-Version, wo "firmware_version" (im Original) noch geändert werden kann?

Die neue Version, wo das auch bei anderen Bootloadern noch machbar sein wird, ist in Arbeit: https://github.com/PeterPawn/YourFritz/blob/bootmanager/bootmanager/yf_bootmanager

Zwar ist jetzt in der Firmware mittlerweile "alles" enthalten, aber es gibt damit nun wieder unterschiedliche Features - je nach eingestelltem Branding - und das macht den Wechsel auch für Tests wieder interessant.

==========================================================================

Ich kann mittlerweile auf der Box ziemlich gut (und auch einigermaßen schnell, das war die eigentliche Herausforderung - neben dem begrenzten Vorrat an Kommandos, weil das auch in der originalen AVM-Firmware funktionieren soll, ohne zusätzliche Binaries) erkennen, ob der Bootloader die persistente Änderung von "firmware_version" zuläßt oder nicht. Getestet ist das bisher auf 7490 (beide Varianten), 7412, 7580 (auch beide Varianten), 7590, 6490 ... die älteren Modelle/Plattformen verwenden ein anderes Format an dieser Stelle (mind. bis zur 7390) und interessieren für diese Frage ohnehin nicht.

Unklar ist noch, ob das auf IPQ401x-Boxen (4040 (auch wenn die "not-mirrored" ist), 7520, 7530) auch funktioniert ... wenn zwei bis drei Leser "hier" schreien und Zugriff auf eine Shell haben und obendrein das auch noch für mich testen würden, kriegen diese eine "Vorabversion" von mir (ich melde mich dann per "Conversation"), wo das noch in drei einzelne Schritte (Extrahieren des Bootloaders aus dem Gerät, Extrahieren des Konfigurationsbereichs aus dem Bootloader (bzw. aus EVA, das ist bei manchen Modellen ja auch "zweistufig" beim Booten bzw. es existieren Kopien, wenn NAND-Flash verwendet wird für den Loader) und schlußendlich das Extrahieren der Daten aus dem Konfigurationsbereich) aufgeteilt ist - dazu muß man also die Skript-Dateien noch selbst der Reihe nach aufrufen (das sind einfach die drei notwendigen Schritte und an jeder der "Schnittstellen" kann man in den Prozess auch mit zuvor erstellten Dateien (Dumps) wieder einsteigen).

Bei den AR10-Boxen bin ich mir zwar fast sicher, daß die genauso arbeiten wie die mit VR9 (wobei auch hier Unterschiede existieren, bei der 7412, wo der Bootloader auch im NAND-Flash gespeichert ist, liegt der Bereich nicht mehr vorne im Loader-Code, sondern steht erst dahinter), aber wenn jemand noch eine 7272 oder eine 3272 haben sollte und zum Test bereit wäre, könnte man diese These auch noch einmal absichern.

In der Theorie müßte das alles auch bei den Modellen mit BCM63xxx (7581/7582) funktionieren - wer ein solches Gerät besitzt und dort Shell-Zugriff hat (der auch sehr einfach zu erlangen wäre, wenn er noch nicht vorhanden ist) und obendrein beim Testen helfen möchte (vorher kann/werde ich diese Plattform nicht unterstützen im Boot-Manager), der wäre als Tester auch willkommen.

==========================================================================

Die Dateien für die zwei neuen Möglichkeiten der Änderung des "Brandings" sind mittlerweile auch fertig und im Repo - die eine Variante (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/add_change_oem.sh) wird in die rc.conf eingebaut (das Skript erledigt das gleich, analog zum "add_to_system_reboot.sh" für den Boot-Manager, nur daß hier ein Aufruf für alle Brandings reicht, weil das eine gemeinsam genutzte Datei ist) und erlaubt das Ändern von OEM über die Kernel-Parameter.

Da hier das Ergebnis ausgewertet wird, ist es am Ende auch egal, aus welchem "Teil" der Bootloader-Variablen (kernel_args, kernel_args1 oder kernel_args_tmp) der zu verwendende Wert gesetzt wird - einige sind persistent, andere nur temporär. Aber in jedem Falle ist der Vorteil, daß man die Änderung auch über den FTP-Server im Bootloader oder über dessen serielle Console vornehmen kann - daher hat dieser Weg auch seine eigene Existenzberechtigung in meinen Augen.

Denn die zweite angepeilte Lösung ist zwar in der Lage, noch viel mehr Bootloader-Variablen durch eigene Werte zu ersetzen, aber das Eintragen der gewünschten Werte erfordert den Zugriff auf das TFFS - entweder in einem laufenden FRITZ!OS oder mit einem "Notsystem" (ein paar der "first_aid"-Images ändern ja auch TFFS-Einstellungen) oder auch durch das Schreiben eines neuen TFFS-Images über den Bootloader (EVA/FTP).

Dazu dient dieses Skript: https://github.com/PeterPawn/YourFritz/blob/master/tffs/yf_custom_environment.sh - es ist darauf ausgelegt, entweder explizit per "sh filename" aufgerufen zu werden oder auch per "dot command" (also als ". filename") in ein anderes Shell-Skript eingefügt zu werden. Die beste Stelle für einen solchen Aufruf, an der die Änderungen auch garantiert die "volle Wirkung" entfalten, ist eigentlich die /etc/inittab und daher ist es auch darauf ausgelegt, sich die notwendigen Dateisysteme notfalls selbst zu mounten, wenn sie noch nicht verfügbar sein sollten ... daher kann man das auch noch vor dem Aufruf des Großteils des "init"-Prozesses (in der rc.S (vor 07.20) oder mittlerweile in der /etc/boot.d/1) ausführen lassen.

Um möglichst wenig mit dem vorhandenen Code in Konflikte zu geraten, entfernt der Code auch alle genutzten Shell-Variablen wieder aus der aktuellen Instanz - das ist beim Aufruf über das dot-Kommando ggf. wichtig, auch wenn die Namen der verwendeten Variablen kaum mit anderen kollidieren dürften. Aber so kann man hinterher auch nicht mehr ohne weiteres ermitteln (im Shell-Code innerhalb derselben Instanz), ob dieses Skript genutzt wurde/wird oder nicht.

Das Skript nimmt den Inhalt des TFFS-Nodes mit der Minor-ID 80 (damit überlebt dessen Inhalt auch ein Zurücksetzen auf die Werkseinstellungen, aber kein Recovery) als Text-Datei und betrachtet jede Zeile darin wie eine aus der /proc/sys/urlader/environment (allerdings werden sowohl Leerzeichen als auch Tabulatorzeichen als Trennung zwischen Name und Wert interpretiert, während im procfs von AVM nur Tabulatoren verwendet werden bei der Ausgabe/Anzeige).

Nur wenn sich der gewünschte Wert aus dieser Datei von dem tatsächlich vorhandenen unterscheidet, wird der vorhandene Wert mit dem gewünschten überschrieben ... das minimiert die erforderlichen Schreibvorgänge und reduziert sie auf die Variablen, die vom Bootloader als "fixed properties" immer wieder auf die "Geburtsdaten" gesetzt werden und nicht nur "Vorschläge" in Form von Standardwerten sind (das sind die beiden Kategorien von Variablen, die im Konfigurationsbereich des Bootloaders hinterlegt sind).

Damit sind die Werte bis zum nächsten Systemstart dann überschrieben und alles andere bei AVM, was über den TFFS-Treiber auf diese Werte zugreifen will (und das ist praktisch alles in der Firmware), arbeitet mit diesen neuen Werten.

Natürlich funktioniert das nur mit einer Firmware, die dahingehend geändert wurde, daß sie das Skript auch beim Startvorgang aufruft ... und man muß beim Eintragen der gewünschten Werte in den TFFS-Node 80 all die Vorkehrungen und Besonderheiten beachten, die generell beim Editieren des Inhalts von TFFS-Nodes gelten.

Aber auch dafür gibt es ja entsprechende Unterstützung ... wer sich schon mal mein tvi-Skript ("TFFS vi" - analog zum nvi von AVM, aber smarter) angesehen hat (https://github.com/PeterPawn/YourFritz/blob/master/tffs/fritzos_scripts/tvi), dem ist vielleicht aufgefallen, daß man dem Skript anstelle eines Namens auch eine Nummer als ersten Parameter vorwerfen kann. Dann kopiert es den Inhalt des durch die Nummer spezifizierten TFFS-Nodes in eine temporäre Datei, startet den vi für diese und schreibt, wenn der Inhalt in der Editor-Sitzung tatsächlich geändert wurde, den neuen Inhalt auch wieder ins TFFS zurück (nach Nachfrage). Wer es sich also (von der Kommandozeile aus) einfacher machen will, der kopiert neben dem Skript zum Überschreiben der Urlader-Einstellungen auch gleich noch das Editor-Skript in seine modifizierte Firmware. Dann kann man einfach tvi 80 aufrufen, wenn man Variablen überschreiben will (beim nächsten Start).

 

[eisbaerin]

Ist das Ändern des Brandings wieder das selbst eingebaute

Ja, wenn du damit den bluetooth_key meinst.

oder hast Du tatsächlich eine 7590 mit einer EVA-Version, wo "firmware_version" (im Original) noch geändert werden kann?

Selbst wenn ich die hätte, wäre wegen /proc/device-tree/chosen ja eine Änderung an der gui_bootmanager nötig gewesen, also dann auch "selbst eingebaut".

Ich kann auf der 7520 und 7272 testen.