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

[PeterPawn]

Bisher gab/gibt es die Informationen zu meinem "Boot-Manager" eher verstreut über verschiedene Threads, weil das irgendwann mal "organisch gewachsen" ist, was (iirc) im "modfs"-Thread begann und dann nach und nach auch Einzug in Freetz hielt.

Dieser ominöse "Boot-Manager" (künftig kürze ich den als "BM" ab und lasse die Anführungszeichen auch weg) wird von einem Installationsskript in die AVM-Dateien eingebaut und bietet im AVM-Interface unter dem Punkt "System -> Sicherung -> Neustart" dann seine Dienste an. Diese bestehen einerseits in der Anzeige der in der FRITZ!Box installierten Systeme und andererseits im Angebot, zwischen diesen System-Versionen umzuschalten und dabei ggf. auch noch (sofern möglich) das "Branding" der Box entsprechend anzupassen.

Am Ende sieht das dann z.B. so aus:


Der BM ist eigentlich ein Bestandteil meines YourFritz-Projekts, daher ist er auch in dessen GitHub-Repository zu finden und zwar hier: https://github.com/PeterPawn/YourFritz/tree/master/bootmanager - die richtige Datei wäre dann allerdings gui_bootmanager, während bootmanager ein "älteres Modell" ist, was kein GUI bietet und daher schon längst entsorgt wäre, würde es dort nicht zusätzlich noch eine Sicherung von Einstellungen pro Partition-Set geben.

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

Kurze Erklärung zu den Grundlagen

Viele der neueren FRITZ!Box-Modelle haben zwei voneinander unabhängige Partition-Sets in ihrem Flash-Speicher und speichern bei einem Update die neue Version in den gerade nicht genutzten Partitionen, auf die nach der erfolgreichen Installation dann umgeschaltet wird, so daß diese beim nächsten Start des Gerätes verwendet werden. Die Auswahl der zu nutzenden Partitionen erfolgt dabei anhand einer Variablen im Bootloader der Box, welche über das laufende System oder auch über den FTP-Server im Bootloader (der sich "EVA" nennt) auf einen passenden Wert gesetzt werden kann. Üblich sind hier die Werte "0" und "1", wobei ein fehlender Wert - bei passenden Modellen - mit "0" gleichzusetzen ist ... ach so, diese Variable hört auf den Namen "linux_fs_start".

Der BM macht jetzt nichts anderes, als sich die beiden installierten Systeme genauer anzusehen und die dort enthaltenen Angaben zu extrahieren und für die Anzeige aufzubereiten. Wünscht der Benutzer beim Neustart des Gerätes die Auswahl des anderen Systems (oder auch ein anderes "Branding" bei den Modellen, wo eine (dauerhafte) Änderung möglich ist), wird vor dem Neustart noch der neue Wert von "linux_fs_start" (und "firmware_version", falls das Branding änderbar ist) gesetzt.

Da es mittlerweile bei vielen FRITZ!Boxen nicht mehr möglich ist, den Wert für "firmware_version" dauerhaft zu ändern (der wird vom Bootloader beim nächsten Start dann wieder auf die "Geburtsdaten" der Box gesetzt), berücksichtigt das Skript auch ein Überschreiben des Wertes für "OEM" (da landet "firmware_version" am Ende im Environment des laufenden Linux-Systems) mit einem festen Wert in jener Datei, wo vom Hersteller normalerweise "firmware_version" ausgelesen würde. Sollte sich durch eine solche Änderung eine (Pseudo-)"Umschaltung" des Brandings ergeben beim Wechsel der Partitionen, wird das entsprechend mit angezeigt.

Da es mitunter auch ganz nützlich sein kann zu erfahren, womit eigentlich die Firmware in einem Partition-Set "behandelt" wurde (und irgendeine Änderung muß sie erfahren haben, sonst wäre der BM ja in keinem der beiden Sets enthalten), wird auch noch anhand von "Marker-Dateien" versucht zu erkennen, welches Projekt das vorhandene Dateisystem-Image erstellt hat. Hier werden z.Zt. nur YourFritz, Freetz und "modfs" unterstützt, für Freetz-NG konnte keine Einigung auf eine passende Marker-Datei (die eine Identifikation anhand des Namens und nicht anhand ihres Inhalts erlaubt) gefunden werden. Ähnliches gilt für die Erkennung eines festen "Brandings" in Freetz - hier wird eine abweichende Form der "Fixierung" verwendet, für deren Erkennung noch ein zusätzlicher Patch erforderlich ist, der Bestandteil von Freetz ist. Daher kann/wird aber die originale Datei in Freetz nicht 1:1 funktionieren ... und Änderungen meinerseits an dieser Datei benötigen immer erst noch eine Aktualisierung des Stands für das YourFritz-Repository im Freetz-Projekt, bevor Freetz-Benutzer mit der jeweils aktuellen Version rechnen können in ihrem neuen Image.

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

