[Problem] Aktuell bootet kein 7490 und 7590AX Image mehr (selbst getestet) Ergänzung patchelf probleme

[Master SaMMy]

So ich habe freetz neu ausgecheckt und habe ein Image gebaut, es per GUI auf die Box gebracht, kein Boot mehr. LED blinkt 4 Mal Power LED bleibt dauerhaft an. Auch nach 30 Min. das gleiche Spiel.

Das gleiche Spiel habe ich, wenn ich es Push.

Ein Image mit FREETZ_FWMOD_SKIP_MODIFY kann ich Pushen auf die Box und es läuft dann auch

EDIT:1
Auf der 7530AX gibt es keine Probleme

Wie ich es mir gedacht habe! Es liegt genau wie ich es mir gedacht habe am Patchelf
Bis hier hin bootet die Images

uboot: rename static-ssl option · Freetz-NG/freetz-ng@a979218

Freetz-NG firmware modification for AVM devices like FRITZ!Box - uboot: rename static-ssl option · Freetz-NG/freetz-ng@a979218

github.com

Benutzt man dann genau das nächste Update was ja der patchelf bump ist

bump patchelf-host · Freetz-NG/freetz-ng@832d680

Freetz-NG firmware modification for AVM devices like FRITZ!Box - bump patchelf-host · Freetz-NG/freetz-ng@832d680

github.com

Läuft nichts mehr 7490

Wenn es einer auch testen will.

git clone https://github.com/Freetz-NG/freetz-ng test
cd test
git checkout a979218b72b67fb247020af2238eb75099a8b46f
make menuconfig
(7490 aussuchen)
make -j10
Das Image wird auf der Box Booten

git checkout 832d680eaa3b4f37e5c63bec65c449cd6e4c10ac
make menuconfig
nur speichern
make -j10
Das Image Bootet nicht mehr

Nachtrag
Die 7590 kann man auch dazuzählen. Zwar nicht von mir selber getestet, aber von einem anderen User gehört .

 

[JohnDoe42]

Zumindest den Teil zur 7490 kann ich bestätigen - mit der .config aus dem Anhang und den aktuellen Repo-Stand ist kein bootendes Image zu bauen.
Sollten man hierzu ein Ticket im Repo anlegen ?
Grüße

JD.

 

[Master SaMMy]

Wenn du aus deiner .config das löscht

# FREETZ_TOOLS_PATCHELF_VERSION_ABANDON is not set
FREETZ_TOOLS_PATCHELF_VERSION_CURRENT=y

und dann ein
make
machst, sollte es eigentlich gehen

 

[Master SaMMy]

Also ich habe nun 2 Lösungen für mich gefunden
die erste ist

Spoiler: Downgrade für patchelf

--- make/host-tools/patchelf-host/patchelf-host.mk    2023-01-31 18:54:41.165334399 +0100
+++ make/host-tools/patchelf-host/patchelf-host.mk    2023-01-31 20:51:19.649189466 +0100
@@ -1,18 +1,13 @@
-$(call TOOLS_INIT, $(if $(FREETZ_TOOLS_PATCHELF_VERSION_ABANDON),0.14.5,0.17.2))
+$(call TOOLS_INIT, 0.14.5)
 $(PKG)_SOURCE:=patchelf-$($(PKG)_VERSION).tar.bz2
-$(PKG)_HASH_ABANDON:=b9a46f2989322eb89fa4f6237e20836c57b455aa43a32545ea093b431d982f5c
-$(PKG)_HASH_CURRENT:=bae2ea376072e422c196218dd9bdef0548ccc08da4de9f36b4672df84ea2d8e2
-$(PKG)_HASH:=$($(PKG)_HASH_$(if $(FREETZ_TOOLS_PATCHELF_VERSION_ABANDON),ABANDON,CURRENT))
+$(PKG)_HASH:=b9a46f2989322eb89fa4f6237e20836c57b455aa43a32545ea093b431d982f5c
 $(PKG)_SITE:=https://github.com/NixOS/patchelf/releases/download/$($(PKG)_VERSION),https://releases.nixos.org/patchelf/patchelf-$($(PKG)_VERSION)
 ### WEBSITE:=https://opencollective.com/nixos
 ### MANPAGE:=https://sources.debian.org/patches/patchelf/
-### CHANGES:=https://github.com/NixOS/patchelf/releases
+### CHANGES:=https://github.com/NixOS/patchelf/commits/master
 ### CVSREPO:=https://github.com/NixOS/patchelf
 
