Telefonieprobleme nach Update auf 7.12 bei 7530

Meine Einschätzung "Gejammer" bezog sich auch nicht auf #7, sondern auf den von mir in #12 zitierten Teil aus Deinem Beitrag #11. Darauf zielt auch das "selbst schuld" - m.E. kaum mißzuverstehen.

Bei der Antwort in #7 hätte ich mir halt noch gewünscht (und da hatte ich selbst noch gar nichts geschrieben in diesem Thread), daß Du - schon aus Achtung ggü. denjenigen, die Dir bis dahin geantwortet hatten - etwas genauer erklärst, WAS da über Deine Fähigkeiten hinausgehen würde.

Die reine Feststellung/Behauptung bringt am Ende niemandem etwas. Weder den anderen, potentiellen Interessenten an der Lösung, die bei genauerer Erklärung der (finalen) Hürde ihrerseits einschätzen könnten, ob sie davon ebenso betroffen wären, noch denjenigen, die solche "Tipps" weitergeben oder entsprechende "Anleitungen" schreiben; diese können damit ihre Texte auch nicht verbessern oder einleuchtender verfassen.

Wenn Du den anderen Weg tatsächlich noch gehen solltest und dabei auf entsprechende Hürden triffst, wäre natürlich der Erfahrungsbericht dazu durchaus wertvoll für andere, spätere Leser und auch für diejenigen, die hier immer wieder versuchen, den Leuten bei ihren Problemen die schnellste und effektivste Lösung anzubieten. Denn daß diese nicht immer von AVM kommt, ist auch ein offenes Geheimnis ... wobei so mancher Support-Mitarbeiter (auch bei Providern) schon mal unter der Hand auf das IPPF verweist.
 
Ich werde dann heute Abend nach Ladenschluß mal versuchen den beschriebenen Weg zu gehen. Vielleicht werde ich dann erstmal wieder von 7.03 auf 7.12 updaten und wenn der Fehler dann wieder
da ist werde ich Deinen Weg versuchen

Noch als kleiner Tipp, abseits der Bademeistervorträge. Du solltest Dir vergegenwärtigen, dass ein recovery.exe stets die aktuell aktive Partition überschreibt. Dies lässt sich eben nur auf dem beschriebenen Weg herausfinden. -Ein falsches recovery.exe zeigt zwar die Firmwareversion neben dem Modell als "gefunden/found" an, aber nicht welche Version ggfs. in der Conterpartition schlummert.-
Im Gegensatz dazu überschreibt ein Update via GUI (egal ob autoupdate oder manuell via Datei) stets die inaktive Komplementär-Partition.
Gleichfalls -nur der Vollständigkeit halber- sollte man vor dem Umschalten NICHT auf Werkseinstellungen gehen/diese anstossen, da sämtliche Einstellungen sonst wirklich weg sind. Diese werden an anderer Stelle -zumeist mtd3 und mtd4- gespeichert.

Abgesehen davon wäre es interessant zu erfahren, welcher Art/wie Deine Telefonie stattfindet. Angefangen vom Telefonie-Provider über die eingesetzten Endgeräte (DECT,IP-Phone, analoges FON ggfs. als eigene DECT-Basis) inkl. wie/wo angeschlossen wäre dies für andere FB7530-Besitzer sicherlich hilfreich, sofern dieses Problem wahrhaftig/reproduzierbar der Firmware 7.12. zuzuschreiben wäre.
LG
 
@PeterBaur: Danke erstmal für Deinen Hinweis. Ich werde mit dem Update dann mal warten. Hast Du den Downgrade hinbekommen?
 
Im Gegensatz dazu überschreibt ein Update via GUI (egal ob autoupdate oder manuell via Datei) stets die inaktive Komplementär-Partition.
Nur noch einmal, um mich zu vergewissern und um die Kommunikation zwischen den Usern zu beleben:

Danach wird die bisherige inaktive Partition vom Updateprogramm zur aktiven gemacht und ich könnte, wenn notwendig, mit linux_fs_start in der bekannten Weise auf die zuvor aktive Version umschalten, richtig?

Kurze knackige Antwort mit 'ja' reicht aus und ihr seid mich wieder los.
 
Ich weiß nicht, wie ein 'ja' die Kommunikation zwischen den Usern beleben kann. Aber gut, dann sind wir dich wieder los. :)
 
War das jetzt eine Umschreibung für 'ja'? Und siehst du, schon sind wir mitten drin in der Kommunikation. Geht doch.:)
 
Kommunikation ist der Austausch von Informationen zur Verständigung zwischen Kommunikationspartnern. Hier findet gerade das glatte Gegenteil statt. Geht doch nicht.
 
Häufig lässen sich Probleme bei der Kommunikation durch Wiederholung der Übertragung beseitigen. Wir können es ja noch einmal versuchen: Lautet die Antwort 'ja'?
 
Danach wird die bisherige inaktive Partition vom Updateprogramm zur aktiven gemacht und ich könnte, wenn notwendig, mit linux_fs_start in der bekannten Weise auf die zuvor aktive Version umschalten, richtig?

Ja, dies ist der oftmals erwähnte Vorteil, bei allen neueren FB-Modellen.
LG
 
@Micha0815 Danke für deine Antwort. Da hat es mit der Kommunikation ja doch noch geklappt:)
Dann bin ich mal, wie versprochen, weg.
 
bei allen neueren FB-Modellen.
Wie neu muß denn ein FB-Modell genau sein, damit das zutrifft? Oder gibt's da doch noch andere Kriterien als "neu", von denen das abhängt?

Welche Version wird eigentlich genau bei:
Ein falsches recovery.exe zeigt zwar die Firmwareversion neben dem Modell als "gefunden/found" an
angezeigt? Welche Version ist denn installiert, wenn da - im Recovery-Programm - nur ein "recovered=2" steht (was auch schon so mancher FRITZ!Box-Besitzer erlebt hat)?

Ich habe auch nichts gegen (richtige) Nacherzählungen, denn das ist hier ja nicht zwingend eine Doktorarbeit, bei der Verweise auf die Quellen nicht nur üblich, sondern unumgänglich sind.