Unterstützte Modelle

Derzeit ist der BM in der Lage, FRITZ!Box-Modelle mit SoCs aus der VR9-Reihe von Lantiq, der GRX5-Reihe von Lantiq/Intel, der IPQ40x9-Reihe von Qualcomm/Atheros und der Puma6-Reihe von Intel zu analysieren und die möglichen Umschaltungen auf diesen Geräten vorzunehmen. Das deckt schon eine ganze Reihe an FRITZ!Box-Modellen ab, von der 74xx-Reihe (die fast immer auf VR9 basiert) über die 7560/7580/7590 mit den GRX5-Chipsets und die 7520/7530 (IPQ4019), bis hin zu den DOCSIS3-Modellen (6490, 6590, 6430) mit dem Puma6-Chipset.

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

Dieser Thread soll künftig als "zentrale Anlaufstelle" für Fragen rund um den BM dienen, damit diese nicht länger über viele andere Threads verstreut und damit nur schwer in einer passenden zeitlichen Abfolge zu lesen sind. Es wird allerdings meinerseits auch kein Kopieren alter Beiträge zum BM in diesen Thread geben - wer irgendwo einen Beitrag findet, von dem er der Meinung ist, der sollte von hier aus verlinkt werden, kann mir ja gerne hier eine entsprechende Nachricht hinterlassen ... ich würde das dann in die folgende Liste einpflegen (zumindest wenn ich mit der Ansicht, daß es dabei um den BM geht, übereinstimme).

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

Links zu anderen Beiträgen/Threads, die sich mit dem Thema "Boot-Manager" befasst haben:
(ohne jeden Anspruch auf Vollständigkeit, erst mal nur als Beispiele)

[Info] - modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Herzlichen Dank für die Hilfestellungen: Ich habe mir als erstes Deinen Patchvorschlag vorgenommen ++ sh -x ../../tools/yf/bootmanager/add_to_system_reboot.sh + '[' -z 1und1 ']' + '[' -z . ']' + TargetDir=./filesystem/ + JsFile=usr/www/1und1/system/reboot.js +...

www.ip-phone-forum.de

Mit welchem Befehl bekomme ich die FW Version des inaktiven Systems in einer 7490/7580/7590 raus?

Hat bitte mal einer den richtigen Befehl für das CLI.

www.ip-phone-forum.de

 

[eisbaerin]

@PeterPawn
Ich habe da noch eine kleine Unstimmigkeit im gui_bootmanager gefunden.
Ich weiß nicht ob du sie beheben willst?

Die 7520 ist ja nun ein Sonderfall, da sie 2 verschiedene Box-FW in den Partitionen haben kann.
Ich habe z.Z. in der einen Partition eine 7520er FW und in der anderen eine 7530er.
In diesem Fall erkennt der gui_bootmanager nicht die inaktiven Brandings, weil er auf den falschen Ordner zugreift.
Und es wird auch die falsche "inactive system version" angezeigt, da müßte 164.07.14 stehen, da es eine 7530er FW ist.

7520+10:$(pwd)# gui_bootmanager debug
system type = IPQ4019
system selector = 0
system is switched = false
system branding = 1und1
system branding is changeable = false
active kernel = /dev/mtdblock0
active filesystem = /dev/mtdblock5
active system version = 175.07.19-79182
active system date = 04.06.2020, 06:51:53 Uhr
active system modification date = 06.06.2020, 07:08:21 Uhr
active system modification source = modfs
brandings supported on active system = 1und1 avm avme
inactive kernel = /dev/mtdblock3
inactive system is installed = true
inactive filesystem = /dev/mtdblock6
inactive filesystem mounted on /var/tmp/2101_1591715781/alt_root
inactive system version = 175.07.14
inactive system date = 08.11.2019, 05:46:33 Uhr
inactive system modification date = 09.02.2020, 01:58:07 Uhr
inactive system modification source = Freetz
find: /var/tmp/2101_1591715781/alt_root/etc/default.Fritz_Box_HW247: No such file or directory
brandings supported on inactive system =
inactive filesystem dismounted

