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

[tacitus-nrw]

Hat sich erledigt.

auch bei mir klappte Telnet Aktivierung nach

prepare_fwupgrade start_tr069

 

[stefanoIT]

There is a way to restore the execution of debug.cfg on boot in 7490 with firmware 6.30? I mean adding or changing a file under /etc/init.d and repacking the firmware with freetz?
Thanks.

 

[PeterPawn]

Is it a question?

In this case ... yes, it's possible. Freetz isn't really needed, you can try the tar archive from #1 in this thread; but you can even use Freetz itself. It's your decision ... IMHO the "modfs" solution is easier to use, if you want to make only minor changes and do not need additional binary files for your image. I don't provide such files ... the embedded SquashFS utilities from modfs are necessary and constitute an exception, the whole modfs-starter solution is another one. But if you need more than this, you should use Freetz to build such files yourself and if you've setup the needed environment, you could use it right to make your changes to the stock firmware.

Call modfs with "./modfs update <path_to_vendors_image_file>" on your router (the steps needed to do so are explained in the embedded README file - only the "update" mode isn't mentioned there so far) and you can add your own commands to debug.cfg using "edit_rcuser" for editing. The telnet daemon is reactivated automatically by modfs, the "edit_rcuser" script is added and the execution of commands from TFFS node 98 (the "file" formerly known as Prince debug.cfg) is initiated near the end of the init process. Adding the ability to the GUI to select the system for the next reboot at the proper page is optional ... as far as I remember.

The download link can be found in #1 ... if you want to have a look first and/or build an own archive file and/or change it to meet your requirements better - in every case you can read the script now on GitHub too: https://github.com/PeterPawn/YourFritz/tree/master/modfs

Sorry for using a thread in german language to "support" users of modfs ... but the devices aren't widely-used outside Germany and most people prefer to communicate in their natural language here.

---

-@all:
Das kann auch gleich generell als weitere Quelle hier verstanden werden ... nachdem bei Freetz eigentlich ein Umzug zu GitHub angedacht wurde (ob der nun stattfindet, ist wohl wieder ungewiß), habe ich in vorauseilendem Gehorsam mal einen GitHub-Account eingerichtet und einige ausgewählte Sachen für die Öffentlichkeit dort eingestellt. Selbst wenn Freetz am Ende vielleicht doch nicht dort landet, werde ich Quellen wohl künftig dort einstellen - ob das für die Archiv-Dateien zum Download auch gilt, weiß ich noch nicht.

Da "git" keine Symlinks mag (zumindest nicht beim von mir verwendeten Mix aus Linux, Windows und GitHub - spätestens auf Windows ist dann Schluß mit Symlinks), lassen sich solche Sachen auf GitHub wohl nicht gut verwalten - und da ist dann der Server hinter yourfritz.de eine Alternative. Aber zumindest werde ich mir das/ein CMS auf dem Server nun endgültig abschminken ... das erleichtert einiges, da ich irgendwelche OpenSource-Geschichten für Blog/CMS auf Python-, PHP- oder Ruby-Basis wieder in eine virtuelle Umgebung sperren müßte, weil da auch jede zweite Woche eine Lücke auftaucht, gerade bei WordPress.

Aber für die Verwaltung von "issues" (bitte wirklich auf erkannte Fehler beschränken und nicht "bei mir geht das nicht" - das geht hier im IPPF besser) ist das auch keine schlechte Lösung (und jeder kann da schreiben) und wenn jemand Änderungsvorschläge unterbreiten will, ist ein Pull-Request die beste Lösung, wenn das nicht nur mit verbaler Beschreibung erfolgt. Das "Auflisten" von Links macht sich dort auch besser - das IPPF bleibt dann immer noch für "Diskussionen" übrig, aber die "Anleitung" wird künftig wohl auf GitHub landen.

 

[stefanoIT]

Thank you for your reply.
I solved the problem adding the following line to rc.tail.sh and repacking.

##########################################################################################
## user rc file
##########################################################################################
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
fi
fi

Now debug.cfg is working again, and telnet too.
Thanks

 

[Riverhopper]

Hallo stefanoIT,
if you are using modfs instead of fwmod (Freetz) you will also get your debug.cfg feature;
keep in mind, that there are many names for the "well known" TFFS node 98: e.g. debug.cfg, rc.user;
Peter decided to use /var/tmp/rc.user - which is a "flat file" - representing a copy of the content of tffs-minor-node-98 (/var/flash/debug.cfg).

You don't need to change any script in /etc/init.d, the modfs/modscripts/mod_rc_tail_sh will do it for you.

# ls -la modfs/modscripts/
-r-xr-xr--    1 root     root          3818 Sep 22  2014 edit_rcuser
-rwxr-xr-x    1 root     root         11678 Jul 18 11:06 gui_boot_manager
-rwxr-xr-x    1 root     root          1202 Aug 15 03:16 mod_enable_telnet
-r-xr-xr--    1 root     root          1349 Sep 22  2014 mod_profile
-r-xr-xr-x    1 root     root          2251 Sep 22  2014 mod_rc_tail_sh
# cd modfs
# ./modfs update ./FRITZ.Box_7490.113.06.50.image
SNIP
Die Modifikation 'enable [COLOR=#0000ff]rc.user[/COLOR] execution' 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 'enable rc.user execution' wurde angewendet, Fehlercode = 0.

Die Modifikation 'create[COLOR=#0000ff] edit_rcuser[/COLOR] command' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'create edit_rcuser command' mit folgender Beschreibung
Es wird ein zusätzliches Kommando 'edit_rcuser' erzeugt, mit dem die Kommandos
in der Datei 'rc.user' sicher bearbeitet werden können, ohne daß man sich um
die Besonderheiten des TFFS kümmern muß.
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'create edit_rcuser command' wurde angewendet, Fehlercode = 0.

SNIP

after reboot you can see that your /etc/init.d/rc.tail.sh has been changed and a "fresh" rc.user file has been created and executed.

diff /var/media/ftp/USB-Stick/FB7490-06.50/113.06.50/etc/init.d/rc.tail.sh /etc/init.d/rc.tail.sh
@@ -51,4 +51,5 @@
 #########################################################################
+rcuser=[COLOR=#0000ff]/var/tmp/rc.user[/COLOR];mkconfigfile $rcuser.tffs 98;[COLOR=#0000ff]cat $rcuser.tffs >$rcuser[/COLOR];rm $rcuser.tffs;test -s $rcuser && delay -d 1 RCUSER "[COLOR=#0000ff]/bin/sh $rcuser[/COLOR]"
 exit 0
#

# cat [COLOR=#0000ff]/var/tmp/rc.user[/COLOR]
/sbin/eventadd 1 "(TFFS-Minor-ID 98) wird abgearbeitet ..."
#

# [COLOR=#0000ff]/sbin/eventsdump -d[/COLOR]
SNIP
xx.12.15 15:32:07 (TFFS-Minor-ID 98) wird abgearbeitet ...
#

Do not edit the temporary flat file /var/tmp/rc.user;
please use /usr/sbin/edit_rcuser, it will change tffs-minor-node-98 for you.

LG Riverhopper

 

[PeterPawn]

@stefanoIT:
Please read the explanation in #385 carefully.

If you really added your own code from #384 and you did it with "modfs" ... I'd expect, your device will execute the content of the file twice. Adding the rc.user-part isn't an optional mod ... afair. This could lead to some unexpected behavior, if your own shell commands aren't detecting that double call.

---

-There's a small change between earlier vendor code calling /var/flash/debug.cfg from rc.tail.sh and your own version in #384:

[COLOR="#FF0000"][B].[/B][/COLOR] /var/flash/debug.cfg

Looks unimportant ... but it has a bearing on execution.

While the period (dot, point) in front of the name reads the next commands to be executed in the current shell from the specified file (up to its end) and executes them in its own context (here the period is a synonym for the "source" command), the version without it creates a new shell instance to execute the commands. If you try to access variables from the original shell instance (executing rc.S, which is a direct child process of "init" and each script in /etc/init.d is executed in this context), this would fail in such an additional instance. Some people were confused by this subtle difference, if their code relies on execution in the wrong context.

Nevertheless both of these methods execute the file synchronously ... that means, the parent script will wait until the child has finished and continue its own execution afterwards. This may also produce some unexpected behavior, if the own code itself starts long running child instances the wrong way. I've seen systems, were the startup process was never finished, because a script with an endless loop (the loop was intended indeed and not the basic error) was started at the last line of a script. Such an endless running startup process is sometimes the reason of other issues.

That's why I decided to use another method to call the own code ... it will run in a detached process started with an one-second delay after the startup instance (remember, it's executing the rc.S file from /etc/init.d) has finished. If someone makes a mistake within the own code and starts child processes synchronously (which keeps the parent instance running), it doesn't matter anymore.

---

-EDIT: Oops ... looks like you've used the period in front of the file name. The e-mail from this board with the "new posting" notification did not show it. After this change the second aspect from above isn't important anymore, as long as you don't start synchronous childs. Some people were very astonished, that their devices did not show correct power-management data ... it was simply caused by such a mistake, where they started synchronous childs with loops and the startup process did never reach the code after calling /var/flash/debug.cfg, were the power-management tables would have been loaded into the monitor driver.

After this change my warning in the first aspect gets more important, because an attempt to call a "file" without execute flag set (as the line without period would do) should fail and this could have been the hurdle, why the double execution hasn't taken place so far (the code without period would create the node, but never call the file really - you've to call "chmod" first, if you want to execute it by name).

 

