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

Kennt es sehr wohl, es ist bloß per Default ausgeschaltet, da weder von AVM noch von Freetz benötigt wird.
OK, das ist gut zu wissen. Ich hatte angenommen, dass Freetz möglichst kompatibel zu AVM ist und soweit möglich die, die gleichen Settings verwendet. D.h. ich muss mir da etwas basteln um keinen Schiffbruch zu erleiden :(
Oder gibt es eine einfache Möglichkeit, die AVM Settlings zu übernehmen?
 
@PeterPawn
Code:
7362SL:$(pwd)# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                49152     18268     30884  37% /wrapper
[COLOR="#FF0000"]devtmpfs                 53608        52     53556   0% /wrapper/dev[/COLOR]
/dev/loop0               15808     15808         0 100% /
devtmpfs                 53608        52     53556   0% /dev
tmpfs                    53760      2448     51312   5% /var
/dev/mtdblock4            2048      1124       924  55% /var/flash
/var/dev/nand            22528     13468      9060  60% /var/media/ftp
7362SL:$(pwd)# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "reserved-kernel"
mtd1: 03000000 00020000 "reserved-filesystem"
mtd2: 00400000 00020000 "kernel"
mtd3: 03000000 00020000 "filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 01600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"
7362SL:$(pwd)# cat /proc/partitions
major minor  #blocks  name

   7        0      15804 loop0
  31        0       4096 mtdblock0
  31        1      49152 mtdblock1
  31        2       4096 mtdblock2
  31        3      49152 mtdblock3
  31        4       2048 mtdblock4
  31        5      22528 mtdblock5
  31        6        256 mtdblock6
  31        7        384 mtdblock7
  31        8        384 mtdblock8
7362SL:$(pwd)#
Die rote Zeile ist neu, die gab es früher nicht. Ist das Normal?


Das habe ich probiert. Sind die Befehle richtig oder fehlen da noch Parameter?
Code:
7362SL:$(pwd)# [B]umount /var/flash[/B]                                                                                                        
umount: can't umount /var/flash: Device or resource busy

7362SL:$(pwd)# [B]umount /dev/mtdblock4[/B]                                                                                                    
umount: can't umount /var/flash: Device or resource busy                                                                                                                             

7362SL:$(pwd)# [B]update_kernel -o /dev/mtd4[/B]
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x200000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
Was kann ich noch machen?
Bitte, bitte hilf mir, ich kann doch fast nur Windows und das auch ganz schlecht ;)
 
Zuletzt bearbeitet:
@eisbaerin:
Das war soweit eigentlich richtig ... wenn nach einem Neustart jetzt immer noch die alten "regular files" in /var/flash stehen sollten (ob das Löschen auch dann geht, wenn da eigentlich gerade ein yaffs2 gemountet ist, weiß ich nicht), dann beende mal "aha", bevor Du das "umount" versuchst. Ich bin etwas verblüfft ob des "busy" beim Dismounten ... der ctlmgr dürfte das eigentlich nicht sein. Wer es wirklich ist, sollte ein "lsof | grep flash" eigentlich zeigen - aber ich tippe auf "aha", der hatte jedenfalls früher mal die ganze Zeit die Finger auf der "ahanet.cfg".

Das mit dem devtmpfs ist jedenfalls in Ordnung unter einem Kernel ab 3.10.73 ... das wird per bind-Mount nach /dev gespiegelt.
 
Erst mal recht herzlichen Dank!
wenn nach einem Neustart jetzt immer noch die alten "regular files" in /var/flash stehen sollten
Ja tun sie.

dann beende mal "aha",
Genau daran lag es:
Code:
# [B]busybox lsof | grep flash[/B]                                                                                                        
aha       1223      root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   
upper_con 1223 1225 root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   
dectule   1223 1226 root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   
clt:upnp  1223 1227 root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   
clt:upnp  1223 1228 root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   
sRX       1223 1229 root    9r      REG       31,4       24    304 /var/flash/ahanet.cfg                                   

# [B]kill 1223[/B]                                                                                                                
# [AHA] SIGTERM received: terminate AHA                                                                                    

# [B]busybox lsof | grep flash[/B]                                                                                                        

# [B]umount /var/flash[/B]                                                                                                        

# [B]update_kernel -o /dev/mtd4[/B]                                                                                               
info 0x0                                                                                                                   
{mtd_info} type 0x4                                                                                                        
{mtd_info} size 0x200000                                                                                                   
{mtd_info} erasesize 0x20000                                                                                               
{mtd_info} writesize 0x800                                                                                                 
{mtd_info} oobsize 0x40                                                                                                    
[main] exit error 0 

# [B]ls -la /var/flash[/B]                                                                                                        
drwxr-xr-x    2 root     root            40 Jan  1  1970 .                                                                 
drwxr-x---   15 root     root          1080 Mar  6 06:16 ..
aber egal was ich dann mache (reboot, PoR, recover), es ändert sich nichts.
Das habe ich auch in mehreren FW probiert.

