ds-mod 0.2.9 läßt sich nicht auf flashen - FRITZ!Box Fon

[kriegaex]

Das Firmware-Update ist fehlgeschlagen:
Es trat ein nicht näher spezifizierter Fehler während des Updates auf.

Der Dauerbrenner. ;-)

Ich nehme an, Du baust entweder mit einem aktuellen Cygwin oder einer Linux-Distribution, die schon tar 1.16 verwendet (z.B. Debian unstable). Da gibt es ein Problemchen mit dem erzeugten tar-Format. Letzteres wird vom bereits etwas älteren tar auf der Original-Fritz!Box-Firmware nicht verstanden - trotz des im Build gesetzten "oldgnu"-Schalters.

Abhilfe: Älteres tar benutzen. Ich benutze in cygwin das an jenem Thread als Anhang hängende und modifiziere meine Datei fwmod gemäß meiner Beschreibung in diesem Thread, etwas weiter oben.

Abhilfe-Alternative: FriBoLi benutzen. Such einfach mal danach im Forum. Es handelt sich um ein fürs Firmware-Kompilieren vorkonfiguriertes Linux als VMware-Image.

P.S.: Das Forum hat eine Suchfunktion...

 

[d4rkm3n]

hallo!
danke für die schnelle Antwort! Über die Suchfunktion bin ich ja auch in diesen Thread gelangt
und du hast recht! Ich verwende Debian unstable!
Ich werde dann mal mir FriBoli besorgen danke für deine Hilfe.
gruß d4rkm3n

 

[han-solo]

wirklich ein tar Problem?

Hallo,

wie könnt ihr euch dies erklären:
Ich habe vor geraumer Zeit ds-mod 0.2.8 unter Suse Linux 10.0 kompiliert und meine 7170 damit geflashed. Die Box hat zwar 2-3 mal gemault, aber letztendlich hat sie das Image doch angenommen.

Ein Arbeitskollege hat einen Tag später ebenfalls dieses Image auf seine 7170 gespielt. Keine Probleme.

Jetzt kommt:
Ein Freund bestellte sich die 7170 ca. zwei Monate später und ich gab ihm dieses Image. Aber es lässt sich ums verrecken nicht aufspielen. Immer die gleiche Fehlermeldung, welche hier schon paarmal gepostet wurde.

Also woran liegt das nun? Vielleicht daran, dass die neue FB eine neuere Firmware drauf hat?
Würde da ein Downgrade auf die 29.04.15 helfen? Wenn das denn überhaupt funktioniert?

Gruß
HS

 

[kriegaex]

Was sagen die Logs?

Was steht denn in update_out.log und update_error.log?

 

[knox]

ich muss auch noch mal etwas öl in dieses feuer hier giessen.

ein bekannter gab mir kürzlich seine nagelneue fritzbox, um diese mit einem frischen ds-mod zu versehen. gesagt, getan - und auf einmal "ist ein nicht näher spezifizierter Fehler aufgetreten".

das ist nun wahrlich nicht der erste flash vorgang in meinem leben, aber das erst mal, dass ich mit solch ernsthaften schwierigkeiten zu kämpfen hatte.

ein blick per telnet in die firmware update logfiles lieferte die mehrfach in diesem thread beschriebene fehlermeldung "Unrecognized filetype". also ein problem mit tar??

mitnichten, bzw. nicht nur, denn was besonders verwunderlich war: exakt das selbe image hatte ich zuletzt erfolgreich auf zwei andere boxen der selben bauart (7170) geflasht?!

als erstes habe ich dann mit der recover.exe von avm ein downgrade von der vorinstallierten 29.04.22 auf 29.04.21 gemacht, aber auch damit ließ sich mein image noch nicht flashen. selbst ein weiterer downgrade auf 29.04.15 wollte das problem nicht lösen!

dann habe ich - mehr aus frust denn als zielgerichtete aktion - ein altes image aus meiner sammlung versucht, 29.04.15ds-0.2.9_20061001. und siehe da, dieses image lies sich auf einmal flashen. (an dieser stelle sei angemerkt, dass ich alle diese images auf der selben fedora büchse erstellt habe!)

und nun das dicke ende: endlich auf 29.04.15ds-0.2.9_20061001 angekommen ließ sich auf einmal auch das zuerst erfolglos probierte 29.04.21ds-0.2.9 ohne probleme flashen.

fazit: offensichtlich ist dieses problem nicht ausschließlich auf die tar-version auf dem build-system zurückzuführen. :noidea:

ergänzung:
das gerät ist laut aufkleber auf der rückseite mit "Fritz!Box 7170 Edition F" bezeichnet. steht F für "freenet"? wäre sehr komisch, da es als neuware bei amazon gekauft wurde. außerdem habe ich nach dem ersten downgrade auch die debranding firmware von haveaniceday draufgespielt, was aber das problem nicht behoben hat.

 