[koyaanisqatsi]

The little difference...

Moins

When using a dot, the nearest explanation to it is an "Include" using in other languages.

So a simple working example...
include (no special rights or SHEBANG and no filename extension)

# This is an include for sh
# No SHEBANG needed
# Also no chmod +x
# And of course and always: No filename extension
# Only type: . include (it seems nothing happens)
# Or: . include hello (ah, better)
# Then type: printf 'Hello world\n'
# Or: printf 'Hello world\n' '...and\n' 'Made my day\n'
# ...its in your SHELL environment, type: set
# ...to see it and type: unset text ; unset printf
# ...for removing it from environment

# Variable
text="hello world"

# Function
printf() {
 echo -ne ${@}
 echo -ne "DEBUG: RC: ${?} COUNT: ${#}\n"
}

if [ ${#} -ne 0 ]
then
 # Functioncall
 printf ${@}
fi

#EOF

@PeterPawn: Schau mal mit set nach, da hab ich das her mit dem Leerzeichen zwischen Funktionsnamen und den runden Klammern.

 

[palast]

Ich habe zur Zeit als inaktives System die 24 und als aktives System die 30 in meiner 7490.
Bisher habe ich das Update auf die 50 vor mir hergeschoben, möchte jetzt aber doch mal mich der Sache widmen, weil ich ein par ruhige Tage habe.

Ich bin etwas vorsichtig bei der Herangehensweise, weil ich leider ohne Auffangnetz arbeiten muss. Der Rettungsweg über das Recovery-File von AVM ist mir leider versperrt, da ich eine Providerbox habe, bei der das Recovery nicht funktioniert.

Daher meine Frage:
Sind irgendwelche Probleme bekannt, die bei der automatischen Vorgehensweise über das Script und den Update-Parameter bei meiner Konstellation auftreten könnten?

 

[Massa]

Hallo zusammen,

Zuerst einmal möchte ich mich gleich entschuldigen wenn ich etwas hier im Thread überlesen habe und deswgen "blöde" Fragen stelle..
...ich habe mir "nur" die ersten 8 Seiten detaillierter, den Rest nur noch übersichtsmässig angeschaut - deswegen ist es sehr gut möglich, dass mir etwas durch die Lappen gegangen ist

Ich wollte (endlich) etwas Zeit investieren und das modfs - Script auf meine 3370 bringen (für leichten Dual-Boot).
Installiert ist dort (immer noch) eine gefreezte FW6.20 - jegliche neuere gefreezte Versionen führen zu einem Bootloop, dem ich endlich auf den Grund gehen will!

Zuerst habe ich ShellInABox installiert, das funktionierte auf Anhieb und funktioniert auch prima :rock:

Dann habe ich das modfs-Paket (das mit 7490 im Namen) auf die Box gebracht, ausgepackt und ausgeführt - nach mehreren Versuchen (Einzelheiten sind unwichtig), bin ich soweit, dass wohl ein paar Links für die 3370 fehlen bzw. Aufrufe falsch sind?!

Hier die relevanten Ausgaben:

Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.
Dafür stehen drei Möglichkeiten zur Auswahl:


a - das root-Dateisystem des laufenden Systems benutzen
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
q - keine Änderungen vornehmen


Bitte den Buchstaben des gewünschten Punktes eingeben : a


Als Quelle wird das root-Dateisystem des laufenden Systems verwendet, damit werden auch bereits vorhandene
Änderungen automatisch in das neue System übernommen. Für das Vermeiden doppelter Änderungen sind die
jeweiligen Skripte verantwortlich.


Es gibt mehrere potentielle Arbeitsverzeichnisse auf verschiedenen Datenträgern bzw.
in verschiedenen Partitionen.


Die folgenden Arbeitsverzeichnisse stehen zur Auswahl:


a - /dev/sda1 (Dateisystem vfat) eingebunden unter /var/media/ftp/UStor01 - freier Speicherplatz: 10 GB
b - /dev/sda5 (Dateisystem ext3) eingebunden unter /var/media/ftp/UStor05 - freier Speicherplatz: 4119 MB
q - keines dieser Verzeichnisse soll verwendet werden


Bitte den Buchstaben des gewünschten Arbeitsverzeichnisses eingeben : b


Entpacken des root-Dateisystem für die Modifikationen ... Fehler
Die getroffene Auswahl ist ungültig.

Ich habe dann im Script die Funktion "spinner" angepasst, so dass ich Error-Logging dafür bekomme
Dort sehe ich dann:

./modfs: line 2901: /usr/sbin/blkid: not found
./modfs: line 2901: /var/mod/bin/175/unsquashfs: not found

Und da hat er natürlich Recht, es müsste /usr/sbin/blkid-ng und /var/mod/bin/175/unsquashfs3 (glaube ich) heissen...

Also scheint er die sq_version nicht richtig zu erkennen; müsste irgendwo in detect_image_filesystem gemacht werden - bei der Erkennung blicke ich aber nicht so richtig durch... :noidea:

 

[PeterPawn]

Auf die Schnelle und aus dem Kopf ... wenn da kein blkid drin ist im Image, vermute ich mal, Du hast es beim Erstellen der Freetz-Version nicht eingebaut, das ist schon per se seit einiger Zeit eine schlechte Idee, weil der Mount-Prozess von AVM das blkid braucht, damit er das automatische Laden der Filesystem-Treiber nutzen kann (in einem anderen Thread ausdiskutiert).

Also solltest Du zumindest für die Dauer des modfs-Laufes irgendwie eine passende Busybox (ggf. sogar die originale von AVM) per bind-Mount aktivieren und bei künftigen Änderungen darauf achten, daß da immer ein korrektes blkid-Programm vorhanden ist. Keine Ahnung, ob und wenn ja wie sich die Ausgabe von blkid-ng von der von blkid unterscheidet, auch bei den Optionen wäre das wichtig, daß das blkid-Applet die "-O"-Option kennt, wenn man für 06.50 den richtigen Filesystem-Typ ab Offset 256 feststellen will.

Ansonsten mußt Du noch für Dein Modell unter der HWRevision im "bin"-Unterverzeichnis von modfs das passenden Unterverzeichnis erzeugen, notfalls benennst Du einfach eines der anderen um, denn das sind alles nur Symlinks auf VR9. Dann sollte auch das unsquashfs gefunden werden.

Am besten besorgst Du Dir erst mal noch die Firmware-Version von AVM und extrahierst dort die Busybox, mit der könnte es dann schon klappen. Ob Dir die Busybox aus dem /var/custom/bin-Verzeichnis helfen könnte (wenn Du modfs-Starter verwendet hast), könntest Du auch probieren, dann müßtest Du halt den Pfad/Aufruf für blkid entsprechend anpassen ... wenn ich das wie üblich (und für mich richtig) gemacht habe, gibt es nur eine einzelne Zuweisung zu einer Variablen mit dem Namen von blkid ... ansonsten eben alle Stellen ändern. Aber wie gesagt, vorher mit der Busybox erst mal probieren ... ein "/var/custom/bin/busybox blkid" sollte da schon ausreichend sein.
EDIT: Stelle gefunden (ich vergesse immer noch, daß ich das Zeug bei GitHub auch ohne Terminal erreiche): https://github.com/PeterPawn/YourFritz/blob/master/modfs/modfs#L72
EDIT2: Ich sehe gerade, daß die 3370 ja bei mir schon unterstützt ist, dann vergiß das mit dem Symlink, dann muß das Skript nur die richtige SquashFS-Version erkennen können und dazu braucht es "blkid".

PS: Wenn Du irgendwann aufgegeben hast beim Lesen, hast Du von der Debug-Ausgabe vielleicht nichts mitbekommen, die habe ich in #1 aber m.W. verlinkt. Die Änderung an "spinner" ist zwar auch machbar, aber die Debug-Ausgabe sollte auch ausreichend sein für die Diagnose, warum das Entpacken nicht funktioniert.

---

-

Der Rettungsweg über das Recovery-File von AVM ist mir leider versperrt, da ich eine Providerbox habe, bei der das Recovery nicht funktioniert.

Zum Rest der Fragen ist meine Meinung ohnehin nicht entscheidend, aber hier würde ich Dir einfach vorschlagen, daß Du die provider-additive.tar einfach schon mal aus reiner Vorsicht sicherst:

mkconfigfile /var/tmp/additive.tar 29
cat /var/tmp/additive.tar >/var/media/flash/[I]irgendwas/[/I]

und gut ist's. Das sollte das gesamte Archiv mit den spezifischen Einstellungen des Providers irgendwo im NAND-Flash sichern, von wo es per NAS ausgelesen (und angesehen) werden kann. Dann noch die Variable "provider" im Urlader-Environment gelöscht und man kann jederzeit auch AVM-Recovery auf die Box ansetzen ... was man aber im Prinzip nie braucht, wenn in der anderen Partition noch ein funktionierendes System liegt (das beim Update ja nicht überschrieben wird), auf das man einfach per EVA umschalten kann (ist derselbe Aufwand wie bei Recovery, notfalls kann man sogar das Recovery-Programm benutzen, um die Box in EVA festzuhalten, falls man das sonst nicht hinkriegt - habe ich im 06.50-Thread zur 7490 irgendwo am Ende eines Beitrags zu "provider additive" mal "angemerkt").

Diese "provider additive"-Konfigurationen sind etwas überbewertet, was ihre Komplexität und den Umgang damit angeht. Fertigt man sich rechtzeitig ein Backup von TFFS/29 an, kann man m.W. (ich habe selbst keine solche Box, so daß ich mich auf Berichte anderer verlassen muß beim Ergebnis) genau dieselbe Konfiguration wiederherstellen, wenn man den Inhalt wieder ins TFFS bringt und die "provider"-Variable erneut setzt.

 

[Massa]

Auf die Schnelle und aus dem Kopf ... wenn da kein blkid drin ist im Image, vermute ich mal, Du hast es beim Erstellen der Freetz-Version nicht eingebaut, das ist schon per se seit einiger Zeit eine schlechte Idee, weil der Mount-Prozess von AVM das blkid braucht, damit er das automatische Laden der Filesystem-Treiber nutzen kann (in einem anderen Thread ausdiskutiert).

Das blkid ist auch drin - nur unter "/sbin/" statt unter "/usr/sbin"

# /sbin/blkid --help                                                                                           
BusyBox v1.22.1 (2014-12-07 23:57:15 CET) multi-call binary.

Sollte passend sein, oder? Ich habe das mal im modfs-Script geändert...

Der Aufruf von "/usr/sbin/blkid-ng --help" liefert übrigens das hier:

blkid from util-linux-ng 2.17.2 (libblkid 2.17.0, 22-Mar-2010)                                                                       
Usage:                                                                                                                               
  blkid -L <label> | -U <uuid>                                                                                                       
                                                                                                                                     
  blkid [-c <file>] [-ghlLv] [-o format] [-s <tag>]                                                                                  
        [-t <token>] [-w <file>] [dev ...]                                                                                           
                                                                                                                                     
  blkid -p [-O <offset>] [-S <size>] [-o format] <dev> [dev ...]                                                                     
                                                                                                                                     
Options:                                                                                                                             
  -c <file>   cache file (default: /etc/blkid.tab, /dev/null = none)                                                                 
  -h          print this usage message and exit                                                                                      
  -g          garbage collect the blkid cache                                                                                        
  -o <format> output format; can be one of:                                                                                          
              value, device, list, udev or full; (default: full)                                                                     
  -s <tag>    show specified tag(s) (default show all tags)                                                                          
  -t <token>  find device with a specific token (NAME=value pair)                                                                    
  -l          lookup the the first device with arguments specified by -t                                                             
  -L <label>  convert LABEL to device name                                                                                           
  -U <uuid>   convert UUID to device name                                                                                            
  -v          print version and exit                                                                                                 
  -w <file>   write cache to different file (/dev/null = no write)                                                                   
  <dev>       specify device(s) to probe (default: all devices)                                                                      
                                                                                                                                     
Low-level probing options:                                                                                                           
  -p          switch to low-level mode (bypass cache)                                                                                
  -S <bytes>  overwrite device size                                                                                                  
  -O <bytes>  probe at the given offset                                                                                              
  -u <list>   filter by "usage" (e.g. -u filesystem,raid)

EDIT2: Ich sehe gerade, daß die 3370 ja bei mir schon unterstützt ist, dann vergiß das mit dem Symlink, dann muß das Skript nur die richtige SquashFS-Version erkennen können und dazu braucht es "blkid".

Nach obiger Änderung meckert der "spinner" immer noch, dass er unsquashfs (ohne angehängte Nummer) nicht findet:

./modfs: line 2901: /var/mod/bin/175/unsquashfs: not found

Und das trotz "vorhandenem blkid"...

PS: Wenn Du irgendwann aufgegeben hast beim Lesen, hast Du von der Debug-Ausgabe vielleicht nichts mitbekommen, die habe ich in #1 aber m.W. verlinkt. Die Änderung an "spinner" ist zwar auch machbar, aber die Debug-Ausgabe sollte auch ausreichend sein für die Diagnose, warum das Entpacken nicht funktioniert.

Du meinst "shell -x"?
Damit erkennt man nur, dass das Kommando schief läuft und dass es einen Fehlercode zurückliefert.
Erst durch Umleitung der Fehlerausgaben sieht man mehr...

...aber warum er jetzt trotz korrekter sq_version (3) noch immer ein unsquashfs ohne angehängte Nummer sucht, verstehe ich nicht...

[EDIT]
Ich habe jetzt einfach mal

cd bin/VR9; ln -s unsquashfs3 unsquashfs

gemacht und dann modfs nochmal ausgeführt.
Jetzt ist es komplett durchgelaufen - hoffe ich.
Zumindest hat er meine ShellInABox geschlossen und auch die Internetverbindung war weg (Router-Reboot wurde aber glaube ich nicht gemacht).
Nachdem ich mich wieder einloggen konnte, war /var/mod wieder ohne modfs - ist das korrekt so?

 

[PeterPawn]

Du meinst "shell -x"?

Eher nicht ... sondern das hier: http://www.ip-phone-forum.de/showthread.php?t=273304&p=2106386&viewfull=1#post2106386

Dann muß man auch nicht mehr raten, woran die Format-Erkennung für das SquashFS-Image scheitert.

 

[Massa]

O.K. - und welche Zeilen aus dem Ringbuffer-Logging würden jetzt helfen?
Ich kann da nicht mehr erkennen als vorher.. (nochmal ausgeführt mit Debugging und "/sbin/blkid")

Ich habe das Logging mal in eine Datei gepackt und hier angehängt - sensible Informationen konnte ich nicht entdecken!?

 

[PeterPawn]

Ich kann da nicht mehr erkennen als vorher.. (nochmal ausgeführt mit Debugging und "/sbin/blkid")

Man sieht zumindest schon mal, daß die Erkennung des Dateisystemtyps für die Image-Datei daneben geht:

2016-01-05 20:03:13.427 - detect_image_filesystem: src=/wrapper/filesystem_core.squashfs, fstype=, rc=222

Schaut man jetzt in das Skript, sieht man da folgende Stelle, wo der Returncode 222 gesetzt wird: https://github.com/PeterPawn/YourFritz/blob/master/modfs/modfs#L509

Also geht offenbar eines der blkid-Kommandos schief ... da dieses Kommando je nach Busybox-Optionen unterschiedlich ausfallen kann, mußt Du einfach mal die Kommandos einzeln testen, welches da nun schief geht.

Wenn da also das Kommando

blkid -o value -s TYPE -p [I]squashfs_imagefile[/I]

problemlos läuft, sollte es auch funktionieren ... wenn nicht, stimmt etwas mit dem Kommando nicht. Erwartet wird ein Returncode von 0 und die Ausgabe des Dateisystemtyps - ich habe natürlich nie mit einer Busybox getestet, die schon beim Erstellen eines Freetz-Images geändert wurde.

Die Möglichkeit des Testens mit "Offset" spielt bei Deiner 3370 ja noch keine Rolle, denn da gibt es ja wohl noch keine Version mit SquashFS4, soweit ich das sehe.

Ansonsten braucht es ein "blkid" mit den richtigen Optionen, meinen Vorschlag, es mit der aus /var/custom zu probieren, hast Du entweder überlesen oder es funktioniert nicht und Du hast versäumt, das zu schreiben. Wenn das Format der Ausgabe bei der Version aus "util-linux" auch paßt (das ist auch bei AVM teilweise in Benutzung), dann kann man auch das nehmen ... aber eine Möglichkeit muß funktionieren. Ohne Kenntnis des Dateisystemtyps müßte man auf die alte Version ohne SquashFS4-Unterstützung zurückgreifen, aber die habe ich vom Server gelöscht, weil es immer zu Verwirrungen kam.

Fazit: Dein blkid-Kommando funktioniert immer noch nicht wie erwartet - der Rest sollten Folgefehler sein.

PS: In der Datei steht logischerweise nichts an sensiblen Informationen ... die habe ich ja genau für solche Veröffentlichung gebaut und ich wäre sicherlich der vorletzte, der sich das nicht genau überlegt, was er in so eine Datei schreibt.

PPS: Den dringenden Hinweis zur Verwendung eines nativen Dateisystems auf dem Stick (besonders bei Boxen mit weniger Hauptspeicher) hast Du ja sicherlich auch gelesen ... wenn da das Loopback-Image aus der Kiste geholt werden muß für die Speicherung der Arbeitsdateien, ist das vermutlich spätestens beim Packen dann wieder zum Scheitern verurteilt ... aber bis dahin ist es ja vielleicht ohnehin noch ein Stück des Weges.

 

[Massa]

Wenn da also das Kommando

blkid -o value -s TYPE -p [I]squashfs_imagefile[/I]

problemlos läuft, sollte es auch funktionieren ... wenn nicht, stimmt etwas mit dem Kommando nicht. Erwartet wird ein Returncode von 0 und die Ausgabe des Dateisystemtyps - ich habe natürlich nie mit einer Busybox getestet, die schon beim Erstellen eines Freetz-Images geändert wurde.

das blkid der freetz busybox-Version liefert den returncode 0, aber keine Ausgabe des Dateisystemtyps.
Das blkid-ng (linux unix-tools) liefert returncode 0 und als Ausgabe "squashfs" - also alles korrekt?!
Das blkid des busybox aus "/var/custom" (ich habe da einfach einen symlink "ln -s /var/custom/bin/busybox /var/mod/usr/sbin/blkid" gemacht) liefert folgendes:

root@FritzBox:/var/mod# ./usr/sbin/blkid -o value -s TYPE -p /wrapper/filesystem_core.squashfs                                                         
usr/sbin/blkid: invalid option -- o
BusyBox v1.23.2 (2015-12-15 22:04:12 CET) multi-call binary.

Usage: blkid [-O offset] [BLOCKDEV]...


Print UUIDs of given/all filesystems
        -O      Probe at the given offset

Also habe ich jetzt die Ausführung von modfs dem blkid-ng versucht.
Da läuft auch alles weiter ohne Fehlermeldung - allerdings hängt sich die Box beim Einpacken auf bzw. resettet sich.
Zumindest ist das die letzte Ausgabe des Scripts und nachdem ich wieder ein Zugriff auf die Box habe, ist "/var/mod" wieder ohne modfs und der Ringbuffer ist (natürlich) auch wieder leer

Vielleicht hängt es mit fehlendem Speicher zusammen - bzw. mit dem folgenden zusammen?

PPS: Den dringenden Hinweis zur Verwendung eines nativen Dateisystems auf dem Stick (besonders bei Boxen mit weniger Hauptspeicher) hast Du ja sicherlich auch gelesen ... wenn da das Loopback-Image aus der Kiste geholt werden muß für die Speicherung der Arbeitsdateien, ist das vermutlich spätestens beim Packen dann wieder zum Scheitern verurteilt ... aber bis dahin ist es ja vielleicht ohnehin noch ein Stück des Weges.

Ist ext3 kein natives Dateisystem?
Oder liegt es daran, dass der Stick zwei Partitionen hat - eine mit fat32 und eine mit ext3?


Seufz, ich suche doch eigentlich nur nach einer bequemen Möglichkeit herauszufinden, warum alle meine auf 6.30 basierenden freetz-Images eine bootloop erzeugen - d.h. nach einer Möglichkeit, nach erfolglosem Updateversuch ohne AVM Recovery auf ein unveränderte Box zuzugreifen, um irgendwelche Log-Informationen abgreifen zu können.

 

[PeterPawn]

Vielleicht hängt es mit fehlendem Speicher zusammen - bzw. mit dem folgenden zusammen?

Ziemlich sicher ...

Ist ext3 kein natives Dateisystem?

Doch, schon ... aber wählst Du denn auch die richtige Partition aus bei der Abfrage? Das sollte sich wieder in der Debug-Ausgabe finden lassen ... welche Filesysteme modfs als "native" ansieht, ist in einer Zeile am Beginn definiert und da sollte ext3 dabei sein.

Wenn dann noch vorher der "prepare_fwupgrade"-Aufruf erfolgt (genaueres sollte in einem der in #1 verlinkten Beiträge zu finden sein), müßte es eigentlich auch auf der 3370 problemlos funktionieren.

Das blkid-Applet der Busybox kennt also offenbar die "o"-Option zur Auswahl des Ausgabeformats nicht ... nun macht es aber auch gar keinen Spaß, sämtliche Möglichkeiten von "blkid"-Kommandos zu sammeln und alle richtig zu behandeln. Ich habe mich offenbar geirrt und baue im Skript auf eine Version, die bei AVM in der Firmware (bisher noch bei jeder Box, die das probiert hat) zu finden ist - in gewisser Weise zu finden sein muß, denn AVM verwendet es - wie geschrieben - selbst, um beim Mounten das richtige Dateisystem anzugeben und die Filesystem-Module automatisch zu laden. Zwar ist das schon eine spezielle Form des Aufrufs, die ich da verwende, aber in der "util-linux"-Version ist diese Option offensichtlich enthalten. Ich habe nie behauptet, daß modfs auch aus einer Freetz-Umgebung mit total verbogenen Utilities funktionieren würde.

Auf der anderen Seite werde ich immer wieder gefragt, warum ich z.B. solche Geschichten wie "which" nicht einfach voraussetze und das lieber in Skript-Code nachbilde, wenn es nicht existiert. Diese ganzen unterschiedlichen "Dialekte" bei ein und demselben Kommando oder die generelle Unsicherheit, ob ein bestimmtes Kommando in so einem "embedded environment" überhaupt existiert (auch das ist ja Schwankungen unterworfen, selbst bei AVM), machen das zu einem ziemlich witzlosen Unterfangen, da jeden Fall abdecken zu wollen. Bei der Dateisystem-Erkennung sehe ich aber keine (Skript-)Alternative, die ein einheitliches Vorgehen ermöglichen würde, schon die Fähigkeiten der libblkid.so sind davon abhängig, was man zur Compile-Time einschließt. Solange das von einem AVM-Image aus funktioniert, werde ich wohl auch nicht daran herumbasteln - wo wollte man da wieder die Grenze ziehen? Die Tabelle in #1 gilt also für AVM-Firmware und nicht für bereits durch Freetz modifizierte ... das kann ich gerne noch einmal explizit in #1 vermerken, mehr aber auch nicht ... sorry.

 

[Gizmo_Ger]

Hallo,
bei mir läuft modfs zwar ohne sichtbaren Fehler durch, allerdings wird die debug.cfg beim nächsten Boot nicht berücksichtigt. Auch nachdem ich ein Recover auf 6.30 durchgeführt und mit entsprechendem modfs-Starter wieder eine Shell habe und auch hier modfs keinen Fehler anzeigt bleibt die debug.cfg unberücksichtigt. Ich habe eine schon vorhandene debug.cfg nach /var/flash kopiert und auch zu Testzwecken die LCR Testversion installiert. Die Einträge erfolgen ohne Probleme, aber kein Kommado wird ausgeführt. Ich habe einen weiteren Lauf des Skriptes veranlasst und mal ein Log erstellt. Was mich irritiert ist, dass es sowohl mit 6.30 als auch 6.50 nicht funktioniert. Das Skript lief vorher ohne Probleme durch. Anhänge lassen sich gerade nicht hinzufügen. Hole ich nach...
Update: Habe Variante b genommen und ein frisches Image vom AVM Server geladen und siehe da: es funktionierte. Vielen Dank für das Skript und deine Erläuterung. Zumindest wieder etwas dazu gelernt.

 

[PeterPawn]

@Gizmo_Ger:
Ich habe tatsächlich keine Ahnung, was ich mit dieser Fehlerbeschreibung (ist es überhaupt eine?) anfangen soll.

Auf der einen Seite könnte es sein, daß Du meine "Ausführungen" zu "debug.cfg vs. rc.user" nicht gelesen hast, auf der anderen Seite könntest Du auch nur nicht berücksichtigen, daß die TFFS-Dateien keine "richtigen" Files sind. Egal wie oft ich den Beitrag lese, es steht eigentlich nicht einmal da, daß es sich um eine 7490 handelt, das kann man (im Moment) nur indirekt daraus ableiten, daß Du etwas von einer 06.50 schreibst.

Nimm's mir nicht übel, aber da fehlt neben der Auflistung, was Du eigentlich wirklich machst, auch noch das von Dir erstellte Log-File ... wenn das allerdings eines von modfs sein sollte, braucht man das hier ohnehin nicht. Da reicht es vollkommen aus, wenn Du mit "cat /etc/init.d/rc.tail.sh" mal diese Datei anzeigen läßt. Wenn in der letzten Zeile das Kommando mit der "rc.user" steht, hast Du ein Problem mit dem Verständnis, wie das funktioniert.

Wenn man nämlich eine reguläre Datei "debug.cfg" unter /var/flash erstellt, ist das lange nicht dasselbe wie ein TFFS-Node. Da das bei der 7490 eben eine yaffs2-Partition von 2 MB unter /var/flash ist, funktioniert das sogar, das nach dem Neustart der Box dort wieder auszulesen. Das in der rc.tail.sh hinzugefügte Kommando interessiert sich aber nicht für das yaffs2 unter /var/flash, das "schaut" direkt ins TFFS.

Also bitte noch einmal langsam, erst noch einmal lesen, dann die eigenen Kommandos prüfen (u.a. auch die rc.tail.sh, wie oben geschrieben) und dann - wenn es immer noch ein Problem ist - gerne noch einmal genauer beschreiben, was da nicht funktioniert. Mit "modfs" hat das aber (zumindest nach dem, was ich bisher verstanden habe) nichts mehr zu tun.

 

[Gizmo_Ger]

@PeterPawn: Erstmal vielen Dank für deinen Post und deine Ausführungen. Ich gelobe Besserung und werde nochmal alles von vorne bis hinten durchlesen. In meiner Signatur sind einige Details zu meiner Hardware vermerkt.

 

[eisbaerin]

@PeterPawn: Da du in dem anderen Thema die FB7412 wieder ansprachst:

Wäre es möglich das modfs für die FB7412 auf der FB7490 auszuführen (natürlich ohne installieren), das .image runterzuladen und dann wie ein normales Update in die FB7412 einzuspielen?