Ich bin mir jetzt nicht mehr so sicher, ob das wirklich anders seien soll.
Hast du mal in der FW nachgesehen?

Hast du noch Ideen, was ich noch machen könnte?
 
Hallo Eisbaerin,
Frage: Hast Du flash_eraseall schon getestet ?

Das Löschen einer MTD-Partition kann per
Code:
# ./busybox flash_eraseall /dev/mtdblock4
durchgeführt werden.

Das yaffs2-Filesystem wird eigentlich automatisch beim ersten mounten erstellt:
Code:
 # mount -t yaffs2 /dev/mtdblock4 /var/flash

Kontrolle:
Code:
# mount | grep mtdblock4
/dev/mtdblock4 on /var/flash type yaffs2 (rw,sync,relatime)
#

LG Riverhopper
 
Das verstehe ich jetzt aber nicht ... wenn Du nach dem Löschen von MTD4 (ich gehe mal davon aus, daß das funktioniert hat, kannst Du jederzeit durch ein "mount -t yaffs2 /dev/mtdblock4 /var/flash" nach dem Löschen verifizieren, dann müßte das gemountete Dateisystem ebenfalls leer sein und zur Kontrolle kann man ja mal irgendwas in der Richtung "echo remove_me >/var/flash/remove_me.txt" machen, das sollte nach dem Neustart noch als "/var/flash/remove_me.txt" weiterbestehen) einen Neustart machst, dann wären die Einstellungen ja leer und die Box müßte (wenn sie jetzt nicht auf die Einstellungen aus dem TFFS zurückgreift, wofür wiederum die char-Devices gebraucht würden) mit dem Einstellungsassistenten starten. Wenn das "nichts" bewirkt, funktioniert offenbar das Löschen von "config" eben doch nicht ... vielleicht versuchst Du es ja mal mit dem "flash_eraseall"-Applet einer Busybox oder sogar mit "echo mtd 4 erase all force >/proc/mtd" genauso löschen, wie es die Firmware beim Initialisieren nach Recovery macht (findet man in S01-head).

Es gibt zwar Mechanismen zum "Konvertieren" (am Ende eher ein Umkopieren und Verlinken (aber mit "hard links") der Dateien) von Einstellungen, ich glaube aber nicht, daß das bei der 7362SL anders abläuft als bei der 7490 (und anderen Modellen), denn diese Dateien in etc/init.d sind doch recht stabil über fast alle Modelle. Vergleiche doch einfach mal die S01-head einer 7362SL mit der einer 7490 ... gibt es da keine Unterschiede, kann ich in der 7490 mal nachsehen.

Wenn dieser Mechanismus in der S01-head verwendet wird, sollte aber auch jeder Eintrag in /var/flash nur noch ein Hardlink auf eine Datei gleichen Namens in /var/flash/data/ sein ... daher glaube ich nicht so richtig daran, daß das bei Dir tatsächlich irgendwie beabsichtigt ist - jedenfalls dann nicht, wenn die Dateien (S01-head) auf beiden Boxen identisch sein sollten.

Ich habe mich auch geirrt, was das Löschen von "config" angeht:
Code:
[COLOR="#FF0000"]if [ -n "${mtd_config}" ] && [ -n "${Recover_was_here}" ] ; then
[/COLOR]del_mtd_config=${mtd_config#mtd}
del_mtd_config=${del_mtd_config%:*}
## erase config (formatting) due to preceding recover
config_erasestring="mtd ${del_mtd_config} erase all"
## force erasing configspace?
case ${Recover_was_here} in
1|2) # [1:ar7man 2:recover 3:factorydef]
config_erasestring="${config_erasestring} force"
;;
*)
;;
esac
echo "[config-space/Recover] config erasing start ... (${config_erasestring})" > /dev/console
echo "${config_erasestring}" > /proc/mtd
echo "[config-space/Recover] config erasing ... done." > /dev/console
fi
Danach sollte ja die "config"-Partition bei jedem Recovery (wegen des "recovered=2" in "firmware_info") ohnehin gelöscht werden, damit wären dann auch die in regulären Dateien im yaffs2 gespeicherten Einstellungen weg. Der Unterschied zwischen Recovery und FactoryReset oben (bei 1 oder 2 wird "force" verwendet, bei "3" (das wird von /bin/setfactorydefaults eingetragen) hingegen nicht) ist mir aber auch ohne Blick in die Quellen der MTD-Verwaltung nicht geläufig ... aber auch hier gilt ja eigentlich, daß nach Werksreset (auf der Basis von "recovered=3" in "firmware_info") jeder Inhalt von "config" entsorgt werden müßte (halt ohne "force"). Das war mir irgendwie wieder entfallen ... aber es macht die Standhaftigkeit dieser (regulären) Dateien bei Dir dann ja noch merkwürdiger.
 
