BurningCrash
Aktives Mitglied
- Mitglied seit
- 21 Jun 2007
- Beiträge
- 1,770
- Punkte für Reaktionen
- 0
- Punkte
- 38
[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen
- Ersteller PeterPawn
- Erstellt am
CleanaZ
Neuer User
- Mitglied seit
- 12 Jun 2006
- Beiträge
- 5
- Punkte für Reaktionen
- 0
- Punkte
- 1
Hallo,
ich hätte da mal ein paar Fragen zu "modfs - Die Gebrauchsanleitung"
1.) Unter Punkt 2 "Vorbereitung" steht
2.1 Wenn die FB online ist, einfach an der Konsole folgendes eingeben:
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
Was für eine Konsole ist denn damit gemeint ? Unter der Windows-Kommandozeilenkonsole bekomme ich da nur Fehlermeldungen.
Und wenn damit die Telnet-Konsole gemeint ist, dann wäre es nett, wenn erklärt würde, wie ich das mit einer FB 7490 machen soll,
auf der sich Telnet ja nicht mehr per #96*7* aktivieren lässt. Oder geht das auch irgendwie im ADAM2/EVA Modus per FTP-Befehlen ?
Und bei "2.2 Wenn man offline ist, dann muß man sich vorher die Datei modfs.tgz auf den PC laden und dann in den NAS der FB kopieren
wüsste ich gerne, ob damit der interne NAS gemeint ist oder eine per USB angeschlossene Festplatte oder USB-Stick, da bei
4. modfs auf einer 7490/3490
Diese beiden FB sind die einzigen, wo man modfs auch ohne Speicher-Stick machen kann, da sie genügend Speicher haben (256MB RAM, 406MB NAS).
Bedingung ist aber, daß der NAS nicht zu voll ist. Bis 100MB belegt ist es noch kein Problem.
Peter empfiehlt auch für diese FB einen Speicher-Stick!
ja steht, dass NUR diese beiden FBs genügend NAS-Speicher haben. Somit müsste man den Punkt 2.2 eigentlich rausnehmen, wenn es bei anderen FBs "offline" per
NAS-Speicher eh nicht funktionieren würde, oder ?
Eine "richtige" Anleitung, wie auch der 'normale' User das modfs installieren und nutzen kann, wäre echt mal eine nette Sache.
Mit "richtige" Anleitung meine ich einen kompletten Ablauf der Installation, also in der Art
1) Bereite die FB folgendermassen vor:
a) per ADAM2: ...
b1) per Telnet bis FW xxx: ...
b1) per Telnet ab FW 6.50: ...
c) per 'sonstwie': ...
2) Lade modfs von der Webadresse xxx und speichere es an Ort yyy etc.
3) Starte modfs folgendermaßen: ...
Ich hab jetzt schon zig Seiten durchgelesen, aber ich krieg es einfach nicht hin, auf der FB 7490 das Telnet zu aktivieren.
Habs mit der FW 6.50 probiert, dann ein Downgrade auf 6.30 - aber es geht einfach nicht. Muss ich noch weiter downgraden
(wenn ja, wo find ich Versionen/Images vor 6.30 ?)
Gruß
ich hätte da mal ein paar Fragen zu "modfs - Die Gebrauchsanleitung"
1.) Unter Punkt 2 "Vorbereitung" steht
2.1 Wenn die FB online ist, einfach an der Konsole folgendes eingeben:
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
Was für eine Konsole ist denn damit gemeint ? Unter der Windows-Kommandozeilenkonsole bekomme ich da nur Fehlermeldungen.
Und wenn damit die Telnet-Konsole gemeint ist, dann wäre es nett, wenn erklärt würde, wie ich das mit einer FB 7490 machen soll,
auf der sich Telnet ja nicht mehr per #96*7* aktivieren lässt. Oder geht das auch irgendwie im ADAM2/EVA Modus per FTP-Befehlen ?
Und bei "2.2 Wenn man offline ist, dann muß man sich vorher die Datei modfs.tgz auf den PC laden und dann in den NAS der FB kopieren
wüsste ich gerne, ob damit der interne NAS gemeint ist oder eine per USB angeschlossene Festplatte oder USB-Stick, da bei
4. modfs auf einer 7490/3490
Diese beiden FB sind die einzigen, wo man modfs auch ohne Speicher-Stick machen kann, da sie genügend Speicher haben (256MB RAM, 406MB NAS).
Bedingung ist aber, daß der NAS nicht zu voll ist. Bis 100MB belegt ist es noch kein Problem.
Peter empfiehlt auch für diese FB einen Speicher-Stick!
ja steht, dass NUR diese beiden FBs genügend NAS-Speicher haben. Somit müsste man den Punkt 2.2 eigentlich rausnehmen, wenn es bei anderen FBs "offline" per
NAS-Speicher eh nicht funktionieren würde, oder ?
Eine "richtige" Anleitung, wie auch der 'normale' User das modfs installieren und nutzen kann, wäre echt mal eine nette Sache.
Mit "richtige" Anleitung meine ich einen kompletten Ablauf der Installation, also in der Art
1) Bereite die FB folgendermassen vor:
a) per ADAM2: ...
b1) per Telnet bis FW xxx: ...
b1) per Telnet ab FW 6.50: ...
c) per 'sonstwie': ...
2) Lade modfs von der Webadresse xxx und speichere es an Ort yyy etc.
3) Starte modfs folgendermaßen: ...
Ich hab jetzt schon zig Seiten durchgelesen, aber ich krieg es einfach nicht hin, auf der FB 7490 das Telnet zu aktivieren.
Habs mit der FW 6.50 probiert, dann ein Downgrade auf 6.30 - aber es geht einfach nicht. Muss ich noch weiter downgraden
(wenn ja, wo find ich Versionen/Images vor 6.30 ?)
Gruß
wenn Du FB7490 mit FW 06.30 hast, dann nimmst Du am Besten SIAB (Shell In A Box), aka modfs-starter
dann einfach die "WebConsole" SIAB temporärer nutzen (Einloggen per https://fritz.box:8010 siehe auch http://www.ip-phone-forum.de/attachment.php?attachmentid=85084&d=1451155372) und anschließend die "Installation der Vollversion" modfs gemäß Abschnitt 2.1 der "modfs Gebrauchsanleitung" durchführen.
Hinweis: steht auch so in Anleitung von eisbaerin
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Hinweis: die Installation von modfs via modfs-Starter funktioniert sogar mit FB7490 FW 06.50 noch;
siehe Anleitung von HandyMaxe:
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,202
- Punkte für Reaktionen
- 589
- Punkte
- 113
noch einfacher und kürzer ist die Nutzung des "Remote Command Execute Triggers", auch "Push Service" genannt,dann braucht man nicht mal neu flashen oder Rebooten;
in 3 Schritten hat man dann Telnet Zugang:
1.) entsprechende Datei /var/media/ftp/start_telnet.sh auf NAS-Storage der Box ablegen;
2.) Push Service "Werkseinstellungen wiederherstellen" definieren,
Details https://service.avm.de/help/de/FRITZ-Box-6490-Cable/014/hilfe_system_pushservice_cfgexport
3.) am Telefon "#991*15901590*" wählen
vorab noch obligatorische Configsicherung erstellen, dann hat man, wenn man bei 1.) vergessen hat den Befehl "/usr/bin/killall firmwarecfg" ans Ende der Datei /var/media/ftp/start_telnet.sh zu schreiben, eine Fallback-Position der Config.
Quellen:
https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851
http://www.ip-phone-forum.de/showthread.php?t=286994&p=2193739&viewfull=1#post2193739
CleanaZ
Neuer User
- Mitglied seit
- 12 Jun 2006
- Beiträge
- 5
- Punkte für Reaktionen
- 0
- Punkte
- 1
Hallo,
und vielen Dank für die Hilfe.
Mit euren Hinweisen und Links hab ich es nun geschafft.
Allerdings hätte ich noch so 1-2 Fragen.
1) Ich hab das System von v6.30 nun mit modfs Update auf v6.60 in der Partition 0 ([FONT="]linux_fs_start=0) liegen.
In der inaktiven Partition 1 ist daher noch das vorherige (Original-)System v6.30 mit SIAB.
a) Wenn ich nun die FB stromlos mache und in den ADAm2/EVA-Modus gehe und dort per ftp irgendwelche
Einstellungen vornehme (z.B [/FONT]quote SETENV firmware_version avm[FONT="]) - wo wird das dann geändert, in Partition 0 oder 1
b1) Wenn ich die AVM-Recovery.exe benutze, welches System auf welcher Partition wird dann zurückgesetzt bzw.
neu eingespielt ?
b2) Wenn ich vorher im 'neuen' System mit modfs in der Partition 0 per WebIF unter "Neustart" in das "derzeit inaktive
System" (also die Partition 1) reboote, wird dann die Recovery.exe nur auf dieser Partition ausgeführt, so dass mein
'neues' System mit modfs unangetastet bleibt ?
c) Wenn ich in das 'alte" System mit v6.30 auf Partition 1 wechsel und dann dort über die Weboberfläche der FB ein
Update vornehme (per Online-Update vom AVM-Server oder per Dateiauswahl von meiner Festplatte), wird dann
nur dieses 'alte' System aktualisiert oder killt das auch mein neues System mit modfs auf Partition 0 (und was ist bei
einem Downgrade statt Update) ?
Ich würde nämlich gerne das modifizierte System mit modfs auf Partition 0 als "Arbeitssystem" einsetzen und das
'alte' System auf der Partition 1 dahingehend nutzen, dass ich dort die Beta-Versionen von AVM per Auto-Update
einspiele - ist sowas möglich (wenn ja, wie) ??
Ach ja, und im neuen modfs-System steht nun oben in der WebUI der Text "Vom Hersteller nicht unterstützte
Änderungen" - kann ich das irgendwie dauerhaft entfernen (oder gibt es da evt. einen modfs-Befehl dafür) ?
Gruß
Ralf[/FONT]
und vielen Dank für die Hilfe.
Mit euren Hinweisen und Links hab ich es nun geschafft.
Allerdings hätte ich noch so 1-2 Fragen.
1) Ich hab das System von v6.30 nun mit modfs Update auf v6.60 in der Partition 0 ([FONT="]linux_fs_start=0) liegen.
In der inaktiven Partition 1 ist daher noch das vorherige (Original-)System v6.30 mit SIAB.
a) Wenn ich nun die FB stromlos mache und in den ADAm2/EVA-Modus gehe und dort per ftp irgendwelche
Einstellungen vornehme (z.B [/FONT]quote SETENV firmware_version avm[FONT="]) - wo wird das dann geändert, in Partition 0 oder 1
b1) Wenn ich die AVM-Recovery.exe benutze, welches System auf welcher Partition wird dann zurückgesetzt bzw.
neu eingespielt ?
b2) Wenn ich vorher im 'neuen' System mit modfs in der Partition 0 per WebIF unter "Neustart" in das "derzeit inaktive
System" (also die Partition 1) reboote, wird dann die Recovery.exe nur auf dieser Partition ausgeführt, so dass mein
'neues' System mit modfs unangetastet bleibt ?
c) Wenn ich in das 'alte" System mit v6.30 auf Partition 1 wechsel und dann dort über die Weboberfläche der FB ein
Update vornehme (per Online-Update vom AVM-Server oder per Dateiauswahl von meiner Festplatte), wird dann
nur dieses 'alte' System aktualisiert oder killt das auch mein neues System mit modfs auf Partition 0 (und was ist bei
einem Downgrade statt Update) ?
Ich würde nämlich gerne das modifizierte System mit modfs auf Partition 0 als "Arbeitssystem" einsetzen und das
'alte' System auf der Partition 1 dahingehend nutzen, dass ich dort die Beta-Versionen von AVM per Auto-Update
einspiele - ist sowas möglich (wenn ja, wie) ??
Ach ja, und im neuen modfs-System steht nun oben in der WebUI der Text "Vom Hersteller nicht unterstützte
Änderungen" - kann ich das irgendwie dauerhaft entfernen (oder gibt es da evt. einen modfs-Befehl dafür) ?
Gruß
Ralf[/FONT]
sämtliche Bootloader-Environmental-Varaiblen wie firmware_version haben Scope "GLOBAL",
d.h. diese Einstellungen wirken beim Booten und werden auf beiden Partition-Sets 0 und 1.
die [FONT=&]AVM-Recovery.exe wirkt auf das aktuelle Partition-Set.[/FONT]
wie vorher geschrieben, die [FONT=&]AVM-Recovery.exe liest die Bootloader-Environment-Variable linux_fs_start aus und überschreibt die zugehörigen Partition-Sets;
die inaktive Partition bleibt unangetastet.
[/FONT]
Ein Update ([FONT=&]Online-Update vom AVM-Server oder per Dateiauswahl von Festplatte, sowie modfs-update) [/FONT]wirkt immer auf das inaktive Partition-Set,
d.h. wenn mit [FONT=&]linux_fs_start=1 gebootet wurde, dann wird bei Update (etwaiger Downgrade wird systemtechnisch als "forced update" gehandelt) das inaktive Partition-Set 0 [/FONT] (bei Dir FW 06.60) überschrieben.
Bei Iststand:
Code:
linux_fs_start=0, Partition-Set 0: v6.60-modfs-0.4.1-191120160505
linux_fs_start=1, Partition-Set 1: v6.30 mit modfs-starter
Zuletzt bearbeitet:
hier musst Du zuerst die Ursachen per "/sbin/eventsdump -d" für diese Meldung ermitteln, z.B.
Code:
/sbin/eventsdump -d
NOT_SIGNED,[COLOR=#0000ff]TELNET[/COLOR]anschleßend kann man mit
Code:
echo clear_id 87 >/proc/tffsDetails siehe Beitrag von ralda: http://wiki.ip-phone-forum.de/software:ds-mod:development:manipulation_erkennung
Eisbaerin ist ja nicht mehr zu sehen und antwortet auf meine PM nicht, Dein Verbesserungsvorschlag ist angenommen, auf die "richtige" Anleitung" von Dir bin ich sehr gespannt
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Noch ein Hinweis meinerseits zu "Recovery": Das Recovery-Programm lädt nur die "normale Firmware" (der Inhalt ist also derselbe wie beim Update-Image) in den Speicher und startet sie dort. Die in dieser gestarteten Firmware enthaltene "/sbin/flash_update"-Datei ist dann das hüpfende Komma, das über das Ziel der Installation entscheidet (das ist dieselbe Datei, die beim "modfs-Starter" benutzt wird für die Modifikation des Systems).
Dort wird die aktuelle Partition ermittelt und in diese geschrieben ... damit ist also der Zeitpunkt entscheidend (beim Start dieses Images aus dem Speicher der Box) und der Inhalt von "linux_fs_start" zu diesem Zeitpunkt, da anhand dieser Variablen die Namen für die Flash-Partitionen "vergeben" werden (mit oder ohne "reserved"-Zusatz) und das "flash_update"-Skript sich auf diese Namen stützt.
Wenn also AVM irgendwann einmal hingehen sollte und in das Recovery-Programm ein Image mit abweichender "flash_update"-Datei einbetten würde, dann ändert sich auch das Verhalten des Recovery-Programms ... weil das eben gar nicht selbst entscheidet, welche Partition beschrieben wird. So ein aus dem Speicher gestartetes Image hat allerdings seinerseits jederzeit die Wahl, welche Partitionen es überschreiben will, denn die "aktiven" Daten liegen bereits im RAM und beide Partitionen-Sätze können gefahrlos beschrieben werden.
Beim Update (aus dem laufenden System heraus) kann (ohne zusätzliche Vorkehrungen) ja nur das jeweils inaktive Partition-Set beschrieben werden - ansonsten würde das System sich ja sein eigenes Wurzeldateisystem überschreiben und nachfolgende Zugriffe auf dieses Dateisystem würden mit einiger Wahrscheinlichkeit zur "kernel panic" führen ... lediglich den Kernel könnte man (nachdem er beim Start ins RAM kopiert und entpackt wurde) überschreiben, das macht aber nur wenig Sinn (da ja Kernel und Dateisystem zueinander passen müssen).
Man kann also vor der Verwendung des Recovery-Programms tatsächlich durch das Setzen von "linux_fs_start" die Zielpartition beeinflussen (beim NAND-Recovery muß man aber auch immer beachten, daß erst der Start des "in-memory"-Images die Daten wirklich in den Flash-Speicher schreibt - man darf nicht zu früh den Stecker ziehen) ... macht man das aus dem laufenden System heraus (also das Umsetzen von "linux_fs_start"), hat es durchaus auch einen Effekt, aber einen (vermutlich) eher unerwarteten.
Da sich dabei die Namen der Partitionen nicht unmittelbar ändern (die werden beim Systemstart festgelegt), schreibt das Update die Daten nach wie vor in die inaktiven Partitionen. Kommt es dann aber an die Stelle, wo der neue Wert für "linux_fs_start" festgelegt werden soll, dann wird dort der aktuelle konsultiert und der alternierende Wert für den nächsten Start gesetzt. Hier würde sich also eine Änderung vor dem Update so auswirken, daß wieder das gerade laufende System beim nächsten Start geladen wird, obwohl die inaktiven Partitionen mit einem neuen System beschrieben wurden.
Hat man diese Mechanismen wirklich begriffen, kann man sie sich zunutze machen ... aber bitte nur dann. Nicht ganz umsonst geht "modfs" vor der Änderung auf der Box hin und prüft diese Einstellungen auf Plausibilität - kommt dabei die "Vermutung" auf, daß das gerade laufende System nicht das für den nächsten Start vorgesehene ist (also "linux_fs_start" nicht zum derzeitigen System paßt), verweigert es die Arbeit - einfach damit da nicht am Ende doch aus dem laufenden System heraus die aktiven Partitionen unabsichtlich überschrieben werden, was nur mit einem Absturz (und anschließender - zumindest hochwahrscheinlicher - Disfunktion) enden kann.
- - - Aktualisiert - - -
Und noch eine Bemerkung zu den "Nicht unterstützten Änderungen": Wer sich daran wirklich stört und trotzdem irgendwo das "ar7login" verwenden will (das ist nämlich für diesen Eintrag im TFFS-Node 87 zuständig und es kommt u.a. auch bei "Shell in a Box" zum Einsatz, weil nur so die "eingebauten Konten" benutzt werden können), der hat entweder die Möglichkeit, das Flag im Node 87 immer wieder zu löschen oder man geht einfach hin und entfernt diese Anzeige aus den Lua-Dateien. Damit sieht man das immer noch in der Support-Datei - man muß sich also vorher überlegen, was man am Ende erreichen will. Da SIAB mit TLS auch nicht unsicherer ist als SSH, braucht es also auch nicht unbedingt "dropbear" als SSH-Server.
Wenn eine (automatische) Änderung der "post_install" mit einem "modscript" nicht gleich in richtige Arbeit ausarten würde (die liegt ja in der "var.tar" vor und damit müßte die zum Patchen erst entpackt, dann geändert und im Anschluß wieder gepackt werden), hätte ich vermutlich schon lange in die "post_install" das Löschen von Node 87 als Option eingebaut.
Ich selbst habe das so gelöst, daß in einem "custom image" für die "E99-custom" auch ein Skript enthalten ist, das bei gesetzter "Warnung" (spart unnötige Schreibzugriffe im TFFS) diese wieder zurücksetzt ... das mache ich aber nur einmalig beim Systemstart, weil gerade auf "fremden Boxen" einer Anmeldung über "ar7login" in den meisten Fällen ohnehin ein Neustart folgen wird. Das Skript selbst ist simpel (nur die Rückgabe von 0 oder 1 je nach ausgeführter Aktion macht daraus mehr als einen Einzeiler):
Wer das gleich in den Lua-Dateien ändern will: Auch da hilft die Suche nach "signed_firmware" - das gibt es einmal in der "diagnosis.lua" als direkte Abfrage (ggf. in mehreren Brandings) und einmal als "Variable" in "retrieve_data.lua", wo es dann von anderen Seiten (u.a. der Übersicht) genutzt wird.
Dort wird die aktuelle Partition ermittelt und in diese geschrieben ... damit ist also der Zeitpunkt entscheidend (beim Start dieses Images aus dem Speicher der Box) und der Inhalt von "linux_fs_start" zu diesem Zeitpunkt, da anhand dieser Variablen die Namen für die Flash-Partitionen "vergeben" werden (mit oder ohne "reserved"-Zusatz) und das "flash_update"-Skript sich auf diese Namen stützt.
Wenn also AVM irgendwann einmal hingehen sollte und in das Recovery-Programm ein Image mit abweichender "flash_update"-Datei einbetten würde, dann ändert sich auch das Verhalten des Recovery-Programms ... weil das eben gar nicht selbst entscheidet, welche Partition beschrieben wird. So ein aus dem Speicher gestartetes Image hat allerdings seinerseits jederzeit die Wahl, welche Partitionen es überschreiben will, denn die "aktiven" Daten liegen bereits im RAM und beide Partitionen-Sätze können gefahrlos beschrieben werden.
Beim Update (aus dem laufenden System heraus) kann (ohne zusätzliche Vorkehrungen) ja nur das jeweils inaktive Partition-Set beschrieben werden - ansonsten würde das System sich ja sein eigenes Wurzeldateisystem überschreiben und nachfolgende Zugriffe auf dieses Dateisystem würden mit einiger Wahrscheinlichkeit zur "kernel panic" führen ... lediglich den Kernel könnte man (nachdem er beim Start ins RAM kopiert und entpackt wurde) überschreiben, das macht aber nur wenig Sinn (da ja Kernel und Dateisystem zueinander passen müssen).
Man kann also vor der Verwendung des Recovery-Programms tatsächlich durch das Setzen von "linux_fs_start" die Zielpartition beeinflussen (beim NAND-Recovery muß man aber auch immer beachten, daß erst der Start des "in-memory"-Images die Daten wirklich in den Flash-Speicher schreibt - man darf nicht zu früh den Stecker ziehen) ... macht man das aus dem laufenden System heraus (also das Umsetzen von "linux_fs_start"), hat es durchaus auch einen Effekt, aber einen (vermutlich) eher unerwarteten.
Da sich dabei die Namen der Partitionen nicht unmittelbar ändern (die werden beim Systemstart festgelegt), schreibt das Update die Daten nach wie vor in die inaktiven Partitionen. Kommt es dann aber an die Stelle, wo der neue Wert für "linux_fs_start" festgelegt werden soll, dann wird dort der aktuelle konsultiert und der alternierende Wert für den nächsten Start gesetzt. Hier würde sich also eine Änderung vor dem Update so auswirken, daß wieder das gerade laufende System beim nächsten Start geladen wird, obwohl die inaktiven Partitionen mit einem neuen System beschrieben wurden.
Hat man diese Mechanismen wirklich begriffen, kann man sie sich zunutze machen ... aber bitte nur dann. Nicht ganz umsonst geht "modfs" vor der Änderung auf der Box hin und prüft diese Einstellungen auf Plausibilität - kommt dabei die "Vermutung" auf, daß das gerade laufende System nicht das für den nächsten Start vorgesehene ist (also "linux_fs_start" nicht zum derzeitigen System paßt), verweigert es die Arbeit - einfach damit da nicht am Ende doch aus dem laufenden System heraus die aktiven Partitionen unabsichtlich überschrieben werden, was nur mit einem Absturz (und anschließender - zumindest hochwahrscheinlicher - Disfunktion) enden kann.
- - - Aktualisiert - - -
Und noch eine Bemerkung zu den "Nicht unterstützten Änderungen": Wer sich daran wirklich stört und trotzdem irgendwo das "ar7login" verwenden will (das ist nämlich für diesen Eintrag im TFFS-Node 87 zuständig und es kommt u.a. auch bei "Shell in a Box" zum Einsatz, weil nur so die "eingebauten Konten" benutzt werden können), der hat entweder die Möglichkeit, das Flag im Node 87 immer wieder zu löschen oder man geht einfach hin und entfernt diese Anzeige aus den Lua-Dateien. Damit sieht man das immer noch in der Support-Datei - man muß sich also vorher überlegen, was man am Ende erreichen will. Da SIAB mit TLS auch nicht unsicherer ist als SSH, braucht es also auch nicht unbedingt "dropbear" als SSH-Server.
Wenn eine (automatische) Änderung der "post_install" mit einem "modscript" nicht gleich in richtige Arbeit ausarten würde (die liegt ja in der "var.tar" vor und damit müßte die zum Patchen erst entpackt, dann geändert und im Anschluß wieder gepackt werden), hätte ich vermutlich schon lange in die "post_install" das Löschen von Node 87 als Option eingebaut.
Ich selbst habe das so gelöst, daß in einem "custom image" für die "E99-custom" auch ein Skript enthalten ist, das bei gesetzter "Warnung" (spart unnötige Schreibzugriffe im TFFS) diese wieder zurücksetzt ... das mache ich aber nur einmalig beim Systemstart, weil gerade auf "fremden Boxen" einer Anmeldung über "ar7login" in den meisten Fällen ohnehin ein Neustart folgen wird. Das Skript selbst ist simpel (nur die Rückgabe von 0 oder 1 je nach ausgeführter Aktion macht daraus mehr als einen Einzeiler):
Code:
#!/bin/sh
rc=0
[ $(ctlmgr_ctl r box status/signed_firmware) = 0 ] && echo clear_id 87 >/proc/tffs || rc=1
exit $rcCleanaZ
Neuer User
- Mitglied seit
- 12 Jun 2006
- Beiträge
- 5
- Punkte für Reaktionen
- 0
- Punkte
- 1
Weitere Fragen
Hallo,
erstmal herzlichen Dank an Pokemon20021 und PeterPawn für die Antworten.
Leider hab ich bisher keinerlei Erfahrung mit Linux außer dem bisschen was ich mir hier durch das Lesen der Beiträge so halbwegs zusammenreimen kann.
Daher entschuldigt bitte, wenn ich immer mal wieder nachfragen muss.
(Noch ein kleiner Hinweis: ihr braucht euch nicht unbedingt die Arbeit machen und für die Antworten meine Fragen zitieren. Da ich immer Zahlen/Nummern vor meine Fragen schreibe, genügt es, wenn diese für die Antwort angegeben werden - ich such mir dann schon Fragen und Antworten zusammen)
So, nun zu meinen neuen Fragen.
1) Wenn ich es recht verstanden habe, werden die modfs-Funktionen ja dadurch installiert/integriert, dass mittel modfs per "./modfs update" die neueste Firmware-Datei vom AVM-Server geholt wird, dann entpackt wird, dann die mit "JA" beantworteten Modulteile von modfs in das FW-Image integriert werden und dieses neue Image dann auf die Box in die inaktive Partition geflasht wird.
Wenn ich nun in modfs einige Fragen zur Installation von bestimmten modfs-Modulen mit JA beantwortet habe und später einige davon nicht mehr haben (also entfernen) möchte, muss ich dann das Ganze von vorne starten mit "./modfs update" UND geht das überhaupt, wenn die FW-Version auf dem AVM-Server (die modfs runterlädt) dieselbe ist, die ich schon auf der Box habe ?
2) in der "modfs Gebrauchsanleitung" ist unter Punkt 3 beschrieben
- Erzeugen einer Installations-Datei für eine andere FB:
Es wird keine vollständige FW erzeugt, sondern ein SquashFS! (siehe auch 7.)
und unter 7. dann
Auf z.B. der 7490:
Die Datei .squashfs auf die 7412 nach /var/tmp kopieren.
Auf der 7412:
- in beiden Partionen muß eine FW installiert sein!!!
- der Kernel der inaktiven Partition muß zur .squashfs passen, sonst neuen Kernel mit normalem update installieren, und auf alte Partition zurückschalten (oder mit "modfs install", siehe 11.).
2a) FRAGE: was heißt hier "...neuen Kernel mit normalem update installieren" - ist damit die Installatiion der normalen Firmware (*.image) Datei von AVM über das WebUI gemeint und was passiert, wenn ich obigen Code bzw. das install_inactive_rootfs ausführe (bzw. wofür ist das).
und unter Punkt 11 wiederum
Installation von Kernel, Wrapper-Partition und Root-Image:
2b) FRAGE: Wenn ich diesen Befehl hier nutze, also
"./modfs install /var/media/ftp/FRITZ.Box_7412.137.06.50.image" entspricht das dann dem o.g. "install_inactive_rootfs" ?
2c) FRAGE: Kann ich mir mit dieser Vorgehensweise auch Images für dieselbe FB erstellen (also auf meiner FB7490 Images für meine FB 7490 - aber mit jeweils unterschiedlichen modfs-Modulen
2d) FRAGE: Kann ich diese Images aus der inaktiven Partition heraus per WebUI installieren, so dass mein modfs-System in der aktiven Partition überschrieben wird oder muss ich das mit modfs installieren (per "./modfs update source_image") oder geht das so eh nicht ?
Hintergrund zu 2c/d) Könnte man sich damit mehrere "fertige" Images mit modfs - aber unterschiedlichen Modulen von modfs - anfertigen und dann bei Bedarf einfach die passende auf die eigene FB draufspielen (z.B. ein Image mit modfs und telnet, ein Image ohne Telnet aber mit Nachtschaltungsanzeige etc.)
3) Leider versteh ich von dem was der Spezialist PeterPawn schreibt nur einen kleinen Bruchteil. Im Post #1014 steht folgendes:
4) Fragen zu der Umschaltung der aktiven/inaktiven Partitionen
Ich habe jetzt folgendes auf meiner Box:
Partition 0 (linux_fs_start 0) - FritzOS 6.60 mit modfs - alle Fragen mit JA beantwortet / alle Module installiert
Partition 1 (linux_fs_start 1) - FritzOS 6.30 (Auslieferzustand FB 7490 o2 edition) und installiertem modfs_starter aka SIAB
In der Partition 0 mit modfs habe ich ja die Möglichkeit (bei entsprechend installiertem modfs-Modul) in der WebUI (über System->Sicherung->Neustart) die FB in/mit der anderen Partition neu zu starten. In der Partition 1 gibt es diese Möglichkeit so ja nicht (außer ich würde dort auch modfs installieren).
4a) In diesem Thread in Post #88 werden diverse "switch_system" Images/Scripts beschrieben. Kann ich diese Pseudo-Images ganz einfach über die WebUI der FB einspielen über die Update-Funktion - und geht das in allen Partitionen (d.h. egal ob mit oder ohne integriertes modfs); oder wird durch diese Pseudo-Images das System in der aktiven oder inaktiven Partition beim Update überschrieben ? [was genau passiert beim Nutzen eines solchen Pseudo-Images eigentlich genau ?]
4b) Wie Pokemon20021 in seiner Antwort an mich erwähnte:
Nun wäre es natürlich genial, wenn man in BEIDEN Partitionen die Möglichkeit hätte, jeweils eine andere/eigene Konfiguration zu verwenden.
In diesem Thread wird ein Bootmanager für 7490 von PeterPawn beschrieben. Wie kann ich diesen Bootmanager bzw. die "bootmanager_7490.tgz" (oder das Script) installieren/integrieren ? Da dieser Bootmanager ja scheinbar 2 verschiedene Konfigurationen (FB-Einstellungen) verwalten kann, würde mich interessieren,
- ob ich diesen Bootloader wie von mir gedacht nutzen kann ?
- wo man diesen Bootloader installieren muss, damit er für beide Partitionen funktioniert (also dass man von jeder Partition in die andere umschalten und dann die jeweils
für diese Partition vorgenommenen FB-Einstellungen nutzen/laden kann) ?
- wie man diesen Bootloader installiert (in dem System/der Partition ohne modfs und/oder in dem System mit modfs) - was für Befehle muss ich da (per Telnet oder per modfs oder sonstwie) eingeben ?
5) Wenn ich per ruKernelTool im Adam2/EVA-Modus die Environment-Variablen auslese, dann wird mir u.a. folgendes ausgegeben:
Soweit ich beim Lesen von Postings etc. bisher mitbekommen hab, sollte dei FB doch eigentlich nur mtd1 bis mtd4 haben. In diesem Artikel werden zwar einige
Hansenet/Alice-Boxen erwähnt, die mtd5 nutzen, aber aber bei der FB mit NAND-Flash sind es doch eigentlich 4, oder ? - kann mir dazu jemand näheres sagen ?
(Leider funktioniert das Auslesen/Speichern/Ansehen der mtd's mit dem ruKerelTool auf meiner 7490 nicht und einen Punkt für mtd5 in dem Tool gibt es erst gar nicht.)
Oder könnte es den mtd5 geben, weil die Box eine "o2 edition" ist und o2 daher dort irgendwelche Infos speichert ?
[es gibt provider_additive auf meiner Box, die ich mithilfe anderer Postings gesichert habe (aber nicht von der Box gelöscht), die "provider = o2" Variable hab ich gelöscht ]
6) Um das ganze etwas besser verstehen zu können
- gibt es irgendwo eine wirklich einfache Einführung in Linux bzw. die wichtigsten Befehle für absolute DAUs
- gibt es eine Übersicht über das Dateisystem der FB - am besten als Baumstruktur/Grafik, damit man sich das überhaupt mal vorstellen kann
- wo und wie kann ich am besten anfangen, um mit dem FB-System vertraut zu werden; ich habe noch eine alte FB 7270 zum rumspielen (oder sollte ich besser die inakive Partition der FB 7490 nutzen um dort Sachen auszuprobieren)
Vielleicht könnt ihr mir ja einige Quellen (Links, eBooks oder Bücher etc) nennen, damit ich mich da einigermaßen zügig einarbeiten kann - sollte aber bitte für absolute (Linux-)Anfänger geeignet sein, da ich bisher nur Windows benutzt habe.
Vielen Dank schonmal fürs Lesen bis dahin.
Gruß
Ralf
Hallo,
erstmal herzlichen Dank an Pokemon20021 und PeterPawn für die Antworten.
Leider hab ich bisher keinerlei Erfahrung mit Linux außer dem bisschen was ich mir hier durch das Lesen der Beiträge so halbwegs zusammenreimen kann.
Daher entschuldigt bitte, wenn ich immer mal wieder nachfragen muss.
(Noch ein kleiner Hinweis: ihr braucht euch nicht unbedingt die Arbeit machen und für die Antworten meine Fragen zitieren. Da ich immer Zahlen/Nummern vor meine Fragen schreibe, genügt es, wenn diese für die Antwort angegeben werden - ich such mir dann schon Fragen und Antworten zusammen)
So, nun zu meinen neuen Fragen.
1) Wenn ich es recht verstanden habe, werden die modfs-Funktionen ja dadurch installiert/integriert, dass mittel modfs per "./modfs update" die neueste Firmware-Datei vom AVM-Server geholt wird, dann entpackt wird, dann die mit "JA" beantworteten Modulteile von modfs in das FW-Image integriert werden und dieses neue Image dann auf die Box in die inaktive Partition geflasht wird.
Wenn ich nun in modfs einige Fragen zur Installation von bestimmten modfs-Modulen mit JA beantwortet habe und später einige davon nicht mehr haben (also entfernen) möchte, muss ich dann das Ganze von vorne starten mit "./modfs update" UND geht das überhaupt, wenn die FW-Version auf dem AVM-Server (die modfs runterlädt) dieselbe ist, die ich schon auf der Box habe ?
2) in der "modfs Gebrauchsanleitung" ist unter Punkt 3 beschrieben
- Erzeugen einer Installations-Datei für eine andere FB:
Es wird keine vollständige FW erzeugt, sondern ein SquashFS! (siehe auch 7.)
Code:
./modfs update source_image target_file_nameAuf z.B. der 7490:
Code:
./modfs update /var/media/ftp/FRITZ.Box_7412.137.06.50.image /var/media/ftp/FRITZ.Box_7412.137.06.50.squashfsAuf der 7412:
- in beiden Partionen muß eine FW installiert sein!!!
- der Kernel der inaktiven Partition muß zur .squashfs passen, sonst neuen Kernel mit normalem update installieren, und auf alte Partition zurückschalten (oder mit "modfs install", siehe 11.).
Code:
cd /var/tmp;wget -q [URL]http://yourfritz.de/7490/install_inactive_rootfs[/URL]
sh ./install_inactive_rootfs /var/tmp/FRITZ.Box_7412.137.06.50.squashfs
cd /var/tmp;wget -q [URL]http://yourfritz.de/7490/switch_system;sh[/URL] ./switch_systemund unter Punkt 11 wiederum
Installation von Kernel, Wrapper-Partition und Root-Image:
Code:
./modfs install source_image"./modfs install /var/media/ftp/FRITZ.Box_7412.137.06.50.image" entspricht das dann dem o.g. "install_inactive_rootfs" ?
2c) FRAGE: Kann ich mir mit dieser Vorgehensweise auch Images für dieselbe FB erstellen (also auf meiner FB7490 Images für meine FB 7490 - aber mit jeweils unterschiedlichen modfs-Modulen
2d) FRAGE: Kann ich diese Images aus der inaktiven Partition heraus per WebUI installieren, so dass mein modfs-System in der aktiven Partition überschrieben wird oder muss ich das mit modfs installieren (per "./modfs update source_image") oder geht das so eh nicht ?
Hintergrund zu 2c/d) Könnte man sich damit mehrere "fertige" Images mit modfs - aber unterschiedlichen Modulen von modfs - anfertigen und dann bei Bedarf einfach die passende auf die eigene FB draufspielen (z.B. ein Image mit modfs und telnet, ein Image ohne Telnet aber mit Nachtschaltungsanzeige etc.)
3) Leider versteh ich von dem was der Spezialist PeterPawn schreibt nur einen kleinen Bruchteil. Im Post #1014 steht folgendes:
FRAGE: Gibt es da irgendwo Infos dazu, was ein "custom image" für die "E99-custom" ist, wie man so etwas erstellt (bzw. dieses Script in so ein "custom image" schreibt und wie man das ganze dann in die FB mit modfs integriert ?
4) Fragen zu der Umschaltung der aktiven/inaktiven Partitionen
Ich habe jetzt folgendes auf meiner Box:
Partition 0 (linux_fs_start 0) - FritzOS 6.60 mit modfs - alle Fragen mit JA beantwortet / alle Module installiert
Partition 1 (linux_fs_start 1) - FritzOS 6.30 (Auslieferzustand FB 7490 o2 edition) und installiertem modfs_starter aka SIAB
In der Partition 0 mit modfs habe ich ja die Möglichkeit (bei entsprechend installiertem modfs-Modul) in der WebUI (über System->Sicherung->Neustart) die FB in/mit der anderen Partition neu zu starten. In der Partition 1 gibt es diese Möglichkeit so ja nicht (außer ich würde dort auch modfs installieren).
4a) In diesem Thread in Post #88 werden diverse "switch_system" Images/Scripts beschrieben. Kann ich diese Pseudo-Images ganz einfach über die WebUI der FB einspielen über die Update-Funktion - und geht das in allen Partitionen (d.h. egal ob mit oder ohne integriertes modfs); oder wird durch diese Pseudo-Images das System in der aktiven oder inaktiven Partition beim Update überschrieben ? [was genau passiert beim Nutzen eines solchen Pseudo-Images eigentlich genau ?]
4b) Wie Pokemon20021 in seiner Antwort an mich erwähnte:
ist es im Moment so, dass die FB-Einstellungen für beide Systeme (v6.30 und v6.60) gelten.
Nun wäre es natürlich genial, wenn man in BEIDEN Partitionen die Möglichkeit hätte, jeweils eine andere/eigene Konfiguration zu verwenden.
In diesem Thread wird ein Bootmanager für 7490 von PeterPawn beschrieben. Wie kann ich diesen Bootmanager bzw. die "bootmanager_7490.tgz" (oder das Script) installieren/integrieren ? Da dieser Bootmanager ja scheinbar 2 verschiedene Konfigurationen (FB-Einstellungen) verwalten kann, würde mich interessieren,
- ob ich diesen Bootloader wie von mir gedacht nutzen kann ?
- wo man diesen Bootloader installieren muss, damit er für beide Partitionen funktioniert (also dass man von jeder Partition in die andere umschalten und dann die jeweils
für diese Partition vorgenommenen FB-Einstellungen nutzen/laden kann) ?
- wie man diesen Bootloader installiert (in dem System/der Partition ohne modfs und/oder in dem System mit modfs) - was für Befehle muss ich da (per Telnet oder per modfs oder sonstwie) eingeben ?
5) Wenn ich per ruKernelTool im Adam2/EVA-Modus die Environment-Variablen auslese, dann wird mir u.a. folgendes ausgegeben:
Code:
Flash-/Speichergrößen:
Memsize: 268.435.456 Bytes (262.144 kB,256 MB, 0,3 GB)
mtd0: 50.331.648 Bytes (49.152 kB, 48 MB)
mtd1: 4.194.304 Bytes (4.096 kB, 4 MB)
mtd2: 262.144 Bytes (256 kB, 0,3 MB)
mtd3: 393.216 Bytes (384 kB, 0,4 MB)
mtd4: 393.216 Bytes (384 kB, 0,4 MB)
mtd5: 2.097.152 Bytes (2.048 kB, 2 MB)Hansenet/Alice-Boxen erwähnt, die mtd5 nutzen, aber aber bei der FB mit NAND-Flash sind es doch eigentlich 4, oder ? - kann mir dazu jemand näheres sagen ?
(Leider funktioniert das Auslesen/Speichern/Ansehen der mtd's mit dem ruKerelTool auf meiner 7490 nicht und einen Punkt für mtd5 in dem Tool gibt es erst gar nicht.)
Oder könnte es den mtd5 geben, weil die Box eine "o2 edition" ist und o2 daher dort irgendwelche Infos speichert ?
[es gibt provider_additive auf meiner Box, die ich mithilfe anderer Postings gesichert habe (aber nicht von der Box gelöscht), die "provider = o2" Variable hab ich gelöscht ]
6) Um das ganze etwas besser verstehen zu können
- gibt es irgendwo eine wirklich einfache Einführung in Linux bzw. die wichtigsten Befehle für absolute DAUs
- gibt es eine Übersicht über das Dateisystem der FB - am besten als Baumstruktur/Grafik, damit man sich das überhaupt mal vorstellen kann
- wo und wie kann ich am besten anfangen, um mit dem FB-System vertraut zu werden; ich habe noch eine alte FB 7270 zum rumspielen (oder sollte ich besser die inakive Partition der FB 7490 nutzen um dort Sachen auszuprobieren)
Vielleicht könnt ihr mir ja einige Quellen (Links, eBooks oder Bücher etc) nennen, damit ich mich da einigermaßen zügig einarbeiten kann - sollte aber bitte für absolute (Linux-)Anfänger geeignet sein, da ich bisher nur Windows benutzt habe.
Vielen Dank schonmal fürs Lesen bis dahin.
Gruß
Ralf
Fehlermeldung: "Überprüfen der Signatur der geladenen Datei" failed, 7490-06.69-42725
bei Anwendung von modfs von FB7490-06.69-42725 ist Fehler aufgetreten;
bei Anwendung von modfs von FB7490-06.69-42725 ist Fehler aufgetreten;
Code:
# ./modfs update ./FRITZ.Box_7490_Labor.113.06.69-42725.image
respawn script with custom BusyBox shell, SHLVL=4
/var/media/ftp/USB-Stick-01/modfs-0.4.1-191120160505/bin/185/busybox sh ./modfs update ./FRITZ.Box_7490_Labor.113.06.69-42725.image
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK
Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.
Im Moment läuft auf der Box die Version: 113.06.69-42372
Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.
Die angegebene Datei '/var/media/ftp/USB-Stick-01/modfs-0.4.1-191120160505/FRITZ.Box_7490_Labor.113.06.69-42725.image' wird als Quelle für die Aktualisierung genutzt.
[COLOR=#ff0000]Überprüfen der Signatur der geladenen Datei ... Fehler[/COLOR]
#
Zuletzt bearbeitet:
Master SaMMy
Aktives Mitglied
- Mitglied seit
- 20 Apr 2016
- Beiträge
- 1,089
- Punkte für Reaktionen
- 217
- Punkte
- 63
Starte es so
NOVERIFY=1 ./modfs update ./FRITZ.Box_7490_Labor.113.06.69-42725.image
so umgehst du den Signatur check
NOVERIFY=1 ./modfs update ./FRITZ.Box_7490_Labor.113.06.69-42725.image
so umgehst du den Signatur check
check_integrity liefert Error 132
- - - Aktualisiert - - -
Danke für Hinweis!
habe ich schon gemacht und Image geflashed,
mir geht es eher noch um die Ursachenfindung.
- - - Aktualisiert - - -
check_signed_image liefert:
Image-Vergleich liefert:
da hat wohl jemand vergessen die Dateien Signatur, Checksum, info.txt reinzupacken;
bei Timestamp "19:36:29" könnte Ursache "Bier erst nach vier" gewesen sein ;-)
- - - Aktualisiert - - -
kennt jemand Impacts, z.B. Filebasiertes Updates, Online-Updates ?
Code:
# /bin/showshringbuf modfs
SNIP
2017-01-14 06:41:22.077 - try_to_check_integrity: target=/var/media/ftp/USB-Stick-01/modfs-0.4.1-191120160505/FRITZ.Box_7490_Labor.113.06.69-42725.image
2017-01-14 06:41:22.124 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
2017-01-14 06:41:22.380 - progress: mode=3, msg= Fehler
[COLOR=#ff0000]2017-01-14 06:41:22.399 - try_to_check_integrity: integrity check failed, error code was 132
2017-01-14 06:41:22.416 - try_to_check_integrity: exiting, rc=205
[/COLOR]2017-01-14 06:41:22.434 - cleanup: running cleanup from file /var/tmp/10822_filelist_1484372479
2017-01-14 06:41:22.453 - /var/media/ftp/USB-Stick-01/modfs-0.4.1-191120160505/bin/185/busybox rm -r /var/tmp/1484372482
#- - - Aktualisiert - - -
Danke für Hinweis!
habe ich schon gemacht und Image geflashed,
mir geht es eher noch um die Ursachenfindung.
- - - Aktualisiert - - -
check_signed_image liefert:
Code:
# PATH=./bin/VR9:$PATH sh ./bin/scripts/check_signed_image ./FRITZ.Box_7490_Labor.113.06.69-42725.image
Found OpenSSL 1.0.2j 26 Sep 2016
Check dgst command ... OK
Check rsautl command ... OK
[COLOR=#ff0000]The specified image file ./FRITZ.Box_7490_Labor.113.06.69-42725.image contains no signature file.[/COLOR]
#Image-Vergleich liefert:
Code:
# tar tvpf FRITZ.Box_7490_Labor.113.06.69-42725.image
drwxr-xr-x 0/0 0 2017-01-13 19:36:29 ./var/
-rwxr-xr-x 0/0 34518 2017-01-13 19:36:29 ./var/install
-r-xr-x--- 0/0 283844 2016-09-28 21:29:46 ./var/regelex
drwxr-xr-x 0/0 0 2017-01-13 19:36:29 ./var/tmp/
-rw-r--r-- 0/0 2505992 2017-01-13 19:36:29 ./var/tmp/kernel.image
-rw-r--r-- 0/0 23937032 2017-01-13 19:36:29 ./var/tmp/filesystem.image
#
# tar tvpf FRITZ.Box_7490.113.06.69-42113.image
drwxr-xr-x 0/0 0 2016-11-18 13:59:59 ./var/
-rwxr-xr-x 0/0 34510 2016-11-18 13:59:59 ./var/install
-r-xr-x--- 0/0 283844 2016-09-28 21:29:46 ./var/regelex
drwxr-xr-x 0/0 0 2016-11-18 13:59:59 ./var/tmp/
-rw-r--r-- 0/0 2505992 2016-11-18 13:59:59 ./var/tmp/kernel.image
-rw-r--r-- 0/0 24137736 2016-11-18 13:59:59 ./var/tmp/filesystem.image
[COLOR=#0000ff]-rwxr-xr-x 0/0 2795 2016-11-18 13:59:59 ./var/info.txt[/COLOR]
[COLOR=#0000ff]-r-xr-x--- 0/0 278552 2016-09-28 21:29:46 ./var/chksum
-rw-r--r-- 0/0 128 2016-11-18 13:59:59 ./var/signature[/COLOR]
#
Code:
# md5sum FRITZ.Box_7490_Labor.113.06.69-42725.image
ae36e1a193f245988741ac814b28cdb9 FRITZ.Box_7490_Labor.113.06.69-42725.image
#da hat wohl jemand vergessen die Dateien Signatur, Checksum, info.txt reinzupacken;
bei Timestamp "19:36:29" könnte Ursache "Bier erst nach vier" gewesen sein ;-)
- - - Aktualisiert - - -
kennt jemand Impacts, z.B. Filebasiertes Updates, Online-Updates ?
Zuletzt bearbeitet:
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,280
- Punkte für Reaktionen
- 456
- Punkte
- 83
Eine korrigierte Version wurde nachgelegt. md5
Zumindest gegen Mitternacht. Etwas unschlüssig bin ich ob dieser Randbemerkung Ist gerade eine ge-modfs-te Labor aktiv, wird die inaktive Partion überschrieben und neu gestartet? Bei ferngewarteten FBs sicherlich ein Trauma, da keine Chance in ADAM2 aus der Ferne zu kommen.
LG
Code:
d0d2991bce0a30086dc628ca4a861170 *FRITZ.Box_7490_Labor.113.06.69-42725.imageLG
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Wenn AVM das richtig implementiert hat (bei der 7390 ergaben sich da ja ein paar Fragen), dann sollte die Einstellung "nur benachrichtigen" (der erste Punkt auf der "Autoupdate"-Seite) ja eigentlich verhindern, daß ein Image von AVM automatisch installiert wird.
Wer sich (sehenden Auges) für die zweite Option entscheidet, der muß eben damit rechnen, daß ein "notwendiges Update" automatisch installiert wird und er - auch bei ferngewarteten Boxen - erst wieder über ein Sicherheitsproblem "einsteigen" muß, damit er entweder auf die andere Partition zurückschalten oder ggf. gleich per "modfs" eine modifizierte Version der neuen Firmware installieren kann.
Die dritte Option verbietet sich (für "modfs"-Benutzer) sicherlich von selbst ... dafür braucht es die "Batch-Variante" von "modfs" (die kommt sicherlich auch irgendwann mal als Veröffentlichung), die man dann in der /var/post_install erst einmal aufrufen kann (so wie das "run_update" aus dem YourFritz-Repo), bevor so ein AVM-Update die Daten dann in die Flash-Partitionen schreibt. Bisher hält mich das dafür notwendige "Verhalten" der Firmware (das erinnert ja dann schon stark an Viren bzw. Würmer, wenn sich so eine geänderte Firmware im Gerät "festkrallt" und sich bei jedem neuen Update der Firmware erneut einnistet) irgendwie davon ab ... andererseits ist das (für die Mehrzahl der "modfs"-Verwender) ja auch ein nicht unerheblicher Aufwand, wenn man jedes Update manuell über "modfs" ausführen muß.
Ich hoffe ja immer noch auf so etwas wie "Einsicht" bei AVM, daß an die Stelle des einfachen Downgrades über ein älteres Image zumindest die Umschaltung auf die letzte vorhandene Firmware ins GUI gehören würde ... ich warte praktisch nur auf den ersten "Unfall" bei einer ausgelieferten Firmware, wo der derzeit notwendige Weg zu einer vorhergehenden Version über Recovery und Wiederherstellen gesicherter Einstellungen (die ja ohnehin keine vollständige Wiederherstellung ermöglichen, wie bekannt ist - das geht bei Zertifikat und DECT-Kopplungen los) dann bei den Kunden zu einem Sturm der Entrüstung führt.
So eine Umschaltung ist kein Hexenwerk und wenn man da noch eine Abfrage der Versionen und darauf basierend das optionale(!) Löschen der vorhandenen Einstellungen in einem einzigen Schritt einbaut, dann kann der Kunde auch eine Labor-Version wieder einfacher testen ... inzwischen ist die Teilnahme am Labor-Test ja fast eine Zumutung (auch wenn sie selbstverständlich freiwillig erfolgt), vor allem dann, wenn man ohnehin bereits bekannte Probleme mit dem Laborzweig hat und daher (absehbar) nach einem solchen Test wieder auf die letzte Release-Version will - dabei ist das eigentlich in Null komma nichts erledigt, wenn man es im GUI anbieten würde. So ein "Aufbau" für Recovery mit LAN-Kabel und Windows-PC ist hingegen ein erheblicher Aufwand (der auch schon lange nicht mehr immer als "Normalzustand" in einem Haushalt vorhanden ist), den man eigentlich (in der überwiegenden Zahl der Fälle) gar nicht bräuchte und man würde trotzdem dasselbe Ergebnis (Box mit vorhergehender Firmware und mit Werkseinstellungen) erzielen.
Wenn man dann noch dem Kunden die Entscheidung über die Notwendigkeit des Löschens der Einstellungen überläßt (daher die Forderung, das nur optional auszuführen), dann ist so ein Test einer Labor-Version auch schnell (und ohne große Reue) möglich - von den ganzen Problemen mit den Leuten, die nicht wirklich lesen können (Stichwort "provider additive") und für die es gar keinen "offiziellen" Rückweg zur Release-Version gibt, ganz zu schweigen.
Wenn das in den Provider-DOCSIS-Boxen nicht gewünscht ist, kann ich das nachvollziehen ... ansonsten liegt eben die "doppelt vorhandene Firmware" in den neueren Modellen vorwiegend brach und AVM verärgert sich (nach meiner Ansicht) nur unnötig die freiwilligen Beta-Tester, wenn man den Aufwand (eher künstlich) hochhält, der für den Rückweg zur letzten Release-Version zu betreiben ist.
Wer sich (sehenden Auges) für die zweite Option entscheidet, der muß eben damit rechnen, daß ein "notwendiges Update" automatisch installiert wird und er - auch bei ferngewarteten Boxen - erst wieder über ein Sicherheitsproblem "einsteigen" muß, damit er entweder auf die andere Partition zurückschalten oder ggf. gleich per "modfs" eine modifizierte Version der neuen Firmware installieren kann.
Die dritte Option verbietet sich (für "modfs"-Benutzer) sicherlich von selbst ... dafür braucht es die "Batch-Variante" von "modfs" (die kommt sicherlich auch irgendwann mal als Veröffentlichung), die man dann in der /var/post_install erst einmal aufrufen kann (so wie das "run_update" aus dem YourFritz-Repo), bevor so ein AVM-Update die Daten dann in die Flash-Partitionen schreibt. Bisher hält mich das dafür notwendige "Verhalten" der Firmware (das erinnert ja dann schon stark an Viren bzw. Würmer, wenn sich so eine geänderte Firmware im Gerät "festkrallt" und sich bei jedem neuen Update der Firmware erneut einnistet) irgendwie davon ab ... andererseits ist das (für die Mehrzahl der "modfs"-Verwender) ja auch ein nicht unerheblicher Aufwand, wenn man jedes Update manuell über "modfs" ausführen muß.
Ich hoffe ja immer noch auf so etwas wie "Einsicht" bei AVM, daß an die Stelle des einfachen Downgrades über ein älteres Image zumindest die Umschaltung auf die letzte vorhandene Firmware ins GUI gehören würde ... ich warte praktisch nur auf den ersten "Unfall" bei einer ausgelieferten Firmware, wo der derzeit notwendige Weg zu einer vorhergehenden Version über Recovery und Wiederherstellen gesicherter Einstellungen (die ja ohnehin keine vollständige Wiederherstellung ermöglichen, wie bekannt ist - das geht bei Zertifikat und DECT-Kopplungen los) dann bei den Kunden zu einem Sturm der Entrüstung führt.
So eine Umschaltung ist kein Hexenwerk und wenn man da noch eine Abfrage der Versionen und darauf basierend das optionale(!) Löschen der vorhandenen Einstellungen in einem einzigen Schritt einbaut, dann kann der Kunde auch eine Labor-Version wieder einfacher testen ... inzwischen ist die Teilnahme am Labor-Test ja fast eine Zumutung (auch wenn sie selbstverständlich freiwillig erfolgt), vor allem dann, wenn man ohnehin bereits bekannte Probleme mit dem Laborzweig hat und daher (absehbar) nach einem solchen Test wieder auf die letzte Release-Version will - dabei ist das eigentlich in Null komma nichts erledigt, wenn man es im GUI anbieten würde. So ein "Aufbau" für Recovery mit LAN-Kabel und Windows-PC ist hingegen ein erheblicher Aufwand (der auch schon lange nicht mehr immer als "Normalzustand" in einem Haushalt vorhanden ist), den man eigentlich (in der überwiegenden Zahl der Fälle) gar nicht bräuchte und man würde trotzdem dasselbe Ergebnis (Box mit vorhergehender Firmware und mit Werkseinstellungen) erzielen.
Wenn man dann noch dem Kunden die Entscheidung über die Notwendigkeit des Löschens der Einstellungen überläßt (daher die Forderung, das nur optional auszuführen), dann ist so ein Test einer Labor-Version auch schnell (und ohne große Reue) möglich - von den ganzen Problemen mit den Leuten, die nicht wirklich lesen können (Stichwort "provider additive") und für die es gar keinen "offiziellen" Rückweg zur Release-Version gibt, ganz zu schweigen.
Wenn das in den Provider-DOCSIS-Boxen nicht gewünscht ist, kann ich das nachvollziehen ... ansonsten liegt eben die "doppelt vorhandene Firmware" in den neueren Modellen vorwiegend brach und AVM verärgert sich (nach meiner Ansicht) nur unnötig die freiwilligen Beta-Tester, wenn man den Aufwand (eher künstlich) hochhält, der für den Rückweg zur letzten Release-Version zu betreiben ist.
==> Ja
jedoch kann man die Auswahl der Modskripte von Dialog-Betrieb (Ja-/Nein-Sager) auf Quasi-Batchbetrieb umstellen, hierfür gibt es die Datei "custom_modscripts":
z.B.
Code:
# cat custom_modscripts
-copy_binaries
-dectcmds.modscript
+edit_rcuser
-gui_boot_manager_v0.2
+gui_boot_manager_v0.3
-mod_custom_images
+mod_default_show_mac
+mod_enable_telnet
+mod_leddisplay
+mod_mount_by_label
+mod_night
+mod_prefer_fonnumber_name
+mod_profile
+mod_rc_tail_sh
+mod_show_name
+mod_show_vpn_on_overview
+mod_swapoff
-template
-yourfritz_hooks
#Das Entfernen von angewendeten Modfs-Modscripten erfolgt üblicherweise durch Neuflashen "./modfs update" oder "./modfs update imagedatei".
Alternativ könntest Du dir IMHO auch ein "Re-Modding" durchführen;
Ablauf:
die SquashFS-Datei für das rootfs aus dem /wrapper-Filesystem holen
Code:
# ls -la /wrapper/
drwxr-xr-x 1 root root 2048 Jan 14 07:02 .
drwxr-xr-x 16 root root 289 Jan 13 19:36 ..
drwx------ 1 root root 2048 Jan 14 07:02 bin
drwx------ 1 root root 2048 Jan 13 19:36 core
drwxr-xr-x 10 root root 14100 Jan 14 09:28 dev
drwx------ 1 root root 2048 Jan 14 07:02 etc
[COLOR=#0000ff]-rw-r--r-- 1 root root 20631552 Jan 14 07:02 filesystem_core.squashfs
[/COLOR]drwx------ 1 root root 2048 Jan 14 07:02 lib
drwx------ 1 root root 2048 Jan 1 1970 lost+found
drwx------ 1 root root 2048 Jan 13 19:36 proc
drwx------ 1 root root 2048 Jan 14 07:02 sbin
drwx------ 1 root root 2048 Jan 14 07:02 tmp
drwx------ 1 root root 2048 Jan 13 19:36 var
#diese neuen Modscripte mit
Code:
# sh -x ./modscripts/<Skript-Name> de $ROOT_DIR_OF_UNSQUASHED4_IMAGE onrequest undoJa, Du kannst auch zwei identische FW-Images auf die Box per Modfs flashen.
Zu Zeiten von modfs_7490 gab es das Skript "copy_7490_systems" http://www.ip-phone-forum.de/showthread.php?t=272725&p=2032528&viewfull=1#post2032528 welches bei FB7490 mit squashfs3, d.h. mit FW 06.2x sehr gute Dienste leistete.
Ja.
siehe:
Nein, siehe 2.a.) wie auch ?
Bitte zuerst Unterschiede zwischen einer Image-Datei (Tar-File) und SquashFS-Datei (z.B. filesystem_core.squashfs) erarbeiten,
auch hilft u.U. ein Blick in Datei http://yourfritz.de/7490/install_inactive_rootfs
der Moderator von Radio Jerewan/Eriwan würde antworten: Im Prinzip ja, aber ...
oder mein Motto ist: wer Will, der kann.
Ehrlich gesagt ist mir der Sinn nicht ganz klar; wozu Images customized auf Verdacht vorhalten ?
da ist es doch einfacher das Org-Image und modfs vorhalten und dann kann man On-the-Fly das gewünschte System customizen und flashen.
Wie willst Du ein "wrong signed" Image per Web-IF flashen ?
da mußt Du schon vorher Vorkehrungen (Stichwort: public key /etc/avm_firmware_public_key9) treffen.
das ist eigentlich in http://www.ip-phone-forum.de/showthread.php?t=273304&p=2156232&viewfull=1#post2156232 sehr schön beschrieben;
auch sind die Source-Files hervorragend dokumentiert:
https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_custom_images
https://github.com/PeterPawn/modfs/blob/master/files/E99-custom
Kurzform:
die Datei /etc/init.d/E99-custom wird per modscripts/mod_custom_images installiert und kann zum Starten von Diensten wie:
- ShellInABox
- TFTP-Server
- dropbear
- SoftVPN
genutzt werden.
Zuletzt bearbeitet:
Neueste Beiträge
-
Selbständige Portfreigabe lässt sich nicht deaktivieren
- Letzte: bahtiyar57
-
Prime Сasual Dating - Real Women
- Letzte: dtuda
-
Deutsche Glasfaser - Telefonnr. nicht registrierbar
- Letzte: HerzogIgzorn
-
[Problem] GELÖST - Weiterleitung funktioniert nur bei einer anderen Handynummer?- Letzte: Rangierdraht
-
[Problem] Freevoipdeal und Anruf bei Drillisch-Sim- Letzte: Jstessi
-
Festlegen bei welchen Repeater sich ein Gerät anmelden darf
- Letzte: zorro0369