[kriegaex]

Das ist doch kein Öl im Feuer, sondern einfach eine wertvolle Info. Gut zu wissen, daß zwar tar eine Rolle spielt (vgl. Fehlermeldung), aber nicht nur die Version auf dem Build-System. Scheinbar hat es auch was mit der Version auf der Box zu tun, evtl. auch noch mit anderen Faktoren (obwohl ich mir kaum vorstellen kann, welche das außerdem noch sein könnten - ich bin nur vorsichtig). Evtl. spielen auch die Benutzerrechte auf der Box und im tar-File eine Rolle, ich weiß nicht. (Vermut, spekulier...)

 

[olistudent]

Natürlich hängt das tar-Problem auch von der Version und den Konfigurationsoptionen der busybox in der original Firmware ab.

MfG Oliver

 

[knox]

Natürlich hängt das tar-Problem auch von der Version und den Konfigurationsoptionen der busybox in der original Firmware ab.

das klingt einleuchtend.

aber ich verstehe nicht, wieso ich mein image auf eine box flashen kann, auf der ein 29.04.15ds-0.2.9 läuft (welches ja die 29.04.15 enthält), aber nicht auf eine box, auf der "nur" eine 29.04.15 läuft?!

die selbe frage stellt sich für 29.04.21: auf eine box mit originalfirmware krieg ich mein image nicht drauf, aber auf eine box mit gemoddeten image schon??

 

[heini66]

das hat oli doch oben schon abgehakt...
die originale busybox scheint das prob mit auszulösen.

 

[knox]

die originale busybox scheint das prob mit auszulösen.

ich dachte, die bleibt beim modden erhalten, wenn man sie nicht explizit neu compiliert? daher meine "doofe" frage...

 

[olistudent]

Nein, die busybox wird immer ersetzt.

MfG Oliver

 

[heini66]

ot

"doofe" frage

kenn ich nicht... kann man denn alles wissen?

 

[ndy2ipphone]

Auch mit dem tar 1.16 kriegt man manuell ein downgrade hin, wenn man eine
andere busybox verwendet und mit

mount -o bind /mypath/busybox /bin/busybox

die alte überschreibt. Bin auch an diesem Problem gestanden, bevor ich auf
diesen Beitrag gestoßen bin. Sonst gilt allerdings tar vor Version 1.16
verwenden. Für Linux user als root mit
wget ftp://alpha.gnu.org/gnu/tar/tar-1.15.91.tar.gz
downloaden und mit
tar -xzf tar-1.15.91.tar.gz
enpacken. Zum installieren wie gehabt:

cd tar-1.15.91
./configure
make
make install

Nach einen erneuten login als der user den dsmod bauen soll sollte
tar --version
folgende Ausgabe erzeugen:
tar (GNU tar) 1.15.91
Copyright (C) 2006 Free Software Foundation, Inc.
.....


Aber ob das auch unter cygwin baut habe ich nicht probiert. Nachdem ich
erst mit cygwin rumgespielt habe (hatte kein Linux PC daheim) und auf die Probleme mit dem flashen gestoßen bin, hab ich dann doch ein Linux in einer VMWare installiert.
SuSe 9.0 ist zu alt (tar 1.13.x), es stehen keine Update-rpms mehr zur Verfügung. Aber was anderes hatte ich nicht zur Hand. Also das tar selbst bauen. Ich bin dann hier mit version 1.16 auf die selben Probleme gestoßen, deshalb hab ich das image manuell auf die Box kopiert und mit tar entpacken wollen, was leider nicht ging. Mit einer anderen busybox (aus dem dsmod)
ging das entpacken. Einfach aus dem dsmod entnehmen und in geeigneter
Form auf die Box bringen und mit oben gen. mount Befehl einbinden.
Danach klappt dann auch das Flashen mit einem mit tar 1.16 gepacktem image, wahrscheinlich auch mit einem unter cygwin erstellten. ;-)

 

[knox]

Sonst gilt allerdings tar vor Version 1.16
verwenden.

ist nett von dir, das hier so ausführlich zu beschreiben, aber ich glaube, das manuelle bauen von tar nicht (mehr) nötig: so weit ich weiss ist das inzwischen in der toolchain mit drin, so daß immer ein "richtiges" tar verwendet wird.

 

[ndy2ipphone]

ist nett von dir, das hier so ausführlich zu beschreiben, aber ich glaube, das manuelle bauen von tar nicht (mehr) nötig: so weit ich weiss ist das inzwischen in der toolchain mit drin, so daß immer ein "richtiges" tar verwendet wird.

OK, aber die baut ja nach mehreren Aussagen hier nicht unter cygwin. Für diese User ist der Teil mit dem mount also interessant.