-$(PKG)_CONDITIONAL_PATCHES+=$(if $(FREETZ_TOOLS_PATCHELF_VERSION_ABANDON),abandon,current)
-$(PKG)_REBUILD_SUBOPTS += FREETZ_TOOLS_PATCHELF_VERSION_ABANDON
-
-$(PKG)_CONFIGURE_OPTIONS += --prefix=/
+$(PKG)_CONFIGURE_OPTIONS += --prefix=/usr
 
 
 $(TOOLS_SOURCE_DOWNLOAD)
--- config/ui/toolchain.in    2023-01-31 18:54:41.029336525 +0100
+++ config/ui/toolchain.in    2023-01-31 20:51:19.645189537 +0100
@@ -8,8 +8,7 @@
     config FREETZ_DOWNLOAD_TOOLCHAIN
         bool "Use precompiled x86_64 toolchains"
         depends on FREETZ_REAL_DEVELOPER_ONLY__DLTCS
-        depends on !FREETZ_ANCIENT_SYSTEM
-
+       
     config FREETZ_BUILD_TOOLCHAIN
         bool "Build own toolchains (4GB diskspace)"
 
@@ -17,7 +16,6 @@
 
 config FREETZ_TOOLCHAIN_CCACHE
     bool "Build ccache for kernel and target"
-    depends on !FREETZ_ANCIENT_SYSTEM
     default y
     help
         ccache is a compiler cache. It acts as a caching pre-processor to C/C++
@@ -809,21 +807,6 @@
 
 comment "Host-tools options ----------------------------------"
 
-choice
-    prompt "Patchelf compatibility" if !FREETZ_HOSTTOOLS_DOWNLOAD
-        default FREETZ_TOOLS_PATCHELF_VERSION_CURRENT
-
-    config FREETZ_TOOLS_PATCHELF_VERSION_ABANDON
-        bool "gcc 5"
-        depends on !FREETZ_HOSTTOOLS_DOWNLOAD
-        help
-            For usage with old Ubuntu 14
-
-    config FREETZ_TOOLS_PATCHELF_VERSION_CURRENT
-        bool "gcc 7"
-        depends on !FREETZ_ANCIENT_SYSTEM
-
-endchoice
 
 config FREETZ_TOOLS_UBOOT_STATIC
     bool "Build U-Boot with static OpenSSL"
@@ -853,7 +836,6 @@
 
 config FREETZ_HOSTTOOLS_DOWNLOAD
     bool "Use precompiled x86_64 host-tools"
-    depends on !FREETZ_ANCIENT_SYSTEM
     default y
     help
         Download and use precompiled binaries files. Not

Oder man muss bei allen mips boxen immer von gcc 7

auf gcc 5 umstellen

Da es aber auf den arm Boxen keine Probleme gibt, weiß ich nicht, ob der Downgrade nötig ist
Oder fda ändert es in den entsprechenden Dateien in freetz-ng ab, sodass bei den mips Geräten dann erst mal weiterhin patchelf 0.14.5 genutzt wird.

 

[FritzM]

Ein freetz im Betreff wäre prima!
Fritz Tztztz!

 

[KunterBunter]

Du meinst, der Beitrag ist hier im Unterforum Freetz-NG genau richtig?

 

[Master SaMMy]

Ja ist er denn es geht hier um die freetz-ng fehler

 

[JohnDoe42]

Wenn du aus deiner .config das löscht

# FREETZ_TOOLS_PATCHELF_VERSION_ABANDON is not set
FREETZ_TOOLS_PATCHELF_VERSION_CURRENT=y

und dann ein
make
machst, sollte es eigentlich gehen

Ich kann das leider nicht bestätigen.

Ich habe zu Beginn ein Recovery gemacht und anschließend ein Minimalimage mit der .config im Anhang gebaut.
Selbiges dann mit /tools/image2inmemory konvertiert:

./tools/image2inmemory images/7490_07.29.all_freetz-ng-21195-41db941cc_20230202-120337.image images/7490_07.29.all_freetz-ng-21195-41db941cc_20230202-120337.in-memory
Reading /home/john/Githubs/freetz-ng/images/7490_07.29.all_freetz-ng-21195-41db941cc_20230202-120337.image
Writing /home/john/Githubs/freetz-ng/images/7490_07.29.all_freetz-ng-21195-41db941cc_20230202-120337.in-memory
Success!