Jetzt wirst du dir vielleicht sagen: "Wozu auch, das Branding kann ja sowieso nicht geändert werden".
Ich habe mir aber einen anderen Namen in den Environments genommen,
und den könnte ich ändern, wenn dein Programm es richtig erkennen würde.

 

[PeterPawn]

OK, das ist ein Problem, weil dann eben "$CONFIG_PRODUKT" in den beiden Firmware-Versionen unterschiedlich ist in der jeweiligen "rc.conf". Ich denke mal darüber nach, wieviel Aufwand eine Anpassung wäre und wie oft das wohl vorkommen wird, daß auf einem Gerät einmal die originale und einmal eine "Alien"-Firmware installiert ist. Je nach Aufwand (es braucht ggf. auch noch eine passende Fehlermeldung, wenn die Brandings nicht ausgelesen werden können) werde ich in die eine ($CONFIG_PRODUKT erst auslesen aus dem "fremden" System) oder andere Richtung (geht nicht, mit passender Fehlermeldung) ändern.

EDIT: Die neu eingecheckte Version sollte das jetzt richtig erkennen können (Download und Aufruf mit "debug" geht ja auch, ohne daß man extra ein neues Image erstellen muß - der Link zeigt schon auf das "raw file" und kann direkt in einem (passenden) "wget" verwendet werden) - wenn's paßt, mache ich später auch "modfs" neu.

Außerdem hätte ich noch eine Nachfrage zur Sicherheit (von Erkenntnissen): Gibt's bei den IPQ-Modellen den Pfad "/proc/device-tree/chosen"? Im Moment mache ich die Entscheidung, ob sich das Branding dauerhaft ändern läßt, nur an der Existenz oder dem Fehlen dieses FDT (das ist der "flattened device tree" nach der OpenFirmware-Spezifikation, der aus dem Bootloader an den Kernel übergeben wird) fest. Ich würde das bei anderen Modellen gerne anhand des Bootloaders erkennen (ich habe eine Idee, wie das funktionieren könnte) ... nur haben die IPQ-Boxen den CONFIG-Bereich an einer vollkommen anderen Stelle und da kann ich mir den Zugriff über ein MTD klemmen.

Bisher kenne ich jedenfalls kein Modell mit FDT (also mit einem Loader, der einen erstellt und beim Start übergibt), wo sich das Branding persistent ändern läßt. Dann würde ich die zusätzliche Erkennung (bzw. die Versuche dazu) nur auf die Modelle ohne FDT beschränken - im Moment werden die halt generell als "änderbar" angesehen, was auch nicht korrekt ist und genau DAS würde ich gerne ändern, wenn mir dann nicht wieder alles mögliche andere unter den Händen stirbt.

Wenn jemand besonders experimentierfreudig sein sollte, kann er/sie ja mal versuchen, welche Kombinationen aus aktiver Kernel- und Dateisystem-Partition sich bei den IPQ-Boxen ergeben, wenn man "linux_fs_start" nicht nur simpel auf "0" oder "1" setzt, sondern auf "0A" bzw. "1A".

Bei den VR9-Boxen wird das "A" einfach ignoriert (weil die Auswertung nur nach dem ersten Zeichen sieht) und bei den GRX-Boxen bringt das die Firmware ziemlich durcheinander. Während der Bootloader offenbar auch nur das erste Zeichen berücksichtigt, versucht der Kernel (in "avm_mtd.c") die Umwandlung in eine Zahl und scheitert bei vorhandenem "A" an dieser Konvertierung.

Im Ergebnis wird dann zwar trotzdem "0" verwendet (weil das zuvor als Standard gesetzt wird), aber damit kommt bei "1A" am Ende der Kernel aus dem einen Partition-Set (diese Auswahl trifft der Bootloader und der erkennt "1") mit dem Dateisystem aus dem anderen (diese Auswahl trifft der Kernel und der verwendet dann "0", wenn der Wert für ihn "ungültig" ist) zum Einsatz.

Der Parser im Kernel der IPQ-Boxen sieht genauso aus, wie der bei den GRX-Boxen ... die Frage ist halt, was der Bootloader hier macht und welche Partition der bei "linux_fs_start=1A" als Kernel verwendet.

Wie die Zuordnung jeweils aussieht, kann man sich per cat /proc/mtd anzeigen lassen.

 

[eisbaerin]

Danke! Das ging aber schnell!

