[Info] FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590)

[rolex0815]

Danke, der Tipp mit dem expliziten Einstellen des "in-memory" war schon super, hatte nämlich kein solches Image kompiliert bekommen.

Wegen dem Powershell Skript kam ich nicht mehr weiter, da ich das gefunden hatte:
/howto-aendern-des-branding-und-installieren-der-retail-firmware-bei-fritz-box-cable-160

Und hier besonders "Schritt 4", da werden 4 Firmware-Files in 4 Partitionen geflasht: mtd11-mtd14

Ich versuch den Flash mit dem PS Script, da hier die Netzwerkverbindung fix steht.
Danke fürs "Anschieben".

 

[PeterPawn]

Die andere Beschreibung von @qwertz.asdfgh gilt explizit nur für die Puma6-Modelle und dort werden Kernel und Dateisystem für zwei verschiedene Architekturen gebraucht - macht zusammen halt 4 Dateien und außerdem schreibt man da auch in die eMMC-Partitionen (über den Bootloader).

Bei den MIPS-Boxen (VR9, GRX5) muß das Image in den Speicher (und nicht in irgendeine Partition) geschrieben (und dort gestartet) werden, von dort installiert es sich dann selbst in den Flash (wenn man nichts wesentliches an diesem Mechanismus geändert hat).

Ich habe mal den Text aus einem anderen Thread herausgezogen und ihn als neuen Thread eingestellt ... das sollte das "Finden" der Bedienungsanleitung für die Skripte aus "eva_tools" etwas erleichtern (EDIT: und inzwischen ist der auch "sticky").

 

[qwertz.asdfgh]

Richtig, das gilt nur für die Puma6 Modelle (und in Zukunft vielleicht auch für die Puma7 Modelle). Aber ich hatte das erst gestern auch mal für die DualBoot DSL-Boxen mit NAND-Flash beschrieben:
/howto-wie-flashe-ich-eine-fritzbox-75xx-mit-signierter-fw-ab-version-6-5x-94#p3361

 

[PeterPawn]

Sehr schön ... hatte ich noch gar nicht gesehen, sonst hätte ich mir das hier vielleicht sogar geschenkt.

Wobei ich nicht so ganz verstehe, warum Du das auf das andere Forum beschränkt hast ... auch wenn der Aufwand einer "zweimaligen Pflege" sicherlich ein nachvollziehbares Argument ist/wäre, ist die "Trefferdichte" hier vermutlich doch höher und im anderen Board habe nicht mal ich einen Account aufgemacht - ohne den sieht man aber nur die Hälfte, weil Bilder und Anhänge wohl eine Registrierung brauchen.

Das mag hier auch so sein (ich war schon lange nicht mehr "Gast"), aber eben mit der größéren Nutzerbasis und auch den höheren Zugewinnen.

 

[eisbaerin]

Das Mounten des NAND-Flashs erfolgt irgendwo in einer "/etc/init.d/Sxx-something"

Danke! Ich habe es gefunden, es ist die S15-filesys, sagt ja eigentlich schon der Name.

das mit einem "overlayfs" zu realisieren

Welche Vor- oder Nachteile hat das gegenüber "mount -o exec,remount /var/media/ftp"?

 

[PeterPawn]

Ein Verzeichnis in einem "overlayfs" ist ein Mix aus zwei anderen, von denen nur eines (das "upperdir") beschreibbar ist bzw. in dem Änderungen an irgendeiner im Mix enthaltenen Datei gespeichert werden. Damit kann man z.B. relativ problemlos eine vorhandene Datei auch in einem r/o-Verzeichnis (wie das jedes Verzeichnis in einem SquashFS-Image ist) ersetzen oder einem Verzeichnis weitere Dateien hinzufügen.

Dateien vom USB-Stick funktionieren (je nach Programm) nur dann, wenn sie für diese "abweichenden Pfade" kompiliert wurden oder dafür konfiguriert werden können ... man paßt also die Programme an die verwendete Dateisystemstruktur an. Bei der Verwendung eines "overlayfs" kann man beliebige Verzeichnisse beschreibbar machen und damit das System an das Programm (und die dort einkompilierten Standardvorgaben hinsichtlich irgendwelcher Pfade zu Dateien) anpassen.

