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

[stoney]

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]

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]

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]

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

wie lautet der Befehl den richtig um die Originalimage zu modifizieren?

:~/freetz/yourfritz-master/tffs$ sudo ./yf_custom_environment.sh FRITZ.Box_7590-07.20.image

 

[PeterPawn]

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:

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:

/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.

 

[stoney]

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.

 

[eisbaerin]

BM - läuft auf der 3272 mit 06.87 auch.

Auf einer 3272 sollte sich aber auch das Branding im BM auswählen lassen.
Zumindest ist das bei mir bei einer 7272 so.

 

[PeterPawn]

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.

 

[FunkReich]

ohne Branding

 

[Insti]

Derzeit ist der BM in der Lage, FRITZ!Box-Modelle.....bis hin zu den DOCSIS3-Modellen (6490, 6590, 6430) mit dem Puma6-Chipset.

Hallo zusammen,

habe für eine bekannte eine 6490 erworben und erfolgreich das aktuelle FritzOS 7.29 der Retailversion installiert.
Würde da gerne wie bei den 7520 den BM und wenn es geht auch Telenet aktivieren. Und bin beim entpacken der beiden Filesystem (arm u. x86) nicht ganz sicher ob die modscripts auf beiden ausgeführt werden müssen oder nur auf einen. Hier mein Script

mkdir /opt/6490
cd /opt/6490
wget https://ftp.avm.de/fritzbox/fritzbox-6490-cable/deutschland/fritz.os/FRITZ.Box_6490_Cable-07.29.image
tar -xvf FRITZ.Box_6490_Cable-07.29.image
mv /opt/6490/var/remote/var/tmp/filesystem.image /opt/6490/mtd11
mv /opt/6490/var/remote/var/tmp/kernel.image /opt/6490/mtd12
mv /opt/6490/var/remote/var/tmp/x86/filesystem.image /opt/6490/mtd13
mv /opt/6490/var/remote/var/tmp/x86/kernel.image /opt/6490/mtd14
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
mv modfs/modscripts/ modfs/modscripts.org
mv modfs/contrib/modscripts modfs/contrib/modscripts.org
mkdir modfs/modscripts
cp modfs/modscripts.org/gui_boot_manager_v0.6 modfs/modscripts/
cp modfs/modscripts.org/mod_enable_calllog modfs/modscripts/
cp modfs/modscripts.org/mod_fixed_branding modfs/modscripts/
cp modfs/modscripts.org/mod_telnet_enable modfs/modscripts/
cp modfs/modscripts.org/mod_rc_tail_sh modfs/modscripts/
cp -r YourFritz/bin/squashfs/armv7l YourFritz/bin/squashfs/aarch64

# ab hier bin ich mir nich ganz sicher:

YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -no-progress mtd11
mv squashfs-root arm-squashfs-root

YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-le -no-progress mtd13
mv squashfs-root x64-squashfs-root

# Würde es reichen auf einem der beiden Filesystem modfs zu installieren oder macht man das auf beiden?
cd modfs/
./run_modscripts ../arm-squashfs-root
./run_modscripts ../x86-squashfs-root

Danke für eure Hilfe.

 

[NDiIPP]

Am ARM-System braucht du dich nicht "zu vergreifen".

 

[Insti]

Danke dir. Werde es Anfang nächster Woche testen.

 

[Insti]

Am ARM-System braucht du dich nicht "zu vergreifen".

Das hat leider noch nicht mit dem Bootmanager und Telnet geklappt obwohl es keine Fehlermeldung gibt:

Spoiler: Terminallog 6490

./run_modscripts ../squashfs-root
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0

