[HowTo] Flash-Script für 7490

@Christoph_F:
Code:
[COLOR=#ff0000]./7490install.sh: 30: ./7490install.sh: eva-login.sh: not found
./7490install.sh: 31: ./7490install.sh: eva_to_memory: not found [/COLOR]
Ich musste in Deinem Skript noch jeweils ein "./" voranstellen, dann klappte es:
Code:
[COLOR=#008000][B]./[/B][/COLOR]eva-login.sh "$IP"
[COLOR=#008000][B]./[/B][/COLOR]eva_to_memory "$FIMG.eva" "$IP"

Alternativ waere denkbar temporaer den Suchpfad zu erweitern:
export PATH=$PATH:.
 
Danke für den Tipp, aber ich bin auf einem Raspberry Pi 2 unterwegs, also ich arbeite mit der bash. ;)


Allerdings gibt es beim Wiedereinschalten folgenden Fehler:
Code:
Warte auf Einschalten von „192.168.178.1“…
..... 192.168.178.1 gefunden!
Debugging on (debug=1).
---> QUIT
./eva_to_memory: 198: [: xFRITZ.Box_7490.113.06.30.image.eva: unexpected operator
./eva_to_memory: 32: read: Illegal option -u
./eva_to_memory: 288: ./eva_to_memory: Bad substitution
Werden hier wirklich die korrekten Zeilen des Skripts von PeterPawn aus YourFritz angegeben?

26-39 (32: "read: Illegal option -u"):
Code:
#
# helper functions
#
read_ftp_response()
{
    local line="   -" rc=0 instream="$1" log="$2"
[COLOR=#ff0000]     while read -u $instream -r line; do[/COLOR]
        [ ! -z "$log" ] && echo "$line" >&$log
        [ "${line:3:1}" != "-" ] && break
    done
    rc=$?
    echo "$line"
    return $rc
}

195-201 (198: "[: xFRITZ.Box_7490.113.06.30.image.eva: unexpected operator"):
Code:
#
# check file size
#
[COLOR=#ff0000] if [ x$filename == x ]; then[/COLOR]
    echo "Missing file name."
    exit 1
fi

281-290 (288: "./eva_to_memory: Bad substitution"):
Code:
#
# now open a connection to the box
#
nc $box_ip $box_port <&$outstream >&$instream 2>/dev/null &
control_connection=$!
data_connection=""
line="$(read_ftp_response $instream $logstream)"
[COLOR=#ff0000] ec=${line:0:3}[/COLOR]
if [ x$ec == x220 ]; then
    login_to_box $instream $outstream $logstream
    ...
Sorry, da steige ich nicht mehr durch. :confused:


Mir ist nicht klar, was "read -u $instream -r line" macht, ebenso die beiden anderen Zeilen, welche auf meinem System ein Problem verursachen. Ich erinnere, dass PeterPawn Posix nutzt (oder?), d.h. da wundert es mich natürlich nicht, dass es bei mir nicht reibungslos auf Anhieb klappt. Gerne würde ich das beheben, bräuchte aber etwas Unterstützung von Leuten, die Ahnung von Skripting haben (inkl. PeterPawn, natürlich). Herzlichen Dank!
 
Zuletzt bearbeitet:
Danke für den Tipp, aber ich bin auf einem Raspberry Pi 2 unterwegs, also ich arbeite mit der bash. ;)

Bist Du Dir sicher ?
Raspberry verwendet eigentlich u.a. Rasbian, ein Debian Derivat, d.h. es wird Dash statt Bash verwendet!

Code:
freetz@raspberrypi:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Mär 30  2012 /bin/sh -> dash
freetz@raspberrypi:~$

Vorschlag: von Dash auf Bash umstellen und erneut testen.
 
Oja, da ist mir ein Fehler unterlaufen - danke! Ich werde es später probieren. Jetzt habe ich es doch mit der "Recovery/Downgrade"-Methode gemacht (läuft noch), und dann sehe ich, ob meine Box überhaupt mit freetz-devel/.60 stabil läuft.


Schade:
Das Update ist fehlgeschlagen:
Die angegebene Datei enthält kein von AVM für dieses Gerät freigegebenes FRITZ!OS.
Das verstehe ich jetzt aber nicht. Ich hatte verstanden, dass es mit dieser Methode klappt, d.h. dass die AVM FW .51 (auf die ich ja zuvor das Downgrade gemacht habe) das nicht prüft. Nun aber wohl doch?
 
Zuletzt bearbeitet:
@ao:
Bitte einen Thread benutzen, nicht mehrere ... wenn Du die "bash" als Shell verwendest und alle notwendigen Programme installiert hast (nc, socat), dann sollte das auch problemlos unter Raspbian laufen - auch wenn ich nicht mehr genau weiß, was bei mir (RasPi 3, u.a. auch mit ebendiesem System) angepaßt werden mußte. Das, wo ich nicht explizit nach der "bash" "verlange", sollte auch mit der "ash" der BusyBox funktionieren.

Überall POSIX-kompatibel zu arbeiten (damit die blöde "dash" auch geht), scheitert i.d.R. schon daran, daß im POSIX-Standard keine "substrings" ohne zusätzliche Programme verarbeitet werden können ... das macht es dann so richtig schnell. :-(

Sofern ich also nicht bei einem Skript explizit dazuschreibe, daß dieses auch mit einer POSIX-kompatiblen Shell funktioniert, ist die Basis immer "ash" - ansonsten steht im SheBang dann auch explizit die "bash" drin, wenn die "ash" nicht ausreicht.
 
Ich brauch leider auch noch etwas Unterstützung.

Ich arbeite in freetz-linox auf einer VM und will die neue Box meines Bruders freetzen.
Ich habe das Skript von Christoph_F verwendet, kann aber eva_to_memory .... auch manuell aufrufen und es scheint durchzulaufen.
Sehr schnell (nach wenigen Sekunden) kommt folgende Ausgabe

Found AVM bootloader: AVM EVA Version 1.1964 0x0 0x740D
Found hardware revision: 185
Memory size is 0x10000000 (256 MB)
Image size is 0x000000 (0 MB)
Setting temporary memory size to: 0x10000000
Setting temporary kernel args to: mtdram1=0x90000000,0x90000000

Offensichtlich schlägt das dd-Kommando fehl, weil das FLAG count_bytes auf meinem System nicht geht.
Dadurch wird eine leere image.eva Datei erstellt.

Wäre für Unterstützung sehr dankbar.

Gruß
maceis
 
Zuletzt bearbeitet:
Offensichtlich schlägt das dd-Kommando fehl, weil das FLAG count_bytes auf meinem System nicht geht.
Dadurch wird eine leere image.eva Datei erstellt.

welches System nutzt du denn ? Freetz-VM 1.4.1.ova, RPi, ???
was liefert "dd -?"
könntest Du Bitte den genauen Befehl zur Erstellung der image.eva, inkl. Befehlsausgaben beifügen, so dass es reproduzierbar wird.
 
Zuletzt bearbeitet:
bash hab ich
lrwxrwxrwx 1 root root 9 Apr 22 01:37 /bin/sh -> /bin/bash
und nc ist bei mir
% nc
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc ....

Das Problem ist:
dd: ungültiges Eingabeflag: »count_bytes“

Wenn ich "iflag=count_bytes" weglasse, wird ein image.eva gespeichert und auch auf die Box geladen.

% du *.image*
27208 7490_06.83-freetz-devel-14237.de_20170421-185342.image
26544 7490_06.83-freetz-devel-14237.de_20170421-185342.image.eva

Wenn ich die Box danach starte, ist aber immer noch die alte FW drauf.

Irgendwie glaub ich, dass es nur noch ein kleiner Schritt ist, der mir fehlt.
Um halb vier heute nacht hab ich vorläufig aufgegeben.

Gruß
maceis

PS: mit einem "echo" vor dem dd-Kommando:

Variante 1:
dd iflag=count_bytes bs=256 if=./var/tmp/kernel.image of=./var/tmp/kernel.image.tmp count=2505728
dd iflag=count_bytes bs=256 if=./var/tmp/filesystem.image of=./var/tmp/filesystem.image.tmp count=24673536

Variante 2:
dd bs=256 if=./var/tmp/kernel.image of=./var/tmp/kernel.image.tmp count=2505728
dd bs=256 if=./var/tmp/filesystem.image of=./var/tmp/filesystem.image.tmp count=24673536


Edit:
Ach so ja , System:
uname -a
Linux freetz-linux 3.2.0-126-generic #169-Ubuntu SMP Fri Mar 31 14:16:01 UTC 2017 i686 i686 i386 GNU/Linux
hab ich neulich erst aktualisiert mit "apt-get upgrade"


Edit 2:
Wenn ich das richtig verstanden habe, könnte man auch die image.in-memory-Datei nehmen.
Ist das richtig?

Und die müsste man eigentlich auch über ftp manuell auf die Box laden können, richtig?

Allerdings: hochgeladen wird es ja, nur die Box nimmt die freetz-FW dann nicht.
 
Zuletzt bearbeitet:
Das Problem ist:
Code:
dd: ungültiges Eingabeflag: 'count_bytes'

ich verwende "Debian 8 (jessie)" und da ist die DD Option "iflag=count_bytes" enhalten:
Welches System nutzt Du ?
Code:
freetz@Pi:~$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
...


Code:
freetz@Pi:~$ dd --help
Aufruf: dd [OPERAND...]
 oder:  dd OPTION
Kopieren einer Datei, Konvertierung und Formatierung gemäß der Operanden.

  bs=BYTES        BYTES Bytes auf einmal lesen und schreiben (siehe ibs=,obs=)
  cbs=BYTES       BYTES Bytes auf einmal konvertieren
  conv=CONV       Datei gemäß kommagetrennter Schlüsselwörter‐Liste konvertieren
  count=N         nur N Eingabeblöcke kopieren
  ibs=BYTES       Lesen von BYTES Bytes auf einmal (Voreinstellung: 512)
  if=DATEI        aus DATEI statt von der Standardeingabe lesen
  iflag=FLAGS     anhand der kommagetrennten Symbolliste lesen
  obs=BYTES       BYTES Bytes auf einmal schreiben (Voreinstellung: 512)
  of=DATEI        in DATEI statt in die Standardausgabe schreiben
  oflag=FLAGS     anhand der kommagetrennten Symbolliste schreiben
  seek=N          N obs‐große Blöcke am Anfang der Ausgabe überspringen
  skip=N          N ibs‐große Blöcke am Anfang der Eingabe überspringen
  status=WELCHE   WELCHE Info nicht auf dem Standardfehlerkanal ausgegeben
                    werden soll. „noxfer“ unterdrückt die übertragungsstatistik
                    und „none“ alle Ausgaben

welches Skript wirft "dd: ungültiges Eingabeflag: 'count_bytes'" aus ?
bitte mit Skriptausgaben beifügen, so dass es nachvollziehbar wird.

- - - Aktualisiert - - -

Verwendest Du dd aus coreutils paket ?

Code:
root@Pi:~# which dd
/bin/dd
root@Pi:~# [COLOR=#0000ff]dpkg -S /bin/dd
coreutils: /bin/dd[/COLOR]
root@Pi:~# dpkg -l | grep coreutils
ii  coreutils                             8.23-4                                    armhf        GNU core utilities
ii  realpath                              8.23-4                                    all          coreutils realpath transitional package
root@Pi:~#
 
Bitte auch meinen letzten Beitrag nochmal lesen.
Hab was editiert und ergänzt.
Wie gesagt, ich glaube ich hab ein image, dass okay ist und hochgeladen wird.

Das dd ist aus dem 7490install.sh Skript oben aus diesem Thread

Muss jetzt leider in die Arbeit und bin erst gegen 9 oder 10 wieder da.

Danke schon mal für Euer Feedback und Eure Unterstützung.

dpkg -S /bin/ddcoreutils: /bin/dd


cat /etc/os-releaseNAME="Ubuntu"
VERSION="12.04.5 LTS, Precise Pangolin"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu precise (12.04.5 LTS)"
VERSION_ID="12.04"

dd --help Verwendung: dd [OPERAND...]
oder: dd OPTION
Kopieren einer Datei, Konvertierung und Formatierung gemäß der Operanden.


bs=BYTES BYTES Bytes auf einmal lesen und schreiben (siehe ibs=,obs=)
cbs=BYTES BYTES Bytes auf einmal konvertieren
conv=CONV Datei gemäß kommagetrennter Schlüsselwörter‐Liste konvertieren
count=BLÖCKE nur BLÖCKE Eingabeblöcke kopieren
ibs=BYTES Lesen von BYTES Bytes auf einmal (Voreinstellung: 512)
if=DATEI aus DATEI statt von der Standardeingabe lesen
iflag=FLAGS anhand der kommagetrennten Symbolliste lesen
obs=BYTES BYTES Bytes auf einmal schreiben (Voreinstellung: 512)
of=DATEI in DATEI statt in die Standardausgabe schreiben
oflag=FLAGS anhand der kommagetrennten Symbolliste schreiben
seek=BLÖCKE BLÖCKE obs‐große Blöcke am Anfang der Ausgabe überspringen
skip=BLÖCKE BLÖCKE ibs‐große Blöcke am Anfang der Eingabe überspringen
status=noxfer Transferstatistik unterdrücken


BLÖCKE und BYTES können folgende multiplikative Endungen tragen:
c=1, w=2, b=512, kB=1000, K=1024, MB=1000×1000, M=1024×1024, xM=M
GB=1000×1000×1000, G=1024×1024×1024, und so weiter für T, P, E, Z, Y.


Jedes CONV‐Symbol kann sein:


ascii von EBCDIC in ASCII
ebcdic von ASCII in EBCDIC
ibm von ASCII in alternatives EBCDIC
block mit Zeilenumbrüchen terminierte Datensätzen durch
Leerzeichen bis zur cbs‐Größe auffüllen
unblock nachlaufende Leerzeichen in Datensätzen von
cbs‐Größe mit Zeilenumbrüchen ersetzen
lcase Großbuchstaben in Kleinbuchstaben ändern
ucase Kleinbuchstaben in Großbuchstaben ändern
swab Jedes Paar von Eingabebytes vertauschen
sync jeden Eingabeblock mit NULLen zur ibs‐Größe auffüllen; wenn mit
„block“ oder „unblock“ benutzt, stattdessen mit Leerzeichen
excl scheitert, wenn das auszugebende Byte bereits existiert
nocreat Die Ausgabedatei wird nicht erzeugt
notrunc Die Ausgabedatei wird nicht abgeschnitten
noerror nach Lesefehlern fortfahren
fdatasync vor Beendigung Ausgabedatendatei physisch schreiben
fsync genauso, zusätzlich auch die Metadaten


Jedes Symbol FLAG kann sein:


append Anfügemodus (nur für Ausgabe sinnvoll; conv=notrunc empfohlen)
direct direkte Ein‐/Ausgabe für Daten benutzen
directory abbrechen, wenn kein Verzeichnis
dsync synchronisierte Ein‐/Ausgabe für Daten benutzen
sync genauso, aber auch für Metadaten
fullblock volle Eingabeblöcke ansammeln (nur iflag)
nonblock nicht‐blockierende Ein‐/Ausgabe benutzen
noatime die Zugriffszeit nicht erneuern
nocache zwischengespeicherte Daten verwerfen
noctty das kontrollierende Terminal nicht von Datei zuweisen
nofollow symbolischen Verknüpfungen nicht folgen


Schickt man einem laufenden „dd“‐Prozess ein USR1‐Signal, gibt dieser
auf der Standardfehlerausgabe Eingabe‐/Ausgabe‐Statistiken aus und fährt
mit dem Kopieren fort.


$ dd if=/dev/zero of=/dev/null& pid=$!
$ kill -USR1 $pid; sleep 1; kill $pid
18335302+0 Datensätze ein
18335302+0 Datensätze aus
9387674624 Bytes (9,4 GB) kopiert, 34,6279 Sekunden, 271 MB/s


Optionen sind:


--help diese Hilfe anzeigen und beenden
--version Versionsinformation anzeigen und beenden


Melden Sie Programmfehler für dd (auf Englisch, mit LC_ALL=C) an [email protected]
GNU coreutils Homepage: <http://www.gnu.org/software/coreutils/>
Allgemeine Hilfe zur Benutzung von GNU-Software: <http://www.gnu.org/gethelp/>
Melden Sie Übersetzungsfehler für dd an <[email protected]>
Für die vollständige Dokumentation starten Sie:
info coreutils 'dd invocation'
 
Und die müsste man eigentlich auch über ftp manuell auf die Box laden können, richtig?

Nein, bei NAND-Boxen geht das nicht wie bei NOR-Boxen per Bootloader-FTP "STOR" Befehl, deshalb gibt es ja für NAND-Boxen das YourFritz/eva_tools/eva_to_memory


- - - Aktualisiert - - -

Das dd ist aus dem 7490install.sh Skript oben aus diesem Thread

==> nimm doch YourFritz/eva_tools/eva_to_memory, dann gibt es kein Problem mit dd

- - - Aktualisiert - - -

Code:
cat /etc/os-releaseNAME="Ubuntu"
VERSION="12.04.5 LTS, Precise Pangolin"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu precise (12.04.5 LTS)"
VERSION_ID="12.04"

==> Vorschlag: das aktuelle freetz-linux-1.4.1.ova aus:
https://sourceforge.net/projects/freetz-linux/
https://sourceforge.net/projects/fr...z-linux-1.4.1/freetz-linux-1.4.1.ova/download

verwenden, dies basiert Ubuntu auf 14.04 und nicht Ubuntu 12.04 und deren veraltete coreutils.
 
Es geht bei der Aktion mit "count_bytes" ja nur darum, die letzten 8 Byte einer Image-Datei abzuschneiden, da dort eine Prüfsumme enthalten ist, die zu unerwünschten (und wie man hier sieht auch fatalen) Verschiebungen der Lage der Daten im Speicher führt.

Läßt man den "iflags"-Parameter weg, werden eben 8 Byte zuviel kopiert und damit landet das Dateisystem an einer falschen integralen Grenze (habe ich auch ausführlich erläutert am Beginn dieses Threads).

Ich habe ja bereits am Beginn des Threads mit @Christoph_F darüber diskutiert ... hier hätte Lesen und Verstehen von #2 (wenn ich das ab #27 richtig verstanden habe) ja vielleicht einiges an Zeit und Aufwand sparen können. Meine Version (image2ram) sollte ohne diese Vereinfachung mit dem "iflags"-Parameter auskommen ... ggf. braucht sie etwas länger beim Kopieren, weil sie mit kleineren Blöcken arbeitet. Da man das nicht alle 5 Minuten wiederholt, sollte das keine entscheidende Rolle spielen.

- - - Aktualisiert - - -

Ja, ich habe gerade noch einmal nachgelesen (ist halt schon wieder lange her) ... ein Aufruf von "image2ram < freetz.image >freetz.memory_image" sollte aus dem TAR-Archiv die Daten korrekt extrahieren.

Wobei natürlich bei der Verwendung von Freetz-Images auch direkt das erzeugte "in-memory"-Image verwendet werden kann ... das ist ja schließlich nur dafür überhaupt erzeugt. Wieso hier im konkreten Fall mit dem TAR-File gearbeitet werden soll, verstehe ich ohnehin nicht.
 
IMHO: Bitte auch die Bootloader-Variable "linux_fs_start" Variable im Auge behalten, sonst wird ggf. das "falsche" System überschrieben;d.h. Befehl "eva_switch_system xxx" vorher eingebenQuelle:
Nimm Dein Freetz-Image, lasse Dir mittels "image2ram" ein passendes "in-memory"-Image daraus erstellen und verwende das mit "eva_to_memory" ... das war's dann schon. Allerdings wird dabei dann das System überschrieben, auf das "linux_fs_start" gerade zeigt. Wenn Du also das andere System überschreiben willst, mußt Du vor der Verwendung von "eva_to_memory" noch die Variable umsetzen.
 
an etwaige nachfolgende Leser:
die Recherche ergab folgendes, das Erstellen des Freetz-in-memory Image für NAND-Boxen ist mind. seit rev. 14049, d.h. seit 17.01.2017 im Trunk enthalten.

http://freetz.org/browser/trunk/fwmod?rev=14049
Code:
     1729        #[COLOR=#0000ff] Create in-memory image [/COLOR]
     1730        img_name="${FW_IMAGES_DIR:-$DIR}/${modimage}" 
     1731        if [ "${FREETZ_AVM_HAS_UPDATE_FILESYSTEM_IMAGE}" == "y" ]; then 
     1732            echo0 "creating in-memory image ${img_name}.in-memory" 
     1733            { 
     1734                cat "$KERNEL_MOD"     | dd bs=256 conv=sync 2>/dev/null; 
     1735                cat "$FILESYSTEM_MOD" | dd bs=256 conv=sync 2>/dev/null; 
     1736            } > "${img_name}.in-memory" 
     1737        fi

d.h. nach "fwmod" ist weder "./7490install.sh" noch "image2ram" mehr erforderlich, das geht mit direkt mit "./eva_discover" sowie "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory"
ggf. nach $IP als Argument bei eva_discover bzw. eva_to_memory angeben.
 
Zuletzt bearbeitet:
Danke Euch allen für Eure Tipps.

Ich kann leider nicht laufend hier mitlesen und mich ständig auf dem Laufenden über die neuesten (ja, ich weiß, ist nicht mehr ganz so neu) Entwicklungen halten,
Ich muss auch zugeben, dass vieles, was die regulars hier schreiben, zu hoch für mich ist.
Auch habe ich #2 gelesen, aber (zugegebenermaßen) nicht alles verstanden.
Ich versuche halt, mir selbst zu helfen, so gut ich kann und erst dann zu fragen, wenn ich alleine nicht mehr weiter weiß.

Bin eben erst heimgekommen, und werden nach dem Essen genauer lesen, was Ihr alles empfohlen habt und hoffe, dass ich damit klarkomme.
Ich melde mich später noch mal und berichte die Ergebnisse.

Gruß
maceis

- - - Aktualisiert - - -

Hallo nochmal;
tja, ich glaube, jetzt hab ich was kaputt gemacht.
Ich konnte zwar "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory" erfolgreich ausführen mit folgendem Ergebnis.

Found AVM bootloader: AVM EVA Version 1.1964 0x0 0x740DFound hardware revision: 185
Memory size is 0x10000000 (256 MB)
Image size is 0x15c9200 (21 MB)
Setting temporary memory size to: 0x0ea36e00
Setting temporary kernel args to: mtdram1=0x8ea36e00,0x90000000
Image uploaded to device.

Leider startet die Box trotzdem nicht mehr.
Ich komme nur noch mit ftp drauf.

Nur wenn ich die Variable "linux_fs_start" ändere, fährt die Box noch hoch und zwar mit einer ziemlich alten AVM-FW.
Auf dieser "Seite" möchte ich aber (zumindest vorläufig) nichts machen.

Kann man da noch was machen, um das ganze wieder zu reparieren.
Ich muss dazusagen, dass ich nur ein uraltes virtuelles Windows irgendwo liegen habe und deswegen noch kein recover versucht habe.

Gruß
maceis
 
Zuletzt bearbeitet:
Einfach auf genau demselben Weg noch einmal eine AVM-Firmware installieren ... im Gegensatz zum AVM-Recovery-Programm bleiben dann die Einstellungen und der NAS-Inhalt erhalten.

Manchmal lesen die Leute aber auch nicht gründlich (soll zumindest schon mal vorgekommen sein - in anderen Threads) ... nachdem so ein Image in die Box geladen wurde, muß es erst einmal starten dürfen und sich selbst in den NAND-Flash schreiben. Dabei blinkt dann die Info-LED vor sich hin (wie bei jedem anderen Update auch) und wenn das Flashen beendet ist, startet die Box noch einmal von selbst (man sieht auch das an den LEDs), diesmal aus dem Flash-Speicher.

Es ist zwar (theoretisch) auch denkbar, ein nicht funktionierendes Image zu erzeugen und in die Box zu übertragen ... aber ich würde (aus leidfoller Ervahrung) eher auf ein Problem bei der Anwendung tippen und bei einem AVM-Image anstelle des Freetz-Images kann nun eigentlich gar nichts mehr schiefgehen. Erst dann, wenn das AVM-Image auch nicht starten will, würde ich über "firmware_info" noch den (NAS-)NAND-Flash löschen lassen (da hängt meine 7490 auch gerne mal, zumindest wenn der Füllstand dort hoch ist) ... ansonsten kann da eigentlich nur wenig schiefgehen und ein "Leider startet die Box trotzdem(?) nicht mehr(?)." ist als Beschreibung auch nicht sehr hilfreich. Solange also der FTP-Server im Bootloader noch erreichbar ist, würde ich das als Allererstes noch einmal wiederholen mit dem Freetz-Image und dabei dann einfach einmal beobachten, was die LEDs so anzeigen - das kann man dann im Anschluß hier sogar schriftlich festhalten und dann können andere vielleicht auch eine Idee entwickeln, wo es am Ende klemmen könnte.
 
Zunächst mal, Danke für Deine Unterstützung.

Die Box befand sich zu Beginn in Werkseinstellung.
Da gibts also nichts zu verlieren und der NAS Speicher müsste eigentlich ziemlich leer sein.

Meine Beobachtungen:
Die Box durfte natürlich schon mehrmals neu starten, dabei habe ich in einem Terminalfenster einen Ping laufen, damit ich sehe wann das Netzwerk hochkommt.
Nach dem "./eva_to_memory ..." blinkt die Info LED einige Sekunden lang schnell, dann blinkt nur doch die Power LED.
Nach ca. 2 Minuten bekomme ich vier bis 5 ping Antworten, dann kommt zwei Minuten lang keine Antwort mehr.
Dann kommen wieder 4 bis 5 ping Antworte und der Vorgang wiederholt sich etwa im zwei Minuten Rhythmus.

Während der ping Antworten zeigt mir ein map auf die Box, dass Port 21 offen ist.
Ich kann ich dann auch mit ftp ... verbinden.

Ich hab auch schon mehrmals und mit zwei verschiedenen Freetz Images den Vorgang wiederholt.
Ihr könnt das natürlich nicht wissen, aber bevor ich hier nachfrage, probier ich immer wiederholt, um eigene Flüchtigkeitsfehler ausschließen zu können.
Kaum etwas wäre mir peinlicher, als hier "dumme" Fragen zu stellen, nur um dann festzustellen, dass es sich um einen einfachen Eingabefehler handelt.

Ich probier jetzt mal Deinen Tipp mit dem Original AVM Image.
Wenn Du Lust hast, könntest Du mal vorsorglich beschreiben (oder steht das vielleicht sogar schon irgendwo beschrieben?), wie man mit "firmware_info den NAND Flash löscht", obwohl der Füllstand dort minimal sein sollte (s. oben).

Danke und Gruß
maceis


- - - Aktualisiert - - -

So, ich hab jetzt folgendes gemacht:

% ./eva_to_memory FRITZ.Box_7490.113.06.30.imageFound AVM bootloader: AVM EVA Version 1.1964 0x0 0x740D
Found hardware revision: 185
Memory size is 0x0e8a4000 (232 MB)
Image size is 0x175c000 (23 MB)
Setting temporary memory size to: 0x0d148000
Setting temporary kernel args to: mtdram1=0x8d148000,0x8e8a4000

Danach kommt der Prompt wieder.
Ich vermisse die Zeile:

Image uploaded to device.

Die Info LED blinkt (natürlich?) jetzt nicht mehr schnell und die Box bleibt bis zum Stecker ziehen per ftp erreichbar. Beim wieder Einstecken, geht es wieder mit dem oben beschriebenen 2-Minuten Rhythmus los.
 
Zuletzt bearbeitet:
Bei einem Inhalt von "recovered=2" in "firmware_info" (wenn da noch eine Versionsnummer steht, wird das mit einem Komma abgetrennt von ihr) formatiert die Firmware den NAND-Speicher (für NAS) neu.

Zwei Minuten sind allerdings eine sehr lange Zeit ... in diesem Zeitraum sollte die Box tatsächlich bereits komplett gestartet sein und - egal was da ansonsten noch passiert - wenigstens auch mal die LEDs fürs WLAN angeworfen haben.

Das schnelle Blinken der Info-LED dürfte/sollte der Schreibvorhgang sein ... aber vor dem Blinken der Power-LED sollte dann eigentlich noch ein Neustart erfolgen - zu erkennen am kurzen Aufblinken aller LEDs gleichzeitig (steht oben aber so nicht). Das irritiert mich aber heftig ... normalerweise wird die Info-LED nach dem Flashen erst unmittelbar vor dem "reboot"-Kommando wieder abgeschaltet.

Es gibt zwar im (neuen) Shell-Skript zum Flashen auch noch die Möglichkeit, sich den Erfolg über den Upload auf einen TFTP-Server "bestätigen" zu lassen, aber das wäre erst dann für mich ein Mittel der Wahl (außer ich habe das alles schon beisammen, was man dafür braucht), wenn nichts anderes mehr geht.

Wenn die Beobachtung/Beschreibung der LEDs nur falsch war und die Box nach dem Flashen tatsächlich neu startet, kann man auch noch einmal über EVA den Inhalt von "firmware_info" löschen ... startet dann überhaupt ein init-Prozess auf der Box, wird sehr früh bei der Initialisierung diese Variable mit der Versionsnummer der gestarteten Firmware neu geschrieben und kann beim nächsten Start als "Anzeiger" verwendet werden, daß die Box darüber hinwegkam.

Ansonsten kann man auch mit einer älteren Version (solange diese dieselben TFFS-Strukturen verwendet, es sollte also schon ein 3.10er-Kernel sein und mithin mindestens eine 06.5x) ein ggf. vorhandenes Protokoll für "crashes" oder "kernel panic" über die Support-Daten auslesen - wie gesagt: In den angegebenen zwei Minuten müßte die FRITZ!Box schon lange bis zum Start der USB-Devices (auch da hilft es ggf., wenn man einen Stick mit einer LED verwendet, bei der man den erfolgten Zugriff dann sehen kann) gekommen sein, wenn alles mit rechten Dingen zugeht.

Als Vergleich mal der "Zeitplan" einer 7490, nachdem der Kernel gestartet wurde (also anhand der Ausgaben in /proc/kmsg; da kommen also noch ein paar wenige Sekunden für das Entpacken des Kernels ins RAM dazu):

ZeitAktion
2Switch wird initialisiert, spätestens hier geht das Interface auf "nicht bereit", ggf. schon vorher
10LED-Treiber wird geladen, normalerweise beginnt hier dann die Power-LED langsam zu blinken (nicht das Doppelblinken bei der DSL-Synchronisation, das kommt erst später)
11-18ISDN und DECT wird initialisiert (binäre Komponenten werden in die Prozessoren übertragen)
18YAFFS2-Dateisystem für den NAS-Speicher wird gemountet
80USB-Geräte werden eingebunden - die Anzahl der USB-Geräte verschiebt dann weitere Aktionen ... bei mir gibt es zwei Geräte, einen 16 GB-Stick und eine HDD mit zwei ext3-Partitionen´und einer Swap-Partition
95Netzwerk wird gestartet (ungefähr hier sollte dann auch auf "ping" geantwortet werden)
98WLAN wird gestartet (WLAN-LED sollte blinken), dauert zwischen 10 und 30 Sekunden

In der relativ langen "Pause" von 20 bis 80 wird in erster Linie der DSL-Teil gestartet (E40-dsl) und noch ein paar "Kleinigkeiten", die man aber von außen nicht richtig erkennen kann - vielleicht sieht man noch das Initialisieren des (internen) S0-Bus, wenn man da ein ISDN-Gerät angeschlossen hat (wenn die 7362SL überhaupt internes ISDN hat). Aber schon dabei sollte eben die Power-LED beim Beginn der DSL-Synchronisation ihren Rhythmus beim Blinken wechseln ... von langsamem Ein/Aus zu zwei kurzen Ein, gefolgt von einem längeren Aus - auch das kann ich oben irgendwie nicht erkennen. Bleibt wieder die Frage, ob die Box gar nicht bis zu diesem Punkt kommt oder ob die Beschreibung zu ungenau war/ist.

Jedenfalls ist so ein Dauer-"ping" ohnehin das denkbar schlechteste Diagnosewerkzeug ... da ist sogar ein Switch noch genauer, weil der dann irgendwann das "media sense" anzeigt. Die Gründe für ausbleibende Antworten auf ein "ping" können eben vielfältig sein und man kann aus dem Fehlen einer solchen Antwort praktisch nicht darauf schließen, wo die Box nun gerade sein könnte bei ihrer Initialisierung.

Die angegebenen Zeiten sind auch nur "Richtwerte", die schwanken je nach Ausstattung der Box und nach angeschlossener Peripherie bzw. nach Verbindungen zur Außenwelt - aber daß sich über 120 Sekunden bei einer startenden FRITZ!Box außer der Power-LED so gar nichts rührt (kein USB und nichts) und es nicht einmal das "andere Blinken" beim Versuch der Synchronisation gibt, ist schon sehr ungewöhnlich.

Von der Beschreibung mit den vier oder fünf ICMP-Replies her würde ich auf WLAN-Probleme tippen (das kommt halt direkt nach dem LAN), wenn ich mir denn sicher wäre, daß das nicht nur die Antworten des Bootloaders bei irgendeinem erneuten Startversuch sind - da aber auch der sich durch das gleichzeitige kurze "Aufflackern" aller LEDs ankündigt (erst recht bei einer Boot-Schleife), bin ich ggü. der bisherigen Schilderung halt noch sehr skeptisch.

- - - Aktualisiert - - -

Bei allem (ohnehin nicht übermächtigen) Verständnis für "ich kann nicht alles gleichzeitig lesen" ... aber ein "normales" AVM-Image direkt auf die Box zu laden, ohne es erst mit "image2ram" umzuwandeln, zeugt auch davon, daß Du hier in diesem sehr kurzen Thread (und sogar in den mehr oder weniger an Dich gerichteten Antworten) schlicht "nicht aufgepaßt" hast.

Außerdem kann man bei jedem Bootversuch nur ein einziges Mal ein Image hochladen ... hier gab es mindestens zwei Versuche. Man sieht es daran, daß der installierte Speicher bereits um die Größe des Images verringert wurde - normalerweise würde der bis 0x90000000 gehen.

- - - Aktualisiert - - -

Theoretisch funktionieren vielleicht sogar mehrere Image-Uploads - solange die integralen Grenzen stimmen. Aber auch darauf würde ich mich erst dann verlassen, wenn ich es selbst erfolgreich getestet habe und da Du hier ja noch auf der Suche nach dem Stein der Weisen bist, der das überhaupt erst einmal ins Rollen bringen soll, würde ich nicht gleich mit einer Übung für "advanced users" starten.
 
Zuletzt bearbeitet:
Okay, das Freetz image ist jetzt auf der Box - Halleluja!
Ich kann allerdings nicht behaupten, zu wissen, wie genau ich das geschafft habe.

Ja, Du hast recht, ich hab das zwischendurch auch mehrmals hintereinander ohne Neustart versucht, dann aber nach Neustart nochmal von vorne.
Hat aber leider auch nicht zum Erfolg geführt.

Jedenfalls habe ich dann versucht ein Recover durchzuführen, was jedoch mit Fehlermeldung (Firmware der Fritzbox 7490 ist mit der Recover Firmware inkompatibel) beendet wurde. Durch diesen Thread angeregt habe ich die Variablen firmware_version auf avme und firmware_info auf 113.06.83 gesetzt und die recover.exe nochmal laufen lassen.
Da kam dann:
Fritzbox 7490 suchen an 192.168.178.1
Fritzbox 7490 suchen an 0.0.0.0
Fritzbox 7490 suchen an 0.0.0.0
Fritzbox 7490 suchen an 0.0.0.0
Das wiederholte sich zig male.
In firmware_info stand dann mal "113.06.83,recovered=3" und kurz darauf gar nichts mehr.
Irgendwann habe ich das Recover abgebrochen.
Dann hab ich wieder auf die Box geschaut und gesehen, dass die WLAN LED an ist und hab ein nmap gemacht.
Als ich gesehen hatte, dass jede Menge Ports offen waren, hab ich mich am Webinterface angemeldet, und siehe da, Freetz war drauf.

Nochmal vielen herzlichen Dank für Deine Geduld und Unterstützung.
Ich verstehe, dass Du manchmal leicht genervt bist, wenn ich (oder andere) so schwer von Begriff sind und / oder nicht genau lesen (oder "aufpassen", wie Du sagst).
Soll jetzt keine Ausrede sein, aber ich hatte einen stressigen Tag und meine Aufmerksamkeit ist auch nicht grenzenlos.
Morgen muss ich wieder arbeiten (eigentlich sollte ich nur Mo-Fr arbeiten müssen) und ich wollte halt noch nicht aufgeben.

Wenn ich mir konzentriert anlesen könnte, wie z. B. der Bootvorgang genau abläuft, wie der Bootloader funktioniert, wie freetz im Detail arbeitet und solche Sachen, würde ich das gerne machen. Ist aber mit einer zugegeben schwachen Basis im Selbststudium leider nicht ganz einfach, die verfügbare Informationsflut zu sortieren und zu filtern.

Ich bin jedenfalls froh, dass ich diese Hürde auch irgendwie überwunden habe.
Hätte ich ohne Hilfe sicher nicht geschafft.

Danke nochmal und Gruß
maceis
 

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.