Das geht zwar mit Mount-Kommandos mit "bind"-Option auch irgendwie, braucht aber immer eine komplette Kopie des "originalen Verzeichnisses" (was beim "overlayfs" dann das "lowerdir" darstellt) an einer beschreibbaren Stelle und damit z.B. im "tmpfs" durchaus erheblichen Platz, weil beim Kopieren vom SquashFS in ein "tmpfs"-Verzeichnis ja auch noch die Kompression der Daten flachfällt.

Wenn Du mal die tatsächlich im SquashFS liegenden Dateien zusammenzählst (gibt ~ 60 MB bei einer 7490), ist das ja deutlich mehr als die ~ 24-27 MB, die man für das SquashFS im Flash veranschlagen muß. Wenn man die alle ins "tmpfs" kopieren wollte (möglichst noch bei einer Box mit einer Gesamtgröße des RAM von 128 MB), wird es sehr schnell finster - bei der Verwendung eines "overlayfs" (was AVM nur bei den GRX-Boxen schon im Kernel hat, bei VR9 muß man es selbst hinzufügen) braucht man nur wenige Verwaltungsinformationen und den Platz für die geänderten Dateien.

 

[eisbaerin]

OK ich hätte die Frage exakter stellen sollen:
Welche Vor- oder Nachteile hat das gegenüber "mount -o exec,remount /var/media/ftp" konkret für mich bei dem NAND?

Aber um meine binarys wieder aus dem NAS ausführen zu können reicht auch das "remount"?
Da bringt mir das "overlayfs" keine Vorteile?
Aber für andere Fälle sicher sehr interessant.

Wobei Du bei der 7580 auch die Möglichkeit hättest,

Und das geht nur bei den GRX5 Modellen? Oder liegt das an der Kernel-Version?

BTW: Ich habe den Urlader als Datei gesichert da (mache ich jetzt bei jeder FB). Wenn ich meinen Fehler nur geahnt hätte, dann hätte ich den vor dem reboot mit deiner Hilfe wieder aufspielen können.
Wäre das
cp /var/tmp/mtdblock1 /dev/mtdblock1
also umgedreht wie beim Sichern gewesen?

 

[PeterPawn]

Das "overlayfs" war eigentlich nur eine Möglichkeit für Deine Suche nach einer Alternative, die ich in dem - von mir in #38 zitierten - Satz von Dir gelesen zu haben glaubte.

Theoretisch sollte der Bootloader sich auch wieder per "update_kernel" installieren lassen (wenn der tatsächlich nicht gesonderten Schreibschutz hat) ... wobei ich auch nicht weiß, was dann bei tatsächlich defekten Blöcken geschieht, denn m.W. hat der Bootloader selbst kein komplettes Defekt-Management. Aber irgendeine Erkennung muß es auch dort geben (und der muß ja eigentlich nur lesen können), denn irgendetwas muß ja auf eine Kopie umschalten im Falle eines Fehlers - den er vermutlich anhand der OOB-Daten feststellen würde.

Ob das einfache "cp" in das Block-Device ausreicht, würde ich bezweifeln ... müßte aber auch erst in den Quellen suchen. Mein Zweifel, daß es einfach so per Block-Zugriff funktioniert (und das wäre das "cp" ja), resultiert aus der Frage, wie sich so ein Zugriff und eine praktisch beliebige Blockgröße mit der "erase size" eines Flash-Speichers verträgt, wo ein Schreibzugriff für Datenblöcke < "erase size" dann ja als "read-copy-write" für den gesamten Erase-Block realisiert werden müßte. "update_kernel" löscht hingegen (dem Augenschein nach zumindest) vor dem Schreiben einen Block erst einmal per "ioctl()" und schreibt dann die Daten für den kompletten Erase-Block. Bei den UBI-Volumes ist für die "Blockbildung" und das Löschen dann der UBI-Layer zuständig.

 

[qwertz.asdfgh]

Wobei ich nicht so ganz verstehe, warum Du das auf das andere Forum beschränkt hast ...

Hatte ich dort eigentlich auch nur gemacht weil ich mit der Anleitung aus #1 da drüben nicht so ganz zufrieden war. Hatte dazu eigentlich schon länger vor mal eine entsprechende Anleitung zu schreiben und mit der Nachfrage dort in diesem Thema hatte ich eben mal eine kleine (nicht komplette) Anleitung auf die schnelle erstellt (die soll dort auch nicht die Anleitung aus #1 komplett ersetzen).
Mittlerweile hat sich diese Frage aber eigentlich erübrigt, für das IPPF hast du es mittlerweile selbst übernommen (habe ich dort auch gleich verlinkt).

 