7520+10:$(pwd)# gui_bootmanager debug
system type = IPQ4019
system selector = 0
system is switched = false
system branding = avm <--- Das ist von mir im Skript geändert worden
system branding is changeable = true  <--- Das ist von mir im Skript geändert worden
active kernel = /dev/mtdblock0
active filesystem = /dev/mtdblock5
active system version = 175.07.19-79182
active system date = 04.06.2020, 06:51:53 Uhr
active system modification date = 06.06.2020, 07:08:21 Uhr
active system modification source = modfs
brandings supported on active system = 1und1 avm avme
inactive kernel = /dev/mtdblock3
inactive system is installed = true
inactive filesystem = /dev/mtdblock6
inactive filesystem mounted on /var/tmp/3351_1591726067/alt_root
inactive system version = 164.07.14
inactive system date = 08.11.2019, 05:46:33 Uhr
inactive system modification date = 09.02.2020, 01:58:07 Uhr
inactive system modification source = Freetz
brandings supported on inactive system = 1und1 avm
inactive filesystem dismounted

Jetzt stimmt auch die inactive system version: 164.07.14 vorher stand dort falsch: 175.07.14

Das klappt auch im GUI.
Nein, keine neue FW gebaut, einfach übermounted.

Gibt's bei den IPQ-Modellen den Pfad "/proc/device-tree/chosen"?

