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

[PeterPawn]

Aber das war bei Dir dann noch vor dem 17.08.2017, oder? Da habe ich die derzeit aktuelle Version erstellt ... nicht daß ich da doch noch Unsinn verzapft habe.

Ich benutze halt nicht immer direkt diese Version vom Server (weil ich natürlich Änderungen erst mal auf der eigenen Box teste und dann am Ende aus dieser getesteten Version das Paket auf dem Server entsteht - das enthält aber nicht immer alle Änderungen, solange einige noch nicht "spruchreif" sind) und so greift dann mal leichte Verunsicherung um sich, wenn jemand (als Einzelner) von solchen Problemen berichtet.

Anhand der Download-Zahlen sehe ich halt, daß auch diese aktuelle Version (als "modfs.tgz", aber dahinter verbirgt sich ja die "modfs-0.4.5.tgz") täglich mehrfach geladen wird (und nicht von irgendeinem Spider, der einem Link folgt) und da denke ich mir dann auch, daß ich dann wesentlich mehr "Klagen" hören müßte, wenn wirklich etwas mit dem Archiv nicht stimmt.

Parallel laden aber auch jeden Tag noch Leute die alten Versionen (bis zur 0.3.3 zurück), weil die in irgendeiner alten Anleitung dann diesen Link stehen haben. Da bin ich tatsächlich am Überlegen, ob ich diese Links nicht alle auf die neueren Versionen umbiegen sollte ... es gab ja einiges an Fehlerkorrekturen. Die meisten klonen halt nicht das GitHub-Repository, sondern laden tatsächlich von der Box aus direkt das TGZ-File von meinem Server.

 

[Pokemon20021]

Nach einer telnetfähigen FW-International-Version muss man weit zurückgraben, wobei dann schon die squash-tools nicht mehr greifen

diese "Downgrade-Orgie" ist doch sehr aufwändig,
ich denke da wäre die "Injection" des ShellInABox Binary direkt in die FW 06.83 int doch wesentlich eleganter/effizienter;
als Image-Vorlage könnte man reset_tainted.image aus PeterPawn Github https://github.com/PeterPawn/YourFritz/tree/master/first_aid nehmen und eben als Nutzlast das SIAB Binary implementieren.

 

[joto]

Hmmm... nach einer Zeit des Testens mit der Labor .. keine Probleme im moment.... scheint soweit zu funktionieren die Box.
Das eimzige was mir so auffaellt ist das die Box manchmal richtig traege ist.

m.f.g

 

[PeterPawn]

Ich denke schon, daß auch bei Fehlern das Feedback dann kommt ... egal ob Power-User oder Gelegenheitsnutzer. Es gibt - auch abseits des IPPF - inzwischen genug andere Anleitungen, wie man "modfs" verwenden kann und die verllinken direkt auf den Server. Wenn es da Probleme geben würde, sollte auch dort jeweils in den Kommentaren der User irgendetwas davon zu lesen sein.

Ansonsten quält mich die Frage, was denn jetzt ein "Annex-A-Land" sein soll und wo sich das von Annex B unterscheiden sollte und noch viel wichtiger, warum das für "modfs" einen Unterschied machen sollte. Ich habe selbst 7490 in der Schweiz (Luzern und Umgebung + Zürich) in Verwaltung ... die arbeiten an einen ISDN-Anschluß der Swisscom ganz normal mit ihrem VDSL-Modem und Annex B - der einzige Unterschied ist die fehlende Notwendigkeit für PPPoE und irgendeine Anmeldung.

Da gibt es auch die Umschaltung zwischen der deutschen und der internationalen Version ... allerdings mittlerweile auf anderem Weg als mit dem Boot-Manager realisiert (sondern eher so, wie ich es für die 6490 mal beim Installieren eines Firmware-Images vom NAND-Flash gezeigt habe) und das macht auch keine Probleme (obwohl natürlich nach erfolgreicher Umschaltung dann dasselbe Ergebnis erzielt wurde, wie mit dem - mittlerweile korrigierten - Boot-Manager). Aber ehe ich auf einer entfernten Box mit "modfs" loslege, erstelle ich lieber die notwendigen Images lokal und lasse sie dann auf der entfernten Box bloß noch installieren - wie gesagt, habe ich im 6490-Thread mal beschrieben, wie man das - auch aus der Ferne - "richtig" machen könnte bzw. wie ich das dort mache.