Zuletzt bearbeitet:
Frage: Hast Du flash_eraseall schon getestet ?
Jetzt ja. ;)
Code:
7362SL:$(pwd)# busybox1.24.1PeterPawnBE flash_eraseall /dev/mtdblock4
flash_eraseall: /dev/mtdblock4: not a char device
Danke auch dir fürs Helfen.


Bei "echo mtd 4 erase all force >/proc/mtd" erhalte ich keine Meldung.
Aber df und ls zeigen alles noch:
 
Zuletzt bearbeitet:
Du machst das aber schon auf die ausgehangene Partition, oder?

Bei "flash_eraseall" will er ein char-Device sehen, das wäre dann entsprechend /dev/mtd4 anstelle von mtdblock4.
 
Du machst das aber schon auf die ausgehangene Partition, oder?
Ja, übrigens alles auf 06.20, da ich dort am schnellsten das telnet anschalten kann:
Code:
# umount /var/flash
#
# /var/media/ftp/busybox1.24.1PeterPawnBE flash_eraseall /dev/mtd4
Erasing 128 Kibyte @ 200000 - 100% complete.
Jetzt kommt es darauf an, was ich dann mache:
- PoR - die Konfig ist noch da, nur das telnet ist aus
- reboot - Konfig und telnet ist weg
Wieso dieser Unterschied? extra 2 mal getestet!
- recover - natürlich ist Konfig und telnet weg

Aber in allen 3 Fällen: Problem ist immer noch vorhanden.


Was ich noch getestet habe:
Code:
# mount | grep mtdblock4
/dev/mtdblock4 on /var/flash type yaffs2 (rw,sync,relatime)
#
# ls -la /var/flash/a*
-rw-r--r--    2 root     root            24 Jan  1  1970 /var/flash/aha.cfg
-rw-r--r--    2 root     root             0 Jan  1  1970 /var/flash/ahadect.cfg
-rw-r--r--    2 root     root             0 Jan  1  1970 /var/flash/ahaglobal.cfg
-rw-------    1 root     root             0 Mar  6 20:52 /var/flash/ahanet.cfg
-rw-r--r--    1 root     root            83 Mar  6 20:52 /var/flash/ahapushmail.cfg
-rw-r--r--    2 root     root             0 Jan  1  1970 /var/flash/ahastat.cfg
-rw-r--r--    2 root     root             0 Jan  1  1970 /var/flash/ahausr.cfg
-rw-r--r--    2 root     root         56209 Jan  1  1970 /var/flash/ar7.cfg
-rw-r--r--    2 root     root             0 Jan  1  1970 /var/flash/aura-usb
#
# rm /var/flash/*
rm: /var/flash/data: is a directory
rm: /var/flash/lost+found: is a directory
#
# ls -la /var/flash
drwxr-xr-x    1 root     root          2048 Mar  6 21:01 .
drwxr-x---   14 root     root          1000 Mar  6 20:54 ..
drwxr-xr-x    1 root     root          2048 Jan  1  1970 data
drwx------    1 root     root          2048 Jan  1  1970 lost+found
#
############In der GUI eine Sicherung gemacht############
#
# ls -la /var/flash
drwxr-xr-x    1 root     root          2048 Mar  6 21:02 .
drwxr-x---   14 root     root          1040 Mar  6 21:02 ..
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 226 Mar  6 21:02 ahausr.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 113 Mar  6 21:02 ar7.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243,  95 Mar  6 21:01 crash.log
drwxr-xr-x    1 root     root          2048 Jan  1  1970 data
drwx------    1 root     root          2048 Jan  1  1970 lost+found
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 119 Mar  6 21:02 tr069.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 120 Mar  6 21:02 user.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 121 Mar  6 21:02 userstat.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 114 Mar  6 21:02 voip.cfg
[COLOR="#FF0000"]c[/COLOR]rw-r--r--    1 root     root      243, 118 Mar  6 21:02 vpn.cfg
#
#########so, das sieht doch eigentlich sehr gut aus###############
#
# reboot
# killall: printserv: no process killed
rmmod: can't unload 'vfat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'fat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_cp437': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_iso8859_1': unknown symbol in module, or unknown parame
ter
rmmod: can't unload 'sd_mod': unknown symbol in module, or unknown parameter
rmmod: can't unload 'ext2': unknown symbol in module, or unknown parameter
rmmod: can't unload 'usb_storage': unknown symbol in module, or unknown paramete
r
rmmod: can't unload 'scsi_mod': unknown symbol in module, or unknown parameter
ls: /var/USB-proc-bus-usb-*: No such file or directory
[1658]++ ++ do internalflash 'prepare unmount'... ++ ++
[1658]++ ++ ...done ++ ++


Verbindung zu Host verloren.
Aber ihr werdet es ahnen: Auch kein Erfolg. Nach dem reboot sind selbst diese Dateien wieder ohne "c".

