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

[Chatty]

contrib/modscripts/mod_multiple_fax_pages - nicht von mir, sondern als Pull-Request über's Repo hinzugekommen: https://github.com/PeterPawn/modfs/pull/30 - auch nicht von mir getestet, hält leider erst jetzt mit der nächsten Version auch Einzug in das von mir bereitgestellte "modfs.tgz" (bzw. die Beta-Datei oben) und stand bisher nur denjenigen zur Verfügung, die mit dem geklonten Repo arbeiten

Gerade heute erst wieder auf einer 6591 mit 07.19 verwendet... mir seit jeher unbegreiflich, warum AVM das nicht in das GUI einbaut.

 

[PeterPawn]

Nachdem ich heute über GitHub darauf aufmerksam gemacht wurde, daß natürlich auch das bisherige Vorgehen beim "Impfen" einer VR9-Box mit Shell-in-a-Box nicht mehr klappt ab 07.19, habe ich das etwas geändert, so daß es auch mit 07.19 wieder funktionieren sollte (https://github.com/PeterPawn/YourFritz/commit/0bad10810c70b16dff97972f741bb00b30df08a5).

Dabei wird aber (zumindest in der von mir selbst bereitgestellten Version für die 7490 und nur diese braucht(e) eine Änderung) weiterhin eine AVM-Version 07.12 als Basis verwendet, weil es beim Schreiben ins YAFFS2-Dateisystem nicht auf die Kernel- oder FRITZ!OS-Version ankommt. Die Entscheidung, ob es sich um ein "altes" System oder eine Labor-Version (bzw. ein künftiges Release) handelt und wie SIAB zu starten wäre, wird erst zur Laufzeit des FRITZ!OS getroffen.

Damit kann man auch mit einer 07.19 bzw. der folgenden Release-Version "starten", wenn man "modfs" verwenden will und bisher noch keinen Shell-Zugang hat(te). Theoretisch sollte es auch funktionieren, ein eigenes Image zum Einpflanzen von SIAB auf der Basis einer 07.19-Version von AVM zu erstellen, solange AVM den "ext2"-Parser im Kernel nicht abgeschafft hat (was nach dem Wechsel auf SquashFS4 für die "filesystem.image" möglich wäre) - das habe ich aber nicht getestet.

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

Sollten sich nicht bis Sonntag hier noch Leute melden, die Fehler in der Umsetzung für die 07.19 gefunden haben, werde ich aus der Beta (0.6.0) eine Release-Version machen - damit ist dann die bisherige Release-Version nicht länger erreichbar zum direkten Download über yourfritz.de ... wer dann eine ältere benutzen will/muß/soll, muß die aus dem GitHub-Repo selbst am richtigen Punkt extrahieren.

 

[Rocky_1965]

[Edit Novize: Riesenfullquote ohne zwingenden Bezug gelöscht - siehe Forumsregeln]

Danke
Ich werde das mit
"/usr/www/avm/home/home.js" die Zeile 595
beim nächten Update mal ausprobieren

wo kann man "data.fritzos.twofactor_disabled" auf false setzten?

 

[PeterPawn]

Version unter yourfritz.de/modfs.tgz auf 0.6.1 aktualisiert (letzter Stand aus Beta 0.6.0) - das hatte ich vergangenes Wochenende dann doch versäumt.

wo kann man "data.fritzos.twofactor_disabled" auf false setzten?

Gesetzt wird es (allerdings erst ab 07.19) in der "retrieve_data.lua" (die findest Du selbst in der Firmware). Soweit ich das gesehen habe, ist die "home.js" auch (bisher zumindest) die einzige Datei, wo das ausgewertet wird, so daß Seiteneffekte (beim derzeitigen Stand wohlgemerkt) auch nicht zu erwarten sind.

 

[FischersFreetz]

Hallo..., ich probierte "modfs" auf einer 7362 sl und bekam eine Fehlermeldung, dass nicht genug Arbeitsspeicher vorhanden bzw. frei ist. Es waren ca. 45 MB frei.
Wie viel RAM muss denn verfügbar sein?

 

[Micha0815]

Aus #1 gelesen und verstanden?

Auf einer 7490 läuft es auch ohne USB-Speicher, auf einer 7362SL oder 3370 wird zusätzlich ein USB-Speicher mit ca. 256MB freiem Speicherplatz benötigt (da ist ein "Sicherheitsaufschlag" schon eingerechnet). Der USB-Speicher muß angesteckt sein, da fehlt noch ein entsprechender Test im Skript, baue ich mit der nächsten Erweiterung für ein anderes Modell dann ein.

LG

 

[PeterPawn]

bekam eine Fehlermeldung, dass nicht genug Arbeitsspeicher vorhanden bzw. frei ist.

Wie sah die Meldung denn konkret aus? Ich kann mich gerade nicht erinnern, daß irgendeine Meldung etwas von "Arbeitsspeicher" anmerken würde: https://github.com/PeterPawn/modfs/blob/master/locale/de

Ansonsten gibt es ja genau dafür das Protokoll (showshringbuf modfs - Ausgabe umleiten in Datei und hier irgendwie anhängen) ... da muß man nicht raten und kann direkt sehen, welche "Speicheranforderung" nicht funktionierte.

Die Frage nach dem RAM-Bedarf ist nämlich gar nicht so einfach zu beantworten ... erstens ist die Belegung durch das "tmpfs" dynamisch und zweitens funktioniert "modfs" (nach Berichten Dritter, ich habe keine 7362SL) auch für dieses Modell. Deshalb wird ja auch der vorhandene Hauptspeicher durch eine Swap-Datei und/oder eine Swap-Partition erweitert - ohne spezielle Parameter wird auch auf dessen Existenz geprüft. Vielleicht meintest Du ja diese Fehlermeldung? Wie man seinen USB-Stick präparieren sollte, steht hier im Thread - einfach mal nach "mkfs" o.ä. suchen lassen.

 

[FischersFreetz]

... auf einer 7362SL oder 3370 wird zusätzlich ein USB-Speicher mit ca. 256MB freiem Speicherplatz benötigt...

Das war bei mir gegeben.

Wie sah die Meldung denn konkret aus? Ich kann mich gerade nicht erinnern, daß irgendeine Meldung etwas von "Arbeitsspeicher" anmerken würde

So sah sie aus:

...
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... Fehler

Der freie Speicherplatz im RAM der Box reicht nicht aus.

Sollte dieser Fall unmittelbar nach dem Neustart der Box und ohne die Verwendung zusätzlicher
Software auftreten, müssen sie auf den Einsatz dieses Paketes verzichten.

Das Protokoll habe ich mal angehängt. Und darin sah auch, wie viel Speicher "gewünscht" wird: 64 MB (=halber RAM).

Ist das eine wirkliche/absolute Mindestvoraussetzung (oder stimmt hier etwas anderes nicht)?

 

[PeterPawn]

Ich habe beim letzten Update die Anforderungen an den Speicher tatsächlich nach oben korrigiert: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2366436

Unter Umständen war das für den freien Platz im "tmpfs" (die Nachricht habe ich da etwas unglücklich formuliert - das "tmpfs" ist halt ein Dateisystem, welches den freien Hauptspeicher dynamisch nutzt) nicht wirklich schlau, zumindest bei den "kleinen" Boxen, die nicht per se 256 MB RAM haben. Hier geht halt die Schere auseinander ... auf der einen Seite die alten Boxen mit wenigen Ressourcen und OHNE neue Firmware-Versionen, die deutlich weniger Platz beim Entpacken brauchen und auf der anderen die mit mehr RAM und neuerer (Labor-)Firmware. Ich wage mal die Prognose, daß es für die 7362SL keine 07.20 mehr geben wird (EDIT: Wobei es bei der ja auch nicht zur Vergrößerung des Platzbedarfs wegen der Zusammenlegung von deutscher und internationaler Version kommen wird - also vielleicht gibt's doch noch ein 07.20, falls RAM nicht zum Problem für AVM wird.)

Als schnelle Lösung würde ich Dir hier empfehlen, die Zeile 2422 auf rc=0 zu ändern - dann wird das Ergebnis der Prüfung auf Platz im "tmpfs" ignoriert. Ursprünglich war dieser Test (auf 10 MB) mal drin, um den Leuten zu zeigen, daß sie entweder die Box neu starten sollten (weil die irgendwann auch "vollläuft") oder daß sie besser mit prepare_fwupgrade { start | start_from_internet | start_tr069 } die unnötigen Prozesse rauswerfen sollten, bevor sie mit "modfs" noch einmal beginnen. Damals war allerdings auch der Swap-Space noch nicht "mandatory".

Für eine längerfristige Lösung muß ich mir erst mal etwas anderes überlegen ... der Sprung von 10 MB auf 64 MB war wohl doch nicht in jedem Falle gerechtfertigt bzw. "schlau". Da muß anhand der Version der zu entpackenden Firmware und anhand der tatsächlich vorhandenen Ressourcen irgendwie ein "Grenzwert" berechnet werden bzw. vielleicht gehe ich sogar hin und rufe bei zu wenig Platz im "tmpfs" das "prepare_fwupgrade" prophylaktisch auf, wenn es nicht durch eine Environment-Variable unterdrückt wird - das hieße dann halt, daß man die Box nach "modfs" direkt neu starten müßte, weil die meisten Prozesse abgeschossen wurden.

 

[FischersFreetz]

... Zeile 2422 auf rc=0 zu ändern ...

Dadurch wurde das Script zum Weitermachen überredet und ich konnte einen ersten Eindruck gewinnen. Ich habe nicht alle Optionen getestet, sondern nur zwei - davon eine mit Erfolg. Mir ist dieser "mod" nicht so wichtig, aber ...

Bist du am (weiteren) Verhalten einer 7362 sl bei Anwendung deines "modfs" interssiert?
(Oder lohnen sich die Anstrengungen in dieser Richtung nicht mehr?)

Werden eigentlich "alle" Firmeware-Versionen unterstützt oder erst ab einer bestimmten Version?

 

[PeterPawn]

Das "modfs" an sich ist nur ein Vehikel, was in der Lage ist, die Firmware zu entpacken, eine Reihe von Skript-Files aufzurufen und danach die Firmware wieder so weit zusammenzupacken, daß man dieses neue SquashFS-Image für den nächsten Start als Root-Dateisystem verwenden kann - als Abschluß kann es dann dieses neue Image noch installieren.

Man muß also unterscheiden ... das "Framework" sollte (ausreichend Speicher vorausgesetzt) auf allen Boxen mit einer "Wrapper-Partition" funktionieren.

Der Knackpunkt sind i.d.R. die "modscripts" - diese nehmen dann die eigentlichen Änderungen an der entpackten Firmware vor und die sind natürlich versionsabhängig, weil AVM ja auch immer mal etwas ändert. Ich habe mich aber bemüht, die Versionen so ab 06.5x immer noch in den "modscripts" zu unterstützen ... vorher gab es "modfs" zwar auch schon, aber das GUI war ja deutlich anders und da viele der Patches sich auf Details des GUI beziehen, gibt es nur wenige dieser Skript-Dateien, die bei < 06.5x überhaupt gebraucht würden.

Wenn irgendein Patch gar keinen Sinn mehr ergibt (entweder weil AVM das dann selbst (wieder) eingebaut hat, wie z.B. bei der "led_display.lua" oder weil erst eine bestimmte Version benötigt wird für eine Änderung), sollte das vom jeweiligen Skript auch korrekt erkannt werden.

Wenn Du also mit den Tests einer 7362SL die "generelle Funktion" von "modfs" meinst ... die sollte (mal von der Änderung beim Speicherbedarf und zu den Gründen dafür habe ich oben ja schon passend verlinkt) gegeben sein.

Geht es um bestimmte Patches, sollten die bei einer 7362SL genauso funktionieren, wie bei den anderen Modellen mit derselben FRITZ!OS-Version und da die 7362SL m.W. eine 07.12 erhalten hat, sollte sie sich da nicht von den anderen Modellen mit dieser Version unterscheiden.

Ein "lohnt eh nicht mehr" sehe ich da also nicht ... aber auch keine Notwendigkeit für eine "Sonderbehandlung" der 7362SL - zumindest nicht im Vergleich zu anderen Modellen mit VR9, NAND-Flash (also mit "wrapper") und beschränkten Ressourcen. Weniger als 128 MB RAM hat m.W. keine dieser Boxen und selbst die 7412 (wo die Ausführung von "modfs" auf der Box üblicherweise auch am fehlenden USB-Port scheitert) kommt mit "modfs" klar (vor der letzten Erhöhung der Speicheranforderungen), wenn man irgendwie den Swap-Space per Netzwerk verwenden kann (der "nbd-client" ist auch bei AVM in der BusyBox enthalten).

Wenn Du also "echte Fehler" bei der 7362SL finden solltest, müßten die bei den anderen Modellen ebenso auftreten ... aber dann kannst Du sie selbstverständlich auch "melden". Wenn also die zweite Modifikation, die nach #1750 ja dann wohl nicht funktionierte, bei der 07.12 machbar sein sollte, dann wäre es "ein Problem", wenn das bei Dir nicht klappt(e).

 

[FischersFreetz]

Dann wäre es (für mich) noch interessant, ob bzw. wie "FREETZ" den "mod" beeinflusst.

Aber hier mal ein Bericht von meinen Eindrücken:
Das "modscript", das den Hinweis auf Veränderungen an der Firmeware beseitigt, konnte ich in einem ersten Versuch erfoglgreich anwenden (siehe Post #1750). Nun zu meinem zweiten Versuch...

Zur Ausgangssituation
[ 7362 sl ] [ FirmewareVersion 131.06.83 rev43615 ] [ FREETZ devel-15014 ]
[ modscripts +gui_boot_manager_v0.6 und +mod_leddisplay ]

Output mit Auffälligkieten (Protokoll im Anhang)

...
...
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/uStor01/1589806912/squashfs-root

sed: unmatched '|'

Die Modifikation 'enable system and branding selection from GUI (v0.6)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ...grep: /var/media/ftp/uStor01/1589806912/squashfs-root/usr/www//system/reboot.lua: No such file or directory
 OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ...grep: /var/media/ftp/uStor01/1589806912/squashfs-root/usr/www//system/reboot.lua: No such file or directory
 Fehler (2)

Die Modifikation 'enable system and branding selection from GUI (v0.6)' wurde angewendet, Fehlercode = 2.

Die Modifikation 'add led display tab' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add led display tab' wurde angewendet, Fehlercode = 0.

Ergebnis:
Nach einem Reboot konnte ich im AVM-Webinterface keinerlei Veränderungen erkennen. Bei "gui_boot_manager_v0.6" war das ja - wegen des Fehlers - zu erwarten. Aber warum die erfolgreiche(?) Modifikation von "mod_leddisplay" keine Wirkung zeigt, ist mir nicht klar.

 

[PeterPawn]

In den Pfadangaben für die zu modifizierenden bzw. zu prüfenden Dateien fehlt jeweils das Verzeichnis mit dem "Branding".

Da Freetz an dieser Stelle die Verzeichnisstruktur manipuliert: https://github.com/Freetz/freetz/blob/master/fwmod#L696 kann das durchaus sein, daß irgendein "modscript" da ins Leere greift. Wobei mich die Frage quält, ob Du Dir hinsichtlich Freetz vs. Freetz-NG sicher bist, denn das sieht man dem Protokoll nicht an - ich bin ohnehin froh, daß die "in-place updates" überhaupt noch halbwegs zu funktionieren scheinen, weil die wohl fast niemand mehr nutzt, sondern überwiegend mit "update" gearbeitet wird von den verbliebenen "modfs"-Benutzern.

Welche Zeile jetzt konkret zu dem Fehler mit dem "sed" führt, weiß ich im Moment genauso wenig, wie die Antwort auf die Frage, warum Freetz das überhaupt (noch) macht. Es macht bei einem SquashFS-Image nur noch sehr begrenzten Sinn (weil identische Dateien ohnehin nur einmal gespeichert werden im Image, das Einzige, was da noch "aufträgt", sind die zusätzlichen Daten für die Verwaltung der File-Infos und auch das macht (fast) keinen Unterschied), das eigene Verzeichnis "all" zu nennen und für die Brandings nur noch Symlinks darauf anzulegen. Spätestens bei 07.19 mit dem Zusammenwerfen von deutscher und internationaler Version wird das vollkommen witzlos, weil die sich unterscheiden müssen zwischen "avm" und "avme".

Wobei ich bei der Verwendung von Freetz ohnehin nicht verstehe, warum man da nachträglich mit "modfs" noch mal "drüberwischen" sollte oder wollte ... erst recht nicht mit den beiden hier getesteten Modifikationen. Der Boot-Manager steht auch als Option in der Freetz-Konfiguration zur Verfügung (https://github.com/Freetz/freetz/blob/master/config/ui/patches.in#L1451) und für die LED-Seite gibt es auch irgendwo in Freetz einen eigenen Patch - beide zusammen (also "modscript" + Freetz-Patch) ergäben auch keinen Sinn. Ansonsten könnte man sogar die Patches aus den "modscripts" auch unter Freetz anwenden lassen (https://github.com/PeterPawn/modfs/blob/master/run_modscripts) - da funktioniert auch die Ermittlung der "Brandings": https://github.com/PeterPawn/modfs/blob/master/bin/scripts/extract_version_values#L136

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

Denn nachdem ich das nun doch einmal mit einem Freetz-Image geprüft habe, mußte ich feststellen, daß hier tatsächlich Freetz die Ursache des Problems ist. In einem "normalen" Dateisystem gibt es unterhalb von "/etc" nur Verzeichnisse, die auf die Maske "default.*" passen, für die einzelnen Länder (default.<lkz>) und eines für die Basiseinstellungen der FRITZ!Box, das auf den Namen "default.$CONFIG_PRODUKT" hört und für jedes von der Firmware unterstützte Branding ein Unterverzeichnis mit diesem Namen enthält:

vidar:/home/FritzBox/FB7490/firmware $ find 113.06.83/etc/default.* -maxdepth 1 -type d -ls
  8392215      4 drwxr-xr-x   2 root     root         4096 Mar  6  2017 113.06.83/etc/default.049
  8392216      4 drwxr-xr-x   4 root     root         4096 Mar  6  2017 113.06.83/etc/default.Fritz_Box_HW185
  8392235      4 drwxr-xr-x   3 root     root         4096 Mar  6  2017 113.06.83/etc/default.Fritz_Box_HW185/avm
  8392234      4 drwxr-xr-x   3 root     root         4096 Mar  6  2017 113.06.83/etc/default.Fritz_Box_HW185/1und1
vidar:/home/FritzBox/FB7490/firmware $

Exakt anhand der Unterverzeichnisse in diesem "default.$CONFIG_PRODUKT"-Verzeichnis iteriert auch AVM über die verfügbaren Brandings. Daher filtere ich aus der Liste der "default.*"-Verzeichnisse alle die aus, die nach dem Punkt nur noch Ziffern enthalten und das eine, was dann übrig bleibt (in der AVM-Firmware), ist das Verzeichnis, in dem ich nach den Brandings suchen kann: https://github.com/PeterPawn/modfs/blob/master/modfs#L885

Da Freetz hier aber leider zusätzliche Verzeichnisse "default.<service>" anlegt, schlägt exakt dieses Ermitteln des Brandings fehl (die Fehlermeldung des "sed" kommt daher) und "modfs" funktioniert damit für ein Freetz-Image nicht, solange das seine Standardwerte für irgendwelche Dienste in "etc/default.something"-Verzeichnissen ablegt.

Ich könnte mir jetzt überlegen, wo ich den richtigen Wert für "CONFIG_PRODUKT" finden kann (das oben gezeigte "extract_version_values" macht das ja auch wieder richtig, nur wird das in "modfs" nicht benutzt, weil ich es erst später geschrieben habe, als AVM die Versionsangaben an eine andere Stelle verschoben hat) ... aus dem laufenden System kann ich ihn nicht nehmen, weil dann "modfs" die Fähigkeit verliert, auch Images für andere Boxen (Modelle) als die, auf der es aktuell läuft, zu erstellen.

Andererseits muß sich gerade auch an Freetz für die nächste AVM-Version soo viel ändern (wenn es überhaupt eine Unterstützung für 07.20+ geben wird), daß man erst mal abwarten kann/muß/sollte, was genau Freetz da ändert, bevor man selbst irgendwie tätig wird.

Ursprünglich war "modfs" ja eigentlich als ein "leichterer Weg" im Vergleich zu Freetz gedacht, wo dem Benutzer das eigene Linux erspart werden sollte, inkl. dem ganzen Aufwand, den eine Freetz-Installation nach sich zieht. Daher bin ich etwas unschlüssig, ob die Idee, auch Freetz-Images nachträglich noch durch "modfs" ändern zu lassen, wirklich so gut bzw. wirklich "verbreitet" ist und wenn man das verneint, lohnt sich nicht mal die "Korrektur" der Ermittlung der Brandings.

Ob das mit der LED-Seite klappen sollte, weiß ich nicht. Theoretisch scheitert das genauso an dem Problem beim Ermitteln des Brandings: https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_leddisplay#L197 - wenn $TARGET_BRANDINGS halt leer ist, wird der Patch auf keine einzige Datei angewendet und die Prüfung (im "precheck" bzw. "postcheck") mittels "grep" scheitert eben nicht am Fehlen der gesuchten Zeilen, sondern bereits am Fehlen der gesuchten Datei, weil der Pfad mit einem leeren "$TARGET_BRANDING" (das ist beim Aufruf der erste Wert aus der Liste bei "$TARGET_BRANDINGS") halt nicht auf eine existierende Datei verweist.

Fazit: Nicht auf Freetz-Images anwendbar (zumindest im Moment) - macht aber in meinen Augen auch nur wenig Sinn. Wobei das "iterative Ändern" (wenn man das existierende System als Basis nimmt anstelle eines neuen Images) vielleicht noch eine interessante Idee bliebe - andererseits läßt sich eben jedes "modscript" auch innerhalb von "fwmod_custom" ausführen ... ggf. eben mit "run_modscripts", auch wenn das noch ziemlich "neu" ist; die Idee bzw. meine Feststellung, daß das so funktioniert, ist deutlich älter und oft wiederholt.

 

[FischersFreetz]

Danke für deine Erklärungen und Hinweise...

... Wobei ich bei der Verwendung von Freetz ohnehin nicht verstehe, warum man da nachträglich mit "modfs" noch mal "drüberwischen" sollte oder wollte ...
... ob die Idee, auch Freetz-Images nachträglich noch durch "modfs" ändern zu lassen, wirklich so gut bzw. wirklich "verbreitet" ist ...

Ich würde sagen: "Nein."
(Ich wollte bloß mal dein "modfs" ausprobieren und sehen, wie es funktioniert. Die 7362 war halt "gefreetzt".)

Nebenbei... Ich habe in deinen Scripts ein bisschen gestöbert und da fiel mir öfter ein " %s " auf, das ich mir nicht erklären kann, z.B.

if ! [ -d "$1" ]; then
        printf " %s is not a valid directory.\a\n"
fi

Wofür steht dieses " %s " ? (wenn es nicht zu weit führt)

 

[PeterPawn]

Wenn da nicht noch ein "$1" dahinter steht, wäre das ein Fehler in der Zeile. Ansonsten kann das "printf"-Kommando eine "Vorlage" in Form eines auszugebenden Textes ("format") mit dem Inhalt von Variablen ("argument...") füllen: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html

Das ist bei numerischen Werten häufig erforderlich (spätestens dann, wenn diese nicht dezimal verarbeitet werden sollen - dann macht das "printf" die Umwandlung) und macht auch bei Zeichenketten häufig mehr Sinn, als diese einfach irgendwie zum Resultat zu verketten.

In dem von Dir gezeigten Beispiel (wo tatsächlich "$1" in der Liste der "arguments" (siehe Link) fehlen würde - aber ich finde diesen Text "is not a valid directory" im YourFritz- und im modfs-Repo auch nur ein einziges Mal und da ist das Statement richtig:

 25 target_dir="$(readlink -f "$1")"
 26 if ! [ -d "$1" ]; then
 27         printf "\"%s\" is not a valid directory.\a\n" "$target_dir" 1>&2
 28         exit 1
 29 fi

(in "run_modscripts")
, denn da steht die Variable, aus der der Zeichenkettenwert kommen soll, ja in der Argumenteliste) macht das u.a. auch deshalb Sinn (und sollte auch in anderen Programmiersprachen, die dasselbe Prinzip beim Zusammenstellen von Ausgaben verwenden, immer so genutzt werden), weil man sich auf diese Weise keine Gedanken darum machen muß, ob "$target_dir" jetzt vielleicht selbst noch "double quotes" oder Leerzeichen enthält oder irgendwelche anderen Zeichen, die beim "Zusammenstückeln" von Nachrichtentexten am Ende zu einem ungültigen Kommando führen könnten.

Um mal ein Beispiel zu zeigen ... das wäre z.B. ein Unterschied zwischen den verschiedenen Formen von "printf"-Verwendung:

vidar:~ $ a="--"; printf "$a ist ungültig\n"
bash: printf: --: invalid option
printf: usage: printf [-v var] format [arguments]
vidar:~ $ a="--"; printf "%s ist ungültig\n" "$a"
-- ist ungültig
vidar:~ $

Die Variante von "printf" mit der Ersetzung (anstelle der Variablensubstitution) ist also "robuster" und weniger anfällig für den "Mißbrauch", der ja häufig auch darin besteht, ein Kommando einfach scheitern zu lassen, wenn mit diesem z.B. die weitere Verwendung ungültiger Werte ausgeschlossen werden soll.

Wobei das im "run_modscripts" jetzt beim "printf" auch mehr ein "Automatismus" meinerseits ist ... eine wirkliche Fehlerbehandlung findet da nicht statt bzw. da wird noch gar nicht versucht, das "wasserdicht" zu machen. Denn wenn man da "--" als Pfadnamen angibt, fallen auch andere Kommandos (z.B. das "readlink" davor) auf die Nase ... da müßte man zum "Abdichten" die Zeile 25 auf: target_dir="$(readlink -f -- "$1")" ändern, damit man die korrekte Fehlermeldung in Zeile 27 erhält. Aber solche wirklich ausführlichen Prüfungen, daß Skripte auch Aufrufe mit unerwarteten Parametern schadlos überstehen, macht man (leider) meistens nur da, wo man sich mit "unbekannten Eingabedaten" konfrontiert sieht und beim "run_modscripts" handelt es sich nur um ein (eher kurzes) Beispiel, wie man die "modscripts" auch ohne "modfs" aufrufen könnte - da sind kaum "feindliche Daten" zu erwarten.

 

[FischersFreetz]

Ich habe gar auf das "printf" geachtet und so den Format-Parameter nicht deuten können.

"Als Wiedergutmachung für deine Mühe", habe ich noch einen "modfs update"-Test mit "enable system and branding selection from GUI (v0.6)" und "enable telnet daemon" auf der 7362 gemacht.
Er lief butterweich durch. (Wenn dich noch ein Test interessiert, dann gib mir einfach ein Zeichen.)

Muss Telnet bei Anwendung von "enable telnet daemon" danach noch (per Telefon, per ??? ) aktivert werden?

 

[Micha0815]

#96*7* ist dein Freund
LG

 

[PeterPawn]

Lies einfach (noch) mal hier: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2366436

Da habe ich praktisch alle derzeit enthaltenen Modifikationen noch einmal aufgeführt und gerade zum Telnet-Daemon auch noch einiges an Hinweisen gegeben, was man dabei beachten muß - der baut jedenfalls absichtlich immer noch auf die Aktivierung per Telefon, weil ich einen ständig aktiven Telnet-Daemon "nicht verantworten" will.

Steht aber auch alles schon in Beiträgen in diesem Thread - nur kommt halt in mittlerweile 5 Jahren und 8 Monaten auch einiges zusammen und damit ist der Thread nun mal "lang" ... man kann ihn aber auch "rückwärts" lesen, wenn man #1 noch dazu nimmt und die Links darin beachtet.

Ansonsten danke für die Rückmeldungen zur 7362SL ... ich gehe aber davon aus, daß tatsächlich der eine oder andere das auch auf der 7362SL benutzt (schließlich hat die mit ihrem VR9-SoC sogar "richtig aktuelle" Firmware bisher - anders als z.B. die 7412), weil er kein Freetz will und trotzdem den Shell-Zugang gerne hätte (oder den Boot-Manager oder was auch immer) und daß gravierende Probleme daher auch schon ihren Weg in diesen Thread gefunden hätten. Die letzten Änderungen mit den neuen Anforderungen an den verfügbaren Speicherplatz waren vielleicht etwas zu sehr von der 7490 und dem neuen Aufbau der Images von AVM (mit deutschem UND internationalem Branding) beeinflußt - andererseits betrafen die letzten Korrekturen ja auch gerade die von AVM neu eingeführten "Probleme" und wer eine andere Box hat, kann auch problemlos mit einer älteren "modfs"-Version arbeiten.

Ich habe trotzdem mal die Tests für den freien Platz im "tmpfs" deaktiviert, solange man nicht "CHECK_TMPFS_SPACE=1" beim Aufruf im Environment stehen hat: https://github.com/PeterPawn/modfs/commit/5b02685f8dfbb0f356bd7e32a7ba498c748e7548

Eigentlich sollte dieser Test nur "Enttäuschungen" vorbeugen (oder sie zumindest auf weniger Benutzer reduzieren), wenn bis zum Packen alles sauber lief und danach dann aber das FRITZ!OS die Box neu startete, weil das "mksquashfs" schon sehr ressourcenintensiv ist und die Box per se erst einmal so eingestellt ist (über "/proc/sys/vm/panic_on_oom"), daß sie bei Speichermangel einfach neu bootet.

Läßt man den Test aus, riskiert man halt auch nichts weiter, als daß es ein paar Abbrüche/Neustarts mehr gibt - wobei die "Pflicht" zum USB-Swapspace das Problem vermutlich parallel auch entschärft hat und damit der Test noch etwas weniger wichtig ist.

Weil ich nun schon mal dabei war, habe ich wohl auch gleich noch "extract_version_values" eingebaut anstelle der "internen" Funktionen zum Auslesen von FRITZ!OS-Infos und ein neues Archiv auf yourfritz.de bereitgestellt.

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

Generell gilt ab jetzt auch: Wenn jemand die neue Version direkt auf seine Box laden will und bereits ein Image mit einer BusyBox verwendet, die beim "wget" auch HTTPS unterstützt (die von AVM macht das nicht, man braucht also eine eigene, die aber z.B. im "modfs"-Paket auch enthalten ist), kann derjenige auch einfach eine Pipeline wie diese verwenden:

wget -q -O - https://github.com/PeterPawn/modfs/archive/master.zip | unzip -q -d /var/media/ftp -

- danach steht dann im Verzeichnis "/var/media/ftp/modfs-master" der jeweils aktuelle Inhalt des Repos zur Verfügung ... allerdings ohne passende Flags.

Deshalb habe ich noch ein Skript hinzugefügt (in "bin/scripts/generate_flags_script.sh"), das ein anderes Shell-Skript generiert, in dem die Flags dann - in erster Linie für die ausführbaren Dateien - wieder korrekt gesetzt werden. Damit kann man nach dem Entpacken des ZIP-Archivs von GitHub mit dem aktuellen Inhalt des "modfs"-Repos auch einfach noch ein sh set_correct_flags.sh aufrufen und hat danach die notwendigen Berechtigungen wieder gesetzt - leider geht das beim Packen eines ZIP-Files durch GitHub ansonsten verloren (beim Klonen mittels "git clone" entscheidet der Git-Client, ob er die x-Flags übernimmt oder nicht).

 

[FischersFreetz]

Lies einfach (noch) mal hier:...

Danke PeterPawn, ich habe einen Überblick über dein "modfs" bekommen, konnte ihn meinen Bedürfnissen nach erfolgreich anwenden und habe Einiges dazugelernt. Bis zum nächten Mal...

FischersFreetz

 

[PeterPawn]

Update für "modfs" ... der "gui_bootmanager" funktioniert jetzt auch mit Boxen auf IPQ4019-Basis (m.W. bisher nur 7520/7530).