[PeterPawn]

Mittlerweile hat sich diese Frage aber eigentlich erübrigt,

Fänd' ich schade ... wir haben einen "unterschiedlichen Stil" und da könnte sich dann jeder das heraussuchen, was er selbst besser lesen und verstehen kann. Da Du Dir diese Arbeit ja schon einmal gemacht hast (und das nun nicht komplett neu erfinden müßtest), würde ich die Kopie der Anleitung aus dem anderen Forum hier sehr begrüßen.

Bei der 6490-Version ist das vielleicht wieder etwas anderes (auch wenn die beschriebenen Schritte hier im IPPF "entwickelt" wurden) und bei beiden Themen auch Deine eigene Entscheidung - ansonsten würde sicherlich nicht nur ich es gut finden, wenn auch dieser Thread sein Spiegelbild hier hätte.

 

[eisbaerin]

Ich habe mal noch eine Frage zu dieser Datei:

7580# ls -la /proc/kc*
-r--------    1 root     root     1610608640 Feb 15 17:26 /proc/kcore

So viel Speicher hat doch die gesamte FB nicht, selbst wenn ich Flash und RAM zusammenrechne.
Wie geht das? Ist die Anzeige falsch?

 

[PeterPawn]

Die Datei repräsentiert eher den physikalischen Speicher und es müssen - gerade bei Systemen mit einer MMU (Memory Management Unit), die für ein Mapping von physikalisch vorhandenem Speicher auf physikalische Adressen sorgt - gar nicht alle Seiten in diesem Speicher auch "vorhanden" sein.

Bei einem 64-Bit-System auf einem Prozessor mit max. 48-Bit-Adressierung sieht das z.B. dann so aus:

vidar:~ # ls -l /proc/kcore
-r-------- 1 root root 140737477885952 Feb 15 18:51 /proc/kcore
vidar:~ # ls -lh /proc/kcore
-r-------- 1 root root 128T Feb 15 18:51 /proc/kcore
vidar:~ #

Da sind natürlich auch nicht 128 TB installiert ... das ist eher die max. genutzte Speicheradresse, die für die Größenangabe herhalten muß (m.W. noch mit einem 4K-Block für die Verwaltung). Die Datei wird dann z.B. von einem Debugger verwendet, wenn er Zugriff auf physikalische Adressen im Speicher erhalten will - es hat auch seinen Grund, warum nur "root" die lesen darf (ACL=0400 und Owner=root).

Das wird natürlich nicht sequentiell ausgelesen, sondern direkt dort adressiert, wo man lesen will (über fseek() oder auch nur über mmap()). Ist dort dann gar kein echter Speicher gemappt oder ist der gerade ausgelagert (bei "virtuellem Speicher" in Form eines Swap-Files), gibt es beim Zugriffsversuch eine entsprechende Ausnahme (Exception), die dann entweder zum Einlagern einer Seite genutzt werden kann oder den Verursacher auch einfach nur beendet (mit SIGSEGV), was auch bei einem ungültigen Zugriffsversuch (z.B. einem Schreibzugriff auf Speicher, der nur lesbar ist oder beim Versuch der Ausführung von Code in einem "NX"-Bereich) der Fall wäre.

 

[eisbaerin]

Danke für die ausfürliche Erklärung!

Seit wann macht AVM das "noexec" aber auch mit dem internen NAS?

Ich beantworte mir und anderen die Frage mal selbst:
Bei der 7590 seit der 49507 vom 12.1.2018

 

[eisbaerin]

Bei einem mksquashfs zeigte mir die 7580 heute an:

Parallel mksquashfs: Using 4 processors

Da stutze ich, weil in qwertzy's HW Liste nur 2 CPU-Kerne stehen.

Dann habe ich mir nochmal die Werte in den Dateien in /sys/devices/system/cpu angeschaut.
IIRC haben die sich verändert. Damals (153.06.81-43458) sah es so aus, als ob nur 2 von 4 genutzt werden.
Und ich hatte damals die Idee, warum nicht alle 4 nutzen.

Kann es sein, daß AVM jetzt wirklich alle 4 Kerne nutzt? Warum jetzt erst?
Aber IMO war das bei der 7490 auch so, daß die am Anfang nur mit einem Kern gearbeitet hat.

