--help
) gibt Auskunft, was das Skript macht.wie lautet der Befehl den richtig um die Originalimage zu modifizieren?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
:~/freetz/yourfritz-master/tffs$ sudo ./yf_custom_environment.sh FRITZ.Box_7590-07.20.image
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
/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
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.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).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 3490testen will,
Folgende Modelle könnten wahrscheinlich ebenfalls funktionieren: 7272, 3272, 3390,3490(geklärt 17.06.2015, 3490 funktioniert)
Auf einer 3272 sollte sich aber auch das Branding im BM auswählen lassen.BM - läuft auf der 3272 mit 06.87 auch.
Das weiß ich auch nicht mehr 100% - außerdem ist die Box ein ziemlicher Exot.Läuft es denn nun verifiziert auf einer 3390?
Hallo zusammen,Derzeit ist der BM in der Lage, FRITZ!Box-Modelle.....bis hin zu den DOCSIS3-Modellen (6490, 6590, 6430) mit dem Puma6-Chipset.
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
Das hat leider noch nicht mitAm ARM-System braucht du dich nicht "zu vergreifen".
./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)
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
Telnet hat auch bei mir (FB 7590) nicht mehr mit den modscripts funktioniert.Edit: Bootmanager hat geklappt !!! Telnet leider nicht.
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).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.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.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.YourFritz
-Repository übernommen./var/run/bootmanager/{input|output}
bereit.gui_bootmanager
wurde - an allen Stellen, wo er auftrat - in bootmanager
geändert.modfs
-Repository übernommen - dort ebenfalls unter einer neuen Versionsnummer 0.7.1.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)).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.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.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.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.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.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.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./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.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).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.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)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.dot
-Kommando in ein anderes einschließen).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).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 |
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.