BTW ... diese dienen i.d.R. auch nicht nur dem "Ruhm" des jeweiligen Autoren, sondern auch der Kontrolle, ob der Doktorand das anderenorts Geschriebene tatsächlich korrekt verstanden hat und damit auch selbst in der Lage ist, es korrekt wiederzugeben. Hier böten sie - sofern angegeben - natürlich dem Leser ebenfalls die Möglichkeit, das Wiederholte mit dem Original zu vergleichen und auf eventuelle Unstimmigkeiten hin zu untersuchen - wobei solche natürlich nie vorkommen.


Nur muß man das ja dann nicht weiter "ausschmücken", was man selbst verstanden hat ... zumindest nicht in der Art, wie es bei den "neueren FB-Modellen" nun erfolgt ist. Ich weiß nicht genau, wieviele Modelle mit zwei Systemen vor und wieviele nach der 4040 erschienen sind (letztere stammt aus dem Sept. 2016, ist also knapp 3 Jahre alt) - aber ich würde jetzt nicht behaupten wollen, daß nur die Modelle nach der 4040 auch noch "neu" sind und vor allem deckt das dann tatsächlich wieder nur einen Bruchteil der Modelle ab, die über diese Fähigkeit verfügen.

Die erwähnte Fähigkeit zum "dual boot" hat also mit der Frage, ob ein Modell neu ist oder nicht, eher weniger zu tun, schon die 6360 (erschienen im Frühjahr 2011) hatte zwei getrennte Systeme (wenn auch noch etwas anders organisiert, weil die tatsächlich 2 NOR-Chips hatte, die per CS umgeschaltet wurden) und konnte zwischen diesem mit der Variablen "linux_fs_start" wechseln. Und der "Beweis" dafür, daß nicht alle neueren Modelle auch tatsächlich mit zwei getrennten Systemen ausgestattet sind, ist die bereits erwähnte FRITZ!Box 4040.

Auch die Wiedergabe der Rahmenbedingungen, unter denen bei einem GRX-Ableger die Version in der inaktiven Partition auch beim Einsatz des AVM-Recovery-Programms in Mitleidenschaft gezogen wird, ist eben nicht ganz korrekt bzw. nicht vollständig. Während bei VR9-Boxen (um mal im Mainstream zu bleiben) das inaktive System den Einsatz des Recovery-Programms unbeschadet überlebt, ist das bei GRX-basierten Modellen bisher zumindest nicht der Fall, weil dann - eben dank des "recovered=2" in "firmware_info" - die verwendete MTD-Partition für das UBIFS neu formatiert wird, womit zwar der - gesondert gespeicherte - Kernel des zweiten Systems überlebt, aber nicht dessen Dateisystem. Bei Puma-Boxen gibt es dann gar kein Recovery-Programm und es entscheidet die Auswahl des MTD bei Schreibzugriff über den Bootloader, welches System installiert wird.

Bleibt also noch die Frage, um was für ein Modell es sich bei der hier thematisierten 7530 am Ende handelt ... und siehe da, deren Shell-Skript zur Installation sieht dem der anderen GRX-Boxen an dieser Stelle täuschend ähnlich (die "ubiformat"-Zeile ist der Knackpunkt):
Bash:
check_and_setup_ubi_volumes() {
echo "[ubi] set up ubi volumes start"
cat /proc/mtd
if [ "${1}" = "force" ] ; then
mtd_ubi_nr=`cat /proc/mtd | grep '^mtd.*\"ubi\"' | sed 's/:.*//' | sed 's/^mtd//'`
if [ -n "${mtd_ubi_nr}" ] ; then
echo "[ubi] format ubi volumes in /dev/mtd${mtd_ubi_nr} ..."
ubidetach -p /dev/mtd${mtd_ubi_nr}
ubiformat /dev/mtd${mtd_ubi_nr} -y -q
ubiattach -p /dev/mtd${mtd_ubi_nr}
echo "[ubi] format ubi volumes done"
fi
fi
#### the sizes for cortexa9 with userdata, should be generated from memorylayout (ToDo)
echo "[ubi] set up ubi volumes"
udevadm trigger
ubimkvol /dev/ubi0 -N avm_filesys_0 -s 44MiB
ubimkvol /dev/ubi0 -N avm_filesys_1 -s 44MiB
ubimkvol /dev/ubi0 -N avm_config -s 2MiB
ubimkvol /dev/ubi0 -N avm_userdata -m
echo "[ubi] set up ubi volumes done"
cat /proc/mtd
ubinfo -a
}
Somit wäre also noch festzuhalten (wir waren ja um Vollständigkeit bemüht), daß bei der 7530 der Einsatz des Recovery-Programms (zumindest des richtigen für das Modell) ebenfalls nicht nur die derzeit aktive Partition betrifft, sondern daß danach auch das inaktive System erst einmal erneut zu installieren wäre (denn das Recovery-Programm - bzw. genauer das von diesem in den Speicher der Box geladene und dort gestartete FRITZ!OS - nimmt ja keine Umschaltung vor und beläßt die Einstellung von "linux_fs_start" - damit bleibt das auch das "inaktive" System). Damit macht auch bei diesem Modell das Recovery-Programm nicht nur das aktive System "kaputt", sondern auch das inaktive und man kann (und sollte) sich nach dem Einsatz dieses Programms eine manuelle Umschaltung über "linux_fs_start" verkneifen, solange man nicht wenigstens ein erneutes Update gemacht hat (oder ein System von Hand über den Bootloader installierte (und zwar in der/den alternativen Partition(en)), wobei dann kein "recovered=2" in "firmware_info" stand).
 
Danke für die Korrektur
Während bei VR9-Boxen (um mal im Mainstream zu bleiben) das inaktive System den Einsatz des Recovery-Programms unbeschadet überlebt...
Dies meine ich erfolgreich bei FB7490/FB7412/FB6490 durchexerziert zu haben, weshalb mir und hoffentlich manch anderem interessiertem Leser es sehr willkommen erscheint als Kurzanweisung.