Ich streite ja gar nicht ab, daß es tatsächlich den Fehler im Boot-Manager gab - der ist aber beseitigt. Entweder es gibt jetzt weiterhin konkret zu benennende Probleme, die sich auch reproduzieren lassen und die man dann "modfs" zuordnen kann (und wenn das so sein sollte, auch muß und darf) oder man zieht - einfach aus Fairness - auch andere Ursachen in Betracht. Ein "ich hatte mal ähnliche Probleme und konnte die auch nie lösen ... kann auch am 'modfs' gelegen haben" ist jedenfalls reichlich unfair. Ohne passende Belege kann das genauso am falschen Tastatur-Layout oder der falschen Farbe des Mousepads gelegen haben ... was für den einen "nur so dahingesagt (oder -geschrieben)" ist, bedeutet für den anderen am Ende auch eine vollkommen unnütze Fehlersuche, wenn das eben nicht an der Software liegt.

Wenn man mit solchen "Meldungen" die Schwelle für das Triggern einer solchen Suche dauerhaft immer höher legt (weil zwischenzeitliche Suchen kein Ergebnis brachten und ggf. auch gar nicht bringen konnten, weil das eigentliche Problem ganz woanders lag), dann muß man sich am Ende auch nicht wirklich wundern, wenn andere Fehlerberichte darunter zu leiden haben ... irgendwann hat man auch mal genug davon, durch jeden hingehaltenen Reifen zu springen.

Ich begrüße (ausdrücklich!) jede sinnvolle und reproduzierbare Fehlermeldung ... oder - wenn die notwendigen Angaben zur Suche beim Auftreten des Fehlers jemandem noch nicht klar waren - jede Fehlermeldung, deren Erstatter sich dann auch wirklich in die Fehlersuche einbringen will und seinerseits alles unternimmt, um anhand der Hinweise von hier den Fehler so zu reproduzieren, daß man ihn auch beheben kann - das hilft dann tatsächlich allen (und auch dem gerade Betroffenen).

Aber wenn jemand nur seinen Mißerfolg vermelden wollte und am Ende nicht einmal klar ist, ob er/sie sich auch an die richtige Vorgehensweise gehalten hat, dann muß ich vermutlich in Zukunft dazu übergehen, derartige Berichte auch zu ignorieren (selbst wenn mir das eigentlich nicht so sehr liegt, wie man sicherlich auch in diesem Thread verfolgen konnte). Es bringt einfach nichts, wenn ich ins Zweifeln gerate und meine Zeit mit der Suche nach irgendwelchen Problemen verplempere, die in Wirklichkeit auf L8 liegen.

Wenn also jemand solche Fehler feststellt, hier meldet und davon ausgeht, daß die irgendwann mal behoben werden, dann bitte ich ernsthaft darum, das nur noch zu machen, wenn er tatsächlich bei der Suche auch mitwirken will. Ansonsten hilft schon ein "Hat bei mir nicht funktioniert, muß aber nicht an der Software gelegen haben ... macht nichts, ich lasse es jetzt sein" - daraus würde ich (nach den jüngeren Erfahrungen) nicht einmal mehr den Versuch ableiten, der Ursache bei diesem Schreiber tatsächlich irgendwie nachzuspüren und meinerseits nachzuhaken, wo es denn nun genau klemmte - dazu muß man das aber klar erkennen können (und die Gründe mögen ja vielfältig sein, von Desinteresse bis Unwillen oder Wegfall der notwendigen Hardware oder Ende des Urlaubs oder was auch immer).

 

[PeterPawn]

Du mußt einfach mal von der Cholerik auf verstehendes Lesen wechseln ... Du kannst hier alle Beiträge stehen lassen.

Trotzdem werde ich - selbst beim mehrmaligen Versuch des Lesens von #1226, speziell des zweiten Absatzes - einfach nicht schlau daraus, was Du da nun wirklich gemacht hast.

Kann man das nicht mal ordentlich als Aufzählung der tatsächlich ausgeführten Schritte in die Tastatur klöppeln, so daß ein anderer das auch mal nachvollziehen kann? Selbst jemand, der ähnliche Probleme haben sollte, kann ja praktisch nur raten, was Du ihm/uns/mir damit nun eigentlich sagen wolltest.

Worüber regst Du Dich eigentlich hier jetzt genau auf (daß Dein Kardiologe wieder mal zu Rate gezogen werden mußte)? Daß ich - auf Deine Fehlermeldung hin - versucht habe, den Fehler zu lokalisieren und den dann - trotz der ungenauen Angabe, wann das Problem wirklich auftrat - gefunden und beseitigt habe?

Auf alle meine nachfolgenden Ratschläge, in welcher Reihenfolge Du nun welche Version installieren oder aktualisieren müßtest, damit diese Änderung des Boot-Managers auch wirksam wird, kam immer nur etwas in der Richtung "keine Zeit mehr, muß wieder abreisen" zurück. Wenn Du dann aus Deiner eigenen Zeitnot die Schlußfolgerung ableitest, Dein Problem läge am "modfs", dann werde ich tatsächlich ungehalten ... denn das von Dir (vermutlich) beschriebene Verhalten hat per se mit "modfs" erst einmal gar nichts zu tun.