root@Osprey:/opt/6490# bash YourFritz/eva_tools/eva_discover
YourFritz/eva_tools/eva_discover: line 121: ./yf_helpers: No such file or directory
YourFritz/eva_tools/eva_discover: line 282: [: /mnt/c/Program: binary operator expected
"socat" utility couldn't be found or isn't executable.
root@Osprey:/opt/6490# bash YourFritz/eva_tools/eva_get_environment env 192.168.178.1 > /opt/6490/env.txt
Found AVM bootloader: AVM EVA Version 1.3272 0x0 0x36409
Environment read from device:
root@Osprey:/opt/6490# ls
FRITZ.Box_6490_Cable-07.29.image  YourFritz  env.txt  eva_get_environment_session.log  modfs  mtd11  mtd12  mtd13  mtd14  squashfs-root  var
root@Osprey:/opt/6490# cat env.txt
HWRevision            213
HWSubRevision         4
ProductID             Fritz_Box_HW213a
SerialNumber          0000000000000000
annex                 Kabel
autoload              yes
bootloaderVersion     1.3272
bootserport           tty0
cpufrequency          1200000000
crash                 [0]0,0,0[1]cc867d0a,5c0a3fd5,1[2]0,0,0[3]0,0,0
firstfreeaddress      0x00b20000
firmware_info         141.07.29
firmware_version      avm
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
linux_fs_start        0
maca                  44:**:**:99:**:40
macb                  44:**:**:99:**:41
macwlan               44:**:**:99:**:42
macwlan2              44:**:**:99:**:43
macdsl                44:**:**:99:**:3D
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
modulemem             6902512
mtd0                  0x0,0x4000000
mtd1                  0x4000000,0x4800000
mtd2                  0xa0000,0xc0000
mtd3                  0xc0000,0x100000
mtd4                  0x100000,0x140000
mtd5                  0x140000,0x1e0000
mtd6                  0x4800000,0x8800000
mtd7                  0x8800000,0x9000000
mtd8                  0x0,0x80000
mtd9                  0x80000,0x90000
mtd10                 0x90000,0xa0000
mtd11                 0x9000000,0xd000000
mtd12                 0xd000000,0xd800000
mtd13                 0xd800000,0x11800000
mtd14                 0x11800000,0x12000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
req_fullrate_freq     100000000
sysfrequency          100000000
tr069_passphrase      U********1uG
tr069_serial          00040E-44********40
urlader-version       4272
usb_board_mac         44:**:**:99:**:3E
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         44:**:**:99:**:3F
webgui_pass           b*******9
wlan_key              51***************3438
root@Osprey:/opt/6490# bash YourFritz/eva_tools/eva_get_environment count 192.168.178.1 > /opt/6490/count.txt
Found AVM bootloader: AVM EVA Version 1.3272 0x0 0x36409
Environment read from device:
root@Osprey:/opt/6490# cat count.txt
reboot_major          u
reboot_minor          u
run_hours             u
run_days              u
run_mounths           u
run_years             u
root@Osprey:/opt/6490# ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:root): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> binary
200 Type set to BINARY
ftp> passive
Passive mode on.
ftp> put mtd11 mtd11
local: mtd11 remote: mtd11
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
5967880 bytes sent in 0.92 secs (6.1824 MB/s)
ftp> put mtd12 mtd12
local: mtd12 remote: mtd12
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
1919752 bytes sent in 0.26 secs (7.0133 MB/s)
ftp> put mtd13 mtd13
local: mtd13 remote: mtd13
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
25313280 bytes sent in 3.72 secs (6.4872 MB/s)
ftp> put mtd14 mtd14
local: mtd14 remote: mtd14
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
3532552 bytes sent in 0.58 secs (5.7973 MB/s)

Umschalten hat auch ganz gut geklappt, leider nicht mit den eva_tools Script sondern manuell da der Pfad nicht mehr passt.

Spoiler: Terminallog Umschalten

root@Osprey:/opt/6490# bash YourFritz/eva_tools/eva_switch_system eth0 192.168.178.1 192.168.178.5
YourFritz/eva_tools/eva_discover: 121: .: Can't open ./yf_helpers
root@Osprey:/opt/6490# ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:root): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote GETENV linux_fs_start
linux_fs_start        0
ftp> quote SETENV linux_fs_start 1

Edit: Bootmanager hat geklappt !!! Telnet leider nicht.

 

[rolex0815]

Edit: Bootmanager hat geklappt !!! Telnet leider nicht.

Telnet hat auch bei mir (FB 7590) nicht mehr mit den modscripts funktioniert.
Man kann ihn aber z.B. ständig laufenlassen.

Vorgehen habe ich in https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/post-2400543 beschrieben.

Achtung: Auch die Beiträge danach lesen lohnt sich.

 

[PeterPawn]

Änderungsversuch, um den Boot-Manager auch unter 07.39+ wieder verwenden zu können: https://www.ip-phone-forum.de/threads/freetz-ng-und-die-fw7-39-boot-manager.311707/post-2457154

Das MUSS noch nicht funktionieren - wenn es jemand testet, hätte ich (bei einem weiterhin bestehenden Problem) gerne ein diff -u für die Dateien /usr/www/avm/system/reboot.lua und /usr/www/avm/system/reboot.js - jeweils verglichen mit der originalen AVM-Version vor der Anwendung des Patches. Wer das testet, ohne so ein diff hinzubekommen, kann mir gerne auch die beiden Dateien NACH dem Patch anderweitig bereitstellen (vermutlich am besten per E-Mail, aber bitte nur in Abstimmung mit mir, da landet schon sehr, sehr vieles im Spam-Filter).

Von einer direkten Veröffentlichung hier im Thread würde ich aber abraten - das ist dann nicht länger nur der wesentliche Teil, der von dem Ändeurngsversuch betroffen war, sondern enthält praktisch (auch) den gesamten AVM-Code. Wie weit das vom UrhG gedeckt wäre (also von den Ausnahmetatbeständen), vermag ich nicht zu beurteilen - aber vorbeugen ist besser als nach hinten fallen.

 

[PeterPawn]

Mit den Erkenntnissen aus diesem Thread: https://www.ip-phone-forum.de/threads/freetz-ng-und-die-fw7-39-boot-manager.311707/ habe ich mal eine geänderte Version zusammengeklöppelt, die noch den alten Aufbau verwendet (die Ansätze des neuen gibt es bisher im Branch bootmanager im YourFritz-Repo: https://github.com/PeterPawn/YourFritz/tree/bootmanager) und bis zur Bestätigung, daß das auch alles unter 07.39 funktioniert, im Branch bootmanager_0.7 untergebracht ist.

Dabei erfolgte auch gleich die Umbenennung von gui_bootmanager nach bootmanager, da der alte Name nur zur Unterscheidung zu einer älteren, CLI-basierten Version diente und mittlerweile das Generieren von GUI-Elementen aus den ermittelten Daten gar nicht mehr in diesem Skript erfolgt, sondern in zusätzlichem JS-Code, der in die AVM-Dateien eingebaut wird.

Damit das auch getestet werden kann, gibt es parallel dazu eine neue Beta-Version von "modfs" - weiteres dazu dann in Kürze im "modfs"-Thread (EDIT - Link: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2465197)

Ich habe mich am Ende dazu entschieden, das eigentliche bootmanager-Skript mit einem weiteren Wrapper-Skript (bootmanager_server) zu verknüpfen und gleichzeitig (ab 07.08 - also in den Versionen, wo bei AVM die Dienste dann über den supervisor verwaltet werden) einen zusätzlichen Service zu erstellen, der beim Systemstart das Wrapper-Skript startet.

Damit ist dann auch gleich die Frage erschlagen, wann die Daten zusammengesucht werden - das erfolgt ebenfalls bereits beim Start des FRITZ!OS und damit im Hintergrund - üblicherweise auch lange vor dem Zeitpunkt, wo die dann vielleicht mal für eine Anzeige benötigt werden.

 

[PeterPawn]

Auch ohne entsprechendes Feedback zu den Änderungen habe ich jetzt - angesichts der zunehmenden Zahl von Labor-/Inhouse-Versionen in der 07.39-Reihe - die Änderungen der Version 0.7 in den `main`-Branch im YourFritz-Repository übernommen.

Die Änderungen:

- Durch fehlende Funktionen in der Lua-Implementierung ab 07.39 wird jetzt ein System-Service mit dem Namen "bootmanager.service" eingerichtet und beim OS-Start automatisch angeworfen.
- Dieser Service stellt die Funktionen, die bisher nur über einen Aufruf des Skripts verfügbar waren, über zwei FIFOs unter /var/run/bootmanager/{input|output} bereit.
- Der Name gui_bootmanager wurde - an allen Stellen, wo er auftrat - in bootmanager geändert.

Die neue Version wurde auch ins modfs-Repository übernommen - dort ebenfalls unter einer neuen Versionsnummer 0.7.1.

 

[PeterPawn]

Es gibt jetzt eine neue Version des Boot-Managers (die auch in "modfs" enthalten ist), bei der umfangreichere Änderungen vorgenommen wurden.

---

Die Textschnipsel, aus denen die Ausgaben im GUI zusammengesetzt werden, sind jetzt in einer gesonderten Datei enthalten: https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/bootmanager.msg, wobei anhand der Language-Variablen in der AVM-Firmware die passende Sprache ausgewählt und nur diese Texte zum Browser übertragen werden (die Sprachauswahl erfolgt also auf der Box und anhand von FRITZ!OS-Einstellungen und nicht anhand der im Browser eingestellten Sprache(n)).

Durch diese Trennung sollte es einfacher sein, weitere Sprachen bereitzustellen - immerhin hat auch AVM jetzt alle unterstützten Sprachen in einem einzigen Image für eine Version. Wenn sich jemand an weitere Sprachen machen wollte ... der Aufbau der Zeilen dürfte selbsterklärend sein (Sprachkürzel:ID_des_Textes=Inhalt_des_Textes,die Zeilen mit any als Sprache werden immer verwendet und die Zeile Languages muß die unterstützten Sprachen aufzählen, wobei die erste Sprache in der Liste gleichzeitig der Standard ist, wenn keine oder eine nicht unterstützte Sprache im FRITZ!OS ausgewählt wurde.

---

Um das Skript etwas zu verkleinern und auch um es besser wartbar zu machen durch das Zerlegen in funktionale Komponenten, wurde auch das Erzeugen des HTML- und JS-Codes für das GUI (bisher als html_display-Operation integriert) ausgelagert in eine gesonderte Datei (https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/bootmanager_html) - dieser Teil ist ohnehin nur für FRITZ!OS-Versionen vor der 07.08-Laborreihe relevant und wird daher bei späteren FRITZ!OS-Versionen auch gar nicht erst installiert.

---

Auch das Skript zur Integration der Aufrufe in das AVM-GUI (https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/add_to_system_reboot.sh) wurde grundlegend überarbeitet, wobei auch die Patches für die verschiedenen FRITZ!OS-Versionen aus dem Skript herausgelöst und in separaten Dateien gespeichert wurden. Das heißt auch, daß man ein paar mehr Dateien kopieren muß, wenn man die Ausgangsdateien irgendwohin verschieben/kopieren will - um die Integration der richtigen Dateien für die vorliegende FRITZ!OS-Version kümmert sich dann das Skript add_to_system_reboot.sh (was man explizit mittels sh <filename> aufrufen muß, weil es /bin/false als SheBang verwendet, damit man es nicht versehentlich aufrufen kann). Wer die Dateien nach dem Klonen des Repositorys an eine andere Stelle kopieren will, muß für die Verwendung von add_to_system_version.sh mit Angabe von TARGET_VERSION=autodetect auch das Skript extract_version_values einschließen, welches nur über einen Symlink im bootmanager-Verzeichnis hinterlegt ist.

---

Da AVM offenbar das "Branding" der ausgelieferten Geräte mittlerweile nur noch in einer Form ausführt, bei der beim Systemstart dieser Wert (firmware_version) wieder aus den Daten im Konfigurationsbereich des Bootloaders restauriert wird (diese Daten werden im Rahmen der Finalisierung bei der Produktion/dem Test der Geräte geschrieben), stellt sich praktisch bei allen neueren Modellen auch die Frage, wie man diese Einstellung dennoch so ändern kann, daß man ggf. in den Genuß von Features gelangt, die nur bei einem bestimmten Branding aktiviert werden.

Bei den Geräten, wo diese Einstellung nur der Standardwert ist, solange kein anderer Wert gesetzt wurde (durch das Schreiben in das Urlader-Environment, z.B. über den FTP-Server in EVA), kann man diese Einstellung auch weiterhin ändern ... eine Entscheidung, ob dieser Weg genutzt werden kann oder nicht, ist aber nicht sicher anhand einer bestimmten Version des Bootloaders von AVM (EVA oder auch urlader) möglich. Daher wird jetzt versucht, beim ersten Start der Skript-Datei für den Boot-Manager den Urlader in der Box zu lokalisieren und den darin enthaltenen Konfigurationsbereich (zumindest dessen erste 1024 Byte) zu isolieren. Wird er gefunden und kann er erfolgreich zerlegt werden, kann man sicher entscheiden, ob das vorliegende Gerät eine einfache und dennoch permanente Änderung des Brandings durch einen Schreibvorgang ins Urlader-Environment unterstützt. In diesem Falle wird auch im GUI die Option zum Wechsel des Brandings angeboten, wenn das zu aktivierende System mehr als eines davon unterstützt.

Bei den Geräten, wo das so nicht funktioniert, hat sich ja das Ändern der Anweisung export OEM in export OEM=<value> in der Datei /etc/init.d/rc.conf eingebürgert (nur Freetz ging/geht da einen Sonderweg, ob das bei Freetz-NG auch noch so ist, weiß ich gar nicht genau), was über Umwege dann auch den Weg nach hier gefunden hat, nachdem es hier anhand eines Beispiels erklärt und hier in den Kontext des gesamten Vorgangs (Entpacken, Ändern, Einpacken, Flashen) eingebettet wurde.

Der Boot-Manager erkennt diese Art der Modifikation, die in ein "festes" Branding mündet, auch und bietet - so sie vorhanden ist - KEINEN Wechsel des Brandings an, zeigt aber im GUI diese Information auch an. Allerdings hat diese Art der Modifikation eben auch ihren Pferdefuß (auch wenn's wohl ursprünglich mal ein Ziegenhuf war) ... während AVM mittlerweile die bekannten Brandings alle in ein Image packt und es somit nicht länger erforderlich ist, parallel zur Änderung des Brandings auch gleich noch eine passende Firmware zu installieren, legt man sich mit dieser Modifikation auf ein einzelnes Branding fest und nimmt sich damit die Option, diese Einstellung zu wechseln.

Außerdem greift diese Änderung erst relativ spät (im Vergleich zu dem, was möglich wäre) im Boot-Vorgang und ist natürlich auch nicht so tiefgreifend, als wenn das bereits im Urlader eingestellt werden kann - nur dort vorgenommene Einstellungen gelten auch schon beim Start des Kernels. Aber der Kernel verwendet diese Information tatsächlich selbst nur selten (einfach mal ein grep firmware_version über die Quellen laufen lassen und die für die AVM-Firmware relevanten Stellen ansehen - nicht jede Fundstelle wird bei AVM auch genutzt), selbst wenn sie sogar in einem gesonderten Pseudo-File im procfs bereitgestellt wird, nämlich in /proc/sys/urlader/firmware_version - das ist aber auch nur ein anderer Zugriffpfad auf denselben Wert im Urlader-Environment, denn eine Änderung dort führt auch zu einem geänderten Wert in diesem speziellen Pseudo-File.

Nur schafft man eine Änderung schon für den Kernel dann eben (ohne den Konfigurationsbereich im Bootloader zu patchen, wovon ich in den allermeisten Fällen abraten würde, solange man sein Ziel auch anders erreichen kann) nicht mehr ... aber es gibt auch noch Optionen, diesen Wert schon deutlich früher zu setzen und vor allem, ihn dabei auch noch variabel zu gestalten.

Eine dieser Optionen (wo die Änderung nicht früher zum Zuge kommt, aber variable Einstellungen erlaubt) ist eine abgewandelte Form des "festen" Brandings. Dabei wird in der AVM-Datei /etc/init.d/rc.conf unmittelbar vor der Zeile mit dem export OEM ein Skript-Aufruf eingefügt, wobei dieses Skript dann die Kernel-Parameter nach einem Eintrag oem=<value> durchsucht und einen dort gefundenen Wert für die (Shell-Environment-)Variable OEM setzt, bevor diese danach dann exportiert wird.

Das Setzen dieses Wertes kann über die Urlader-Einstellung kernel_args oder kernel_args1 erfolgen, diese sind bisher m.W. auch nicht als Bestandteil der "festen Einstellungen" in der EVA-Konfiguration gesichtet worden. Manuell geht das wieder über entsprechende SETENV-Kommandos per EVA-FTP und wenn dieses Feature in der Firmware des zu aktivierenden Systems verankert ist, setzt der Boot-Manager diesen Wert auch automatisch anhand dessen, was im GUI ausgewählt wurde. Neben dem Aufruf der Skript-Datei in der /etc/init.d/rc.conf, wird noch die Existenz eines Markers (eine Zeile, die mit # YF_CHANGE_OEM beginnt) geprüft, bevor dieses Feature als verwendbar angesehen wird und eine Änderung des Brandings auf diesem Weg auch im GUI angeboten wird (https://github.com/PeterPawn/YourFr...2f249c6772f7f5d5/bootmanager/bootmanager#L578). Allerdings funktioniert es bei einigen Modellen (ich kenne da speziell die Puma6-Modelle) nicht, denn dort filtert der Bootloader die erlaubten Parameter auf der Kommandozeile und läßt nur bestimmte Werte zu (und fügt seinerseits auch weitere Werte ein).

Um diesen Ansatz in eine Firmware-Struktur zu integrieren, gibt es das Shell-Skript yf_change_oem.sh (https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/add_change_oem.sh), das einfach mit der Angabe TARGET_DIR=<basedir> im Shell-Environment aufgerufen werden kann, wobei <basedir> das Wurzelverzeichnis der FRITZ!OS-Dateisystemstruktur ist, in der die Änderungen vorgenommen werden sollen (also TARGET_DIR=<basedir> sh ./add_change_oem.sh als kompletter Aufruf). Weitere Dateien werden nicht benötigt, ein passendes Skript für "modfs" gibt es derzeit noch nicht.

Einen weiteren Weg hatte ich schon vor langer Zeit in diesem Thread weiter vorne beschrieben: https://www.ip-phone-forum.de/threa...einer-passenden-fritz-box.307098/post-2378212. Damit ist dann nicht nur der Wert für das Branding zu ändern, sondern es läßt sich (für die Zeit bis zum nächsten Systemstart) auch jeder andere Wert dort überschreiben (die einzige Voraussetzung ist, daß der Variablenname für das TFFS in der Tabelle im Quelltext des TFFS-Treibers hinterlegt ist - es funktionieren also keine "völlig beliebigen" Namen).

Die neue Version des Boot-Managers sucht nach Aufrufen dieses Skripts (mit dem Namen yf_custom_environment.sh) in den folgenden Verzeichnissen bzw. Dateien (https://github.com/PeterPawn/YourFr...2f249c6772f7f5d5/bootmanager/bootmanager#L124):

• /etc/init.d
• /etc/boot.d
• /etc/inittab
• /wrapper/etc/inittab (bei Modellen mit VR9-Chipset)

Wird ein solcher Aufruf gefunden (ohne Prüfungen, ob der auch tatsächlich erfolgt), wird ebenfalls das Ändern des Brandings im GUI aktiviert und beim Neustart der ausgewählte Wert (so er sich vom bereits gespeicherten unterscheidet) in den TFFS-Node geschrieben, der für das alternative Environment verwendet wird. Dabei wird dann davon ausgegangen, daß beim nächsten Systemstart das Skript von irgendwoher auch aufgerufen wird und die Werte, die sich aktuell im Urlader-Environment von den gewünschten unterscheiden, überschrieben werden. Damit kann man dann im Extremfall sogar HWRevision überschreiben,wobei dieser Wert im Kernel bei der Initialisierung tatsächlich mehrfach verwendet wird, um irgendwelche Entscheidungen zu treffen und ein Überschreiben sich erst ab dem Zeitpunkt der Änderung auch auswirkt.

Auch für die Integration von yf_custom_environment.sh gibt es im Moment noch kein Skript für "modfs" - es gibt einfach zu viele Möglichkeiten, wo und wie man dessen Aufruf in die AVM-Firmware integrieren könnte. Wobei die /etc/inittab sicherlich immer noch der einfachste und auch der effektivste (weil am frühesten wirksame) Weg wäre - wenn ich ein "modscript" dafür bereitstellen sollte, dann wird das jedenfalls diesen Weg implementieren. Ansonsten muß man eigentlich nur irgendwo in der Firmware den Aufruf einbauen (und natürlich den TFFS-Node mit den zu ersetzenden Werten bestücken - siehe oben bei der "Vorstellung" des Skripts) - das muß nicht zwingend ein expliziter Aufruf sein, das Skript läßt sich auch "sourcen" (also mittels dot-Kommando in ein anderes einschließen).

Für manuelle Änderungen an der Datei, welche die alternativen Werte für das Environment enthält, empfehle ich die Verwendung dieser Skript-Datei: https://github.com/PeterPawn/YourFritz/blob/main/tffs/fritzos_scripts/tvi - beim Aufruf mit tvi 80 werden alle notwendigen Schritte zum Editieren des TFFS-Nodes vom Skript ausgeführt und der vi aufgerufen. Beim Verlassen des Editors werden dann event. ausgeführte Änderungen (aber erst nach einer Nachfrage) ins TFFS zurück geschrieben. Dieses Skript muß man dann auch noch in die eigene Firmware-Struktur kopieren, wenn man sie dort irgendwann verwenden will (es gibt aber andere Optionen - diese Datei ist nur der am einfachsten zu benutzende Weg).

---

Zusammenfassen kann man diese Optionen beim Branding also wie folgt:

Option	Pro	Contra
änderbar über EVA-Einstellungen	- "ab Werk" verfügbar, wenn die EVA-Version paßt	- nur in älteren Modellen mit älteren Bootloader-Versionen verfügbar
nicht änderbar		- keine Features von anderen Brandings zum Austesten
festes Branding in rc.conf	- ermöglicht die Benutzung anderer Features	- nur ein einzelnes Branding nutzbar, keine Möglichkeit der Umschaltung im GUI
variables Branding über Kernel-Parameter	- ermöglicht die Benutzung anderer Features - Umschaltung per GUI	- nur die Änderung des Brandings ist verfügbar, andere EVA-Einstellungen können nicht geändert werden - funktioniert nicht bei allen Modellen
variables Environment über yf_custom_environment	- praktisch jeder Wert im Urlader-Environment kann an die eigenen Wünsche angepaßt werden	- die Änderungen greifen erst, nachdem der Kernel schon initialisiert wurde (das gilt für die anderen Optionen aber auch) und einige der im Environment hinterlegten Werte (bis hin zur maca bei einigen Modellen), können nicht mehr WIRKSAM geändert werden

Ich persönlich würde mich daher immer für yf_custom_environment entscheiden, wenn ich die Wahl hätte - damit hat man die Flexibilität UND die Möglichkeit von Änderungen und darüber hinaus macht diese Lösung auch noch dann Sinn, wenn es bei den Änderungen nicht um das Branding geht.

 

[PeterPawn]

Ich gebe es auf ... bei Versuchen, ein paar Fehler/Formulierungen oben noch zu korrigieren, funkt mit ständig irgendein (idiotisch konfigurierter) Filter von Cloudflare dazwischen und ich bin es leid, da jedesmal die Ursache des Problem zu "erraten". Letzter Versuch war: Cloudflare Ray ID: 6e67cab88b4191ef - falls sich jemand ansehen möchte, warum das Update da blockiert wurde. Ich finde jedenfalls keinen Grund mehr - irgendwelche Stellen, wo ich ggf. ein "<sсriptname>" verwendet hatte, habe ich schon geändert ... obwohl auch dabei ein "Zuschlagen" eines Filters nachgerade lächerlich ist und nicht wirklich "smart".

 

[treysis]

@PeterPawn
Jetzt gibt es ja die 7.50, die ein etwas anderes Webinterface hat. Allerdings vorerst nur für die 7590.

Für meine 7520 habe ich mir nun erstmal für die Labor-Version (7.39) ein neues signiertes Image gebaut (mit Hilfe von @Osprey vom und der Signatur von @Insti). Allerdings startet die Box daraufhin alle paar Minuten neu. Ein Aufrufen des Neustart-Reiters im System-Menü führt auch zu einem Absturz der Box. Wenn ich das Image allerdings ohne gui_boot_manager (v0.8) erstelle, dann läuft alles prima. Natürlich kann ich dann keine Partition zum Neustart mehr auswählen.

Jetzt hatte ich erstmal die Befürchtung, dass das auch die finale 7.50 betreffen könnte. Die gibt es aktuell aber eben nur für die 7590 (non-AX). Evtl. kann das mal jemand überprüfen, ob die Box damit auch Probleme bekommt? Oder zumindest als Grundlage nehmen, um die gui_boot_manager für die neue FritzOS-Version anzupassen?

Edit DM41: Beitrag hierhin verschoben aus

Anleitung zum Ändern des "Branding" bei FritzBox - (auch) für DAUs

Anleitung zum Ändern des "Branding" Da das alte Thema (hier) zu alt, zu lang und zu unübersichtlich geworden ist, versuche ich hier mal was neues zusammenzubauen, was hoffentlich auch jeder versteht. Hier auch noch etwas zum lesen: >>klick

www.ip-phone-forum.de