Damit macht auch bei diesem Modell das Recovery-Programm nicht nur das aktive System "kaputt", sondern auch das inaktive und man kann (und sollte) sich nach dem Einsatz dieses Programms eine manuelle Umschaltung über "linux_fs_start" verkneifen, solange man nicht wenigstens ein erneutes Update gemacht hat (oder ein System von Hand über den Bootloader installierte (und zwar in der/den alternativen Partition(en)), wobei dann kein "recovered=2" in "firmware_info" stand).

Hintergrund: Ich habe hier eine recht neue (ein paar Wochen alte) FB7590, der ich nach der Auslieferungs-FW via FTP ein in-memory.image verpasst hatte inkl. fwmod(freetz)-bootmanager, wodurch sich die FB nach einem linux-fs_start-Switch nichtmehr "berappelt" da ich nach einem bootmanager-Umschalten ein recovery.exe auf die aktuelle partition ausführte.
Nach dem freundlichen Hinweis schon klar, weshalb ein switchen auf die andere linux_fs_start-Partition in einer Reboot-Schleife endet.
Egal wohin ich switche linux_fs-start 1 oder 0 greifen alle FW-Recoverys (07.01,07.10,06.93,07.12) nicht wirklich, da sie wohl ausschliesslich mtd8 und mtd1 restaurieren.
Da ich kein Doktorand bin ...
OT: Als studentische Hilfskraft kursierte seinerzeit der kolportierte Treppenwitz an der GHUW
Ein Student muss alles Wissen!
Ein Doktorand muss wissen wo es steht!
Ein Professor muss wissen, wo sein Doktorand ist!
sei
OT-OFF


sei meine Unzulänglichkeit verziehen. Nicht jeder Leser/Member hier hat die Musse und Zeit, sich mit wissenschaftlicher Akribie durch ellenlange/zähe Beiträge/Fundstellen durchzuackern -sofern er/sie auch zeitnah findet/versteht-, wobei so mancher u.U. statt Abitur nur Mittlere Reife hat und ausser "Lesen" nicht die zugrundeliegenden Zusammenhänge und das Wissen extrahieren kann für das eigene/zielführende Handeln.

Insofern wurde in
Danach wird die bisherige inaktive Partition vom Updateprogramm zur aktiven gemacht und ich könnte, wenn notwendig, mit linux_fs_start in der bekannten Weise auf die zuvor aktive Version umschalten, richtig?

Kurze knackige Antwort mit 'ja' reicht aus und ihr seid mich wieder los.

ja lediglich um eine freundliche Bestätigung gebeten, um ebend sicher zu gehen, keinen Fehler zu machen ... Gab es hierzu jüngst eindeutige Posts?

OT Entfernt - HabNeFritzbox

Eigentlich wäre es hilfreich, ein paar kurze Hinweise zu erfahren, wo sich aktuelle FB7590/7580/6890-Modelle? (bekannt als GRX-Modelle) im Handling bzgl. Recovery.exe unterscheiden zu z.B. einer FB7412/7490 ... die bei einem Revcovery auch die User-Einstellungen resetten?
Recovery-Versuch mit 7.01 in linux_fs_start =1
Code:
FRITZ!Box 7590 suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
    Hardware:    FRITZ!Box 7590
    Urlader:    4578
    Firmware:    recovered=2
Flashbereich (mtd8)
    Lösche    Flashbereich (mtd8)
    Restauriere    Flashbereich (mtd8)
    Restauriere    Flashbereich (mtd1)
FRITZ!Box 7590 erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.
nach Umschalten via ftp in linux_fs_start =0 und dort recovery 07.12 der identisch aussehende log
Code:
FRITZ!Box 7590 suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
    Hardware:    FRITZ!Box 7590
    Urlader:    4578
    Firmware:    recovered=2
Flashbereich (mtd8)
    Lösche    Flashbereich (mtd8)
    Restauriere    Flashbereich (mtd8)
    Restauriere    Flashbereich (mtd1)
FRITZ!Box 7590 erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.
was gleichfalls in einer Rebootschleife endet?
Sollte ich eine defekte FB7590 erwischt haben ... Amazon tauscht sie wohl aus! Fatal wäre, wenn ich frevelhafter Weise "nur" etwas repetierend, aus minderem Verständnis heraus, falsch mache?
LG
Edit: Schreibfehler und Syntax korrigiert, damit Orthographie-Liebhaber sich nicht so schwer tun mit dem Lesen und Verstehen.
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: nsus
sich nach dem Einsatz dieses Programms eine manuelle Umschaltung über "linux_fs_start" verkneifen, solange man nicht wenigstens ein erneutes Update gemacht hat (oder ein System von Hand über den Bootloader installierte (und zwar in der/den alternativen Partition(en)), wobei dann kein "recovered=2" in "firmware_info" stand).

ich habe bei meiner 7590 das Inhaus System installiert und dann auch mehrmals "linux_fs_start" erfolgreich ausgeführt .... heißt das nun das durch die Inhaus OS kein "recovered=2" in "firmware_info" stand... oder weil ich kein recover gemacht habe ...
 
Nicht jeder Leser/Member hier hat die Musse und Zeit, sich mit wissenschaftlicher Akribie durch ellenlange/zähe Beiträge/Fundstellen durchzuackern -sofern er/sie auch zeitnah findet/versteht
Was ja noch nicht heißen muß, daß man ihm nicht - als Antwortender - die Chance dazu einräumt. Man kann (nein, man sollte sogar) ja neben der eigenen Zusammenfassung, die man für geeigneter hält, durchaus noch auf die Stelle (oder zumindest eine davon) verlinken, wo man selbst die Informationen gefunden/gelesen hat (sofern man sie nicht durch eigene Analyse ermittelte).

Das sorgt eben nicht nur für "intellektuelle Redlichkeit" (auch wenn diese durchaus ein Aspekt sein kann, weil es bei so mancher "Entdeckung" eben auch viel Arbeit bedeutet, bis man sie entsprechend dokumentiert hat, denn dieser Schritt (die Dokumentation) ist in der Regel erst der allerletzte Punkt, dem schon viele Arbeitsstunden vorausgingen, vom Bemerken eines Umstands über das Systematisieren bis zum Beschreiben), sondern es gibt auch den anderen Lesern die Chance, selbst noch einmal nachzulesen, was man vielleicht an Einzelheiten unterschlagen hat (weil es einem selbst nicht wichtig erschien) oder was man am Ende sogar falsch verstanden hat - wenn's gut läuft auch zu der Feststellung, daß man es tatsächlich alles richtig verstanden und wiedergegeben hat.

