[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Hallo,


vlt. kann mir hier jemand helfen - bin absoluter Neuling mit modfs und mach da schon ein paar Tage mit rum
wollte eine aktuelle FB 7490 (6.93) telnet fähig machen
dazu habe ich die 6.24 Recovery installiert und telnet aktiviert - OK
modfs installiert und mit modfs 6.30 update - OK
nach modfs update auf 6.50 kommt Fehler is_puma_na not found - telnet funktioniert noch die Box lässt sich aber über die Weboberfläche nicht mehr neu starten kann zwar die Auswählen es erfolgt aber kein erbot
brauche ich da ein Zwischenupdate oder was kann ich machen

edit. Fehlermeldung korrigiert
 
Recovery mit einer 06.93, Einrichten von Einstellungen, Shell-in-a-Box über Image aus "first_aid" installieren und dann noch einmal mit "modfs" antreten ... gegen den Unfug, irgendwelche alten Versionen mit Telnet-Zugang als Ausgangspunkt zu nehmen, habe ich inzwischen oft genug versucht "anzuschreiben".

Wer diesen Weg unbedingt gehen will, muß sich dann selbst helfen bzw. kann nicht auf Hilfe von meiner Seite rechnen (was andere machen, kann ich nicht beeinflussen - ich werde aber auch falschen Vorschlägen in solchem Kontext nicht länger widersprechen, solange daraus nur unnötige Arbeit und nicht die offensichtliche Zerstörung einer Box resultiert) ... ich werde aber auch keinerlei Tests mehr unternehmen in der neuen Version (beim "Installieren" der richtigen Version für den vorhandenen Kernel), ob da jemand noch mit einem alten 2.6er-Kernel (und damit einer Version < 06.5x) herumgurkt.

Das ist über zwei Versionen hinweg schon "kompliziert" genug und ich will mich auf die Gleichsetzung "3.10.73" (bei VR9) und "uClibc 0.9.33.2" verlassen können, dem als Alternative dann nur noch "uClibc-ng 1.0.14" bei neuerem Kernel gegenübersteht. Es gibt - in meinen Augen und ich bin auf Gegenargumente sehr gespannt - keinen plausiblen Grund, heute noch "modfs" von einer Version < 06.5x aus zu verwenden ... zumindest nicht bei den unterstützten VR9- (und AR10-)Modellen.

Ansonsten klingt das in #1501 auch etwas komisch als Beschreibung ... ich rate jetzt mal und behaupte, daß die Meldung "is_puma_na not found" aus dem Versuch des Aufrufs des Boot-Managers stammen soll. Es ist durchaus denkbar, daß die (uralte) FRITZ!OS-Version 06.50 diese Funktion (mit der bei DOCSIS-Boxen der Umzug der Router-Funktionen auf den x86-Core "entdeckt" werden kann) tatsächlich noch nicht enthielt ... dann darf man eben den Boot-Manager (bzw. dessen Version 0.4) für diese FRITZ!OS-Version nicht verwenden. Der damals aktuelle Boot-Manager in Version 0.3 dürfte mit FRITZ!OS 06.50 keine Probleme haben. Dasselbe gilt sicherlich auch noch für einige andere Modifikationen ... bei FRITZ!OS-Versionen < 06.5x dürfte so manches andere Skript noch mit Ansage gegen die Wand fahren und selbst ab 06.5x hat sich da noch ständig irgendetwas in den Lua-Dateien bzw. im JS-Code geändert.

Wer also alte Versionen mit "modfs" erstellen bzw. modifizieren will, der sollte dann auch zu der "modfs"-Version greifen (und sie sich aus dem GitHub-Repository selbst erstellen), die aktuell war, als die alte FRITZ!OS-Version erschien (bzw. die dann als Anpassung an solche neuen FRITZ!OS-Versionen aus der Taufe gehoben wurde). Die Vorstellung, die aktuellen "modfs"-Versionen müßten auch heute noch die Anpassung von 06.23 ermöglichen, ist zwar "romantisch" (und funktioniert in Teilen tatsächlich noch) ... aber eigentlich gar nicht wirklich "beabsichtigt". Wer sollte den damit verbundenen Testaufwand denn stemmen?

Es gab bzw. gibt inzwischen sechs FRITZ!OS-"Generationen" (06.3x, 06.5x, 06.6x, 06.8x, 06.9x, 07.0x), für die man "modfs" verwenden kann (letztere halt noch unfertig) und innerhalb dieser Generationen dann teilweise noch mehrere Versionen - das kann kein Einzelner mehr testen und es gibt ja irgendwo auch keinen plausiblen Grund, warum man das tun sollte.

Wenn es für 06.9x (die letzte) und 07.0x (die aktuelle) verwendbar ist, sollte das bereits ausreichend sein und sich in einer originalen 06.93 bei der 7490 einen Shell-Zugang einzubauen (auch hier wird zu oft "telnet" mit "Shell" gleichgesetzt, was reichlich unpräzise ist und den Blick auf (sicherere) Alternativen verstellt), kostet keine fünf Minuten - für die weit verbreitete 7490 stelle ich sogar schon das fertige Image dafür zur Verfügung.

Wieso da irgendjemand auf die Idee kommt, bis zu einer 06.24 zurückzugehen (die eigentlich von "modfs" noch gar nicht unterstützt wurde) und dann den "Marsch durch die Instanzen" anzutreten, würde mich ernsthaft interessieren. Selbst das Märchen mit dem Beginn bei 06.50 und anschließender Installation von Shell-in-a-Box über ein Update-Image, ist ja im Umlauf und wäre hier noch die deutlich verständlichere Vorgehensweise gewesen.

Aber noch einmal ganz deutlich, auch für spätere Leser: DAS IST SCHWACHSINN - es kostet ein einziges Booten der Box mit dem passenden Image (und dann noch mal einen normalen Neustart) und man hat den Shell-Zugang zu diesem System. Dafür braucht man ein Image, welches ich für die 113.06.93 sogar schon bereitstelle - für die 07.01 könnte man zwar auch ein neues machen, aber nach meiner Erfahrung funktioniert dort das alte noch, weil die Binaries darin statisch gelinkt sind und bei den aufgerufenen Funktionen der abweichende Kernel wohl nicht weiter stört.
 
Zuletzt bearbeitet:
Also bräuchte man deiner Meinung nach gar nicht auf 06.93 gehen sondern könnte direkt auf 07.01 recovern und dein Image nutzen?

Und das es so viele Irrenden gibt, liegt in erster Linie daran, dass du in #1 auf hier verweist, wo zu lesen ist: "Grundvoraussetzungen: ... Auf der FB muß eine FW von min. 06.20 sein". Klar, wenn man dann nochmal zum nächsten Thread (Implant SIAB) klickt, erfährt man auch seit März 2018, dass du freundlicherweise o.g. Image bereitstellst. Aber eben immer noch nicht, für welche Firmwareversion das funktioniert.
 
Zuletzt bearbeitet:
Ja, bei mir funktioniert das Shell-in-a-Box aus diesem Image auch für den Aufruf von "modfs" - ob es an anderen Stellen ggf. Probleme gibt, habe ich nicht weiter getestet. Bei statisch gelinkten Binaries sollte das aber auch keine allzu entscheidende Rolle spielen ... aber ich werde einfach noch ein passendes Image mit einer Shell-in-a-Box für uClibc-ng 1.0.14 bereitstellen (wobei die C-Library eben ohnehin statisch gelinkt ist und event. Inkompatibilitäten nur noch bei Syscalls auftreten können). Das nehme ich gleich im Anschluß mal in Angriff ...

Das mit #1 ist sicherlich richtig ... aber ich habe auf den anderen Thread keinen wirklichen Einfluß und es gibt auch keinen "Verlautbarungsthread", in dem ich Neuigkeiten und Änderungen zum Thema "modfs" in "kondensierter Form" hinterlassen könnte. Zwar ist dieser Thread hier jetzt tatsächlich auch auf 75 Seiten angewachsen (nach nunmehr vier Jahren, denn gestern war der Start dieses Threads genau diese vier Jahre her) ... aber dafür kann ich auch nichts (jedenfalls nicht nur).

Auch am "Aussehen" von #1 kann ich nichts mehr machen (jedenfalls nicht mit akzeptablem Aufwand) ... ich habe damals einiges an Energie in diese Tabellen gesteckt und auch wenn der BBCode-Interpreter von Xenforo damit nicht klarkommt, habe ich einfach nicht die Zeit dafür, das noch einmal zu überarbeiten - zumal die "gestalterischen Mittel" ja deutlich weiter eingeschränkt sind in Xenforo.

Ich habe aber mal die Anregung aufgegriffen und direkt an den Beginn von #1 noch einen Verweis auf meinen Beitrag vom 16.03.2018 gestellt - mehr kann (bzw. will) ich an dieser Stelle nicht machen.

Wer sich eine bessere Beschreibung bzw. Übersicht wünscht, kann ja mal eine Liste mit Links auf die (seiner Ansicht nach) wichtigen Beiträge mit "zusätzlichen Informationen" aus diesem Thread zusammenstellen - ich habe kein Problem damit, die dann in #1 noch einzufügen bzw. auch von #1 auf eine solche Zusammenstellung (wenn er das in einem eigenen Thread machen möchte) zu verweisen. Den Link auf den anderen Beschreibungsthread von @eisbaerin habe ich auch deshalb nicht herausgenommen (auch wenn er schon recht alte Informationen zusammenfaßt), weil ein solcher Thread (bzw. es reicht für ein "Stichwortverzeichnis" ja vielleicht auch ein einzelner Beitrag) immer noch besser ist als keiner.

Ja, es mag auch immer wieder "Neueinsteiger" geben ... aber eine Beschreibung für diese Zielgruppe würde ich innerhalb des IPPF gar nicht mehr erstellen wollen und für eine Beschreibung über "GitHub Pages" (wo mittels "jekyll" aus Templates dann statisches HTML generiert wird) fehlt mir einfach wieder die Zeit - ich hatte das hier sogar schon alles lokal vorbereitet, damit man seine Seiten testen kann, bevor man sie auf GitHub veröffentlicht.

----------------------------------------------------------------------------------------------------------------------

Ich weiß nicht mehr genau, wie oft ich gegen diese Downgrades schon argumentiert habe ... spielt auch nicht wirklich eine Rolle. Solange mir niemand einen Vorschlag machen kann, wie ich das (ohne übermäßigen zusätzlichen Aufwand) so beschreiben und dann auch so prominent hervorheben kann, daß es tatsächlich auch gefunden wird (daß die Ergebnisse bei Google ohne "site:ip-phone-forum.de" nur noch einen "Sehschlitz" liefern auf die IPPF-Inhalte, trägt auch nicht wirklich zur Besserung der Situation bei), wenn sich jemand (vorbildlicherweise) auf die Suche macht.

Mir ist auch bewußt, daß z.B. @TomTomNavigator in seinem ein externes Blog auf ein Downgrade verweist (https://www.antary.de/2017/07/04/fritzbox-shell-zugang-nachruesten-auch-bei-aktuellem-fritzos/) ... aber auch da habe ich keinen Einfluß.

Ein Grund dafür mag vielleicht sein, daß er selbst Probleme hatte, ein passendes Image für eine 7430 mit den Skripten aus "toolbox" (im YourFritz-Repository) zu erstellen (https://www.ip-phone-forum.de/threa...-oder-besser-nicht.294386/page-2#post-2279739) ... mit dem von @stoney erstellten Image (der sicherlich auch nur meine Skript-Dateien benutzt hat, zumindest steht da nichts Gegenteiliges) hat es dann ja funktioniert.

Ich weiß also auch nicht, was ich noch machen soll um gegen "die Mär" anzukämpfen, man müsse unbedingt den Weg über 06.50 wählen (der bei anderen Modellen als 7490 auch nicht so richtig funktioniert, weil es da gar keine 06.5x mehr gibt, die unsignierte Images und damit "modfs-Starter" noch akzeptiert) ... wie oft ich im "Suche Firmware"-Thread schon versucht habe, das entsprechend klarzustellen, habe ich auch nicht gezählt. Allerdings wird dort halt auch (mit Ansage) gelöscht - mein Vorhaben, mal einen passenden Beitrag zu verfassen, der im "Suche Firmware"-Thread verlinkt werden kann, habe ich bisher auch noch nicht umgesetzt (nur mal im Dialog mit @DM41 angesprochen). Ob der dann auch gelesen würde, bevor jemand wieder mal (und noch mit der "Telnet-Begründung") nach einer alten Firmware sucht, ist aber ohnehin eine vollkommen andere (und offene) Frage ... deshalb ist da mein "Antrieb" auch entsprechend minimal.

Ich bin sogar schon am Überlegen gewesen, die für "modfs-Starter" verlinkten Images einfach von meinem Server zu entfernen ... in der Hoffnung, daß sich deren Fehlen dann herumsprechen und somit dieser Weg des Downgrades als "nicht mehr funktionierend" angesehen würde, was hoffentlich im Anschluß in der Suche nach Alternativen gipfelt. Aber das kann auch ein Bärendienst sein ... denn wenn dann jemand auf die Idee kommt, das Downgrade tatsächlich bis 06.24 zu empfehlen (weil da Telnet vielleicht noch "nativ" geht - ich weiß gar nicht mehr genau, wann das ausgebaut wurde), wäre das deutlich nach hinten losgegangen.

EDIT: Große Entschuldigung an @TomTomNavigator ... ich habe thomasheinz.net mit antary.de verwechselt und das oben korrigiert (noch selbst bemerkt, aber peinlich genug).
 
Zuletzt bearbeitet:
Ich habe jetzt mal die Skript-Dateien in "toolbox" und die SIAB-Images für 7412 und 7490 aktualisiert im Repo - wobei bei der 7490 eben jetzt zwei verschiedene Versionen existieren, welche die jeweilige Kernel-Version zusätzlich im Namen tragen (bei der 7412 gibt es ja keinen 3.10.107-Kernel und damit weiterhin nur ein Image).

Das "build_shellinabox_implant_image"-Skript sollte die notwendige Version der Binaries selbst erkennen können ... dazu setze ich auf die Buildroot-Version, mit der das "chksum"-Utility im verwendeten AVM-Image erstellt wurde. Ist deren Jahreszahl 2016 oder größer, wird auf 3.10.107 umgestellt. Wie zuverlässig das ist, muß sich zeigen - beim Aufruf mit "-d" wird auf STDERR angezeigt, welche Binaries verwendet werden.
 
Moin,
auf meiner Fritzbox läuft noch die Version 6.23.
Ich hab auch schon mal modfs durchlaufen lassen, ohne Fehler und auch ohne reboot.
Ist es denn problematisch, modfs mit dem Paramter "update" und der Firmware 6.23 laufen zu lassen?
Bzw. falls das ohne Fehler durchläuft, kann ich dann ohne Gefahr rebooten?
VG
Günter
 
kann ich dann ohne Gefahr rebooten?
Welche Gefahr würdest Du denn erwarten? Die Frage läßt sich so pauschal nämlich nicht beantworten ... beim Neustart durch Rausziehen und Reinstecken des Steckernetzteils mit tropfnassen Händen kann das bis zu Lebensgefahr gehen.

Ansonsten dürfte für die Hardware eher keine Gefahr bestehen und wie man ggf. wieder auf die zuvor genutzte Firmware kommt, ist auch beschrieben - von daher droht also auch wenig Gefahr.

Mir fehlt also schon ein bisschen die Phantasie, welche Gefahren hier relevant sein könnten ... aber das ist ja häufig so und ging den Erbauern von "Jurassic Park" (1 bis 3) irgendwie auch nicht viel anders. Oder sind das gar keine Dokus?

Ob die aktuellen Versionen von "modfs" tatsächlich auch noch unter 06.2x sauber arbeiten (da wurde noch ein Kernel aus der 2.6er-Serie verwendet und ein anderes Dateisystemformat für das OS), habe ich nie mehr getestet und werde ich auch nicht selbst testen ... es gibt einfach gar keinen Grund, von einer 06.2x aus mit "modfs" zu beginnen und dann sollte man das auch nicht tun.

Ein wenig "am Betriebssystem vorbei" ist diese Art der Installation eines neuen Systems ja schon (man sieht es z.B. auch bei der Statistik-Anzeige in der "Firmware-Update"-Seite) und wenn man die Chance hat, die Settings zunächst mal durch das FRITZ!OS bei einem "normalen Update" anpassen zu lassen, dann sollte man das auch tun. Der Shell-Zugang ist ja im Handumdrehen wiederhergestellt - wenn das niemand zweimal die Woche machen will, verstehe ich das auch noch, aber die 06.2x müßte aus Mitte 2014 und inzwischen vier Jahre alt sein (das ist dann eine deutlich geringere "Update-Frequenz").
 
habe jetzt 6.93 Revovery Image installiert, Einstellungen vorgenommen
EVA_Discover.ps1 bringt folgende Meldung
- trying to connect to FTP port ....
- Error during FTP Connection attempt
- EVA_IP 192.168.178.1
- True
EVA_FTP.ps1 bringt dann Fehler
- Scriptfehler aufrungd eines Überlaufs der Aufruftiefe ....
 
Klingt komisch ... einfach das Protokoll anhängen für die PowerShell. Wenn da tatsächlich ein FTP-Server aus EVA geantwortet hat, dann sollte das Login auch funktionieren.

Außerdem braucht man nur beim Aufruf die Optionen für "Debug" und "Verbose" mit angeben, dann sieht man auch genauer, was da passiert - steht alles im "pinned thread" zum Gebrauch der "eva_tools".

Es sind bisher jedenfalls keine Fehler in "EVA-FTP-Client.ps1" bekannt ... wenn etwas nicht funktioniert, war das bisher eigentlich immer . Allerdings muß man eben die Voraussetzungen sauber umsetzen ... bis hin zu den richtigen Versionen, wenn man nicht ohnehin schon unter Windows 10 arbeitet (wo die neuesten Versionen automatisch im System installiert werden). Steht auch alles im erwähnten Thread - ggf. auch nur als Link auf andere Stellen, wo ich das beschrieben habe.
 
Mein FB 7490 hat die 6.83 FW Internationaler Version
Vor ein par Monate habe ich mittels ./modfs update auf 6.93 (oder 6.98) gebracht aber da fehlte der Overview und habe die FB wieder auf 6.83 umstellen mussen.
Jetzt ist die 7.01 da aber leider bricht die Produktion zusammen nach ./modfs update 7.01.image. Das Telnet Fenster verschwindet ohne Fehler Anzeige und der FB reboot wieder auf 6.83.
Soll ich noch etwas abwarten ? Was kann ich tun um rauszufinden was da fehlt?
 
"modfs"-Protokoll vorzeigen und die Beta-Version nehmen ... steht ein paar Beiträge weiter vorne. Auch das lesen, was sich seitdem geändert hat.

Die VPN-Anzeige in der Übersichtsseite habe ich noch nicht repariert, aber die kann für die Labor-Reihe und das neue Release auch nicht ausgewählt werden. Ansonsten macht "modfs" mit der Übersichtsseite gar nichts und wenn deren Anzeige nicht funktionieren sollte, kann das nur unter sehr, sehr unwahrscheinlichen Umständen am "modfs" liegen.

Aber auch da braucht man das Protokoll, um Probleme zu sehen ... und daß man unbedingt beim Update auf die 07.0x Swap-Space bereitstellen sollte, steht auch weiter vorne in den Beiträgen, die seit dem Erscheinen der 113.07.01 geschrieben wurden.
 
  • Like
Reaktionen: alfa_ajx732
Klingt komisch ... einfach das Protokoll anhängen für die PowerShell. Wenn da tatsächlich ein FTP-Server aus EVA geantwortet hat, dann sollte das Login auch funktionieren.

Außerdem braucht man nur beim Aufruf die Optionen für "Debug" und "Verbose" mit angeben, dann sieht man auch genauer, was da passiert - steht alles im "pinned thread" zum Gebrauch der "eva_tools".
.......


Hi,

verbose und debug hatte ich angegeben
hier mal ein Bildschirmfoto vom PS - kenne mich mit Windows nicht so richtig aus (Mac User) weiß nicht wo ich das PS Protokoll finde
PowerShell.png

//edit by stoney: Bild geschrumpft + Zitat gekürzt
 
Zuletzt bearbeitet von einem Moderator:
Tja, ich habe immer noch keine richtige Idee, warum hier der Zugriff per FTP nicht funktionieren soll.

Ich habe es gerade noch einmal selbst getestet mit der aktuellen Version aus dem Repository:
Code:
PS C:\Windows\system32> Q:\EVA-Discover.ps1 -Verbose -Debug
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
[...]
VERBOSE: Sending discovery packet (20) ...
VERBOSE: Sending discovery packet (21) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
True
PS C:\Windows\system32>
Die jüngsten Änderungen haben der Funktionsfähigkeit des Skriptes (inkl. FTP-Login) also nicht geschadet.

Damit stellt sich die Frage, warum der FTP-Zugriff nicht funktioniert, denn gefunden wird die Box ja noch per UDP-Broadcast.

Die üblichen Verdächtigen hier wären:
  • falsches Interface ... die Broadcasts gehen auf dem mit der niedrigsten Metric raus und da kommt auch die Antwort dann her - wenn die IP-Adresse zu einem anderen Interface gehören sollte, kommt kein FTP-Paket bei der Box an
  • AV-Suite irgendwo installiert, die sich wieder nicht raushalten kann
  • Firewall zu strikt eingestellt - wobei FTP eigentlich alles ausgehend wäre und eher selten geblockt wird, obwohl man bei lokalem Zugriff auch nie wirklich sicher sein kann
Der letzte Patch rüstete ja noch eine Möglichkeit nach, die vom PC zu verwendende IP-Adresse (und damit indirekt auch das Interface) auszuwählen (Parameter "if_address" oder so) - ansonsten änderte er nichts.

Nun sind ja diverse AV-Suiten dafür bekannt, daß sie irgendwas auf dem FTP-Port überwachen wollen (ist halt immer noch eines der Standardprotokolle im Internet) ... daher wäre das mein allererster Tipp.

Wobei man anstelle von "EVA-FTP-Client.ps1" ja nach dem Finden der Box auch direkt mal "ftp 192.168.178.1" versuchen könnte (in ein Skript packen, weil ohne funktionierenden FTP-Zugriff in "EVA-Discover.ps1" die Zeit etwas eng wird) ... wenn das auch nicht geht, geht gar kein FTP-Zugriff und ansonsten liegt es ggf. an den Firewall-Einstellungen für den PowerShell-Host.
 
mit ftp ip_box kann ich mich aus der Powershell nach dem Discover anmelden
user adam2 sucessfully logged in

edit. d.h. Discover funktionert trotz fehlermeldung und der ftp port ist offen also nicht zeitkritisch
 
Trotzdem liefert ja "EVA-FTP-Client.ps1" auch eine Fehlermeldung (und damit wird es auch mit dem Upload des SIAB-Images nichts) ... schon komisch. Sieht fast so aus, als dürfte die PowerShell keine FTP-Verbindungen öffnen - aber woran das nun auf irgendeinem System liegen soll, ist per Ferndiagnose mit "Raten" nahezu aussichtslos beim Versuch, es zu ergründen.

Am ehesten würde ich hier immer noch auf fehlende Bibliotheken bzw. auf falsche Versionen tippen ... denn offenbar kann per PS nicht vernünftig auf das Netzwerk zugegriffen werden. EVA-Discover.ps1 und EVA-FTP-Client.ps1 verwenden auch noch unterschiedliche Klassen für den FTP-Zugriff (einmal "FTPWebRequest" und einmal ganz simpel einen TCPClient) - da liegt dann die falsche Version des .NET-Frameworks eigentlich verdammt nahe.

Was für ein Windows ist das denn und sind da tatsächlich die notwendigen Updates installiert?
 

Code:
PS C:\Users\CAD\Desktop> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\implant_siab_3.10.107.image.7490 }
AUSFÜHRLICH: Unexpected answer ´´ from remote host.
PS C:\Users\CAD\Desktop>

Frage an die Powershell-Profis: Gibt es im Powershell auch einen Skript-Tracing-Mode analog zu Bourne-Shell "bash -x script.sh" ?
 
Zuletzt bearbeitet:
Hallo,
ich habe mit modfs-0.5.0-beta.tgz auf einer FB 7490 mit OS 6.93 ein Update durchführen wollen.
Alles ist durchgelaufen mit Fehlercode=0, außer add VPN summary on overview page mit Fehlercode=1, was auch korrekt ist, da das neue OS > 6.98 ist.
Aber das "Packen des neuen root-Dateisystems ... \" ist stehen geblieben. Zwischenzeitlich hat die FB gebootet, natürlich mit dem vorherigen FW-Stand. Ich habe im FB-NAS ca. 371 MB frei. Braucht es noch mehr freien Speicher?
 
@jono:
Das Problem ist nicht der Speicher mit einem Dateisystem ... der Swap-Space erweitert praktisch den zur Verfügung stehenden Hauptspeicher, indem gerade nicht benötigte Speicherseiten dorthin ausgelagert werden können und am Mangel an diesem Speicher krankt das Einpacken - ggf. für die 07.0x noch mehr, weil die wohl größer ist (auch wenn ich immer noch nicht geschaut habe, warum das so ist).

Der interne Flash des NAS wird von der Beta aber ohnehin nicht mehr benutzt - siehe hier: https://www.ip-phone-forum.de/threa...ierte-fritz-boxen.273304/page-74#post-2295395 ... damit ist es auch egal, wieviel Platz dort vorhanden ist (es sei denn, man will ihn unbedingt nutzen und gibt die Variable beim Aufruf an). Bei solchen Abbrüchen ist und bleibt die erste Methode zur Umgehung der USB-Stick - wie man auch ohne Partition darauf Swap-Space einrichten kann, habe ich (nach dem Erscheinen der 07.01) irgendwo in diesem Thread noch einmal gezeigt.

Gibt es im Powershell auch einen Skript-Tracing-Mode
Die PowerShell bleibt bei Ausgaben über "Write-Debug" normalerweise stehen und ermöglicht die Inspektion von Variablen u.a. ... ich habe das extra verhindert (z.B. hier: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA-FTP-Client.ps1#L61), damit man nicht nur "Write-Verbose" für ausführlichere Ausgaben hat, sondern mit "Write-Debug" noch ein weiteres Level an "Geschwätzigkeit" hinzufügen kann, welches mit den Bordmitteln (und nicht mit zusätzlichen Klassen) arbeitet.
 
Danke für die Antwort. Ich habe einen USB-Stick präpariert mit EXT3 (1,5GB) und Swappartition mit 1GB. Nun sagt mir modfs "Permission denied". Ich habe schon probiert, nur es klappt nicht.
Code:
drwxr-xr-x    7 root     root          4096 Sep 27 11:14 .
drwxrwxrwx    5 root     root          4096 Sep 27 11:14 ..
-rw-rw-r--    1 1000     1001         11080 May  9 14:00 BOOTSELECTION.ger
-rw-rw-r--    1 1000     1001         18092 Mar 31  2017 LICENSE
drwxrwxr-x    9 1000     1001          4096 Sep 27 11:14 bin
drwxrwxr-x    2 1000     1001          4096 Sep 27 11:14 contrib
drwxrwxr-x    2 1000     1001          4096 Sep 27 11:14 files
drwxrwxr-x    2 1000     1001          4096 Sep 27 11:14 locale
-rwxrwsrwt    1 1000     1001        101402 Sep 22 00:38 modfs
dr-xrwxr--    2 1000     1001          4096 Sep 27 11:14 modscripts

drwxrwxrwx    5 root     root          4096 Sep 27 11:14 .
drwxrwxr-x    1 root     root          2048 Sep 27 10:46 ..
drwxr-xr-x    5 root     root          4096 Sep 27 10:46 FRITZ
drwx------    2 root     root         16384 Sep 27 10:38 lost+found
drwxr-xr-x    7 root     root          4096 Sep 27 11:14 mod
-rw-r--r--    1 root     root     1073741824 Sep 27 11:04 swapfile
 
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.