Elend langsames Erzeugen eines Recovery-Programms für Windows

[Parallix]

Nach einiger Zeit habe ich mal wieder eine neue Fw gebaut und dabei erschreckt festgestellt, dass jetzt auch ein "PE32 executable for MS Windows (GUI) Intel 80386 32-bit" erzeugt wird. Als glückliche(r) Linux-BenutzerIn fragt man sich natürlich, wozu das Windows Executable dient und ob man die nun deutlich (!) länger dauernde Erzeugung nicht irgendwo abschalten kann. Wenn schon ein Executable, wäre dann nicht Java das Format der Wahl um alle Betriebssysteme zu bedienen?

Parallix

PS: Werde die Fw morgen mal an T-ADSL1000 testen. Oder gibt's von Eurer Empfehlungen, dies besser nicht zu tun?

 

[Jörg S.]

...festgestellt, dass jetzt auch ein "PE32 executable for MS Windows (GUI) Intel 80386 32-bit" erzeugt wird. ... deutlich (!) länger dauernde Erzeugung nicht irgendwo abschalten kann.

Bei mir wird zwar nichts von Windows angezeigt (könnte am Linux liegen), aber offenbar ist neuerdings eine Option "Build Recover Firmware" bei den "Optional Settings for Speed-to-fritz" vorausgewählt, die ewig braucht, um eine Recover .exe zu erstellen. Ich hatte schon gedacht, das Script hätte sich aufgehängt (und es deswegen ungeduldigerweise abgebrochen... ) und mich schon gar nicht mehr getraut, die vorher ja schon erzeugte Firmware zu benutzen.

Tschüs,

Jörg,
der gleich die frisch gebraute "fw_C_7570_75.04.94-15316_Fritz_Box_7570_54.04.78-15496-sp2fr-09.10.23-r-616M-1190_OEM-avm_annexB.image" testen wird...

 

[skyteddy]

Die Option "Build Recover Firmware" gehört in meinen Augen per default abgeschaltet. Wer braucht das schon?