z.Z. bei mir:

kernel_max   3
offline      leer
online       0-3
possible     0-3
present      0-3
uevent       leer

IIRC damals:

offline      1,3
online       0,2

oder so ähnlich.

Wie war gleich der Befehl um sich die CPU's anzuzeigen?

 

[PeterPawn]

Afaik wurden die bisher bei der 7580 so eingesetzt, daß auf 0 und 2 das FRITZ!OS lief, auf 1 der Hypervisor und auf 3 die DSPs für 5 Kanäle realisiert waren (über irgendein Device konnte man da auf diesen dritten Kernel per FIFO zugreifen, iirc). Wobei ich mir nicht sicher bin (kenne aber die Spezifikationen für den GRX350 auch nicht wirklich, nur ein paar verstreute Info-Blätter von Intel), ob das alles "echte" Kerne sind und nicht nur VPEs nach MIPS MT (https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00452-2B-MIPSMT-WHP-01.02.pdf).

Die Infos in "/sys/devices/system/cpu" stammen wahrscheinlich aus dem Device-Tree im Bootloader ... das sollte mit dem Inhalt von "/proc/device-tree/cpus" korrespondieren.

Vermutlich werden dann bei Dir auch vier CPUs unter "/proc/cpuinfo" angezeigt, oder?

Was ist das denn für eine Bootloader-Version? Wenn die Box nur einen Tag später produziert wurde als die vorhergehende, dann sind solche Unterschiede ja tatsächlich eher unerwartet.

 

[eisbaerin]

7580:$(pwd)# ls -la /proc/device-tree/cpus
dr-xr-xr-x    6 root     root             0 Feb 16 21:10 .
dr-xr-xr-x   23 root     root             0 Feb 16 21:10 ..
dr-xr-xr-x    2 root     root             0 Feb 16 21:10 cpu@0
dr-xr-xr-x    2 root     root             0 Feb 16 21:10 cpu@1
dr-xr-xr-x    2 root     root             0 Feb 16 21:10 cpu@2
dr-xr-xr-x    2 root     root             0 Feb 16 21:10 cpu@3
-r--r--r--    1 root     root             5 Feb 16 21:10 name

/proc/cpuinfo

Danke, das war der "Befehl", den ich suchte:

7580:$(pwd)# cat /proc/cpuinfo
system type             : GRX500 rev 1.2
machine                 : AVM7580 vrx318 (GRX550, HW225-1) Main model
processor               : 0
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 200.000
BogoMIPS                : 131.14
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VPE                     : 0
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 1
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 200.000
BogoMIPS                : 131.14
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VPE                     : 1
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 2
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 200.000
BogoMIPS                : 131.14
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 1
VPE                     : 0
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 3
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 200.000
BogoMIPS                : 131.14
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 1
VPE                     : 1
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d

oder auch alle auf 1GHz:

7580:$(pwd)# cat /proc/cpuinfo
system type             : GRX500 rev 1.2
machine                 : AVM7580 vrx318 (GRX550, HW225-1) Main model
processor               : 0
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 1000.000
BogoMIPS                : 655.68
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VPE                     : 0
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 1
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 1000.000
BogoMIPS                : 655.68
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VPE                     : 1
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 2
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 1000.000
BogoMIPS                : 655.68
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 1
VPE                     : 0
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d
processor               : 3
cpu model               : MIPS interAptiv V2.0
cpu MHz                 : 1000.000
BogoMIPS                : 655.68
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : dsp mt eva
shadow register sets    : 1
kscratch registers      : 0
core                    : 1
VPE                     : 1
VCED exceptions         : not available
VCEI exceptions         : not available

segment control registers 0:002d0a0a 1:020d020a 2:003d003d

bootloaderVersion unverändert: 1.3229
Ich habe aber mal die 2 Dateien vom Bootloader verglichen mit Notepad++, da waren mehr Unterschiede, als ich erwartet hatte. 2 größere Blöcke. Willst du dir die mal anschauen?

dann sind solche Unterschiede ja tatsächlich eher unerwartet.

Ich habe das jetzt auch überhaupt nicht mit der anderen HW in Verbindung gebracht.
Eher mit der neueren FW.
Bei der 7490 wurde damals mit neuerer FW dann der 2. CPU-Kern "dazugeschaltet".

Was wird denn bei dir da angezeigt? 2 oder 4 CPUs?
Was steht bei dir bei offline und online?

 

