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

stoney

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
5,581
Punkte für Reaktionen
446
Punkte
83
Könnte ebenfalls mit einer 7520 sowie (mal schauen wo die abgeblieben ist) einer 3272 und falls sich niemand anderes findet, falls erforderlich auf einer 7590 (wenn es die Zeit zulässt).
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Ich bin nun doch noch dabei, die drei Skript-Dateien zu überarbeiten. Aus leidvoller Erfahrung in der Vergangenheit will ich die halt nicht nur als "proof of concept" ohne (C)-Notiz und Benutzungshinweise einchecken - daher dauert das noch. Das erste ist fertig, habe ich mal in einem gesonderten Branch (eva_config) eingecheckt, der ohnehin bei mir auf dem lokalen Git-Server existierte und immer wieder aktualisiert wurde (praktisch meine Arbeitskopie). Damit kann man zwar schon den Urlader aus den Boxen extrahieren (https://github.com/PeterPawn/YourFritz/blob/eva_config/eva_tools/eva_get_urlader_from_device), aber das "Zerlegen" (als Vorstufe für das Verständnis, welche Variablen "fest" sind und welche nur als Standardwert initialisiert werden und überschrieben werden können) ist noch "in Arbeit". Aber zum Backup des eigenen Loaders sollte es schon mal reichen - der Hilfebildschirm (mit Option --help) gibt Auskunft, was das Skript macht.
 

stoney

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
5,581
Punkte für Reaktionen
446
Punkte
83
Hab's doch gewusst - die 3272 ist mir in die Hände gefallen und steht nun, wenn Test notwendig/interessant sind, auch zur Verfügung (nur Zeit ist weiterhin mein größter Feind in Sachen Hobby).
 

prisrak1

Mitglied
Mitglied seit
14 Mai 2017
Beiträge
324
Punkte für Reaktionen
25
Punkte
28

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Das ist kein einfacher Befehl ... diese Datei ist dazu gedacht, in das eigene Image eingebaut und aus der "/etc/inittab" (so jedenfalls meine Empfehlung) heraus aufgerufen zu werden.

Dazu muß man sich nur ansehen, wie andere Aufrufe dort aussehen ... das unterscheidet sich tatsächlich etwas zwischen den Modellen.

Je nachdem, ob man dem Skript im eigenen Image noch "Ausführrechte" zugewiesen hat (also das x-Flag passend gesetzt ist) oder nicht, kann man es eben direkt über seinen Namen oder über ein "/bin/sh filename" aufrufen. Solange im TFFS-Node mit der Minor-ID 80 keine Zeilen stehen (die muß man dann erst per Shell-Zugriff dort eintragen), macht das Skript praktisch auch gar nichts.

Das Mounten des "procfs" (unter "/proc") bzw. eines "tmpfs" (unter "/var") kann man in den Skat drücken, das macht die "/etc/init.d/rc.S" gleich noch einmal bzw. die "/etc/boot.d/core/head" bei 07.19/07.20 (es gibt noch weitere Stellen, die ggf. "/proc" mounten könnten, z.B. die "/sbin/flash_update" im Wrapper bei VR9-Boxen).

Bei einer VR9-Box würde man das also z.B. so in die "/etc/inittab" (hier aus der 113.07.12) eintragen:
Rich (BBCode):
null::sysinit:/bin/mount -t squashfs /filesystem_core.squashfs /core -o loop
null::sysinit:/bin/mount /dev /core/dev -o bind
null::sysinit:/bin/sh /sbin/yf_custom_environment.sh
null::sysinit:/sbin/pivot_root /core/ /core/wrapper/
null::sysinit:/wrapper/sbin/flash_update
#
/dev/ttyS0::sysinit:/etc/init.d/rc.S

# Start an "askfirst" shell on ttyS0
/dev/ttyS0::askfirst:-/bin/sh

# Stuff to do before rebooting
/dev/ttyS0::shutdown:/bin/sh -c /var/post_install
... das wäre sogar wieder eine Änderung, für die man (immer noch nur bei den VR9-Boxen) gar kein neues Image bauen müßte, sondern nur die Skript-Datei unter "/sbin/yf_custom_environment.sh" im YAFFS2 ablegen und den Eintrag in der "/etc/inittab" erzeugen müßte.

Das sollte man hier dann auch noch vor dem "pivot_root" ausführen (solange das Skript in der YAFFS2-Partition steht), dann ist man vom Verhalten des "init"-Applets der BusyBox unabhängig, weil beim "pivot_root" dann die "/etc/inittab" aus dem SquashFS-Image in der "filesystem_core.squashfs" die "aktive" wird und es unterschiedliche Ergebnisse geben kann, je nachdem, wann das "init"-Applet diese Datei liest bzw. ob es sie "in einem Rutsch" schon vor dem "pivot_root" komplett analysiert und den Inhalt einfach schon vor dem Ausführen des ersten Kommandos in interne Abläufe übersetzt.

Bei anderen Architekturen gibt es das "pivot_root" dann nicht (und wegen der fehlenden YAFFS2-Partition auch keine Möglichkeit, das so einfach zu integrieren) und damit muß man sich dort keine Gedanken über den Zeitpunkt des Lesens der "/etc/inittab" machen. In der 154.07.20 könnte man das z.B. einfach so machen:
Rich (BBCode):
/dev/ttyLTQ0::sysinit:/bin/sh /sbin/yf_custom_environment.sh
/dev/ttyLTQ0::sysinit:/etc/boot.d/1
/dev/ttyLTQ0::askfirst:-/bin/sh
/dev/ttyLTQ0::shutdown:/bin/sh -c /var/post_install
... natürlich muß man auch da das Skript zusätzlich ins SquashFS-Image packen (und zwar unter dem Pfad, wo es dann beim Aufruf gesucht wird). Und so geht das dann analog auch noch für andere Modelle ... jeweils passend zur Architektur.

Das Skript sollte sich jedenfalls problemlos aufrufen lassen, solange die "Randbedingungen" stimmen und das wären
  1. der in den Kernel gelinkte TFFS-Treiber
  2. ein existierendes "procfs", das man mounten kann
  3. ein existierendes "tmpfs", in dem man das "char device" für den TFFS-Node anlegen und den Inhalt zwischenspeichern kann (hier könnte man auch gleich das "devtmpfs" unter "/dev" nehmen, ich habe mich dagegen entschieden) siehe Ergänzung am Ende
  4. eine BusyBox mit ein paar Applets (bei AVM definitiv dabei), die unter "/bin/busybox" zu finden ist
Mehr braucht das Skript nicht und das sollte alles bereits direkt nach dem Aufruf von "init" durch den Kernel (das "init" arbeitet dann eben die "inittab" ab) vorhanden sein. Gleichzeitig sorgt der frühe Aufruf dafür, daß wirklich fast alle Stellen "erwischt" werden, wo auf Urlader-Variablen zugegriffen wird - und die Implementierung sorgt durch den vorherigen Vergleich mit den existierenden Werten auch dafür, daß die notwendigen Schreibzugriffe bei jedem Systemstart auf das erforderliche Minimum begrenzt werden.

Und wie schon mal geschrieben ... solange im TFFS-Node 80 keine Einträge vorhanden sind, macht das Skript praktisch gar nichts. Das Dismounten von "/proc" und "/var" macht wenig Sinn und verkompliziert das Ganze nur, besonders wenn man es doch später aufrufen will, wo das "umount" dann sogar unerwünscht wäre und vermutlich ohnehin nicht funktioniert, wenn das in Benutzung ist ... daher habe ich das gar nicht erst in Erwägung gezogen, da noch auszuwerten, ob das "mount" nun aus dem Skript erfolgte oder nicht. Das wäre ein Stelle, wo man noch "nacharbeiten" könnte - ob man's muß oder auch nur sollte, wird sich irgendwann mal zeigen.

Wer dann mittels dieses Skripts, nachdem er es in seine Firmware eingebaut und diese installiert hat, z.B. das Branding ändern lassen will, braucht nur eine Zeile firmware_version avm (oder was auch immer) in den TFFS-Node 80 schreiben ... natürlich immer unter Beachtung der Besonderheiten beim Editieren von TFFS-Nodes und genau dafür hatte ich schon weiter vorne das "tvi" aus dem YourFritz-Repo empfohlen. Da kann man natürlich auch jede andere Variable setzen ... bei einigen macht es Sinn, bei anderen eher nicht. So ist es z.B. ziemlich witzlos, den Wert von "firmware_info" von dort zu setzen ... das macht die startende Firmware kurz darauf ohnehin noch einmal selbst und es gibt sogar bestimmte Konstellationen (z.B. das Vorhandensein von "recovered=2" in diesem Wert, wo dann die UBI-Partition nicht eingerichtet wird vom Kernel), die eine korrekte Funktion der Firmware verhindern könnten.

Daher auch noch einmal der Hinweis: Der Inhalt des TFFS-Nodes 80 wird beim Zurücksetzen auf die Werkseinstellungen nicht gelöscht (genau deshalb habe ich eine Nummer unter 100 dafür ausgewählt) - wer den Inhalt dort wieder loswerden will und die Box nicht mehr starten kann (denn von der Shell aus ist das mit einem einfachen echo clear_id 80 > /proc/tffs auch wieder schnell gemacht), der muß schon das Recovery-Programm bemühen (oder einen der zahlreichen anderen Wege, aber hier reicht das "Angebot" eines einzelnen).

EDIT: Pfad im ersten Beispiel korrigiert ... zu diesem Zeitpunkt ist das YAFFS2-FS noch direkt gemountet und nicht unter "/wrapper", wo es erst nach dem "pivot_root" landet.

EDIT2: Nachdem sich einiges im Skript-Code geändert hat ggü. der ursprünglichen Implementierung, habe ich das mit dem "tmpfs" unter "/var" noch einmal überdacht und es am Ende auch überarbeitet. Da der Inhalt des TFFS-Nodes nicht mehr (aktiv) zwischengespeichert wird (das "pipefs" im Kernel sollte sich darum kümmern, daß er vom "cat" zum "read" gelangt), braucht es außer dem Char-Device-Inode für den TFFS-Node gar keine weitere Stelle, an der direkt irgendwohin geschrieben wird - das "printf" ins Urlader-Environment zählt dabei nicht als "direkt".

Damit bleibt als einzige zu erzeugende und danach auch wieder zu löschende Datei nur noch das übrig, was mit "mknod" angelegt und nach dem Auslesen mit "rm" wieder gelöscht wird - exakt dafür ist ja eigentlich das "devtmpfs" (bzw. auch der Pfad "/dev" in der LSB) gedacht und dann kann man das auch verwenden. Das reduziert die Abhängigkeiten weiter und man muß außer dem "procfs" nichts weiter mounten - damit interessiert es auch nicht mehr, ob nicht vielleicht doch irgendwo später in den AVM-Skripten das "tmpfs" in "/var" gemountet wird und - wenn das nicht erforderlich sein sollte, weil es schon vorhanden ist - dabei dann auf das Entpacken der Strukturen aus der "/var.tar" verzichtet wird. Das war bisher noch eine Schwachstelle, daß man das immer irgendwie überprüfen mußte, daß es bei AVM auch unbedingt erfolgte, wenn "/var" schon gemountet war (was ich für GRX- und VR9-Boxen getan hatte) - solange man das Entpacken nicht auch noch selbst machen will.
 
Zuletzt bearbeitet:

stoney

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
5,581
Punkte für Reaktionen
446
Punkte
83
Also modfs - BM - läuft auf der 3272 mit 06.87 auch.

Falls noch irgendetwas von/aus der Box benötigt wird, sag Bescheid.

Kleiner Hinweis am Rande - und die 7272 funktioniert doch auch, wenn ich mich jetzt richtig erinnere.
Ausdrücklich werden zur Zeit nur die Modelle 7490, 7362SL, 3370, 3390 und 3490 unterstützt.

Wer das gerne aber mal auf einer 7272, 3272, 3390 oder 3490 testen will,
Folgende Modelle könnten wahrscheinlich ebenfalls funktionieren: 7272, 3272, 3390, 3490(geklärt 17.06.2015, 3490 funktioniert)
Läuft es denn nun verifiziert auf einer 3390? Eine solche darf ich auch mein Eigen nennen, könnte also ebenfalls auf dieser testen.
 

Anhänge

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,899
Punkte für Reaktionen
367
Punkte
83

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,095
Punkte für Reaktionen
998
Punkte
113
Läuft es denn nun verifiziert auf einer 3390?
Das weiß ich auch nicht mehr 100% - außerdem ist die Box ein ziemlicher Exot.

Wenn ich von "verifiziert" schreibe, wird das aber normalerweise auf mind. einem positiven Erfahrungsbericht basieren (irgendwann in 2015?) - wobei man hier auch zwischen "modfs" und dem Boot-Manager unterscheiden sollte. Letzterer unterstützt deutlich mehr Modelle, als das "modfs" (zumindest der Teil, der auf der Box laufen soll) jemals tun wird. Die Erfahrungsberichte zum "modfs" finden sich dann auch in dem von Dir verlinkten Thread.

Für "modfs" ist das Format der Firmware von Bedeutung, für den Boot-Manager eigentlich nur die Plattform, auf der er läuft und die Tatsache, daß beim entsprechenden Modell zwei Systeme vorhanden sind, zwischen denen mit "linux_fs_start" umgeschaltet werden kann. Die dort eingebauten "Sperren" sind reine Vorsichtsmaßnahmen - ich will nicht, daß eine von mir geschriebene Software Schaden anrichtet, nur weil sie die Plattform, auf der sie läuft, nicht richtig erkennt.

Da die einzigen Aktionen im BM aber ohnehin "read-only"-Mounts und max. das Schreiben über "/proc/sys/urlader/environment" sind (Stand heute), sollte das Schadenspotential tatsächlich gering sein. Aber für die saubere Erkennung, was nun die aktiven und die inaktiven Partitionen sind bzw. wo die überhaupt liegen (die Puma-Modelle sind ja noch mal komplett anders aufgebaut), sollte das Skript schon etwas von der verwendeten Plattform wissen.

Daher (und für andere Fehlersuchen) auch der "debug"-Modus - funktioniert der und stimmt obendrein noch seine Ausgabe, stehen die Chancen gut, daß die Plattform "bedient" werden kann. Wenn also die 7530 AX tatsächlich mit einem Broadcom-Chip um die Ecke kommt und zwei Systeme bietet, sollte der BM auch dort funktionieren (obwohl er zunächst die Arbeit verweigern wird) - vielleicht hat ja jemand den auch schon mal auf einer 7581/7582 ausprobiert?

EDIT:
@stoney:
Die Infos zur 3390 stehen hier ganz am Ende des Beitrags.