Das eine ist das Framework, welches sich um Entpacken, Ändern, Packen und Installieren der Firmware kümmert und das andere sind die einzelnen Modifikationen. Wenn jetzt tatsächlich der Boot-Manager in irgendeiner der beiden Versionen Probleme beim Umschalten machen sollte (dem Text nach hast Du ja beide Versionen getestet, eine Protokoll-Datei für den (auch wieder nur dem Text nach) erfolgreichen "modfs"-Lauf hast Du auch nirgendwo angehangen), dann hat das wenig bis nichts mit "modfs" und dem Update-Prozess zu tun.

Hier kann man - im Gegenteil - so viele Fehler selbst machen, daß eine so verworrene Beschreibung wie oben (ich muß das Kind nun mal beim Namen nennen, auch wenn Du jetzt vielleicht erneut auf das Tödlichste beleidigt bist) keineswegs zur Klärung beiträgt. Installiert man von einer deutschen Version aus eine internationale, wird (absichtlich) das Branding nicht verglichen ... trotzdem wird natürlich bei erfolgreicher Modifikation (das klappt wieder, weil "modfs" alle in der originalen Vorlage vorhandenen Brandings der Reihe nach patcht) das System eingepackt und installiert und wenn bis zu diesem Punkt kein Fehler auftrat, auch über "linux_fs_start" umgeschaltet.

Jetzt würde jeder kundige FRITZ!Box-Besitzer hingehen und VOR dem Reboot erst einmal das Branding im Environment ändern ... warum sollte er sich den Aufwand antun (der ggf. eine andere Verkabelung braucht bzw. einen anderen Rechner, je nachdem, womit er "modfs" auf der Box benutzt hat) und das erst danach über den FTP-Server ändern? Abgesehen von den dabei immer noch möglichen Fehlerquellen ... ich wüßte auch nicht, daß "modfs" in irgendeiner Weise ansagt, welches "fs_x" jetzt beim nächsten Start geladen würde oder nicht. Das tut max. der Boot-Manager im GUI und auch den könnte man selbstverständlich für den Neustart der Box verwenden (sofern der in der aktuell genutzten Version auch vorhanden ist), dann wird das Branding tatsächlich auch wieder (automatisch) mit umgeschaltet.

Wenn das GUI einer FRITZ!Box nach einer Änderung des Brandings nicht erreichbar ist, dann prüft man als allererstes die - von Dir hier ja wohl von Hand vorgenommene - Änderung des Brandings noch einmal nach ... das ist ein lange bekanntes und überdeutliches Zeichen für den falschen Wert in "firmware_version", wenn das GUI nicht geladen werden kann. Was hat jetzt "modfs" damit überhaupt zu tun?

Wenn das System startet (der Kernel wurde von "modfs" installiert und auch das Dateisystem muß ja irgendwie vorhanden und gültig sein, wenn die Box ansonsten funktioniert), dann kann "modfs" da eigentlich nichts falsch gemacht haben ... das faßt nämlich das Branding gar nicht an.

Die naheliegendste Erklärung wäre es - selbst wenn Du es nicht hören willst - hier nun einmal, daß Du selbst ein falsches Image als Vorlage angegeben hast (das könnte man mit der Protokolldatei sofort verifizieren) und damit am Ende eine deutsche Version installiert war, der Du natürlich mit einer manuellen Änderung auf "avme" dann die GUI-Dateien unter dem Gesäß wegziehst. Das ist 10x logischer als irgendeine Ursache im "modfs" selbst, solange die Box an sich läuft und Du zuvor eigenhändig den Wert für "firmware_version" manipuliert hast ... so etwas zu diagnostizieren, erfordert aber als allerersten Schritt immer die kritische Überprüfung der eigenen Aktionen und erst dann, wenn da eigene Fehler definitiv ausgeschlossen sind (das sind dann nämlich die angesprochenen L8-Probleme), dann sollte man - am besten mit "Belegen" für die behaupteten Fehler - auch mit einer Fehlermeldung auflaufen.

 

[joto]

Hallo,

Weniger aufregung kann auf keinen fall schaden.
Hab mir auch eine Zwangspause verordnet.
Habe auch meine Probleme mit dieser Box , werde die sache noch mal spaeter angehen.
Hatte auch eine andere Box hier und keinerlei Probleme mit modfs.
Ich steh auch auf dem Schlauch , aber was solls kann es eh nicht aendern .... schaun wa ma.
Ich habe schon die merkwuerdigsten Sachen gesehen... alles gleich, aber bei dem einen Funzte es und beim anderen nicht.... so ist es manchmal halt.