Ja.
Ich habe aber extra bei mir diese Abfrage auskommentiert, damit ich die OEM angezeigt bekomme und umschalten kann.
(ein # vor der Zeile 210 - has_fdt_environment && return 1)
Im debug (s.o.) klappt es, aber im GUI erhalte ich eine weißes Fenster.
Was muß ich da noch ändern?
Ich benutze in den Environments den Namen bluetooth_key, da der z.Z. noch ungenutzt und änderbar ist.
Ist auch im Skipt geändert, deshalb wird bei der 7520 avm angezeigt, obwohl es keine 7520 mit OEM=avm gibt.

Dann würde ich die zusätzliche Erkennung (bzw. die Versuche dazu) nur auf die Modelle ohne FDT beschränken

Bitte nicht. Ich bin ja gerade dabei eine neue Version für das Ändern des Brandings zu entwickeln.
IMO ist es jetzt bei den neuen FW mit 3 OEM's wieder wichtig, da jede OEM doch etwas anders bei den Providern reagiert.
Da sollte man schnell mal das Branding ändern können, ohne erst jedes mal eine neue FW zu bauen.

Was hältst du davon, den anderen Namen im Environment zu nutzen?




EDIT:

7520+10:$(pwd)# gui_bootmanager html_display
<br><h3>Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:</h3><br>
<input type="radio" id="radioRunning" name="linux_fs_start" value="running" checked="checked">
<label for="radioRunning">
<b>das aktuell laufende System</b> (linux_fs_start=0)
<br><br>Version 175.07.19-79182 vom 04.06.2020, 06:51:53 Uhr<br>
zuletzt modifiziert am 06.06.2020, 07:08:21 Uhr durch "modfs"
</label>
<br><br>
<input type="radio" id="radioAlternative" name="linux_fs_start" value="alternative">
<label for="radioAlternative">
<b>das derzeit inaktive System</b> (linux_fs_start=1)
<br><br>Version 164.07.14 vom 08.11.2019, 05:46:33 Uhr<br>
zuletzt modifiziert am 09.02.2020, 01:58:07 Uhr durch "Freetz"
</label>
<br><br>
<h4>Branding &auml;ndern</h4>
<span id="running_branding">
Das oben ausgew&auml;hlte System unterst&uuml;tzt mehrere Firmware-Versionen, im Moment ist "<b>avm</b>" eingestellt.
<br>
<label for="idRunningBranding">
Beim n&auml;chsten Start wird folgender Wert gesetzt und bis zur n&auml;chsten &Auml;nderung verwendet:&nbsp;
</label>
<select id="idRunningBranding" name="running_branding">
<option value="1und1">1und1</option>
<option value="avm" selected="selected">avm</option>
<option value="avme">avme</option>
</select>
</span>
<span id="alternative_branding">
Das oben ausgew&auml;hlte System unterst&uuml;tzt mehrere Firmware-Versionen, im Moment ist "<b>avm</b>" eingestellt.
<br>
<label for="idAlternativeBranding">Beim n&auml;chsten Start wird folgender Wert gesetzt und bis zur n&auml;chsten &Auml;nderung verwendet:&nbsp;</label>
<select id="idAlternativeBranding" name="alternative_branding">
<option value="1und1">1und1</option>
<option value="avm" selected="selected">avm</option>
</select>
</span>

Den Rest kann ich hier nicht posten, da kommt sonst ein Fehler von der Foren-SW.

Sieht aber gut aus. Warum wird es mir aber im GUI nicht angezeigt?

 

[PeterPawn]

Ich bin durchaus bereit, wieder eine Umschaltung des "Brandings" über eine Variable einzubauen (näher dann aber im neuen Thread), anstatt das nur "fest" in der "rc.conf" zu setzen - wenn jetzt immer "avm" und "avme" in einer Firmware stecken, lohnt sich diese Umschaltung nämlich auch für meine eigenen Tests bzw. Vergleiche.

Warum wird es mir aber im GUI nicht angezeigt?

Der Teil mit der Ausgabe über "html_display" findet nur bei älteren FRITZ!OS-Versionen Verwendung. Neuere erzeugen die HTML-Elemente dynamisch im Browser auf dem Client (aus den .js-Files) und da liefert das Lua-File nur noch die passenden Daten im JSON-Format. Dafür wird dann aber "get_values" verwendet - das wird obendrein noch gecacht, damit es nicht bei jedem Aufruf neu ausgelesen werden muß.

Eine Änderung während des laufenden Systems ergibt sich ohnehin nur durch die Verwendung von "modfs" (wo dann der Cache auch noch aktualisiert wird, wenn der BM existiert) oder durch eigene Manipulationen. Der Rest installiert ja jeweils ein neues System aus einem Image (inkl. Freetz) und da reicht es dann, einmalig beim Start die Werte zu ermitteln.

Daher muß man - wenn man eine Änderung im GUI sehen will - erst einmal den Cache löschen (gui_bootmanager clear_cache - siehe hier: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1465) und erst ab diesem Zeitpunkt werden die Daten auch wieder neu ausgelesen (inkl. der Tatsache, ob nun das Branding umschaltbar ist oder nicht).

Zum Punkt mit dem variablen Branding auch bei Boxen, wo das von AVM nicht unterstützt wird, komme ich gleich noch mal ... erst einmal sortiere ich jetzt meine Beiträge um.

 

[eisbaerin]

Daher muß man - wenn man eine Änderung im GUI sehen will - erst einmal den Cache löschen

Das habe ich natürlich gemacht, trotzdem blieb das Fenster weiß.

 

[PeterPawn]

So, jetzt geht's weiter zum Thema "Boot-Manager".

Da ich es tatsächlich (s.o.) für sinnvoll/machbar halte, die Brandings dann eben beim Modifizieren "über die Hintertür" wieder einzuführen, würde ich das in den BM mit einbauen.

Allerdings behagt es mir nicht, dafür irgendeine andere Variable zu "mißbrauchen". Auch wenn ich das bei "bb1" bis "bb9" tatsächlich selbst schon propagiert habe für die Speicherung eines eigenen öffentlichen Schlüssels für eine Signatur - da hatte ich andere Gründe, weil es wirklich nur über den FTP-Server möglich ist, eine ausreichend lange Zeichenkette (256 Zeichen für einen Exponenten eines 1024-Bit-RSA-Keys) im Bootloader zu hinterlegen.

Ich würde mich hier eher wieder an bereits existierende Mechanismen bei AVM anlehnen und ebenso wie es beim "Annex" möglich ist, den in der entsprechenden Environment-Variablen anzugeben (was AVM macht und was sich auch häufig nicht persistent ändern läßt) und über die "kernel_args" zu überschreiben, das auch für "OEM" einführen. Das hat gleichzeitig den Vorteil, daß der bisherige Weg, ein "festes Branding" durch das "export OEM=value" zu spezifizieren, damit nicht in Konflikt gerät.

Man bräuchte nur VOR diesem "export"-Statement noch einen Test einbauen, ob "kernel_args" (oder auch "kernel_args1" bzw. "kernel_args_tmp") die Zeichenkette "OEM=value" enthalten und wenn das der Fall ist, wird eben "value" ausgelesen und OEM passend gesetzt (ggf. noch mit einem Test, ob das Branding auch tatsächlich enthalten ist, ansonsten ignoriert man den Wert einfach und nimmt den von der Box oder vom (Haupt-)Branding aus der Firmware).

Zwar ist die Suche innerhalb der Zeichenkette dann etwas aufwändiger, dafür paßt es aber auch so lange, wie es die "kernel_args*"-Variablen gibt. Denn wenn AVM auf die Idee käme, die "bluetooth_key"-Variable einfach aus dem TFFS zu werfen, müßte man das wieder umstellen, wenn man diese verwendet - man macht sich zu abhängig. Die "kernel_args" kann/wird man eher nicht entsorgen - darüber arbeiten ja auch noch andere Mechanismen.

Ich müßte allerdings noch einmal testen, wie sich die Puma6-Modelle bzgl. von "kernel_args" verhalten ... die haben ja das Problem, daß sie diese pro System bräuchten und iirc der Bootloader die nicht ohne weiteres setzen will (muß ich bei Gelegenheit probieren) - wobei mir das bei denen ohnehin egal wäre, denn da kann der Bootloader iirc ja ohne weiteres auch weiterhin "firmware_version" persistent ändern, was das Ganze dann obsolet werden läßt mit der "dynamischen Auswahl".

 

[eisbaerin]

So, jetzt sollte die Reihenfolge stimmen.
Wenn ihr aber wenigstens ein mal auf mich gehört hättet, wäre es viel schneller und einfacher gegangen.

IMO könnte in die Überschrift noch so was wie "Branding ändern" rein.

oder auch "kernel_args1"

Ja, die hatte ich auch schon in Erwägung gezogen.

"kernel_args_tmp"

Die finde ich in der nametabel nicht. Ist das eine geheime?

 

[PeterPawn]

Die finde ich in der nametabel nicht. Ist das eine geheime?

Nein, eben nur eine "temporäre", die nicht im TFFS gespeichert und nur vom Bootloader "verstanden" wird, der sie an den Kernel übergibt (u.a. auch beim Start aus dem RAM, aber man muß sich nicht darauf beschränken).

Ich mache mal ein "modscript", was diese Auswertung von "OEM=value" in der "rc.conf" nachrüstet - aber ggf. nicht mehr heute (bzw. innerhalb dieser "Wachperiode", weil die 23 Minuten "heute", die noch übrig sind, für ein (getestetes) Skript ohnehin etwas schmal wären).

Das habe ich natürlich gemacht, trotzdem blieb das Fenster weiß.

Dann schau mal mit dem JS-Debugger des Browsers nach, was da ggf. zur Ausnahme im JS-Code führt.

 

[koyaanisqatsi]

Hallöle


Sehr schön, nur das HTML könnte besser sein.
(o) das ... System
...dass das das klein ist, dass muss doch nicht sein.
Nur rein für die Ästheten unter uns.
Wundert mich, dass @eisbaerin das noch nicht moniert hat

Ach ja, wenn dieser Post geliked wird, löst er sich in Luft auf.

 

[PeterPawn]

Sehr schön, nur das HTML könnte besser sein.

Welches HTML denn? Das ist - wie geschrieben - dynamisch generiert mit dem AVM-Framework, was auch alle anderen Seiten verwenden ... da wird "schöner" dann schwer, solange nicht die "Form" (Textauszeichnungen, Farbe) gemeint ist, was bei mir deutlich als "sachlich" gedacht war (schon die unterschiedliche Farbe für das "h3"-Element (rgb(0, 51, 101)) mit der "Überschrift" stammt aus dem CSS von AVM).

Oder meinst Du nur den Text (also den Inhalt)?

Das mit dem kleingeschriebenen "das" ist durchaus Absicht ... das ist in meinen Augen eine Aufzählung ohne vollständige Sätze für die einzelnen Punkte der Aufzählung (das sind nur die mit den Checkboxen, der Text darunter ist "Erklärung" auf einer anderen Stufe der Gliederung), die deshalb auch keine Satzzeichen enthalten ... und ohne Satzzeichen am Ende gibt es auch keinen Anlaß, den Punkt mit einem Großbuchstaben zu beginnen, solange das erste Wort nicht selbst ein Substantiv ist. Das hat für mich eher mit Grammatik als mit Ästhetik zu tun.

 

[koyaanisqatsi]

Oh, dann hab ich hoffentlich was dazugelernt.
Danke für die Erläuterung.

Und ja, der Inhalt war gemeint.

 

[eisbaerin]

Dafür wird dann aber "get_values" verwendet - das wird obendrein noch gecacht,

Da ist IMO auch alles richtig:

7520+10:$(pwd)# gui_bootmanager get_values
active_version="175.07.19-79182"
active_date="04.06.2020, 06:51:53 Uhr"
active_modified_by="modfs"
active_modified_at="06.06.2020, 07:08:21 Uhr"
active_brandings="1und1 avm avme"
inactive_version="164.07.14"
inactive_date="08.11.2019, 05:46:33 Uhr"
inactive_modified_by="Freetz"
inactive_modified_at="09.02.2020, 01:58:07 Uhr"
inactive_brandings="1und1 avm"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
system_is_switched=false

Sobald ich dort "switch_branding_support=false" setze, klappt die Anzeige im GUI, natürlich ohne OEM Auswahl.
Mit "switch_branding_support=true" kommt das weiße Fenster.
Das kannst du ja ganz einfach bei dir nachstellen.

Ich vermute da ist noch ein Fehler in der reboot.js und/oder reboot.lua.
Die Variante mit Auswahl der OEM wurde bei den neueren FW ja nie mehr genutzt, deshalb ist das nie aufgefallen.

EDIT:
Ich habe das gleiche jetzt mal bei meiner 7580 mit 07.12freetz gemacht.
Da klappt das GUI mit Auswahl der OEM.

Also liegt es wohl an der FW 7.19, daß da noch etwas an den reboot.* Dateien geändert werden muß.

 

[PeterPawn]

Die Variante mit Auswahl der OEM wurde bei den neueren FW ja nie mehr genutzt, deshalb ist das nie aufgefallen.

Nope, das ist ziemlich sicher nicht die (alleinige) Ursache.

Denn selbst wenn das vielleicht nicht mehr in allen Boxen genutzt werden konnte, 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.

Das ist die Anzeige von dieser Box, wobei hier tatsächlich die aktuelle Version aus dem Repo per "bind"-Mount in ein altes Image eingebunden wurde und um ganz sicher zu sein, daß es sich wirklich auch um die Daten aus der geänderten Version handelt, habe ich noch ein "mod" an die Versionsnummer in der aktiven Partition anhängen lassen:


Sooo einfach ist das also auch nicht für mich nachzustellen ... leichter wäre immer noch der Versuch, das im JS-Debugger des Browsers zu sehen, wo da das Problem entsteht. Ich müßte hier erst ein Image für die 7580 bauen (lassen), was den Boot-Manager enthält. Diese Box wird von mir aber gerade für die Tests zur korrekten Erkennung der Möglichkeit zur persistenten Änderung des Brandings verwendet und hat im Moment in beiden Partitionen die "offizielle" 07.12. Das dauert dann also noch eine Weile, zumal es ja offenbar ein JS-Problem ist und nicht eines, was man mittels "get_values" oder "debug" sehen würde.

 

[Insti]

Ich müßte hier erst ein Image für die 7580 bauen (lassen), was den Boot-Manager enthält.

Hallo zusammen,

ich habe Heute eine 7580 bekommen und gleich mit dem Script von @PeterPawn ein Image erstellt und geflasht.
Im Bootmanager wird mir auch keine Auswahl angezeigt zwischen den Brandings. Die Box ist rot/weiß ohne Branding. Kann es sein das nie ein Update gemacht wurde weil die zweite Partition nicht lesbar ist?
Hier noch die Ausgabe vom BM über Telnet

password:


BusyBox v1.24.2 (2019-02-11 19:22:07 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# gui_bootmanager debug
system type = GRX500
system selector = 0
system is switched = false
system branding = avm
system branding is changeable = false
active kernel = /dev/mtdblock0
active filesystem = /dev/mtdblock5
active system version = 153.07.12
active system date = 22.07.2019, 15:32:15 Uhr
active system modification date = 10.06.2020, 11:28:30 Uhr
active system modification source = modfs
brandings supported on active system = avm (fixed)
inactive kernel = /dev/mtdblock3
inactive system is installed = true
inactive filesystem = /dev/mtdblock6
inactive filesystem mounted on
inactive filesystem could not be mounted
# gui_bootmanager get_values
active_version="153.07.12"
active_date="22.07.2019, 15:32:15 Uhr"
active_modified_by="modfs"
active_modified_at="10.06.2020, 11:28:30 Uhr"
active_brandings=""
inactive_version=""
inactive_date=""
inactive_modified_by=""
inactive_modified_at=""
inactive_brandings=""
current_branding=""
switch_branding_support=false
current_switch_value=0
system_is_switched=false
#

Hoffe konnte weiterhelfen.

 

[PeterPawn]

Bei den Boxen mit UBI-Layer für den Flash-Speicher (für Dateisysteme, "config" und die NAS-Partition) wird bei der Verwendung des Recovery-Programms die zweite Dateisystem-Partition ebenfalls gelöscht (beim "ubiformat"). Daher kann es dort vorkommen, daß die Kernel-Partition im alternativen System noch intakt ist, daher ein System vermeintlich erkannt wird und doch dessen Dateisystem-Partition nicht gemountet und untersucht werden kann.

Das werde ich bei Gelegenheit auch noch anpassen, dann müssen sowohl die Kernel- als auch die Dateisystem-Partition irgendwelche Daten enthalten - derzeit wird nur die Kernel-Partition geprüft: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L454 - es gibt offenbar soviele "Spezialfälle" da draußen, daß man eine Weile beschäftigt ist, wenn man die alle abdecken will.

Wobei ich vielleicht auch noch einmal in den JS-Code gehe ... es geht mir auch auf den Zeiger, daß da jede kleine Ausnahme sofort dazu führt, daß überhaupt nichts mehr angezeigt wird, weil die Generierung der HTML-Elemente abgebrochen wird. Eigentlich sollte der originale Teil von AVM ja weiterhin generiert und angezeigt werden - ggf. muß ich das nur besser gegen unvollständige Daten sichern und dann lieber im Fehlerfall auf jede (zusätzliche) Anzeige verzichten.

EDIT: Wobei ich gerade im Screenshot sehe, daß das doch eigentlich sehr ordentlich aussieht ... das Fehlen des zweiten Systems wird (halbwegs) korrekt erkannt und auch so dargestellt. Da habe ich mich von "es wird keine Auswahl angezeigt" in die Irre führen lassen ... das ist so jedenfalls vollkommen korrekt. Wenn das zweite System nicht erkannt wird, müßte trotzdem noch eine Umschaltung möglich sein ... die Warnung davor, sollte aber der angezeigte Text deutlich zum Ausdruck bringen. Denn dasselbe Phänomen kann tatsächlich auch dann auftreten, wenn ein System vor 06.50 und eines danach installiert sind - diese sind wechselseitig nicht in der Lage, ihre SquashFS-Formate zu mounten und dann kann das zweite System auch nicht identifiziert werden (das erste arbeitet ja gerade, das geht immer).

 

[eisbaerin]

Im Bootmanager wird mir auch keine Auswahl angezeigt zwischen den Brandings.

brandings supported on active system = avm (fixed)

Du darfst natürlich nicht das modscript "mod_fixed_branding" ausführen, sonst ist es nicht mehr umschaltbar.
Wozu bei dir auch, wenn sie sowiso schon "ohne Branding" ist?

Welche Version hat der Bootloader der 7580?

cat /proc/sys/urlader/environment | grep boot

Geht auch das?

cat /proc/device-tree/chosen/bootloaderVersion

 

[Insti]

Welche Version hat der Bootloader der 7580?

root@ubuntu ~ > telnet 192.168.1.45
Trying 192.168.1.45...
Connected to 192.168.1.45.
Escape character is '^]'.
password:


BusyBox v1.24.2 (2019-02-11 19:22:07 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# cat /proc/sys/urlader/environment | grep boot
bootloaderVersion       1.3082
# cat /proc/device-tree/chosen/bootloaderVersion
1.3082#

 

[NDiIPP]

Bisher kenne ich jedenfalls kein Modell mit FDT (also mit einem Loader, der einen erstellt und beim Start übergibt), wo sich das Branding persistent ändern läßt.

FRITZ!Box 7560 und 7580 mit Bootloader-Version <=1.3082.

 

[PeterPawn]

Übergeben die tatsächlich einen FDT beim Start? Ich war (auch mangels passender Geräte) bisher immer der Ansicht, die Fallback-Daten im "avm_kernel_config"-Bereich wären genau für diese Modelle vorhanden, weil die eben keinen FDT an "head.S" im Kernel übergeben in den Argumenten.

Hat mal jemand einen Bootloader-Dump einer 7580 mit einer alten Version, wo die Änderung noch möglich ist/war? (Einen, wo man das nicht persistent ändern kann, habe ich selbst und für die 7490 auch irgendwo noch Dumps beider Versionen.) Gerne auch noch ein Listing von "/proc/device-tree", da wird der FDT im laufenden System zugänglich gemacht.

Ich bin ohnehin (zumindest im Moment) noch der Ansicht, daß es gar nicht tatsächlich an der Version des Bootloaders liegt, sondern am Aufbau der Daten im "CONFIG"-Bereich, der bei der Finalisierung gespeichert wird - und genau für die Überprüfung dieser Theorie bräuchte ich mal einen Loader einer 7580, bei dem es sich ändern läßt und gerne auch einen für eine 7560 (wo das m.W. generell möglich ist - ggf. gibt's da auch nur keine neueren Loader-Versionen).

Wenn sich jemand "engagieren" möchte, gerne per E-Mail an eine der Adressen, die in meinem PGP-Key (im YourFritz-Repo) hinterlegt sind.