[Gelöst] F!B 6591 Bootloop

[porcupine]

By the way - es ist vollkommen normal, wenn Freetz-NG für ein originales System UNKNOWN anzeigt, denn darin gibt es nun mal keine /etc/.version: https://github.com/Freetz-NG/freetz...files/root/usr/mww/cgi-bin/system_lfs.cgi#L65

Ah danke, nice to know.

 

[PeterPawn]

Intressant wäre natürlich trotzdem die Antwort auf die Frage, warum ist es initial passiert?

Was meinst Du damit genau? Denn daß Du Dein rsync verkackt hattest, dürfte doch eigentlich bewiesen sein, oder?

 

[porcupine]

Wieso? Hat die Box denn keinen anderen Flash mehr?

Keine Ahnung, es scheint ja noch mtdblock devices zu geben, allerdings wurde hier darauf verwiesen, dass dies kein vollständiges Backup ist ...

Der würde ja passen - wenn jetzt die Kontakte auch noch sicher sind UND jeweils der korrekte Pegel verwendet wird, dann sollte auch innerhalb des von Dir als Punkt 5 beschriebenen Zeitraums etwas auf der Schnittstelle zu sehen sein - die Geschwindigkeit (und Bit-Anzahl + Parität) steht ja bei @fesc.

Geschwindigkeit, Bit-Anzahl und Parität hatte ich eingestellt --> kein Erfolg

Evtl. löte ich mal noch die Header auf um die Kontaktierung auszuschließen. Wäre die Frage ob der KernelOutput hier im Nachgang noch viel bringt für die Ursachenforschung.

Was meinst Du damit genau? Denn daß Du Dein rsync verkackt hattest, dürfte doch eigentlich bewiesen sein, oder?

Davon gehe ich aus. Nur was genau ist da passiert?

 

[PeterPawn]

Nur was genau ist da passiert?

Wenn man eine ext4-Partition immer weiter beschreibt, ist die halt irgendwann mal voll und wenn dann dort noch offene Transaktionen existieren (immerhin ist das ein Dateisystem mit Journal), die nicht beendet und auch nicht zurückgerollt werden können, dann kann das betroffene Dateisystem eben nicht mehr so ohne Weiteres gemountet werden und braucht i.d.R. einen manuellen Eingriff, der aber im FRITZ!OS nicht vorgesehen ist.

es scheint ja noch mtdblock devices zu geben

HAST Du eigentlich JEMALS die jetzt schon mehrfach erwähnte Datei zur 6591 bis zum Ende durchgelesen? Da steht doch auch drin, wie der SPI-Flash partitioniert ist und mtdblock3 dürfte eher darin liegen. Außerdem sollte ja auch /proc/mtd passende Informationen liefern.

Seine "Nachfragen" über mehrere Seiten zu verteilen, mag ja wie eine schlaue Strategie wirken - aber irgendwann merkt das auch der Dümmste (der in diesem Fall wohl ich bin).

 

[porcupine]

Wenn man eine ext4-Partition immer weiter beschreibt, ist die halt irgendwann mal voll und wenn dann dort noch offene Transaktionen existieren (immerhin ist das ein Dateisystem mit Journal), die nicht beendet und auch nicht zurückgerollt werden können, dann kann das betroffene Dateisystem eben nicht mehr so ohne Weiteres gemountet werden und braucht i.d.R. einen manuellen Eingriff, der aber im FRITZ!OS nicht vorgesehen ist.

Das klingt logisch.

HAST Du eigentlich JEMALS die jetzt schon mehrfach erwähnte Datei zur 6591 bis zum Ende durchgelesen? Da steht doch auch drin, wie der SPI-Flash partitioniert ist und mtdblock3 dürfte eher darin liegen. Außerdem sollte ja auch /proc/mtd passende Informationen liefern.

Ja die Datei habe ich mir mehrfach durchgelesen, leider bleiben halt immer Fragen und auch "GIDF" ist halt nicht hilfreich, weil meist der passende Kontext fehlt.

Vielen Dank Dir und schönen Sonntag noch!

 

[fesc]

Sind die Zuordnungen bei Puma7 dynamisch

Wenn ich meinen eigenen aufzeichnungen trauen darf sind sie statisch.
linux_fs_start=0 bootet von mtd0/1/6/7
linux_fs_start=1 bootet von mtd;/</=/>

 

[fesc]

Kein Output

mute=0 habe ich bei mir nur für alte BIOS versionen beschrieben.
Generell kann man beim bauen der boot images zwei register-zugriffe einbauen die den UART output aktivieren:

mm 0xfed94810 0x00914b49 -w 4
mm 0xfed94820 0x00914b49 -w 4