So wie vielleicht nicht jeder (wie im Zitat oben) die Zeit hat, will auch nicht jeder automatisch auf solche Vergleiche mit einer Originalquelle verzichten, weil viele eben auch die Erfahrung gemacht haben, daß beim Zitieren oder gar beim Übersetzen immer mal wieder eine Kleinigkeit verloren gehen kann, die aber in so manchem Fall durchaus von Bedeutung sein kann, ohne daß der Zitierende es bemerkte, weil er vielleicht doch andere Umstände zu bewältigen hatte, bei denen die "wirklich komplizierten" Zusammenhänge noch gar nicht im Spiel waren.

Die Beurteilung, ob eine solche Primärquelle am Ende zäh, ellenlang oder gar unverständlich war bzw. ist, sollte man vielleicht doch jedem Leser selbst überlassen ... wer sich aus solchen Informationen am Ende selbst bedient hat (und dieses trotz der damit verbundenen Anstrengungen und Widrigkeiten), der muß das ja zumindest für wichtig genug erachtet haben, daß er selbst es konsumierte. Sich da jetzt hinzustellen und anderen per se schon das Verständnis bzw. die Fähigkeit dazu abzusprechen (so endet das oben stehende Zitat ja), ist in meinen Augen einigermaßen unangebracht.

Dein "Treppenwitz" stellt das doch auch schon sehr schön dar ... der Professor muß/kann/darf sich darauf verlassen, daß der Doktorand weiß, wo es steht (am Ende gar, wo der Prof. es veröffentlichte, wenn dieser der primäre Autor war), weil es seine Aufgabe ist, den "aktuellen Stand der Lehre" zu erarbeiten. Wenn der Doktorand das jetzt aber an die Studenten weitervermittelt (damit die irgendwann mal alles wissen) oder in seiner Doktorarbeit weiterverwendet, wird er - das ist nun mal üblich im universitären Lehrbetrieb - das auch jeweils mit Angabe einer Quelle machen, solange die "Lehrveranstaltung" nicht komplett selbstentwickelt ist und selbst dann wird noch auf irgendwelche Quellen verwiesen, damit die Hörer ihr Wissen damit vertiefen können.

Nun ist das ja gerade im Internet noch deutlich leichter zu realisieren, als auf irgendwelchen PowerPoint-Folien, etc. oder in einer Doktorarbeit ... daher sollte man auch regen Gebrauch davon machen (zumindest ich mache das auch so, wie man nachlesen kann) - selbst wenn das hier kein solcher Lehrbetrieb ist.

Die Vorteile (für beide Seiten, weil die eine sich keine "Plagiate" und/oder unvollständige "Nacherzählungen"/Zusammenfassungen zum Vorwurf machen lassen muß, solange jeder selbst nachlesen kann bei der angegebenen Quelle und die andere Seite profitiert von den bereits angesprochenen Zusatzinfos und Vergleichsmöglichkeiten) springen meines Erachtens ins Auge.

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

Und da die meisten Bademeister "im Nebenberuf" auch noch Rettungsschwimmer sind und gerade bei diesem Wetter auch für "geregelte Abläufe" sorgen und die Freiwilligen der DLRG so manchem, der sich und seine Möglichkeiten/Fähigkeiten selbst überschätzt hatte, wohl auch in diesem Sommer schon das Leben gerettet haben werden, sehe ich sogar die Provokation in der Einschätzung "Bademeistervorträge" gelassen ... nur erwarte ich auch (oder eher gerade) dann, daß entsprechende "Zusammenfassungen" (so Du sie denn als notwendig ansiehst, weil Du @PeterBauer das eigenständige Lesen meiner Beiträge, die sich mit den von Dir zusammengefaßten Themen beschäftigen, nicht zutraust) sachlich richtig sind und sofern es daran fehlt, bist Du bekanntlich auch nicht das einzige "Opfer" solcher Korrekturen meinerseits. Meine Motivation für solche Korrekturen habe ich oft genug erklärt ...

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

Um auch das nicht unerwähnt zu lassen ... ich bin durchaus ein Fan einer Schreib- oder Ausdrucksweise, die auch mal ins Feuilleton der Sonntagszeitung passend könnte und goutiere entsprechende Formulierungen. Nur sollten sie dann auch die entsprechende Klarheit in ihrer Aussage haben und ich kann z.B. mit dem Satz:
Fatal wäre, wenn ich frevelhafter Weise "nur" etwas repitierend aus minderem Unverständnis falsch mache?
so gar nichts anfangen. Dann doch lieber etwas weniger blumig, aber mit klarer Aussage im Satz ... was ist denn ein "minderes Unverständnis"? Den Gesetzen der Logik folgend (duplex negatio affirmat) wäre das ein besonders ausgeprägtes Verständnis oder was sollte "weniger" oder "geringeres" Unverständnis sonst sein?

Kommt dabei am Ende so etwas Widersprüchliches wie oben heraus, wirkt es "etwas bemüht" und wenn das dann noch desöfteren "verunglückt" (ein "Repetieren" ist zwar auch ein "Wiederholen", aber ein "positiv besetztes", denn es dient ja als Methodik gerade dazu, durch derartige Wiederholungen, häufig auch mit Variationen des zu Erlernenden, etwas zu verstetigen - wollen wir mal hoffen, daß es bei Deinem Umgang mit dem Recovery-Programm noch nicht zu spät ist), bildet sich beim Leser durch dermaßen frevelhaften Umgang mit Worten, die anderen Sprachen entlehnt wurden (es gibt ja den Spruch: "Fremdwörter sind Glückssache.") oder der eigenen entstammen, jedoch in falschem Zusammenhang verwendet wurden, möglicherweise ein finaler Eindruck, der für die eigene Reputation tatsächlich fatal wäre.