Das folgende Flashen via EVA-FTP-Client1.ps1 lief fehlerfrei durch. Bis hierhin alles unauffällig.

Nach einem folgenden Reboot erreichte ich leider nur das Fritz-WebIF, auf Port 81 lauschte nichts. Daraufhin habe ich im Bootloader den Parameter linux_fs_start abgefragt, Ergebnis: Der Parameter existiert nicht. Ein folgendes Setzen dessen auf linux_fs_start = 1 ergab eine nicht bootende Box.

Grüße

JD.

 

[Master SaMMy]

Schau mal hier

[Problem] - Aktuell bootet kein 7490 und 7590AX Image mehr (selbst getestet)

So ich habe freetz neu ausgecheckt und habe ein Image gebaut, es per GUI auf die Box gebracht, kein Boot mehr. LED blinkt 4 Mal Power LED bleibt dauerhaft an. Auch nach 30 Min. das gleiche Spiel. Das gleiche Spiel habe ich, wenn ich es Push. Ein Image mit FREETZ_FWMOD_SKIP_MODIFY kann ich...

www.ip-phone-forum.de

 

[JohnDoe42]

Bei mir leider auch negativ.
Ein

git checkout a979218b72b67fb247020af2238eb75099a8b46f

mit anschliessendem Bau des .configs aus #8 nebst

quote SETENV linux_fs_start 1

endet in einer nicht bootenden Box.

 

[Master SaMMy]

Es ist doch schon alles gepatcht, wie soll das dann bitte gehen.

git checkout a979218b72b67fb247020af2238eb75099a8b46f
make patchelf-host-dirclean
make patchelf-host-precompiled FREETZ_VERBOSITY_LEVEL=2
make menuconfig

Und wie gesagt auf gcc 5 umstellen (sorry das brauchst du ja nicht zu machen, denn bist ja vor den patchelf bump)

 

[PeterPawn]

Daraufhin habe ich im Bootloader den Parameter linux_fs_start abgefragt, Ergebnis: Der Parameter existiert nicht. Ein folgendes Setzen dessen auf linux_fs_start = 1 ergab eine nicht bootende Box.

Kaum verwunderlich. Wie sich die Box (bzw. der Bootloader) hinsichtlich einer fehlenden(!) Variablen linux_fs_start verhält, ist mehrfach beschrieben - es wird eben schlicht ein Wert von 0 angenommen.

Solange man das OS sich aus dem RAM selbst installieren läßt (die Alternative wäre ein Update über das FRITZ!OS), ändert sich da auch nichts - es wird in die Partitionen für das AKTIVE System installiert und dann gibt es auch keine Notwendigkeit, die Variable linux_fs_start irgendwie neu zu schreiben, so daß sie dann NIEMALS auf den Wert 0 oder 1 gesetzt wird.

Und solange in die Partitionen (bei AVM heißt das ja inzwischen "slot") für linux_fs_start=1 kein OS installiert wurde (und das macht eben NUR ein Update, weder das AVM-Recovery noch irgendeine andere Methode, ein Image ins RAM der Box zu laden), solange wird man daraus auch nicht booten können. Wer würde dann da etwas anderes erwarten?

 

[JohnDoe42]

Nach dem gestrigen Patch habe ich mit der .config im Anhang ein Minimal-Image gebaut.
Der anschließende Flashversuch lief so:

PS E:\YourFritz-main\eva_tools> .\EVA-FTP-Client-Rev.ps1 169.254.95.1 -Verbose -Debug -Scriptblock { BootDeviceFromImage .\latest.image}
DEBUG: Response:
220 ADAM2 FTP Server ready
================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2
================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in
================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.1964 0x0 0x740D
================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000
200 GETENV command successful
================
DEBUG: Memory size found    : 0x10000000 (256 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x00000084
DEBUG: Set memory size to   : 0x07ffff7c
DEBUG: Set MTD RAM device to: 0x87ffff7c,0x88000000
DEBUG: Sent
SETENV memsize 0x07ffff7c
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87ffff7c,0x88000000
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY
================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM
================
DEBUG: Uploading file '.\latest.image' to '0x87ffff7c 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (169,254,95,1,12,10)
================
DEBUG: Sent
STOR 0x87ffff7c 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection
================
DEBUG: Upload completed, waiting 5 seconds for acknowledgement ...
DEBUG: Response:
553 Execution failed.
================
DEBUG: Sent
SETENV memsize 0x10000000
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set
================
DEBUG: Sent
QUIT
================
DEBUG: Response:
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In E:\YourFritz-main\eva_tools\EVA-FTP-Client-Rev.ps1:646 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Die Box bootet nicht.

 

[Master SaMMy]

Also ich weiß ja nicht so recht auf einigen Boxen läuft es wieder. Aber auf dem 1750E stecke ich nun in der Reboot schleife.

Problem besteht weiter hin.

 

[PeterPawn]

DEBUG: Image size found : 0x00000084

Ich weiß ja nicht so genau, was dieser "Bericht" Deinerseits bewirken soll - ich fühle mich also mal max. für die korrekte Funktion des Powershell-Skripts zuständig und das arbeitet - nach meiner Ansicht - zuverlässig.

Ein korrektes Image kann keinesfalls nur 0x84 = 132 Bytes groß sein - Du solltest also noch einmal Dein ./latest.image überprüfen. Da Freetz-NG das ja nicht selbst erzeugt, mußt Du ja noch irgendwelche ZUSÄTZLICHEN Verarbeitungsschritte vornehmen lassen (ich hoffe mal INSTÄNDIG, daß das nicht wieder in Wahrheit das TAR-File sein möge, was von Freetz-NG erzeugt und unter diesem Namen "verlinkt" wird), wobei mir auch die Phantasie fehlt, wie man zu einer Image-Datei von 132 Byte kommen sollte, denn ein (gültiges) TAR-Archiv ist (aus dem Kopf) schon mind. 1536 Bytes groß (ein Header à 512 Byte für eine Datei mit 0 Byte Inhalt + 2 EOF-Blöcke à 512 Bytes, gefüllt mit binären Nullen).

Da stimmt also irgendetwas mit der angegebenen Datei nicht ... angesichts der Größe würde ich sogar darauf tippen, daß das in Wahrheit ein Symlink irgendwohin ist (das wäre im Freetz-NG-Kontext ja tatsächlich so, denn da ist das nur ein Symlink auf die zuletzt erzeugte Image-Datei) und beim Kopieren wurde dann nur dieser Symlink übertragen und nicht die Datei, auf die der eigentlich zeigt.

 

[Master SaMMy]

So ich habe mal ein paar Informationen noch bezüglich der 7490 1750E. Beim Testen ist mir aufgefallen (Image immer gleiche gebaut nur einmal mit patchelf 0.17.5 und einmal mit 0.14.2). Dass die Images unterschiedlich groß sind (ok sagt jetzt nicht, weil es unterschiedlichen patchelf Versionen sind)
Dieses Image mit der Größe läuft z.B. nicht 16,7 MB (16.660.480 Bytes) dafür das schon 16,7 MB (16.711.680 Bytes). Es ist jedes Mal ein Image für den 1750E. Nun kommt aber noch ein komisches Verhalten dazu. Was mir bei dem 7490 aufgefallen ist (da gibt es auch unterschiedliche Größen bei den Images)(nur leider alle gelöscht). Das, um ein paar Bytes kleinerer Image lässt sie zwar per push auf die Box bringen, nur rebootet er nicht selber, ich muss denn Stecker ziehen. Was aber mit den Images, was ein paar Bytes größer ist nicht so ist. Da macht die Box alles selber.

Was auch ein sehr lustiges Verhalten ist, wird ein Image für den 1750E gebaut läuft dieses auch ohne Probleme, wenn ich aber nun eins für die 7490 im gleichen Verzeichnis baue, bekomme ich ein Image was nicht lauffähig ist und beide sind Mips Geräte.

Daher nutze ich jetzt für alle Mips Geräte ein downgrade. Weil ich kann, doch nicht jedes Gerät in einem eigenen Verzeichnis bauen oder testen, welche geht und welche nicht.

 

[hermann72pb]

... Weil ich kann, doch nicht jedes Gerät in einem eigenen Verzeichnis bauen oder testen, welche geht und welche nicht...

Doch, ist leider so @Master SaMMy . Ich habe auch 3-4 Arten von Boxen und baue auf meinem Dual-Boot-Notebook, wo der Platz auf integrierter SSD auch recht knapp ist. Ich lege dafür pro Box je ein Ordner, wie z.B. 1750, 2400, 7490, 7590, um allerdings Platz zu sparen, verlinke ich solche Sachen wie dl und ein Paar "allgemeine Ordner" zu einem gemeinsamen Ordner oberhalb dieser Ordnerstruktur. Das mache ich schon seit Jahren so, mittlerweile wurde das schon bei FREETZ NG zum Teil sogar "intergriert" (mit dem dl). Dieses Mal um Jahreswende herum hatte ich das Gleiche noch mit der toolchain versucht und kam zu ähnlichen Ergebnissen wie du. Bei mir waren allerdings 1750 und 7590 im Spiel, die unterschiedliche Struktur haben und unterschiedliche "Tools" (ich meine, die hatte ich auch ausgelagert gehabt, wenn ich mich jetzt richtig erinnere) und unterschiedliche Toolchains. Dennoch kannich auch ähnliche "Seiteneffekte" wie du bestätigen:

• 1750 frisch ausgecheckt - Image gebaut - geflasht ==> läuft
• 7590 frisch ausgechekt - Ordner auf bestehende verlinkt - Image gebaut - geflasht ==> läuft
• 1750 versucht zu bauen ==> bricht beim make mit unerklärlichen Fehlern in der Toolchain oder beim bauen/benutzen von tools ab

Ok, das erste "läuft" ist etwas gelogen, aber da lief es nicht aufgrund eines anderen Fehlers von cuma im rc-Skript für alle Repeater. Da war eine andere Geschichte im Spiel. Auf jeden Fall musste ich leider meine Experimente mit dem gemeinsamen Nutzen der Ornder "Toolchain", "Tools" usw. einstellen. Das war die Konsequenz für mich. Ich bin da kein Crosscompiler-Experte dafür, um es zu erklären, behaupte aber hier spekulativ, dass da beim Bauen der Toolchain und aller Tools an solche "Querverlinkungen" nicht gedacht wird und noch "oben drauf" eigentlich davon ausgegangen wird, dass da alles frisch ausgecheckt und neu gebaut wird. Sprich, wenn in den Ordnern bereits was liegt und was Neues als "drüber gebüggelt" da gebaut wird (entspricht auch deinem im gleichen Ordner für unterschiedliche Modelle zu bauen), dann hat es solche komische "Seiteneffekte". Darum sage ich es bei FREETZ NG vermehrt und immer öfter hier: Leider muss man solche Experimente unterlassen und im Zweifelsfall immer wieder neu auschecken und in einem völlig neuen Ordner von vorne anfangen, angefangen von der Toolchain und Tools. Früher war es gefühlt diesbezüglich etwas stabiler und unempfindlicher. Aber es hilft wahrscheinlich nicht zu meckern, müssen wir leider damit leben.

 

[Master SaMMy]

Wie gesagt, ich nutze mein Script i-matik welches mir unter freetz-ng diese Verzeichnisse macht.

arm
686
mips
mipsel

Und ich nutze nun bei den mips und mipsel denn Downgrade aus Thread 4 und habe keine Probleme mehr. Ich weiß, dass das so auch keine Lösung ist. Aber es hilft ;-)

 