m.f.g.joto

 

[Virgus]

Hello everybody and thanks again for the help you gave me so far!

I tried to follow all the recent discussion via google translator and I'm back here to report a strange behaviour.

Before getting into details let me summarize my setup:
- an FB7490 (AVM german version) which I use for my apartment
partition 0 with unmodded OS 6.31; partition 1 with unmodded OS 6.83
- a second FB7490 (AVM international version, which I've been configuring in the last days) to be used in my mom's apartment
partition 0 with modded OS 6.31; partition 1 with modded OS 6.83
Both of these units are used with external cable modems as I have fiber connection in both apartments.

Thanks to your suggestions I successfully modded the second unit and had ssh being started at boot, but after many modfs run and reboot I've seen a very strange behaviour occur when I reboot the unit:
- the FB restart occurs after a very long time (more than two minutes!)
- the FB "hangs" into adam2 FTP mode indefinitely

This strange behaviour occurs whatever "reboot" I do, either via SSH reboot command or via the GUI System>Backup>Restart to both currently active or alternative system. The only difference with reboot command is that the time is not two minutes but only a few seconds.
So the solution for this second box is now to turn phisically off and on the box to have the adam2 FTP mode last the normal 5 seconds instead of "infinite".

At this point I wanted to see what would have happened to my german FB7490 by modding both partitions and I ended with the same behaviour.
This second unit is perfectly usable but I cannot reboot if I'm not phisically near the box to be able to turn power off and on manually.

Now as the user Joto did for his "problems" I also spent days already and would like to track down where the problem is.
- trying to restore both OS 6.31 and then modding only with OS 6.31 would be my first choice as I suspect that this behaviour is related to version 6.83.
- a second step would be to upgrade the part 1 with OS 6.52 and see what happens.
- then finally upgrade again to OS 6.83

I hope you could give me your suggestion on how to proceed and hopefully some tricks to log the actions I'll perform in a way that might be useful to track down what's happening as this is a quite favorable situation where I can use one unit for testing without having to shutdown my internet connection everytime.
Both of these units are now connected to the main modem/router, so I set up both units with same network parameters and VoIP numbers and can swap from one to the other by simply swapping a RJ45 cable.

Thanks for any help you might give me.
V.

 

[PeterPawn]

In most cases this behavior shows an unclean shutdown ... there're only little chances, that it's really related to "modfs" itself.

Usually people start own services from an USB stick and/or other places and forget to add appropriate extensions to stop these services on a shutdown or reboot ... the right place to do this, is the (writable) "/var/post_install" file.

Even if the name suggests, it would be related to "install", it's in reality the main script, which will be executed during a shutdown or reboot sequence (look into "/etc/inittab").

Here many AVM services will be stopped and sooner or later (more sooner, because most AVM services usually don't need the NAS storage) the whole USB stack gets killed - this may be a problem for services running from a stick, if they will be requested to stop normally (kill without SIGTERM).

If a service doesn't react to a stop request, it may take some time, until it gets killed by the original firmware.

You should look into "/etc/term.sh" for an impression, how AVM handles these stop functions in the running system and combine this further with a glance on "/var/post_install" to see the "shutdown handling".

If you start a simple telnet session (where "getcons" is executed), this session may survive much longer than any other shell access (as long as you don't have a serial port to access) and you could be able to watch the shutdown process and identify the service, which is in charge for this long delay.

If you haven't a telnet service in your image, it's really simple to establish it as a temporary solution, as long as the "telnetd" applet is present in the "busybox" binary.

It's in the "modfs" static version (without any needs for a symlink) and it's in the original version, here you have to create the symlink for "/usr/sbin/telnetd" first, which needs a bind-mounted and writable "/usr/sbin" directory with a copy of its original content in tmpfs.

 

[Virgus]

Many thanks Peter for the prompt reply!
I'll investigate and study your suggestions in the next days and report soon the results.

 

[eisbaerin]

Ich hatte mal modfs (Version vor dem 17.8.) auf einer 7580 getestet.
Lief für eine 7490 durch.

Das neue modfs (vom 17.8.) auf einer 7580 geht auch für die 7490.

Wenn ich es aber für eine GRX5 probiere, erhalte ich schon beim Auspacken folgenden Fehler:

2017-09-03 09:12:53.740 - progress: mode=1, msg=Extrahieren des Flash-Filesystems aus dem Firmware-Image ...
2017-09-03 09:12:53.753 - extract_filesystem: src=/var/media/ftp/FRITZ.Box_7580.153.06.83.image, target=/var/tmp/1504422772/filesystem.image
2017-09-03 09:12:54.005 - extract_filesystem: exiting, rc=0
2017-09-03 09:12:54.038 - progress: mode=3, msg=[1;32m OK[0m
2017-09-03 09:12:54.071 - progress: mode=1, msg=Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ...
2017-09-03 09:12:54.083 - extract_rootfs_from_wrapper: src=/var/tmp/1504422772/filesystem.image, target=/var/tmp/1504422772/filesystem_core.squashfs
2017-09-03 09:12:54.103 - detect_image_filesystem: src=/var/tmp/1504422772/filesystem.image, offset=0, fstype=squashfs4, rc=0
2017-09-03 09:12:54.121 - get_temp_dir: directory=/var/tmp/7825_1504422774
2017-09-03 09:12:54.162 - remove_directory: directory=/var/tmp/7825_1504422774, rc=0
2017-09-03 09:12:54.174 - extract_rootfs_from_wrapper: exiting, rc=41
2017-09-03 09:12:54.207 - progress: mode=3, msg=[1;31m Fehler[0m
2017-09-03 09:12:54.240 - cleanup: running cleanup from file /var/tmp/7825_filelist_1504422770
2017-09-03 09:12:54.252 - /var/media/ftp/mod/bin/225/busybox rm -r /var/tmp/1504422772
2017-09-03 09:12:54.252 - /var/media/ftp/mod/bin/225/busybox rm -r /var/tmp/7825_1504422774

Mach ich etwas falsch oder ist da noch ein Fehler im Programm?

Ja, ich weiß es ist für die GRX5 Boxen noch nicht frei gegeben.
Ich hatte gehoft, das Entpacken und Packen geht schon.
Die modscripts hätte ich schon angepaßt.

Was mir noch aufgefallen ist:
Wenn ich modfs mit der gleichen GRX5-Datei ein 2. mal laufen lasse, dann ist der schon in 5s bei dem Fehler.
Da geht dann selbst die Signaturprüfung in Windeseile.
Ist das so gewollt oder wird da etwas nicht sauber gelöscht?

 

[PeterPawn]

In der veröffentlichten Version ist noch nicht einmal das Auspacken richtig enthalten, wenn ich mich richtig erinnere (ich müßte erst nachsehen).

Eigentlich dürfte der oben im Protokoll schon gar nicht mehr in "extract_rootfs_from_wrapper" laufen, weil es eben diesen "Wrapper" gar nicht gibt bei den GRX5-Modellen. Da greift auch nicht etwa der alte Code für den 2.6er-Kernel und SquashFS3, denn auch dort gab es das Wrapper-FS ja schon und AVM hatte zum 3.10er-Kernel hin nur auf "ext2" gesetzt für den Wrapper (der zuvor einfach ein weiteres SquashFS-Image war, wenn ich mich richtig erinnere), weil die Kernel gegenseitig die SquashFS-Versionen nicht hätten mounten können und damit das Kopieren ins YAFFS2-FS nicht möglich gewesen wäre - "ext2" kannten dann halt beide Kernel-Versionen.

Das würde der Code in "modfs" vermutlich auch noch gebacken kriegen ... aber es fehlt eben am "äußeren Dateisystem". Dafür kann man das eigentlich so weit vereinfachen an dieser Stelle, daß man gleich das "filesystem.image" anstelle von "filesystem_core.squashfs" weiterverwendet. Aber das geht auch wieder nur bis zum Einpacken gut ... spätestens beim Versuch des Kopierens des neuen Root-FS in die Wrapper-Partition ist Schluß mit lustig.

Am Ende ist der ganze Aufbau bei den GRX5-Boxen sogar einfacher ... aber ich hatte selbst ein paar Probleme, da lauffähige Systeme in den über UBIFS emulierten MTD zu installieren und so traue ich mich noch nicht, da irgendetwas an jemand anderen herauszugeben. Zumal der hier von Dir "geplante" Weg der Modifikation der GRX5-Firmware auf einer VR9-Box noch ein weiteres Hindernis ist ... bisher ist halt immer ein Wrapper vorhanden und das wäre auf dem "modfs"-System selbst ja auch noch so ... man müßte das also wirklich direkt an das als Vorlage verwendete Image koppeln.

Es gibt zwar (aus der Erinnerung) erste Versuche, die Modelle und ihren Aufbau auch in "modfs" einzuführen (das kann man nicht immer sicher anhand des Inhalts eines AVM-Images ermitteln bzw. es kostet auf der Box zu viele Ressourcen), das ist aber alles nicht vollständig.

Zu allem Überfluß hatte ich zwischenzeitlich auch noch Probleme, das FS für das inaktive System im gerade laufenden System zu mounten - damit funktionierte dann der Boot-Manager nicht bei der 7580. Das scheint aber nach der Labor-Version kein Thema mehr zu sein, jedenfalls klappt es in der 06.90 dann auch wieder, "/dev/mtdblockX" für "reserved-filesystem" irgendwo zu mounten.

Wenn sich jemand selbst daran machen möchte, würde ich demjenigen empfehlen, daß er gar nicht erst versucht, eine Version zu erstellen, die für alle Modelle funktioniert, sondern - zumindest als Einstieg - erst einmal die Unterfunktionen so weit ausdünnt, daß nur noch die GRX5-Variante enthalten ist ... also den ganzen Wrapper-Kram komplett wegwerfen und bei der Installation für das Dateisystem kann man die Installation des Kernels (mittels "update_kernel") praktisch 1:1 kopieren (nur mit anderer Quelle und anderem Ziel-MTD). Das macht auch nur für den "update"-Modus Sinn ... ansonsten müßte man den ganzen Code für das Suchen der Vorlage (wenn man das bestehende System nimmt und weitere Änderungen hinzufügen will) auch noch anpassen, weil der auch irgendwo im Wrapper suchen würde.

Zwischenzeitlich hatte ich sogar meine eigene Arbeitsversion verloren, weil ich die (absichtlich) nicht ins "git" eingecheckt hatte ... seitdem mache ich das selbst auch praktisch von Hand, wenn ich eine 7580 anpassen will (und andere mußte ich noch nicht bearbeiten). Daraus entstand dann (weil ich das zum wiederholten Male machte, denn das ging schon für die ganzen Labor-Versionen so) auch der neue Thread zur 153.06.90 und dem Telnet-Service. Im Prinzip braucht man ja nach dem dort beschriebenen Erstellen des Symlinks (oder auch anstelle dieses Kommandos) nur die Abarbeitung der "modscripts" einzusetzen (mit den richtigen Parametern aufgerufen) und dann ist das Ergebnis genau dasselbe wie beim "modfs", wenn man es wieder einpacken läßt.

Mit den passenden Tools (und die liegen ja auch im "modfs"- oder im YourFritz-Repo (dort dann im "binaries"-Branch) in der MIPS-Version vor) kann man den im anderen Thread beschriebenen Ablauf auch auf einer FRITZ!Box durchexerzieren für eine andere Box (oder auch die eigene). Anstelle des "git clone" lädt man sich dann halt den Inhalt des Repositories als ZIP-Datei herunter und entpackt diese ... die Tools dafür sind auch alle in der BusyBox vorhanden. Nur die Installation läuft dann eben etwas anders ... wer will, kann aber auch die problemlos aus dem laufenden System heraus (für das inaktive) mit "update_kernel" ausführen und dann von Hand umschalten.

Im Moment geht das halt auf einem (x86-)Linux-System einfacher und anstatt da nun erst einen einzelnen Shell-Zugang einzurichten (das Prinzip von "modfs-Starter" funktioniert hier ja wegen des fehlenden Wrapper-FS nicht), kann man auch gleich die komplette modifizierte Firmware installieren lassen. Bei den VR9-Modellen war das erzeugte Image ja nicht direkt dazu geeignet, über den Bootloader installiert zu werden (dem fehlte der Wrapper außen herum) - das ist bei den GRX5 einfach anders und ob ich mir nun erst einmal ein Image mit einem Shell-Zugang baue oder gleich ein komplett modifiziertes, macht keinen echten Unterschied bzw. geht i.d.R. auf einem x86-Linux eben schneller und praktisch "in einem Aufwasch". Ein einfaches Skript, welches die gewünschten "modscripts" automatisch der Reihe nach mit den richtigen Angaben aufruft (ohne große Nachfragen), ist in 10 Minuten geschrieben.

Für die Leute, die nirgendwo eine Linux-Installation haben und keine wollen, habe ich mal angefangen, die "squashfs-tools" noch etwas zu patchen, damit man mit diesen auch unter der "bash" im Windows 10 etwas anfangen kann ... das ginge notfalls auch noch - im Moment stimmen nur die Zeitstempel nach dem Einpacken nicht mehr mit den originalen überein.

PS und OT: Was ist eigentlich im Deutschen der korrekte Genitiv des amerikanischen "repository"? Ich denke da zwar nur selten drüber nach und schreibe eigentlich immer dieselben Zeichen wie in der Plural-Form, aber ich konnte auch keine (halbwegs allgemeingültige) Quelle finden, wie z.B. im Amerikanischen dann der Genitiv gebildet würde ... die Form mit Apostroph und "s" ist offenbar für "repository" auch nicht so üblich (also kein "the repository's name", sondern eher "name of the repository").

 

[eisbaerin]

Zumal der hier von Dir "geplante" Weg der Modifikation der GRX5-Firmware auf einer VR9-Box

Nein, da hast du mich mißverstanden, ich habe alles auf der 7580 gemacht.
Es steht immer da:

auf einer 7580

 

[PeterPawn]

@eisbaerin:
Ok, hatte ich wirklich falsch verstanden ... da gehört dann der Fehlschlag (spätestens wenn's ans Installieren gegangen wäre, aber glücklicherweise war ja schon beim Entpacken Schluß) aber in die Kategorie: Glück gehabt.

Ich weiß nicht genau, wie die 7580 am Ende reagiert, wenn man ihre inaktive Dateisystem-Partition als YAFFS2 mounten will, nachdem man sie mit "erase all" über den MTD-Treiber gelöscht hat - wobei der YAFFS2-Treiber gar nicht im GRX-Kernel enthalten ist, wenn ich mich nicht irre, denn auch der NAS-Speicher verwendet da UBIFS (ob mit oder ohne Kompression, habe ich noch gar nicht nachgesehen).

 

[koyaanisqatsi]

Moin

PS und OT: Was ist eigentlich im Deutschen der korrekte Genitiv des amerikanischen "repository"? Ich denke da zwar nur selten drüber nach und schreibe eigentlich immer dieselben Zeichen wie in der Plural-Form, aber ich konnte auch keine (halbwegs allgemeingültige) Quelle finden, wie z.B. im Amerikanischen dann der Genitiv gebildet würde ... die Form mit Apostroph und "s" ist offenbar für "repository" auch nicht so üblich (also kein "the repository's name", sondern eher "name of the repository").

Ein "Repo" viele "Repos"
Im Deutschen wird halt munter gedengelt
Korrekt wäre ja für viele Mobiltelefone: Handies
...aber daraus wurde nichts und allgemein sinds dann die: Handys
Wenn du also mehrere Repos korrekt ausschreiben möchtest, dann sinds halt: Repositories
...oder: Der Inhalt dieses Repositories fällt unter ...

Extrem wirds unter dem Gesichtspunkt, dass es ja 2 Arten von Englisch gibt.
...wir sollten hier eigentlich streng europäisch linguistisch vorgehen.
Die Briten sind ja eigentlich raus.
Ja, ich würde ihnen auch den Zugang zum TAT-14 wegnehmen.

Und dann wären da noch unsere "Doppelstaatsbürger".
...immerhin, sympathischerweise mit vertrauten Umlauten.
Vielleicht heisst es in nicht allzuferner Zukunft: IP-Phöne-Förüm

 

[eisbaerin]

in die Kategorie: Glück gehabt.

Nö, nö. Ich wollte ja nur eine Datei erstellen und testen+helfen welche modscripts noch angepaßt werden müssen.
Vor dem flashen hätte ich schon noch nachgefragt, ob das schon geht.
Am liebsten wäre mir ja eine neue "install_inactive_rootfs" für die GRX5 Boxen. Oder gibt es die schon?

BTW: Der LED-Reiter funktioniert in der 7580 schon bei mir, z.Z. mit übermounten.

 

[PeterPawn]

Gibt es noch nicht ... ist aber wirklich nur ein Aufruf von "update_kernel" mit den richtigen Parametern bei "-i" (SquashFS-Image) und "-o" (MTD, wenn ich mich nicht irre, die "character"-Variante, aber das kann man z.B. in der S03-flash_update vergleichen) und da lohnt sich das Skript eigentlich nur für das Ermitteln der richtigen MTD-Nummer. Aber ich denke mal drüber nach bzw. schaue mal ins "install_inactive_rootfs", ob man das vielleicht besser aufbohrt ... aus dem laufenden System heraus ist die Existenz von "/wrapper" ein ziemlich sicheres Zeichen für VR9 bzw. gegen GRX5.

 

[Virgus]

Many thanks Peter for the prompt reply!
I'll investigate and study your suggestions in the next days and report soon the results.

Hello PeterPawn,
I somehow solved the problem but only temporarily: the waiting time was due to the webDav online storage,
please find the telnet outputs attached. I configured STRATO HiDrive services correctly and I suppose this
is a problem of AVM.

On the other side the forced reboot to "adam ftp" mode was due to dropbear and sftp-server running
as if I clean the commands with /usr/sbin/edit_rcuser the problem disappears.

Regarding your instructions of terminating scripts via /var/post_install I was wondering if my processes should be terminated before or after the others.
- In the first case I was wondering if it was not a bad idea of modding /etc/inittab while running ./modfs by adding a second custom "pre-post_install" script:

# Stuff to do before rebooting
/dev/ttyS0::shutdown:/bin/sh -c /var/pre-post_install
/dev/ttyS0::shutdown:/bin/sh -c /var/post_install​

- In the second case: would appending some terminating commands directly to /var/post_install be fine (It's already 279 lines so I like the previous idea more, if viable)?
What would you suggest me to do?

Again thank you for all you patience and efforts to support everybody with modfs!
Have a nice weekend,
V.

 

[PeterPawn]

If your own services aren't needed during the reboot/shutdown sequence, you should terminate them in front of each AVM service. Appending commands to "post_install" isn't a good idea, because these commands will (a) never be reached or (b) get executed after it's much too late to access USB devices or the internal NAND flash as NAS storage ... all of them are dismounted while executing the original AVM commands in the first 297 lines.

You may hook yourself into the shutdown process at its very beginning ... how this could be done with a "generic approach", is shown (as an example) in https://github.com/PeterPawn/YourFritz/tree/master/autoupdate and the corresponding post, mentioned there in the README.md file (this post is in German, but if an automatic translator will not help, you may asked further questions in English - best in this thread here).

But naturally you could simple add commands like "/etc/init.d/dropbear stop" (old LSB style), if you've provided the appropriate scripts (and "/etc/init.d" may point somewhere else, too). But keep in mind, that each command accessing USB devices has to be executed before the USB stack will be unloaded (usb.pandu was the script used therefore, iirc) and that "post_install" tries to identify each process, which accesses "/var/media/ftp" (the code starts in line 70) and such processes will be terminated.

And to solve/research your WebDAV problem, you should have a look at line 109 in "post_install" ... usually the "mount.davfs" process should be stopped there calling "/etc/webdav_control stop". But this may take a while ... look into this file at "stop_webdav()", how much effort is needed there to prevent inconsistent data (half synchronized uploads, current state needs to be saved for later restarts, etc.).

If you hook into the (writable) "post_install" file (it's unpacked from "/var.tar" during boot sequence), it's unnecessary to hook into "/etc/inittab" (which is stored persistent). Any changes to "/var/post_install" (e.g. during the start process of an own service) are volatile and in this way, only activated services are hooked into the shutdown process. If your coding is right, additions will not harm this process, even if a referenced file does not exist due to unknown reasons.

EDIT: I forgot, that post-related links with "old style" do not work as expected ... to find the correct post in the referenced (very long) thread, you may use this link: http://www.ip-phone-forum.de/posts/2186357

 

[Gizmo_Ger]

Beim Packen der Firmware legt meine 7490 regelmäßig einen Neustart hin. Besteht die Möglichkeit den log anstatt in den Zwischenspeicher auf den angeschlossenen USB Stick zu schreiben, damit ich sehen kann, wann genau der Reboot erfolgt?

 

[PeterPawn]

Ich tippe einfach mal, daß Du ihr keinen Swap-Space auf einen angeschlossenen USB-Volume gegönnt hast.

Da der bei mir auch im "normalen" Betrieb aktiv ist und es somit nicht so richtig "oom"-Probleme gibt, weiß ich auch nicht, ob das Schreiben von "0" nach "/proc/sys/vm/panic_on_oom" etwas Sinnvolles/Anderes bewirkt ... theoretisch würde dann nur das Packen gekillt, solange es der einzige "Schurke" ist.

Aus "https://www.kernel.org/doc/Documentation/sysctl/vm.txt":

panic_on_oom

This enables or disables panic on out-of-memory feature.

If this is set to 0, the kernel will kill some rogue process,
called oom_killer. Usually, oom_killer can kill rogue processes and
system will survive.

If this is set to 1, the kernel panics when out-of-memory happens.
However, if a process limits using nodes by mempolicy/cpusets,
and those nodes become memory exhaustion status, one process
may be killed by oom-killer. No panic occurs in this case.
Because other nodes' memory may be free. This means system total status
may be not fatal yet.

If this is set to 2, the kernel panics compulsorily even on the
above-mentioned. Even oom happens under memory cgroup, the whole
system panics.

The default value is 0.
1 and 2 are for failover of clustering. Please select either
according to your policy of failover.
panic_on_oom=2+kdump gives you very strong tool to investigate
why oom happens. You can get snapshot.

Auf "2" wird der Wert in "/etc/init.d/rc.tail.sh" gesetzt ... man könnte jetzt entweder das Schreiben von "0" versuchen oder man spendiert dem System einfach Swap-Space.

Wie das geht und warum/wie man das am besten machen sollte (File vs. Partition), ist irgendwo in #1 auch verlinkt. Es kann halt sein, daß es ein "old style"-Link ist, der wieder nur auf Seite 1 des betreffenden Threads führt ... dann hilft die Antwort von @qwertz.asdfgh auf meine eigene Frage in diesem Thread: https://www.ip-phone-forum.de/threa...beiträge-funktionieren-nicht-wirklich.296634/ beim Erstellen der passenden URL.