Und obendrein dauert die Erzeugung 1,5 mal so lange, wie die ganze Firmwareerzeugerei :-( Auf meiner alten Linux-Büchse kann man es kaum erwarten.

Happy computing!
R@iner

 

[Jpascher]

Bin anderer Meinung, sonst hätte ich es nicht eingeschaltet.

Du weist ja wo du das Abschalten kannst. Oder Controll C reicht ja auch wenn du keine gepätchtes Recover erzeugen willst.

Derzeit braue ich noch dringend mehr Rückmeldungen zur gepätchten Recover Firmware.

Bezüglich Zeit: Das umpacken dauert etwas lange, eine schnellere Lösung als das bytweise kopieren wäre gefragt! vielleicht hat einer der Linux Experten mal eine blick drauf ob man das nicht auch mit alternativen Methoden schneller schafft.

 

[Parallix]

Elend langsame Erzeugung eines Recovery-Executables

Bin anderer Meinung, sonst hätte ich es nicht eingeschaltet.

Unter demokratischen Gesichtspunkten müßte es aber wohl abgeschaltet werden. Wenn jemand ein Recovery braucht, dann kann er dieses ja auch jederzeit nachträglich erstellen.

Du weist ja wo du das Abschalten kannst. Oder Controll C reicht ja auch wenn du keine gepätchtes Recover erzeugen willst.

CTRL-C und der Affengriff sind Dinge, die man normalerweise nur dann einsetzen sollte, wenn die Soft- oder Hardware nicht ordentlich läuft.

Derzeit braue ich noch dringend mehr Rückmeldungen zur gepätchten Recover Firmware.

Da die Anzahl der Leute, die eine Recover-Firmware benötigen wohl eher gering ist, werden sich wahrscheinlich ja nicht so viele melden.

Bezüglich Zeit: Das umpacken dauert etwas lange, eine schnellere Lösung als das bytweise kopieren wäre gefragt! vielleicht hat einer der Linux Experten mal eine blick drauf ob man das nicht auch mit alternativen Methoden schneller schafft.

Wenn Du mir mal kurz erläuterst, was Du wo umpackst, kann ich mir das gerne mal ansehen.

 

[Jpascher]

Wenn Du mir mal kurz erläuterst, was Du wo umpackst, kann ich mir das gerne mal ansehen.

Es gibt ein Untererzeichnis:
recoversubscripts

In diesen Verzeichnis findest du einige Files die sollten eigentlich selbsterklärend sein.
Aufgerufen werden die von build_new_recover_firmware.
Prinzipiell könnte man den patch auch nach windows portieren es werden ja keine speziellen Linux Tools verwendet für die es keinen Ersatz in Windows gibt.

 

[Parallix]

Es gibt ein Untererzeichnis:
recoversubscripts

In diesen Verzeichnis findest du einige Files die sollten eigentlich selbsterklärend sein.
Aufgerufen werden die von build_new_recover_firmware.
Prinzipiell könnte man den patch auch nach windows portieren es werden ja keine speziellen Linux Tools verwendet für die es keinen Ersatz in Windows gibt.

Du verwendest ein dd mit ibs=1, also einer Input-Blocksize von einem (!) Byte. Das ist naürlich fatal. Schneller würde es hier mit einer größeren Blocksize. Dann kann man aber in der Regel count nicht mehr dazu verwenden, eine exakte Anzahl von Bytes zu kopieren. Ein Trick, den ich einsetzen würde wäre, die allgemeine Blocksize bs auf die Anzahl der zu kopierenden Bytes zu setzen, hier bs=$exe_length, und dann mit count=1 (kann man hier sogar weglassen) genau einen Block kopieren. Auf das Setzen unterschiedlicher Input- bzw. Output-Blocksizes also ibs bzw. obs kann man dann verzichten.

Gruß

Parallix

 

[Jpascher]

Sehr gut werde ich gleich mal ausprobieren!

Kann ich dann noch skip verwenden?

 

[Parallix]

Schnelles Recovery-Executable

Sorry, das skip hatte ich übersehen.

Sehr gut werde ich gleich mal ausprobieren!

Kann ich dann noch skip verwenden?

Jein!

Skip arbeitet natürlich noch, aber die Anzahl der zu überspringender Bytes ist dann zu groß. Performante Abhilfe hilft hier eine Verbundanweisung:

( dd bs=$bytes_to_skip seek=1 count=0 && dd bs=$bytes_to_copy ) < "$input_file" > "$output_file"

Gruß

Parallix

 

[Parallix]

Erstellung eines Recovery-Executables für Windows mit Linux

@Jpascher: Hat meine Vorschlag

...

funktioniert?

 

[Jpascher]

Ja, so einigermaßen habe jetzt gerade die Änderungen hoch geladen.

seek=1 scheint nicht zu machen was es sollte, hab es nun etwas anders realisiert.


( dd of="/dev/null" ibs=$offs obs=8192 count=1 2> /dev/null && dd of="$output_file" ibs=$size obs=8192 count=1 2> /dev/null ) < "$input_file"

 

[Parallix]

Hallo Johann!

Uhren schon umgestellt ;-)

Ja, so einigermaßen habe jetzt gerade die Änderungen hoch geladen.

seek=1 scheint nicht zu machen was es sollte, hab es nun etwas anders realisiert.


( dd of="/dev/null" ibs=$offs obs=8192 count=1 2> /dev/null && dd of="$output_file" ibs=$size obs=8192 count=1 2> /dev/null ) < "$input_file"

Wie lautete denn Deine Zeile mit seek? O.g. Realisierung ist auch OK und orientiert sich ja auch weitgehend an meinem Vorschlag. Warum Du aber immer noch ibs und obs unterschiedlich setzt, ist mir unklar.

 

[Jpascher]

Wie lautete denn Deine Zeile mit seek?
Habe alle Möglichkeiten durchprobiert, ich wenn es sein muss rekonstruiere ich alle Varianten nochmal.
Auch die folgende Variante funktioniert nicht:
( dd of="/dev/null" bs=$offs skeep=1 2> /dev/null && dd of="$output_file" ibs=$size obs=8192 count=1 2> /dev/null ) < "$input_file"

O.g. Realisierung ist auch OK und orientiert sich ja auch weitgehend an meinem Vorschlag.

Stimmt!

Warum Du aber immer noch ibs und obs unterschiedlich setzt, ist mir unklar.

Ich bin dem nicht weiter nachgegangen warum die Angabe von obs=8192 unbedingt erforderlich ist, ohne dieser Angabe werden aber fehlerhafte Files produziert.

 

[Albert75]

Bei mir sind es 34 Sekunden ohne exe und 62 mit. Pessimistisch ausgedrückt doppelt so lang oder 100 % mehr. Ich finde es nicht schlimm und man kann es ja vorher auswählen. Aber da hat eben jeder seine eigene Meinung. An sich finde ich die exe sehr gut, wenn man die Firmware in einen Haushalt trägt, wo nur Windows-Rechner stehen.