Evtl. möchte auch nicht jeder, zum ausprobieren des mod, 2 bis 4GB Platz (und die benötigte Zeit) verschwenden, um eine 4 - 8 MB große Datei zu erzeugen. (BTW, VMWare SuSe 9 mit allen Tools und Tar lag mit weniger als 60 Minuten und 1,2GB deutlich unter der Zeit und dem Platz, die die toolchain nach Angaben hier im Forum braucht. Wobei es sicher auch noch deutlich weniger Platz tut - ich war bei der Paketauswahl aber faul.)

Ich wollte eigentlich auch nur mal probieren, und war sauer, dass es nicht auf Anhieb funktionierte, dann hartnäckig.
Die von mir aufgewendete Zeit wollte ich anderen ersparen. Ich kannte auch den Hinweis auf die toolchain noch nicht. (Suche nach meinem Problem hier brachte zumindest keinen Hinweis.) Deshalb dieser Post.

Auch ein Download von FriBoLin hätte wohl länger gedauert.

PS: Den Links in Deiner Signatur stimme ich voll zu.

 

[papafinger]

Hi,

habe folgendes Problem (ist auch schon oft genug durchgekaut worden, aber bei mir funzt es eben nicht.)

Fakt ist:

FB 7141 mit FW 40.04.25 entbrandet, FriBoli heruntergeladen, VMPlayer installiert und gestartet. So weit so gut.

Ich habe aber unter Windows XP SP2 (neuste Patches usw.) Firewall ausgeschaltet, keinen Zugriff auf Friboli. Netzwerkkarte steht auf DHCP, kann auch überall hinpingen, aber beim Verbinden von Netzlaufwerken unter Windows muß ein Benutzername und Passwort eingegeben werden. Keines der Benutzer oder Passwörter (bofh oder root) wird anerkannt.
Kann mir irgendjemand helfen?? Please

mfg

Jens

 

[ndy2ipphone]

Ich habe ja wie gesagt nicht FriBoLi benutzt und kenne auch dessen Umfang nicht. Denke aber mal, da ist auch ein ssh-server installiert. Das ist inzwischen eigentlich bei jeder Distribution Standard. Nur um ein paar Dateien rüberzukopieren benutz doch einfach WinSCP.
Direkter Download hier. (Webseite "http://winscp.net/eng/docs/lang:de")

Der Downloadlink ist nur eine einfache Datei ausführbare Datei. Ruf die auf, gib IP des Linux Benutzername und Password an, klick auf Login und schon kannst Du zwischen beiden Rechnern im Norton Commander Stil Dateien kopieren. Um den DS-Mod drauf und das Image zurückzubekommen ist das doch völlig ausreichend.

Ich weiß nicht welche Frontends für eine Sambakonfiguration in FriBoLi enthalten sind, aber das mal eben in den Configs zu machen ist nicht unbedingt trivial, da ist ssh/scp das wesentlich Einfachere.

 

[Hammer Unslieb]

Unter Gentoo hat ein Update auf das (als unstable markierte) tar 1.16.1 nicht geholfen. Erst ein downgrade auf tar 1.15* hat geholfen. Da aber nicht jeder unbedingt den Paketmanager seines Systems umgehen möchte, hier ein etwas besserer Lösungsweg:

# Schritt 1: 
# Ein altes tar installieren, welches anschließend mit  "oldtar" aufrufbar sein soll
wget [url]ftp://alpha.gnu.org/gnu/tar/tar-1.15.91.tar.gz[/url]
tar xzf tar-1.15.91.tar.gz
cd tar-1.15.91
./configure --program-prefix=old
make
make install # als root
oldtar --version # sollte 1.15.91 anzeigen
cd ..

# Schritt 2:
# dsmod patchen, so dass der tar-Befehl einfacher auswechselbar ist.
# Dafür bitte zunächst den angehängten Patch herunterladen
gunzip ds-0.2.9-tarcmd.patch.gz
patch -p0 < ds-0.2.9-tarcmd.patch

# Schritt 3:
# dsmod-0.2.9/fwmod bearbeiten und die Zeile TAR_CMD="tar" durch TAR_CMD="oldtar" ersetzen

Der tarcmd-Patch sollte übrigens am besten auch in das normale Paket mit rein

Gruß, Roland
EDIT: Kleine Fehler korrigiert, war wohl zu müde

 

[kriegaex]

Wie wär's denn als Alternative umgekehrt? Vor einem "richtigen" FW-Upgrade ein mit altem tar gepacktes neues tar auf die Box spielen, im Ausführungsskript dafür sorgen, daß der Softlink darauf umgesetzt wird (statt auf die Busybox) und dann ganz locker ein beliebig gepacktes tar-Image einspielen?

Jetzt weiß ich bloß nicht, wie man so ein tar einzeln für MIPS baut. Eine ganze Busybox könnte evtl. für manche Boxen zu viel sein, kann ich mir vorstellen. Die mit viel Speicher oder USB können das natürlich locker.

Mal wieder laut gedacht.