Was hat es eigentlich mit dem Pfad /var/flash/data auf sich?
Den gibt es weder auf meiner 7412 noch auf der 7490.
Wenn ich den weg lösche ist er nach dem reboot wieder da.
Wozu ist der da?

Ich habe da endlos weiter probiert (immer wenn ich nicht antworte bin ich am probieren):

Wenn ich nach dem oberen noch folgendes mache:
Code:
rm /var/flash/data/*
mknod /var/flash/data/ahausr.cfg c 243 226
mknod /var/flash/data/ar7.cfg c 243 113
mknod /var/flash/data/crash.[COLOR="#FF0000"]cfg[/COLOR] c 243 95
mknod /var/flash/data/tr069.cfg c 243 119
mknod /var/flash/data/user.cfg c 243 120
mknod /var/flash/data/userstat.cfg c 243 121
mknod /var/flash/data/voip.cfg c 243 114
mknod /var/flash/data/vpn.cfg c 243 118
mknod /var/flash/data/wlan.cfg c 243 115
Dann werden nach einem reboot wenigstens diese Dateien in /var/flash auch mit "c" angezeigt.
Und auch die /var/flash/crash.log obwohl ich mich ober verschrieben habe. Ok, das ist eine der wenigen Dateien, die immer mit "c" erscheint.

Hilft das weiter? Was kann ich jetzt noch machen?
Und natürlich immer ein großes Danke von mir!
 
Zuletzt bearbeitet:
Das mit der Existenz von "/var/flash/data" bei Dir ist mir neu und das ist ja tatsächlich der Punkt, an dem dieses "check_and_store_yaffs_to_tffs_node" in S01-head ansetzt.

So wie ich das beim Lesen interpretiere, werden da in die S01-head zwei Funktionen eingefügt:
Code:
########### prepare config on nand before accessing /var/flash anyway ############
#! /bin/sh
check_and_store_tffs_node_to_yaffs() {
[...]
}
check_and_store_yaffs_to_tffs_node() {
[...]
}
#########################################
## ADDITIONAL Config-space hosted on NAND
Das "Einfügen" aus einer anderen Quelle ist Spekulation, leite ich aus dem überflüssigen SheBang mitten in der Datei her und aus der Tatsache, daß die erste Funktion (tffs_node_to_yaffs) bei mir nicht aufgerufen wird in der S01-head ... auch wenn die restlichen Meldungen innerhalb der Datei das suggerieren wollen:
Code:
########### tffs node to yaffs ########
## echo "[COLOR="#FF0000"][tffs_node_to_yaffs] start.[/COLOR]"
## ls -al /var/flash
for conv_node in ${tffs_nodes_list} ; do
conv_node_id=${conv_node%%,*} # bis zum ersten komma
conv_node_name=${conv_node##*,} # ab dem letzten komma
[COLOR="#006400"]check_and_store_yaffs_to_tffs_node[/COLOR] ${conv_node_id} ${conv_node_name}
done
## ls -al /var/flash
## echo "[COLOR="#FF0000"][tffs_node_to_yaffs] done.[/COLOR]"
###########
, so wird doch nur der entgegengesetzte Weg (yaffs_to_tffs) aufgerufen, jedenfalls in der S01-head und nur dort stehen ja diiese internen Funktionen zur Verfügung.

Diese aufgerufene Funktion sieht dann so aus:
Code:
  check_and_store_yaffs_to_tffs_node() {
    local prefix=/var/flash
    local minor=$1
    local name=$2
    local major=`grep tffs /proc/devices`
    local tffs_major=${major%%tffs}
    local converted=""
    if [ -z "${tffs_major}" ] ; then echo "[yaffs_to_tffs_node] ERROR: can't get TFFS Major-ID"; fi
    if [ -z "$1" ] || [ -z "$2" ] ; then echo "Usage: check_and_store_yaffs_to_tffs_node 141 calllog" ; fi
    if [ "$minor" -lt "$((0x64))" ] || [ "$minor" -gt "$((0xFF))" ] ; then echo "[yaffs_to_tffs_node] ignoring TFFS Node (minor: $minor)" ; fi
    ################
    ## old location basedir
    if [ -d "${prefix}/data" ]; then
      echo "[yaffs_to_tffs_node] INFO: found basedir ${prefix}/data"
    fi
    ## new conversion of file to node needed?
    if [ ! -c "${prefix}/$name" ]; then
      if [ -f "${prefix}/data/${name}" ] ; then
        if ! checkempty ${prefix}/data/${name} ; then
          ## create node for new location (at first, remove hardlink at this place)
          rm ${prefix}/${name}
          mknod ${prefix}/${name} c ${tffs_major} ${minor} || echo "[yaffs_to_tffs_node] ERROR: can't create TFFS Device file ${name} (minor: $minor)"
          ## save data to new location
          cat ${prefix}/data/${name} >${prefix}/${name}
          ## remove regular file in 'old location basedir'
          rm ${prefix}/data/${name}
          echo "[yaffs_to_tffs_node] Regular file '${name}' converted to TFFS Device file ${name} (minor: $minor) and cleared"
          converted=yes
        else
          ## create node for new location (at first, remove hardlink at this place)
          rm ${prefix}/${name}
          mknod ${prefix}/${name} c ${tffs_major} ${minor} || echo "[yaffs_to_tffs_node] ERROR: can't create TFFS Device file ${name} (minor: $minor)"
          ## create empty file in new location
          cat /dev/null >${prefix}/${name}
          ## remove regular file in 'old location basedir'
          rm ${prefix}/data/${name}
          echo "[yaffs_to_tffs_node] Regular file '${name}' is empty, TFFS Device file ${name} (minor: $minor) cleared"
          converted=yes
        fi
      else
        echo "[yaffs_to_tffs_node] Regular file '${name}' already converted? (missing regular file and TFFS Device file ${name} (minor: $minor)) "
      fi
    fi
    ## file must be replaced by node file
    if [ -c "${prefix}/${name}" ] && [ ! -f "${prefix}/data/${name}" ] && [ "${converted}" == "yes" ]; then
      echo "[yaffs_to_tffs_node] Regular file '${name}' replaced by TFFS Device file ${name} (minor: $minor)"
    fi
  }
Das Spannende daran ist es aber, daß vor dieser Funktion noch ein paar weitere Schritte kommen, die eigentlich dazu führen müßten, daß es kein /var/flash/data-Verzeichnis gibt - jedenfalls sehe ich (bei der 7490, den Vergleich mit der Firmware der 7362SL mache bitte selbst) nicht, wo das Verzeichnis herkommen sollte, wenn der Ablauf der folgende ist:

1. der Inhalt der kompletten "config"-Partition wird gelöscht, wenn da "recovered=[0-9]" in "firmware_info" im Environment gefunden wurde

2. die Partition wird gemountet und dabei werden die yaffs2-Strukturen erstellt (hier müßte jetzt "data" erzeugt werden, wenn das irgendwie Sinn ergeben sollte) - nachdem die bei Dir ja gemountet ist, kann es auch nicht so richtig sein, daß dieses Mounten das Problem ist und sich unter /var/flash immer noch "tmpfs" finden läßt

3. es wird in "tffs_update_major_in_nodes" geprüft, ob sich die Major-ID des TFFS-Drivers (bei Dir wohl die 243, dem Listing nach zu urteilen) geändert hat ... wenn ja, werden die vorhandenen char-Devices (aus einem früheren Lauf der Box, denn nach Recovery oder Reset ist die Partition ja noch leer) gelöscht und mit der neuen Major-ID wieder angelegt - hier gibt es Potential für ein Problem, wenn "tffs_major" nicht gesetzt sein sollte, weil zwar eine entsprechende Meldung erfolgt, die restlichen Kommandos aber trotzdem ausgeführt werden anstatt die Funktion zu verlassen ... aber das kann es bei "leerer Partition" ja auch nicht sein, da gibt es kein char-Device, was konvertiert werden müßte

4. die Liste der möglichen Konfigurationsdateien (tffs_nodes_list) wird aufgebaut

5. für jeden Eintrag der Liste wird geprüft, ob eine reguläre Datei gleichen Namens in der (leeren!) config-Partition vorhanden ist (unter dem Pfad in $tffs_node_prefix, was fest auf /var/flash eingestellt ist) - wenn nicht, wird das entsprechende char-Device mit "mknod" erstellt

6. und jetzt kommt auch (schon?) der Aufruf des oben gezeigten "check_and_store_yaffs_to_tffs_node"

Woher da jetzt das Verzeichnis "data" kommen soll, damit die Bedingung
Code:
   if [ -f "${prefix}/data/${name}" ] ; then
erfüllt wird oder wohin da das char-Device verschwindet, damit
Code:
  if [ ! -c "${prefix}/$name" ]; then
"wahr" wird (beides in dieser Funktion oben zu sehen), ist mir (ohne die passende Hardware) ein Rätsel.

Bleibt halt die Frage, wie es anderen Besitzern einer 7362SL so ergeht ... vielleicht ist das tatsächlich "normal" und AVM macht da eine gesonderte Behandlung für die 7362SL. Warum das bisher nie aufgefallen sein sollte, weiß ich dann auch nicht.

Damit kann man diesen Mechanismus aber wahrscheinlich trotzdem benutzen (zumindest in der Theorie sollte das gehen, probiert habe ich es auch noch nicht), um nach einem Neustart der Box die Daten im TFFS zu überschreiben. Dazu (wie gesagt, Theorie und nicht getestet) müßte man wohl nur ein Unterverzeichnis "data" unterhalb von /var/flash selbst erzeugen und dort die Dateien ablegen, die nach dem Neustart in die TFFS-Nodes kopiert werden sollen. Dann noch den Node für das char-Device gelöscht und an dessen Stelle ein reguläres File gleichen Namens angelegt (der Inhalt wäre egal) und beim nächsten Start sollte die reguläre Datei das Anlegen des char-Devices im ersten Schritt verhindern, während dann in der Funktion oben das fehlende char-Device und die Existenz der Datei unter dem Pfad /var/flash/data dafür sorgt, daß deren Inhalt in den TFFS-Node kopiert wird.

Wenn jetzt nicht ausgerechnet nach dem Wiederherstellen der Einstellungen bei Dir die char-Devices vorhanden wären, würde ich ja fast vermuten wollen, daß AVM beim Wiederherstellen der Einstellungen so vorgeht, wie ich es beschrieben habe ... aber das Listing vor dem Neustart spricht ja nun deutlich dagegen - insofern wird es eher mysteriöser als klarer.

Das Anlegen von /var/flash/data in der S01-head wird jedenfalls bei mir gar nicht aufgerufen (das wäre dann in "check_and_store_tffs_node_to_yaffs" und einen solchen Aufruf gibt es nicht, sagt mir "grep") .. wie gesagt, ich würde jetzt als nächstes erst einmal den Unterschied zwischen der 7490 und der 7362SL in den Dateien in /etc/init.d versuchen festzustellen. Gibt es keinen, fehlt mir die Erklärung, woher das "data"-Verzeichnis kommen sollte. Gibt es dort einen Aufruf von "tffs_node_to_yaffs", wäre die Frage, welche Umstände zu einem Aufruf führen.
 
Danke für deine ausführliche Erklärung!

Jetzt weiß ich erst, was du mit S01-head meinst. Ich bin sonst immer nur in /var/...
Für mich bitte immer mit vollständigem Pfad angeben ;)

Aber ich habe einen entscheidenden (glaube ich zumindest) Unterschied gefunden.

So bei der 7490:
Code:
########### tffs node to yaffs ########
## echo "[tffs_node_to_yaffs] start."
## ls -al /var/flash
for conv_node in ${tffs_nodes_list} ; do
conv_node_id=${conv_node%%,*} # bis zum ersten komma
conv_node_name=${conv_node##*,} # ab dem letzten komma
[COLOR="#FF0000"]check_and_store_yaffs_to_tffs_node[/COLOR] ${conv_node_id} ${conv_node_name}
done
## ls -al /var/flash
## echo "[tffs_node_to_yaffs] done."
###########
Und so in der 7362SL:
########### tffs node to yaffs ########
## echo "[tffs_node_to_yaffs] start."
## ls -al /var/flash
for conv_node in ${tffs_nodes_list} ; do
conv_node_id=${conv_node%%,*} # bis zum ersten komma
conv_node_name=${conv_node##*,} # ab dem letzten komma
check_and_store_tffs_node_to_yaffs ${conv_node_id} ${conv_node_name}
done
## ls -al /var/flash
## echo "[tffs_node_to_yaffs] done."
###########
Also ist es wohl fast eindeutig ein Fehler bei AVM, oder?

Die weiteren Schlußfolgerungen überlasse ich dir, ich habe da keinen Überblick wo sich das auswirkt.
Ich vermute aber ganz stark, das dies die Ursache des Problems ist.
 
Zuletzt bearbeitet:
Wenn es nicht Absicht ist, was sich dahinter verbirgt ... ich verstehe den Sinn trotzdem nicht bzw. nicht richtig.

Vielleicht will AVM ja weg von der Speicherung der Einstellungen im TFFS bei älteren Geräten, weil Flash-Fehler im NOR eben andere Auswirkungen haben und bei älteren Geräten dieser Flash-Speicher schon recht oft beschrieben wurde bzw. es aktuell häufiger Zugriffe auf das TFFS (bzw. genauer "auf die Einstellungen") gibt, weil ja auch Zeitbudgets usw. irgendwie gesichert werden müssen (bzw. deren Verbrauch) und da moderne NAND-Filesysteme einfach mit ihrem Defekt-Management (auch wenn die verkraftbaren Schreibzyklen bei NAND weniger sind) besser geeignet sind? Alles nur Spekulation ... wenn ich verfolge, wie lange diese Code-Teile in der S01-head zurückreichen (ich habe nur bei der 7490 bis 06.05 nachgesehen), dann ist das auch keine so ganz neue "Erfindung" bei AVM und bisher hatte ich das eher als mögliche Lösung bzw. ein Überbleibsel von einem früheren Upgrade der Firmware angesehen (bei älteren Modellen).

Kannst Du nachvollziehen bei der 7362SL, wie weit diese Zeile (vor allem der Unterschied zwischen 7362SL und 7490) zurückreicht? Es ist ja tatsächlich genau "die Gegenrichtung" und damit wird jeder TFFS-Node in das "data"-Verzeichnis kopiert, wie es bei Dir ja auch erfolgt. Da wäre es jetzt spannend, ob das vor der 06.50 auch schon so war ... und es nur niemandem richtig aufgefallen ist oder ob das tatsächlich absichtlich erfolgt. Bliebe in jedem Falle die Frage, warum das bei der 7362SL und der 7490 dann so anders gehandhabt wird ... nur die Erklärung, daß die 7362SL als Modell bereits älter ist als die 7490 und damit diese Geräte langsam "in die Jahre kommen" (zumindest die ersten), erscheint mir selbst halbwegs plausibel. Sollte jemand eine besser passende Erklärung in petto haben ... immer her damit.
 
Ich bin z.Z auf 06.20, wo ich das gefunden habe. Aber ich schätze das reicht von der 06.03 bis zur 06.50 und weiter.

Aber in der 7362SL stimmt ja die "Überschrift" und die echos mit der Funktion überein.
Es sieht für mich so aus, als wurde das in der 7490 "mal so schnell" geändert.

Die stat.cfg und userstat.cfg mit den Verbrauchsdaten werden IMO jede Minute neu geschrieben.

Wie ist das jetzt aber mit der 7412. Die hat doch IMO keinen NOR.
Also muß es doch im NAND liegen, oder?
Aber da sind es trotzdem "C-Dateien".
Die hat aber eine ganz andere S01-head, nur 2KB groß.
Aber dann ist doch, daß die Dateinen bei der 7362SL im NAND liegen noch kein Grund, daß es keine "C-Dateien" sind, oder?


und es nur niemandem richtig aufgefallen ist
War ja bei mir auch nur Zufall, weil ich mal wieder wie gewohnt im WinSCP auf die ar7.cfg klickte, und mich dann hinterher wunderte wieso daß bei 06.50 geht.
 
Zuletzt bearbeitet:
Bei der 7412 wird die "config"-Partition nicht verwendet (habe ich irgendwo schon mal geschrieben, obwohl der Platz für sie ja existiert) und die char-Devices werden bei jedem Start neu im "tmpfs" angelegt (wie bei den NOR-Modellen auch) ... hier erfolgt das in S08-tffs und da auch die beiden "eingebetteten Funktionen" (check_irgendwas) in der S01-head fehlen, ist die so klein.

Auch wenn die 7412 keinen NOR-Flash hat, wird dort ein TFFS im NAND emuliert (deshalb wird bei diesem Modell bei Recovery auch nicht MTD3 und/oder MTD4 geschrieben, sondern "mtdnand" :mrgreen:) - vermutlich um die notwendigen Änderungen gering zu halten. Am Ende wird da eine NAND-Partition mit den Strukturen des TFFS beschrieben ... diese Emulation geht aber so weit, daß sogar ein "cat /proc/tffs" irgendwelche "virtuellen Device-Namen" für die verwendeten TFFS-Devices ausgibt, die mit den realen Devices in der Firmware nichts mehr zu tun haben (in diese Falle bin ich bei einigen Skripten auch getappt).
 
So, da denke ich können wir diesen Fall abschließen.
Ich danke dir für die nette Zusammenarbeit!
Ich denke du hast aber auch wieder was dazu gelernt.

Ich hätte zum Schluß noch eine bestimmt ganz doofe Anfängerfrage:
Wie beende ich eine Win-XP Telnet Verbindung sauber?
Bei Putty/SSH mach ich immer "exit" und das Fenster schließt sich.
Bei dem Telnet mache ich auch "exit", aber es wird nicht richtig beendet.
Das merke spätestens beim nächsten Telnet oder Putty, da steht dann immer: weitere telnet Verbindung aufgebaut
Und ich bekomme keine Console-Meldungen.
Ich habe auch schon mit ps gesucht, aber nichts gefunden, was ich da killen könnte.
 
Ich würde da "ctrl" und "plus" (die Sterntaste im "normalen Bereich, kein NumPad o.ä.) verwenden und dann mit "c" die Verbindung zum Host trennen (sollte die Shell dort beenden) und dann mit "q" den (lokalen) Telnet-Client beenden. Ob das unter XP so geht, kann/will ich (mangels XP-VM, ich müßte erst suchen) nicht testen.
 
Hallo Zusammen,

habe derzeit auf der 7362SL die Firmware 6.30 mit modfs telnet und debug.cfg wiederhergestellt. Nun gibt es das Update auf 6.50.
Wie führe ich am besten ein Upate auf 6.50 aus um zu gewährleisten das ich die vorgenommenen Modifikationen behalte oder wieder freischalten kann?

Drei Sachen habe ich per fsmod-script bereits ausprobiert.
- Download neusten Firmware von Server => schlägt fehl
- Firmware manuell gedownloaded und Verzeichnis manuell angegeben => Fehler beim mounten der entpackten root-Datei
- update-Parameter versucht, hier rebootet die Box beim Packen

Funktioniert das Pseudo Image mit integrierten Telnet vll. noch um nach einem Standard-Update per AVM GUI ein temporäres telnet zu bekommen
um dann wieder per fsmod die aktuell installierte firmware zu modifizieren?
 
Zuletzt bearbeitet:
@PeterPawn:
Danke!
Es geht auch ohne "c", die Shell wird trotzdem beendet.
Mit exit wurde die Shell auch beendet, sonst hätte ich ja was zu killen gefunden.
Nur "tty is "/dev/pts/0"" zählte immer höher.

So, wollen wir alle Beiträge zu dem Fall löschen, da es ja nun doch nichts mit modfs zu tun hat?
Bitte entscheide du.
 
Zuletzt bearbeitet:
update-Parameter versucht, hier rebootet die Box beim Packen
Vernünftigen USB-Speicher anstecken (1x Swap-Partition, 1x ext3 für Daten) und es sollte mit dem "update" klappen. Das hat auch nichts mit "06.50 oder nicht" zu tun, es steht bereits irgendwo weiter vorne, daß "memory pressure" (und die 7362SL hat nun mal nur den halben Hauptspeicher der 7490) zu Problemen führen kann.

Auch der denkbare Workaround mit dem Aufruf von "prepare_fwupgrade start_tr069" (letzteres nur dann, wenn man auf WLAN verzichten kann, weil man eine LAN-Verbindung zur Box hat, ansonsten nimmt man "start") sollte aufgeführt sein.

Daß ein direktes Update einer 06.50 von einer 06.30 aus nicht funktioniert (also ohne explizites "update" beim Aufruf), hatten wir weiter oben, steht auch als "issue" im GitHub. Wenn ich Zeit dafür habe, korrigiere ich das ... solange hilft sich entweder jeder selbst oder man greift zum Workaround mit dem Update.

Das Problem des fehlenden Speicherplatzes würde mit sehr hoher Wahrscheinlichkeit ohnehin auch bei den ersten beiden getesteten Varianten (automatischer oder manueller Download vom AVM-Server) bestehen ... ich wüßte jedenfalls nicht, warum das anders sein sollte - ganz im Gegenteil. Da beim automatischen Download noch der dsld funktionieren muß, kommt da der vorherige Aufruf von "prepare_fwupgrade start" gar nicht in Frage, denn dann würde sowohl der dsld als auch der avmike (der ohne DSL-Verbindung ja ohnehin nichts bringt) beendet und das war's dann mit einem "online check".

So, wollen wir alle Beiträge zu dem Fall löschen, da es ja nun doch nichts mit modfs zu tun hat?
Bitte entscheide du.
Ich bin da nahezu emotionslos ... andererseits wurde das ja auch zum ersten Male hier festgestellt (jedenfalls soweit ich weiß) und selbst wenn der Thread-Titel nicht paßt, könnten die Beiträge ja bei einer Suche trotzdem gefunden werden.

Da ohnehin niemand wirklich die bisherigen Seiten bis hier sequentiell abarbeitet (deshalb versuche ich ja die Links in #1 halbwegs aktuell zu halten), sehe ich auch kein großes "Störpotential". Ich kann mich auch nicht erinnern, daß ich hier jemanden mal aufgefordert hätte, mehrere Seiten zurückzublättern oder gar gefordert hätte, daß man alle Seiten dieses Threads liest. Mir reicht es eigentlich schon, wenn man vor dem Stellen von Fragen die in #1 verlinkten Beiträge wenigstens mal überfliegt und die dort bereits beantworteten Fragen nicht erneut aufs Tapet kommen. Wenn ich dann noch etwas in #1 unterschlagen haben sollte, was wichtig war oder ist, dann trage ich das gerne dort nach. Den Hinweis auf den erforderlichen USB-Speicher habe ich jedenfalls bereits am 06.11.2015 noch einmal in #1 aufgenommen und dabei sollten eigentlich keine Zweifel übrig bleiben können, worüber ich dort geschrieben habe und auch das "prepare_fwupgrade" ist dort bereits enthalten.
 
Zuletzt bearbeitet:
Danke für die Hilfe. Wollte nur kurz eine Rückmeldung geben, habe deine Ratschläge beherzigt doch leider hat es nicht funktioniert:
- habe nun zwei verschiedene Sticks ausprobiert
- den Stick mit 1x Swap-Partition, 1x ext3 für Daten partitioniert
- prepare_fwupgrade start_tr069 ausgeführt
- dann Befehl
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.3.tgz | gunzip -c | tar x;./modfs update /var/media/ftp/STT-Storage-01/FRITZ.Box_7362_SL.131.06.50.image
Doch leider rebooted die Box wieder bei "Entpacken des root-Dateisystems für die Modifikation"
Setze mich morgen wieder damit auseinander, wird ja irgendwie zu lösen sein :)
Kommisch ist nur bei der 6.30 hat damals mit gleichen USB Stick alles einwandfrei funktioniert unter Berücksichtigung von "prepare_fwupgrade start_tr069"
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
244,919
Beiträge
2,220,975
Mitglieder
371,689
Neuestes Mitglied
ResalSausi
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.