Auch bei einem "Augenzwinkern" sollte eben immer noch etwas Humor zu erkennen sein ... und - gesetzt den Fall, das war die Absicht dahinter - eine satirische Überspitzung ist nachgerade dazu verdammt, besonders genau und zielgerichtet zu wirken - da kann man sich solche "Ausrutscher" erst recht nicht leisten. Aber zurück zum Thema FRITZ!Boxen ... das Schattenboxen sei hiermit abgeschlossen (zumindest meinerseits).

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

Die Beschreibung der Abläufe bei der 7590 verstehe ich nicht ... wie so ein Recovery-Programm arbeitet (Environment auslesen, TFFS-Image bauen, TFFS-Image schreiben, Firmware in den Speicher laden und starten), habe ich (mehrfach) beschrieben.

Wer sich mit einer dieser Beschreibungen die Abläufe Schritt für Schritt vergegenwärtigt, der sollte auch erkennen können, wann und durch wen die Daten in den verschiedenen Partitionen (TFFS, Kernel, Dateisystem) und im Environment (hier in erster Linie in "firmware_info") geändert werden.

Die Angabe des Recovery-Programms, daß es gerade "mtd8" "renovieren" würde, ist bei den meisten Modellen auch Quatsch ... das ist "AVM-Code" für das im NAND-Flash gespeicherte TFFS-Image. Wenn das Recovery-Programm intern ein "STOR mtdnand" ausführt (diesen Partitionnamen wird man im Urlader-Environment ja gar nicht finden), denn behauptet es einfach, es würde nach "mtd8" schreiben.

Anders als bei den Modellen mit "legacy TFFS", wo die Daten im NOR- oder SPI-Flash gespeichert werden (üblicherweise als "mtd3" und "mtd4" aus Sicht des Bootloaders), wird hier vom Recovery-Programm auch nur ein einzelner Schreibvorgang nach "mtdnand" verwendet und nicht zwei.

Auch die Info, daß jetzt "mtd1" geschrieben wird, ist nur zur Hälfte richtig ... das beschreibt wiederum das Laden des OS in den RAM der Box (bei den meisten Modellen wird dazu eine virtuelle Partition "mtd1" im RAM benutzt, wie man auch an den anderen Angaben im Bootloader - u.a. an den "kernel_args" mit "mtdram1=<something>" - sehen kann) und hat mit der tatsächlich im Bootloader als "mtd1" definierten Partition auch nichts zu tun ... mal ganz abgesehen davon, daß diese Anzeige ohnehin nur aus dem "Wortschatz" des Recovery-Programms stammt und es schon deshalb keine direkte Entsprechung im Bootloader geben muß.

Wenn der Eintrag der Version der gerade startenden Firmware eben erst in einem Init-Skript aus "/etc/init.d" erfolgt und ein startender Kernel sein Dateisystem nicht finden kann, weil der Einsatz des Recovery-Programms das auch dann zerstörte, wenn es in der alternativen Partition lag, dann KANN da eben in "firmware_info" kein gültiger Wert stehen, wenn er es nicht schon vor diesem Startversuch tat. Das System kommt nämlich gar nicht bis zum Auslesen/Ändern des Environments ... es findet schlicht kein Root-FS und verfällt umgehend in Panik.

Das Eintragen einer anderen Version in "firmware_info" übernimmt schon sehr früh im Startprozess das Skript "S01-head" oder später das Installationsskript (bei GRX-Boxen heißt es heutzutage i.d.R. E03-flash_update). Da dieses noch andere Environment-Variablen auswertet (u.a. kann dort über "ptest" die Version der neuen Firmware auch noch "überschrieben" werden - ebenso ist die Ausgabe des Installationsprotokolls über das Netzwerk per TFTP an ein Ziel im LAN möglich), wird eine eingehende Beschreibung dieses Vorgangs aber schnell unübersichtlich, zumindest dann, wenn sie "populärwissenschaftlich" sein soll und die diversen "Nebenwege" nicht vernachlässigen will, weil diese durchaus interessante Möglichkeiten bergen.

Eigentlich wäre es hilfreich, ein paar kurze Hinweise zu erfahren, wo sich [...] im Handling bzgl. Recovery.exe unterscheiden
Gibt es bereits ... eine erneute (kurze oder auch ausführliche) Beschreibung halte ich jedenfalls für unnötig bis zur (plausiblen) Beantwortung der Frage: Welcher Unterschied sollte jetzt genau dazu führen, daß dieser Beitrag (so ich einen verfassen würde) in der Zukunft leichter gefunden werden kann, als die bisher bereits geschriebenen?

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