[Hilfesuchender5]

Guten Abend,

ich habe versucht die Anleitung für eine 7590 mit Fritz!OS 7.0 durchzuspielen. Bei folgenden Punkten ist die Anleitung nicht mehr ganz korrekt (ich ergänze die Punkte mal, vielleicht hilft es ja jemand):

• die Binaries sind nicht mehr im Branch sondern nun ein Git Submodule. Checkout erfolgt im yf-Verzeichnis via

  git submodule update --init --remote --force bin

• Bei den Befehlen "unsquashfs" und "mksquashfs4-avm" gibt es 2 Varianten. von denen man die korrekte auswählen sollte
• Die gewählten Varianten müssen noch "ausführbar" gemacht werden - chmod 777 oder ähnliches

Die Schritte konnte ich alle erfolgreich abschliessen, leider wird aber das "upgeloadete" Image nicht verarbeitet:

EVA_FOUND=1
EVA_IP=xxxxxx
Found AVM bootloader: AVM EVA Version 1.3258 0x0 0x46409
Found hardware revision: 226
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0x1823300 (24 MB)
Setting temporary memory size to: 0x067dcd00
Setting temporary kernel args to: mtdram1=0x867dcd00,0x88000000
Image uploaded to device.

Der Upload sieht gut aus, es passiert aber nichts weiter.

Ich vermute mal, dass es an der 7.0 liegt. Hat jemand eine Idee?

Grüße.

 

[PeterPawn]

BusyBox extrahieren und als erstes mal nachsehen, ob da überhaupt ein "telnetd"-Applet enthalten ist in der 07.00 - da AVM ja selbst mit SIAB arbeitet, braucht es den eigentlich gar nicht mehr und es würde mich nicht wundern, wenn der irgendwann mal fliegt. Ohne Applet nutzt auch der nachträgliche Einbau des Symlinks nichts.

Wenn das Applet existiert, im nächsten Schritt erst mal prüfen, ob der Telnet-Daemon über das Telefon aktiviert wurde ... DAS wird ja nicht automatisch durch die Änderung des Dateisystems ebenfalls bewirkt.

Und mir fallen bestimmt noch ein paar andere (mit der 07.00 möglicherweise einhergehende, wie bei der Frage nach dem Applet ... aber auch "allgemeine", denn die Aktivierung des Daemons gilt ja für alle Versionen) Widrigkeiten ein, die man untersuchen sollte (oder müßte) ... aber einen Schritt nach dem anderen.

Das geänderte Verhalten beim Auschecken habe ich in irgendeinem anderen Thread beschrieben ... aber danke für ein exzellentes Beispiel dafür, warum das mehrmalige Dokumentieren derselben Fakten eigentlich so gar keine gute Idee ist, falls (bzw. richtiger: wenn) sich mal etwas ändert. Vielleicht schaffe ich es ja, mir diesen Thread als "abschreckendes Beispiel" zu merken, wenn mal wieder die Frage aufkommt, warum ich so häufig auf die Suche nach bereits vorhandenen Informationen verweise.

Das mit dem "chmod" irritiert mich ... vermutlich liegt das aber ohnehin eher an den beim Auschecken verwendeten Optionen (suche mal nach "core.filemode" in dieser Beschreibung: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-config.html). Ist das nicht die Ursache, schauen wir auch da genauer hin.

 

[Hilfesuchender5]

Vielen Dank für Deine schnelle Antwort. Ich werde mir die Punkte mal morgen anschauen.
Ich vermute aber momentan, dass das Problem davor liegt. Der eigentliche "Flash" Vorgang ("Wenn sich das System in den Flash schreibt, blinkt die INFO-LED in einem relativ hektischen Modus...") findet gar nicht statt.

 

[PeterPawn]

Dann am besten ein Terminal-Protokoll von der Modifikation der Firmware zeigen ... manchmal überliest man nur irgendeinen Befehl und wenn das hier nicht starten will, paßt vermutlich der Kernel nicht oder das Root-FS wird nicht gefunden.

Dieses Problem dürfte dann auch nichts mit der Frage "07.00 oder nicht" zu tun haben ... ich muß ohnehin selbst eine 153.07.00 mit Shell-Zugang fertig machen. Dabei schaue ich mir das mit der Installation über das rc-Skript noch einmal an, glaube aber kaum, daß AVM da tiefgreifende Änderungen vorgenommen hat.