Das ganze nach EFI/BOOT/startup.nsh in part_02_ATOM_KERNEL (das ist ein fat filesystem image). Beschrieben habe ich das prinzipiell in "Getting Access to the EFI shell", wobei da auch der bootvorgang unterbrochen wird um in die efi shell zu kommen. Wenn man die zeilen vor allem anderen in startup.nsh einfügt sollte der serielle output kommen.
In meinem buildsystem passiert das implizit wenn man ENABLE_CONSOLE=1 im configurationsfile aktiviert.

übrigens geht das meist auch ohne löten wenn man einfach die pinheader in die Löcher klemmt und, wenn man durch die Löcher trifft, sogar ohne das Gehäuse zu öffnen.

Nur was genau ist da passiert?

Das könnte man vielleicht rausbekommen wenn du den rsync nochmal machst und eine konsole dran hast. Bei mir resettet die Box gerne mal wenn der Speicher knapp wird (~700MB) .. was läuft denn sonst noch so?

 

[Queer-new]

Es freut mich, daß dein Problem gelöst werden konnte @porcupine. Mit meinem Bauchgefühl, daß einige adam2-Befehle nicht wirklich angenommen wurden, lag ich wohl nicht exorbital daneben, wobei für mögliche Hardwarefehler @chips sicherlich eine gefragte Adresse ist, sofern dergleichen zu mutmassen sind -als Hinweis zu

(mir ist ohnehin unklar, was @chips da helfen sollte - vermutlich nur das Löten zeigen, anstatt da mit "fliegender Verdrahtung" zu arbeiten?)

Im Übrigen las ich in meiner Recherche , daß die USB-Schnittstellen und Nutzung für grosse HDDs und Backups, das AVM-OS schonmal zum Reboot zwang. Mit freetz-ng sicherlich mal ein Gedanke wert an die raren Experten, was da schief lief.

Danke

Im übrigen habe ich auch nichts gegen "zielgerichtete Fragen" - jedoch gegen Wiederholungen, die unnötig sind bzw. wären, wenn der Fragesteller*in einfach mal selbst suchen würde. Nichts anderes wollte ich mit meinen "Suchvorschlägen" zeigen und wenn Du solche eigenen Anstrengungen für "nicht mehr zeitgemäß" hältst, dann haben wir beide da ein Problem miteinander.

da bin ich ganz bei dir. Nur sind deine Ansprüche, was denn nun zu Lesen und gefälligst zu Finden und kombinatorisch als eigene Lösungsvorstellung selbst anzuwenden sind exorbitant hoch, dem die meisten hier wohl nicht gerecht werden können. Die Zeiten von harten Schulen in den 60zigern, wo Rohrstock Ohrfeigen und sonstige Züchtigungen die gängige Wahl der Lehrkräfte war, ist GOTT SEI DANK vorbei. Von daher kann ein Wenig Geduld und Empathie im Tenor von Beiträgen wohl nicht ganz verkehrt sein, es sei denn das Forum ist die Hochburg der "alten weissen Männer" was die wissbegierige Jugend an ihre Vorstellungen zwangsadaptieren möchte. Das war mein letzter Hint zu diesem Problem, was ich wahrlich nicht mit dir bekommen möchte, da es bei weiteren Fragen den Hilfe-Core auf NULL setzt. Es hat mich wirklich riesig gefreut, daß du mich auf das richtige Gleis gesetzt hast und damit die Box vor dem Werthof gerettet hast.

OT: Da ich schon länger mit dem WLAN-Problem kämpfte, habe ich mir in Kleinanzeigen Ersatz besorgt, leider mt einem alten BIOS, wo dieser Tage so ein Teil eintreffen wird. Vielleicht kann man sich auch über die Möglichkeiten der bei fesc erwähnten UEFI-Shell austauschen, da dazu die Fundquellen/-stellen eher spärlich, was und wie man darüber erreichen kann. Eine permanente Einbaustelle im Gehäuse-Fuss habe ich schon ausgeguckt, was einfach und unauffällig aussieht und ständiges Aufschrauben oder Stochern durch Löcher erspart.

 

[porcupine]

In meinem buildsystem passiert das implizit wenn man ENABLE_CONSOLE=1 im configurationsfile aktiviert.

übrigens geht das meist auch ohne löten wenn man einfach die pinheader in die Löcher klemmt und, wenn man durch die Löcher trifft, sogar ohne das Gehäuse zu öffnen.

Danke, da flashe ich vielleicht mal Deine Version auf die zweite Partition.

Das könnte man vielleicht rausbekommen wenn du den rsync nochmal machst und eine konsole dran hast. Bei mir resettet die Box gerne mal wenn der Speicher knapp wird (~700MB) .. was läuft denn sonst noch so?

Leider weiss ich ich nicht mehr 100% den exakten Cmd, aber ja nachstellen könnte ich es.
Auf der FB läuft eigentlich nicht sonderlich viel: dropbear, OpenVPN, NAS mit 2 Platten, samba und ab und zu halt rsync & screen

Vielen Dank nochmal an alle die an der Lösung beteiligt waren.