[JohnDoe42]

Hallo zusammen, ich möchte doch nurz nochmal un Hilfe ersuchen.

Ich habe eine 7490 mit einer offiziellen 6.24 recovert. Dies lief normal.
Danach habe ich versucht, ein Minimal-Image aus dem Freetz-NG-Repo über das WebIF zu flashen, Ergebnis:



Im Anschluss habe ich versucht, mit den eva-tools ein Original-Image zu flashen, Ergebnis:

PS E:\YourFritz-main\eva_tools> .\EVA-FTP-Client.ps1 169.254.95.1 -Verbose -Debug -Scriptblock { BootDeviceFromImage .\FRITZ.Box_7490-07.29.image}
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.1964 0x0 0x740D

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x10000000 (256 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x02111000
DEBUG: Set memory size to   : 0x05eef000
DEBUG: Set MTD RAM device to: 0x85eef000,0x88000000
DEBUG: Sent
SETENV memsize 0x05eef000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x85eef000,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file '.\FRITZ.Box_7490-07.29.image' to '0x85eef000 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (169,254,95,1,12,0)

================
DEBUG: Sent
STOR 0x85eef000 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
553 Execution failed.

================
DEBUG: Sent
SETENV memsize 0x10000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In E:\YourFritz-main\eva_tools\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Nach zehnminütigem Abwarten und Stecker ziehen landet die Box allerdings wieder bei 6.24. Hat noch jemand einen Tip für mich, wie ich ein Image auf 7.29 basierend flashen könnte ?
Grüße

JD.

 

[PeterPawn]

Das ist WIEDER kein Image im "in-memory"-Format. Period.