oder weil ich kein recover gemacht habe ...
Deshalb ... nur danach steht in "firmware_info" das "recovered=2". Wobei auch das Zurücksetzen auf Werkseinstellungen dort etwas einträgt (die Zusammenhänge werden aber komplizierter) und man deshalb tatsächlich (wie in #22 zu lesen, wenn ich auch die Begründung dort nicht so richtig verstehe) vor der Installation irgendeiner Version über den Bootloader auch nicht unmittelbar dieses Zurücksetzen ausführen sollte (oder man versteht die damit verbundenen Nebenwirkungen bzw. ist bereit, sie zu ignorieren) ... oder man läßt die Box danach wenigstens noch einmal starten.

Nicht alle Daten werden unmittelbar bei diesem Zurücksetzen gelöscht, sondern manche erst beim nächsten Systemstart ... deshalb sollte man auch vor dem Verkauf einer gebrauchten FRITZ!Box nicht nur das Zurücksetzen ausführen, sondern im Anschluß die Box noch einmal neu starten lassen (mind. bis zum Blinken der WLAN-LED). Insgesamt haben - zumindest in neueren Versionen mit dem etwas smarteren Installationsskript - aber noch einige weitere Einstellungen Einfluß auf das Ergebnis ... deshalb umfassen "Handlungsempfehlungen" (aka "Anleitungen", so ich denn tatsächlich mal welche gebe) in der Regel auch nur das Hauptthema und nicht die Variationen, selbst wenn diese zur vollständigen Beschreibung eigentlich gehören würden. Aber man findet bei mir halt auch die Angaben, woher ich meine Schlußfolgerungen habe und die Verweise auf die entsprechenden AVM-Skripte, aus denen ich sie ableite ... primär wieder mit dem Ziel, daß man sich dort selbst genauer informieren kann, wenn man es möchte.
 
Zuletzt bearbeitet:
Beiträge nur eine gewisse Maximalgröße haben sollten
Haben sie schon ... bei 50.000 Zeichen ist (afaik) Schluß. Das verhindert im Moment u.a. auch wirksam, daß ich einige meiner alten Threads überarbeiten kann. Du wurdest also schon erhört - wenn auch nicht durch Aufnahme dieses Zusatzes in die Board-Regeln.

Ansonsten gäbe es doch für die Fans der ganz kurzen Beiträge noch diverse andere Dienste, die auch nur sehr viel kürzere Mitteilungen verwenden (auch wenn selbst Twitter von seinen alten 140 Zeichen weg ist und inzwischen 280 Zeichen erlaubt sind) ... wollte ich mich tatsächlich so kurz fassen, nutzte ich diese Dienste. Anders als die übergroßen Bilder, mit denen Du das zu vergleichen geruhst, nehmen diese Texte auch nur den unbedingt notwendigen Umfang an Ressourcen (in erster Linie beim übertragenen Datenvolumen) in Anspruch ... nicht alles was hinkt, ist eben automatisch auch ein korrekter Vergleich.

Wer aber tatsächlich auch nur so wenig denkt, daß er das stets in 280 Zeichen unterbringen kann, der käme doch mit anderen Diensten deutlich besser klar - wenn ich bisher in solcher Kürze irgendjemandem antwortete, war die Reaktion in den überwiegenden Fällen jedenfalls ein "Hä?" ... und das bringt dann beiden Seiten nichts, erst recht nicht späteren Lesern, die vielleicht noch einen anderen Kontext haben bei ihrer Recherche.

Aber ich werde - nach dieser Antwort - einfach mal die nächsten sieben Tage jeden weiteren Beitrag meinerseits auf 140 Zeichen beschränken ... mal sehen, wie positiv das am Ende aufgenommen wird.

Bringt es eigentlich etwas, wenn ich meinerseits beantrage, daß Beiträge auch nur (wie es die Forenregeln eigentlich sogar vorsehen) mit korrekter Grammatik und Orthographie veröffentlicht werden dürfen? Oder mit einem minimalen sinnvollen Inhalt, jenseits von "Bei mir funktioniert alles." oder "Verstehe ich gar nicht, ist mir zu hoch."? Vielleicht sollte man auch über etwas wie "betreutes Schreiben" nachdenken, um die Extreme (bei mir sehr lange Beiträge, bei manch anderem komplett fehlender Inhalt oder eher wirre Gedankengänge - zumindest "auf dem Papier" und nur danach kann es der Leser hier halt beurteilen) auszugleichen?
 
Zuletzt bearbeitet:
  • Like
Reaktionen: LastRaven
Ich habe jetzt auch ein Ticket bei AVM eröffnet
 
dann KANN da eben in "firmware_info" kein gültiger Wert stehen, wenn er es nicht schon vor diesem Startversuch tat. Das System kommt nämlich gar nicht bis zum Auslesen/Ändern des Environments ... es findet schlicht kein Root-FS und verfällt umgehend in Panik

Ich kann nicht wirklich ungültiges erkennen.
Code:
C:\WINDOWS\system32>ftp 192.168.178.1
Verbindung mit 192.168.178.1 wurde hergestellt.
220 ADAM2 FTP Server ready
530 not logged in
Benutzer (192.168.178.1:(none)): adam2
331 Password required for adam2
Kennwort:
230 User adam2 successfully logged in
ftp> quote GETENV firmware_info
firmware_info         154.06.92

200 GETENV command successful
ftp> quote GETENV firmware_version
firmware_version      avm

200 GETENV command successful
ftp> quote GETENV ptest
ptest

200 GETENV command successful

Was der ftp-Server (ADAM2) bei der FB7590 alles versteht bzw. kann, übersteigt mein Wissen.
Bei der FB6490 gab es mal ein script, mit dessen Hilfe man sich aus einer *.export ein gültiges TFFS basteln und direkt in den eMMC hochladen konnte.

Bei einer 7590 ist dies wohl so ähnlich nicht vorgesehen. Zu "ptest" fand ich nur [urlhttps://www.felixcloutier.com/x86/ptest]dieses, was mir sinnvoll erschien[/url], mich allerdings keinen Millimeter weiterbrachte, sofern es dabei um interne Speicheroperationen des NAND-Speichers geht, mit denen ich sicherlich nicht "per Du" bin, sondern eher "perdu".
LG
 
TFFS steht nicht im eMMC, auch nicht bei der 6490; aus einer Export-Datei kriegt man kein TFFS-Image, nur aus der erw. Support-Datei.


133 Byte
 
Danke für die Richtigstellung. Ich hatte einen alten Beitrag von @fesc im Kopf im 6490er Bereich zu dem environment, TFSS und Bootloader, wo die Zusammenhänge wohl etwas verwirrend -zumindest für mich- zum Ausdruck kamen.
Das mit den erweitereten Supportdateien war ein Flüchtigkeitsfehler. Für eine FB7590 wird dies wohl eh nichts bringen, (ich habe sträflicherweise eh nur eine *.export erstellt) da
...

printf "This script is not supposed to handle dumps from devices with a\n"
printf "NAND-based TFFS driver.\n\n"
der TFFS-Skripte-Stuff wohl nur für andere Modelle nutzbar ist. Es gibt zwar für die 6490 Hinweise, wie man mit den div. Angaben auf dem Aufkleber sich ein TFFS imho minimalistisch erstellen könnte, um aus der Bootschleife zu kommen. Inwieweit dies auch für die 7590/7530/7580 zutrifft, durchschaue ich nicht.

Zu dem Flashvorgang einer 7590 gibt es auch nicht sonderlich viel, ausser diesem Thread wo zwar gleichfalls festgestellt wurde, dass einiges fehlerhaft angegangen wurde und final auf ein powershell-script ausgewichen wurde, das ursprüngliche ncftp-Vorgehen aber Fragen hinterlässt, wie es denn nun richtig gewesen wäre. Ein "RETR env" mag mir auchnicht gelingen per ncftp.

Wie per ADAM2 ein Filesystem (sofern dies bei mir offensichtlich durch linux_fs_start-Wechsel und anschliessendem recovery beschädigt wurde) für NAND-Boxen ins RAM und dann final im Speicher an der richtigen Stelle landet, ist z.B. in dieser Quelle auch nicht wirklich zu entnehmen.

Sämtliche Versuche über avm-recovery und/oder in-memory.image bringen meine FB7590 nicht mehr aus der Reboot-Schleife. Da vermutlich sämtliche Einstellungen (SIP+Co) irgendwo noch in der FB vorhanden sind, scheue ich mich vorerst etwas, diese zu reklamieren bei Amazon, da ich nicht weiss, in wessen Hände die FB später landet, falls sich mit ein paar einfachen "Fingerübungen" die FB wieder ins Lot bringen lässt und ggfs. mit einem "7590_skip_auth.image" aus dieser sämtliche Daten abgegriffen werden könnten.
LG
Edit: Link korrigiert
 
Zuletzt bearbeitet:
das ursprüngliche ncftp-Vorgehen aber Fragen hinterlässt, wie es denn nun richtig gewesen wäre.
Keine Ahnung, welche Fragen das sein sollen. Es gibt bei einer FTP-Verbindung grundsätzlich zwei Seiten ... einmal den Server und einmal den Client. Letzterer versteht in der Regel auch lokale Kommandos (Anzeige normalerweise mit "help"), aus denen er dann die passenden Kommandos für den Server ableitet. Dessen "Instrumentarium" kann man (bei einem "voll ausgebauten" Server, da gehört der in EVA allerdings nicht dazu) mittels "quote help" ermitteln:
Code:
vidar:/home/GitHub/YourFreetz $ ftp fb7490
Connected to fb7490.[...]
220 FRITZ!Box7490 FTP server ready.
331 Password required for [...]
230 User [...] logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
cd /
250 CWD command successful.
ls -la
229 Entering Extended Passive Mode (|||49512|)
150 Opening ASCII mode data connection for '/bin/ls -lgA -la'.
drwxrwxr-x 1 ftp ftp 2048 Jul 28 11:01 .
drwxrwxr-x 1 ftp ftp 2048 Jun 21 2013 Bilder
drwxrwxr-x 1 ftp ftp 2048 Jun 21 2013 Dokumente
drwxrwxrwx 1 ftp ftp 2048 Jun  5 06:30 FRITZ
drwxrwxr-x 1 ftp ftp 2048 Jun 21 2013 Musik
drwxrwxrwx 8 ftp ftp 1736 Jul 31 19:52 Online-Speicher
drwxrwxr-x 1 ftp ftp 2048 Jun 21 2013 Videos
drwxrwxrwx 12 ftp ftp 12288 Jul 28 11:01 YourFritz
drwxr-xr-x 9 ftp ftp 4096 Jul  7 11:48 modfs
drwxrwxrwx 21 ftp ftp 4096 Jul 28 11:01 system
drwxrwxrwx 2 ftp ftp 40 Jan  1 1970 volatile
-rw-r--r-- 1 ftp ftp 3053056 Jul 11 03:00 YourFritz-base-VR9-3.10.107-1.0.14.image
-rw-r--r-- 1 ftp ftp 24387584 Jul 17 10:10 bintools.custom
-rwxrwxrwx 1 ftp ftp 3129 Dec  9 2018 yourfritz_icon.png
226 Transfer complete.
ftp> help
Commands may be abbreviated.  Commands are:

!               case            dir             fget            idle            mdelete         modtime         ntrans          progress        rcvbuf          rmdir           sndbuf          type
$               cd              disconnect      form            image           mdir            more            open            prompt          recv            rstatus         status          umask
account         cdup            edit            ftp             lcd             mget            mput            page            proxy           reget           runique         struct          unset
append          chmod           epsv            gate            less            mkdir           mreget          passive         put             remopts         send            sunique         usage
ascii           close           epsv4           get             lpage           mls             msend           pdir            pwd             rename          sendport        system          user
bell            cr              epsv6           glob            lpwd            mlsd            newer           pls             quit            reset           set             tenex           verbose
binary          debug           exit            hash            ls              mlst            nlist           pmlsd           quote           restart         site            throttle        xferbuf
bye             delete          features        help            macdef          mode            nmap            preserve        rate            rhelp           size            trace           ?
ftp> quote help
214- The following commands are recognized (* =>'s unimplemented).
   USER    PASV    MLFL*   ALLO    XCWD    NOOP    XPWD    EPRT
   PASS    TYPE    MAIL*   REST    LIST    MKD     CDUP    FEAT
   ACCT*   STRU    MSND*   RNFR    NLST    XMKD    XCUP    OPTS
   SMNT*   MODE    MSOM*   RNTO    SITE    RMD     STOU    AUTH
   REIN*   RETR    MSAM*   ABOR    SYST    XRMD    SIZE    PBSZ
   QUIT    STOR    MRSQ*   DELE    STAT    RRMD    MDTM    PROT
   PORT    APPE    MRCP*   CWD     HELP    PWD     EPSV
214 Direct comments to [email protected].
ftp>
Wie man sieht, sind die bekannten Kommandos auf Server- und auf Client-Seite weitgehend unterschiedlich ... für die Umsetzung der Absichten, die durch die Eingabe eines Kommandos im Client geäußert wurden, in die passenden Server-Kommandos ist der Client zuständig. Will man stattdessen ein Server-Kommando direkt eingeben, muß man diesem ein "quote" voranstellen.

Damit erklärt sich das hier: https://www.ip-phone-forum.de/threads/7590-dateiübertragung-zum-vom-eva-bootloader-schlägt-fehl-425-cant-open-data-connection.296350/post-2235423 auch von selbst ... es geht damit los, daß ein Kommando "SYST" lokal eingegeben wird, das aber nicht verstanden werden kann, weil es nicht zu den Client-Kommandos gehört.

Wenn danach alle weiteren Kommandos mit "quote" direkt an den Server gesendet werden, kriegt der Client davon nichts weiter mit und kann daher auch keine weiteren Aktionen, die für einige der Kommandos erforderlich wären (u.a. das Öffnen und Schließen von zusätzlichen TCP-Verbindungen für die Datenübertragung), in die Wege leiten.

Ein "RETR env" mag mir auchnicht gelingen per ncftp.
Das ist auch nicht weiter verwunderlich, denn das Client-Kommando im "ncftp" dafür heißt nun mal "get env" ... "RETR" und "STOR" sind die SERVER-Kommandos hinter "get" und "put".

Zu dem Flashvorgang einer 7590 gibt es auch nicht sonderlich viel
Dem widerspreche ich mal auf das Schärfste, denn der unterscheidet sich nun mal (wurde auch oft genug erwähnt) nicht von dem bei den anderen GRX5-Boxen und für diese habe ich das (auch mehrfach) beschrieben. Wer hier also unbedingt nach "7590" sucht, anstatt nach GRX5 oder nach "verwandten Modellen" einer 7590, der macht denselben Fehler, als wenn er für die Beschreibung von Vorgängen bei einer 7430 oder 7362SL nun genau nach diesen Modellen sucht, anstatt zu erkennen, daß diese beiden ebenfalls VR9-Boxen mit NAND für das OS sind und daher weitgehend dieselben Prozeduren helfen.

Wie per ADAM2 ein Filesystem [...]
Interessiert mich auch nicht wirklich, was da im anderen Forum (obendrein noch so verlinkt, daß man es gar nicht wirklich lesen kann, sofern man dort keinen eigenen Account hat) beschrieben wurde ... für GRX-Boxen habe ich die Abläufe hier im IPPF erläutert (teilweise sind die Threads sogar gepinnt) - wobei ich aus der Erinnerung diese Erklärungen im anderen Board durchaus für sehr hilfreich halte; gerade für die Leute, die sich immer wieder beschweren, daß ihnen die meinen zu unverständlich wären.

Inwieweit dies auch für die 7590/7530/7580 zutrifft, durchschaue ich nicht.
Beim Schreiben eines TFFS-Images unterscheiden sich die GRX-Boxen nicht von den anderen Modellen ... die Umsetzung von "legacy image" auf NAND-Strukturen nimmt tatsächlich der Bootloader der GRX-Boxen selbst vor. Ich vermute mal, daß AVM hier den "TFFS image builder" in den Recovery-Programmen nicht ändern wollte ... daher verwenden die GRX-Boxen exakt dasselbe Format beim Schreiben eines neuen TFFS-Images, wie die früheren Modelle.

Allerdings erfolgt die interne Speicherung eben in einer anderen Form und das bisher von mir veröffentlichte Skript, mit dem man einen TFFS-Dump (wie er z.B. in den erweiterten Support-Daten zu finden ist, wenn alles gut geht bei deren Download) in seine Bestandteile zerlegen kann, funktioniert bei Boxen mit "NAND-TFFS" (u.a. gehört dazu auch die 7412) nicht. Aber beim Zusammenbau eines neuen, leeren TFFS-Images, das nur die "Geburtsdaten" der Box im Urlader-Environment enthält (wozu man "build_tffs_image" verwenden könnte), sind die Abläufe exakt dieselben - auch bei den GRX-Boxen.

Wer also die richtigen Daten zusammenkriegt (besonders wichtig sind hier diejenigen, die für das Gerätekennwort beim verschlüsselten Speichern der Einstellungen verwendet werden - gibt es hier Diskrepanzen, sind die Einstellungen nicht länger lesbar) aus den verschiedenen Quellen (vieles steht auf dem Typenschild), der kann sich auch bei den GRX-Boxen sein eigenes TFFS-Image bauen. Wobei das bei diesen Modellen automatisch auch weniger Relevanz hat ... viele der Einstellungen stammen aus dem CONFIG-Area im Bootloader und werden auch von dort in den ODT übernommen (der wird beim Systemstart vom Bootloader an den Kernel übergeben) und danach vom System verwendet. Das ist u.a. ein Grund, warum sich eine solche Box nicht von einer Änderung an "firmware_version" beeindrucken läßt ... diese Einstellung wird aus dem CONFIG-Bereich direkt übernommen und es interessiert kein Schwein, was da in einem TFFS-Image stehen mag.

Aber meinerseits ist das Thema "7590" hier dann auch durch ... dieser Thread hat ja eigentlich ein anderes Anliegen.

Wenn Du also eine Box hast, die nicht mehr starten will, mache dafür einen neuen Thread auf und beschreibe sowohl die derzeitigen Symptome als auch die bisher unternommenen Rettungsversuche. Wenn man das systematisch angeht, wird man die Box vermutlich auch wieder zum Leben erwecken können ... aber zuerst mal geht es auch um die Feststellung, woran es nun wirklich liegt.

Ein zerstörtes TFFS-Image (Woher sollte das eigentlich kommen? Es würde ja vermutlich niemand auf die Idee kommen, à la ruKernelTool einfach eine Datei der Länge 0 nach mtdnand zu schreiben und selbst dann bin ich mir nicht sicher, daß der Bootloader - der das ja umsetzen muß - da tatsächlich das vorhandene TFFS zerstört, wenn keine neuen Daten vorliegen.) wäre jedenfalls erst mal eine der weniger wahrscheinlichen Erklärungen für mich und bei dem Begriff "Reboot-Schleife" gehen die Vorstellungen beim Leser sicherlich auch weit auseinander. Je nachdem, wie lang ein Intervall einer solchen Schleife am Ende ist, wäre die Ursache für das erneute Reboot dann auch an vollkommen unterschiedlichen Stellen zu suchen und um sich dessen zu vergewissern, gibt es ja ein paar markante Stellen im Bootablauf, denen man auch dann nachspüren kann, wenn man ansonsten nicht mehr mit dem Gerät interagieren kann (zumindest nicht in vollem Umfang).
 
Zuletzt bearbeitet:
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.