[Gelöst] F!B 6591 Bootloop

porcupine

Neuer User
Mitglied seit
24 Apr 2024
Beiträge
19
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

ich habe hier eine F!B 6591 welche aktuell in einer Bootloop hängt.

Zur Vorgeschichte:
Ich hatte die FB auf eBay Kleinanzeigen geschossen und es war natürlich eine gebrandete Vodafone Version. Das DeBranding hat allerdings super geklappt und die FB lief jetzt seit mehreren Monaten sehr stabil mit freetz-ng.

Zum Vorfall:
Ich wollte ein Backup meines Servers auf die lokale HDD an der FB machen. Hab das ganze über SSH direkt auf der FB laufen lassen. (rsync auf den Folder '/ftp/Volume' oder so ähnlich)
Irgendwann hat die FB einfach neu gestartet und hängt seitdem in einer Bootloop.

Kann es sein, dass ich mit einem fehlerhaften rsync-cmd meine FB komplett zerschossen habe?

Was ich bereits versucht habe:

  • flashen diverser Firmwares (freetzng-build via vBox / push_firmware, orginial AVM Image via eva-tools)
  • setzen der Startpartition mit linux_fs_start 0 / 1
  • env & count ausgelesen (siehe Anhang)
  • TFFS Image erstellt
    • laut Anleitung flashen auf mtd3 / mtd4
      • "put mtd.img mtd3" -> 501 unknown variable mtd3
Wie und auf welche Werte kann ich mtd3 / mtd4 setzen? Sind das überhaupt die richtigen Partitionen für TFFS?

Was mich sehr verwundert ist in der env.txt der Bereich für mtd4:
mtd3 0x5300000,0x5B00000
mtd4 0x0,0x0

Hat hier jemand Tipps wie ich die FB wieder hinbekomme?
Siehe auch CrossPost: Link zu unseriösen/unerwünschten Quellen entfernt - by stoney
 

Anhänge

  • count.txt
    150 Bytes · Aufrufe: 1
  • env_redacted.txt
    1.6 KB · Aufrufe: 6
Zuletzt bearbeitet von einem Moderator:
Kann es sein, dass ich mit einem fehlerhaften rsync-cmd meine FB komplett zerschossen habe?
Unwahrscheinlich. Aber man soll ja niemals nie sagen… Für wahrscheinlicher halte ich da schon, dass das Netzteil der 6591 "zerschossen" wurde.

Was mich sehr verwundert ist in der env.txt der Bereich für mtd4:
mtd3 0x5300000,0x5B00000
mtd4 0x0,0x0
Das ist doch völlig normal für ne 6591…
 
Ich würde es mal mit dem Zusatz recovered=2 in firmware_info versuchen, falls tatsächlich beim rsync fälschlicherweise der interne Flashspeicher (also die AVM_MEDIA-Partition) komplett beschrieben wurde (dafür reicht schon ein fehlendes Unterverzeichnis in der Pfadangabe) und jetzt nicht mehr gemountet werden kann, weil da offene Transaktionen existieren bzw. das Dateisystem für die Partition (iirc ist das ext4) erst einmal gefixt werden müßte. Dabei gehen dann allerdings alle Daten in der NAS-Partition flöten.

Je nach dem Alter der Firmware gibt es wohl auch noch weitere "Einträge" in firmware_info, mit denen man das Verhalten - auch für die Cable-Boxen, bei denen ja kein Recovery-Programm veröffentlicht wird von AVM - beim Start beeinflussen kann … einfach mal suchen. Iirc habe ich das hier erklärt, welche Optionen AVM da eingebaut hat. Tatsächlich ist darüber auch das Zurücksetzen auf Werkseinstellungen möglich, wenn die Box nicht mehr vollständig startet - was bei Cable-Boxen ja ansonsten mangels Software von AVM nicht klappt.

Vom Ersetzen der TFFS-Daten sollte man ohnehin die Finger lassen, solange das eigentliche Problem nicht klar erkannt ist. Obendrein verwenden die Puma7-Boxen ein komplett anderes Layout für ihren eMMC und ob da überhaupt in EVA ein Mapping für die TFFS-Partitionen als MTD existiert, ist -soweit ich das kenne - auch unbekannt.

Ansonsten ist natürlich auch die Aussage "Bootloop" nur wenig hilfreich - ETWAS mehr an Angaben, z.B. zur Dauer bis zum Reboot und den Anzeigen der LEDs in einem solchen Zyklus, dürfen es dann schon noch sein, wenn man wenigstens eine UNGEFÄHRE Vorstellung entwickeln soll, woran das nun liegen könnte.
 
Unwahrscheinlich. Aber man soll ja niemals nie sagen… Für wahrscheinlicher halte ich da schon, dass das Netzteil der 6591 "zerschossen" wurde.

Ich halte das Netzteil eher für unwahrscheinlich. Kann es aber gern mal probieren mit Wechseln.
Die FB ging halt genau wenige Minuten nachdem ich das rsync Backup gestartet hatte offline. Da ist mir der Zufall zu groß, dass just in diesem Moment das Netzteil nicht mag. (Die FB lief vorher mit 2 USB Platten über 2 Monate durch)
Ich würde es mal mit dem Zusatz recovered=2 in firmware_info versuchen,

Wie genau lese ich firmware_info aus? per ftp?

Vom Ersetzen der TFFS-Daten sollte man ohnehin die Finger lassen, solange das eigentliche Problem nicht klar erkannt ist. Obendrein verwenden die Puma7-Boxen ein komplett anderes Layout für ihren eMMC und ob da überhaupt in EVA ein Mapping für die TFFS-Partitionen als MTD existiert, ist -soweit ich das kenne - auch unbekannt.
Ok, dass ist gut zu wissen. Und ja, per EVA ging das flashen auf mtd3/mtd4 schonmal nicht ...
Ansonsten ist natürlich auch die Aussage "Bootloop" nur wenig hilfreich - ETWAS mehr an Angaben, z.B. zur Dauer bis zum Reboot und den Anzeigen der LEDs in einem solchen Zyklus, dürfen es dann schon noch sein, wenn man wenigstens eine UNGEFÄHRE Vorstellung entwickeln soll, woran das nun liegen könnte.
Also direkt nach dem PowerOn:
  1. grüne LED dauerhaft an15s
  2. alle LEDs an ~1s
  3. alle LEDs aus ~5s
  4. grüne LED blinkend 1x ~1s
  5. grüne LED dauerhaft an 10s
  6. grüne LED blinkend im Sekundentakt ~3min
  7. repeat
 
Die FB ging halt genau wenige Minuten nachdem ich das rsync Backup gestartet hatte offline. Da ist mir der Zufall zu groß, dass just in diesem Moment das Netzteil nicht mag.
Zu welchem anderen beliebigen Zeitpunkt wäre denn die Wahrscheinlichkeit eines angenommenen Ausfalls des Netzteils deiner Meinung nach größer?
 
Mal abgesehen davon, daß ja bei den Puma7-Boxen m.W. auch alle LEDs (bis auf eine) grün sind (und deshalb vermutlich auch jeweils dran steht, was die signalisieren sollen) … bis 6. ist das alles der Bootloader für Puma7 (5. müßte das Laden des Kernels sein (ATOM- und/oder ARM-, was auch immer länger braucht)) und wenn dann das System bis zu drei Minuten arbeitet (während der ARM-Teil die DOCSIS-Komponenten startet und versucht zu synchronisieren), bevor die Box neu startet, klingt das immer mehr nach einer zerwürgten NAS-Partition (für mich).

EDIT:
Ich habe auch die Stelle gefunden, wo ich die neuen Möglichkeiten für das Zurücksetzen von Einstellungen per firmware_info "erwähnt" hatte - das war/ist tatsächlich etwas schwerer zu finden, egal mit welcher Suche, wenn man die passenden Stichwörter nicht kennt:
in der 07.39 taucht an dieser Stelle auch neuer Code auf, der zusätzlich auf die Existenz der Kombinationen reset=tffs (für "Werkseinstellungen"), reset=locale (für die eingestellte Sprache UND das Land) und reset=setcountry (setzt die Telefonie-Einstellungen auf Werksvorgaben) prüft und entsprechende Aktionen auslöst.
 
  • Like
Reaktionen: porcupine und NDiIPP
[…] klingt das immer mehr nach einer zerwürgten NAS-Partition (für mich).
Und die Ursache des Reboot könnte dann wohl auch daran liegen, das dabei nicht nur in die AVM_MEDIA Partition geschrieben wurde sondern auch in andere Ordner (was dann ja ggf. in der RAM-Disk landet und somit ist dann vermutlich der Arbeitsreicher ausgegangenen -> Kernel-Panik -> Reboot…).
 
Zu welchem anderen beliebigen Zeitpunkt wäre denn die Wahrscheinlichkeit eines angenommenen Ausfalls des Netzteils deiner Meinung nach größer?
Netzteil kann ich ausschließen. Hab das Netzteil einer (nichtbaugleichen) anderen Fritzbox probiert. --> selbes Fehlerbild
vice versa funktioniert aber das Netzteil an der anderen FB.

EDIT:
Ich habe auch die Stelle gefunden, wo ich die neuen Möglichkeiten für das Zurücksetzen von Einstellungen per firmware_info "erwähnt" hatte - das war/ist tatsächlich etwas schwerer zu finden, egal mit welcher Suche, wenn man die passenden Stichwörter nicht kennt:
>in der 07.39 taucht an dieser Stelle auch neuer Code auf, der zusätzlich auf die Existenz der Kombinationen reset=tffs (für "Werkseinstellungen"), reset=locale (für die eingestellte >Sprache UND das Land) und reset=setcountry (setzt die Telefonie-Einstellungen auf Werksvorgaben) prüft und entsprechende Aktionen auslöst.

Danke dafür. Wenn ich es richtig verstanden hat komme ich an die Einstellung per firmware_info über GETENV im ftp client? Und dann per SETENV neu setzen und reboot?
Mal abgesehen davon, daß ja bei den Puma7-Boxen m.W. auch alle LEDs (bis auf eine) grün sind (und deshalb vermutlich auch jeweils dran steht, was die signalisieren sollen) … bis 6. ist das alles der Bootloader für Puma7 (5. müßte das Laden des Kernels sein (ATOM- und/oder ARM-, was auch immer länger braucht)) und wenn dann das System bis zu drei Minuten arbeitet (während der ARM-Teil die DOCSIS-Komponenten startet und versucht zu synchronisieren), bevor die Box neu startet, klingt das immer mehr nach einer zerwürgten NAS-Partition (für mich).
Sorry, ja mit grüner LED meinte ich die Power-LED. Hab übrigens beide Platten jetzt erstmal abgestöpselt. Sollte aber für das Bootverhalten unerheblich sein?

Hab die Platte mal an meinen Rechner lokal gesteckt, da ist auch ein kein Ordner oder Content von der rsync-Kopieraktion. Also schon starkes Indiz, dass es irgendwo anders hin ging....
Und die Ursache des Reboot könnte dann wohl auch daran liegen, das dabei nicht nur in die AVM_MEDIA Partition geschrieben wurde sondern auch in andere Ordner (was dann ja ggf. in der RAM-Disk landet und somit ist dann vermutlich der Arbeitsreicher ausgegangenen -> Kernel-Panik -> Reboot…).
Hmm klingt plausibel. Aber nur RAM-Disk wäre nach einem Reboot dann ja wieder ok?
 
Aber nur RAM-Disk wäre nach einem Reboot dann ja wieder ok?
Das ja. Aber die AVM_MEDIA Partition eben nicht. Und vermutlich ist bei diesem rsync-Job sowohl in diese (was nun den erfolgreichen Start von FRITZ!OS verhindert) als auch in die RAM-Disk (was den Reboot auslöste) geschrieben worden.
 
GETENV/SETENV

Je nach FTP-Client sollte man nicht beides in einer FTP-Session machen, denn die Antwort auf GETENV entspricht nicht dem Standard (RFC) für FTP und KANN daher den Client aus dem Tritt bringen (siehe entsprechende Berichte/Beiträge, u.a. auch hier im Board). Besser man arbeitet also mit "low level"-Tools, die die FTP-Kommunikation nachbilden, ohne auf RFC-Konformität zu bestehen, wenn man GETENV zusammen mit weiteren Kommandos in einer FTP-Session benutzen will.

Aber es reicht tatsächlich auch aus, wenn man (an dieser Stelle) nur einen neuen Wert setzt … die Versionsnummer des startenden FRITZ!OS, die ansonsten darin steht, wird ohnehin wieder restauriert. Das ist gleichzeitig auch ein Indiz dafür, wie weit die Box beim Start gekommen ist.
 
Danke.

Hab es mit dem cli ftp -client der Powershell probiert und dann nochmal mit dem ftp-client des TotalCommander.

Hab erst das hier quote SETENV firmware_info 161.07.57,reset=tffs probiert und dann einen Neustart gemacht.

Kein Erfolg, bootloop noch da. Die firmware_info war dann aber nach Neustart wieder resetted auf 161.07.57

Dann hab ich noch folgendes probiert: quote SETENV firmware_info 161.07.57,recovered=2 (im Netz gefunden, aber nicht sicher ob es zur FB passt)

Anscheinend überlebt jetzt aber firmware_info auch einen PowerCycle. D.h. nach poweron steht immernoch firmware_info 161.07.57,recovered=2 drin.


Das LED-blink Pattern hat sich auch etwas verändert:

Dieser Teil hier ist weggefallen: grüne LED blinkend im Sekundentakt ~3min
Die Bootloop ist also etwas schneller geworden. Keine Ahnung ob ich mit dem 2. Cmd noch irgendwas verschlimmbessert habe. :/

Gibts noch weitere Vorschläge?
Würde Zugriff via USB>TTL was bringen?
 
Zuletzt bearbeitet:
Du musst es auch wieder zurücksetzen (recovered=2 entfernen)

Mit einer konsole könntest du evtl sehen wo es hängt, und evtl auch eine shell (je nachdem wie weit sie bootet). Ich habe hier eine box die ein ähnliches bild zeigt, wobei die Ursache ist dass dar ARM teil nicht bootet und dann ein watchdog zuschlägt.

Edit: Bist du sicher dass das erste (mit reset=tffs) geklappt hat? Eigentlich sollte das nicht automatisch zurückgesetzt werden.
Edit2: Sorry, falsch, es wird zurückgesetzt:
Code:
# Reset firmware_info to original value - finalize
echo "firmware_info $version" > "${URLADER_ENV}"
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1
Du musst es auch wieder zurücksetzen (recovered=2 entfernen)
Jup, hab ich gemacht. Das Bootloop-Verhalten bleibt aber gleich. (Also nur noch die kurze Bootloop)

In welchem Bereich liegen eigentlich die Daten für das TFFS Recovery? Kann es sein, dass der Bereich auch nen Treffer abbekommen hat?

Im anderen Forum wurde noch auf die Methode verwiesen ein clean TFFS image zu erzeugen und das auf mtd3 / mtd4 zu flashen. Die Aussagen dazu sind aber bissl widersprüchlich.

Eigentlich ist mir die Fritzbox zu schade zum entsorgen oder für eBay ...
 
Läuft nicht der TFFS-Server bei Puma7 auf dem ARM-Core? Dann dürfte ja das Zurücksetzen über reset=tffs nicht funktioniert haben, solange der ARM-Teil tatsächlich nicht startet.

Der Zusatz recovered=2 sollte m.E. nur dazu geführt haben, daß die NAS-Partition erst einmal formatiert wird vor dem Mount-Versuch. Das sollte eigentlich keine Auswirkungen auf das ARM-System haben, oder?

@porcupine:
Bist Du Dir wirklich sicher, daß in den jetzt zu startenden Partitionen (beim Löschen der TFFS-Inhalte wurde/würde ja automatisch auch der Wert von linux_fs_fstart gelöscht und somit als 0 gewertet) auch ein korrektes System (am besten ein originales von AVM) installiert ist? Klingt für mich jetzt so, als ob da gar kein Kernel geladen werden kann - falls zuvor linux_fs_fstart tatsächlich auf 1 stand, könnte man es auch wieder über EVA setzen, dann sollte der andere Slot benutzt werden, der ja vorher vermutlich noch startete.

EDIT: Oder man installiert das System einfach noch einmal neu, damit man sicher sein kann, daß da wirklich eines ist.
 
Zuletzt bearbeitet:
Oder man installiert das System einfach noch einmal neu, damit man sicher sein kann, daß da wirklich eines ist.
Hab jetzt mittels EVA einfach nochmal das Original-AVM image geflasht. Hat leider nix gebracht.
 
einfach nochmal das Original-AVM image geflasht
Wie wäre es denn (endlich) mal mit ein paar Protokollen? Man kann ja tatsächlich auch beim Flashen viel falsch machen, angefangen bei den korrekten Partition-Namen in EVA.

Insgesamt ist das alles nicht so seeehr logisch und systematisch, was hier geschah und was dann an Rettungsversuchen von Dir unternommen wurde. Das geht damit los, daß die Box lt. Environment in #1 niemals als wirklich vollwertige Retail-Box eingerichtet wurde, denn da steht ja (immer noch) ein RTL=n in der DMC-Variablen.

Und wenn die Versuche mit reset=tffs keinen Einfluß auf das Neuformatieren der NAS-Partition hatten, dann ist das tatsächlich auch so zu erwarten, denn damit wird nur folgendes bewirkt:
Rich (BBCode):
case "${fw_info_env}" in *reset=tffs*)
echo werkseinstellung > /proc/tffs
echo cleanup > /proc/tffs
;;
esac
Da werden also nur die Werkseinstellungen geladen und die alten TFFS-Einstellungen "kondensiert" (bereinigt).

Es gab ja Gründe, warum ich zuerst die Verwendung vonrecovered=2 "empfohlen" habe:
Ich würde es mal mit dem Zusatz recovered=2 in firmware_info versuchen, falls tatsächlich beim rsync fälschlicherweise der interne Flashspeicher (also die AVM_MEDIA-Partition) komplett beschrieben wurde (dafür reicht schon ein fehlendes Unterverzeichnis in der Pfadangabe) und jetzt nicht mehr gemountet werden kann, weil da offene Transaktionen existieren bzw. das Dateisystem für die Partition (iirc ist das ext4) erst einmal gefixt werden müßte. Dabei gehen dann allerdings alle Daten in der NAS-Partition flöten.
- denn wenn man in die Firmware schaut, ist es tatsächlich so, daß bestimmte Fehler auch in der NAS-Partition durchaus zu einem Reboot-Request führen können:
Rich (BBCode):
do_fsck()
{
local filesystem="$1"
local partition="$2"
local ret_code=0
fsck="fsck.${filesystem}"
info "Running ${fsck} on ${partition}"
ret_str=$(${fsck} -p ${partition}) || ret_code=$?
if [ $ret_code -ne 0 ]; then
if [ $ret_code -eq 2 ]; then
info "${fsck} on ${partition} failed with request for reboot, rebooting now..."
reboot
fi
if [ $ret_code -eq 1 ] || [ $ret_code -eq 4 ] || [ $ret_code -eq 32 ]; then
info "${fsck} on ${partition} failed non critical?: (${ret_str}($ret_code))"
else
error "${fsck} on ${partition} failed (${ret_str}($ret_code))"
return 1
fi
fi                                                                                                                                                                                                             
}
(die Formatierung stammt original aus der AVM-Firmware, mit Ausnahme der Farbe)

Und dieser Code wird immer dann aufgerufen, wenn das Mounten einer Partition nicht auf Anhieb funktioniert:
Rich (BBCode):
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
do_fsck "${filesystem}" "${partition}" || true
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
info "Creating new filesystem on ${partition} (${fs_label})"
if ! mkfs.${filesystem} -F -L "${fs_label}" -j -E "${mkfs_extra_flags}" -O "${mkfs_extra_feature}" "${partition}"; then
error "${script}: mkfs on ${partition} failed"
exit 1
fi
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
error "${script}: Giving up."
exit 1
fi
fi
fi
Zwar wird dann (wenn das Prüfen der Partition mit einem nicht-kritischen Fehler endet) auch versucht, die Partition neu zu formatieren (der mkfs-Arfruf), aber da muß das System auch erst mal ankommen und nicht schon vorher im o.g. Code neu starten.

Die zusätzliche Info, was man mit dem reset=something bewirken kann, habe ich Dir nur noch gegeben, weil Du unbedingt der Ansicht warst, mit einem eigenen TFFS-Image hantieren zu müssen - das ist eindeutig NICHT länger erforderlich, wenn auf der Box eine Version >= 07.39 (wobei das erst im Laufe der Labor-Reihe implementiert wurde, iirc, und nicht von Beginn an funktionierte) installiert ist.



Vielleicht gehst Du ja jetzt doch mal systematisch vor und das fängt dann für mich schon damit an, daß man die Veränderungen, die sich ggf. durch den Zusatz von reset=tffs in firmware_info ergeben haben, erst einmal überprüft (am besten gleich das ganze Urlader-Environment noch mal zeigen). Denn Deine Vorstellungen hier:
In welchem Bereich liegen eigentlich die Daten für das TFFS Recovery?
stimmen auch nur zum Teil mit der Realität überein. Es gibt allerdings im Bootloader einen Konfigurationsbereich, der sich m.W. auch bei Puma7-Modellen mit einem kühnen RETR config auslesen lassen müßte und dort findet man dann - neben anderen Daten, u.a. dem CM-Zertifikat der Box - auch die "Geburtsdaten" so einer Box, aus denen die festen Werte beim Start des Loaders restauriert werden und wo es für ein paar andere Werte (DMC sollte u.a. dazu gehören, deshalb sind da auch persistente Änderungen möglich) Standardvorgaben gibt, die man jedoch ändern KANN.

Insofern entsteht bei mir auch der Verdacht (no offense), daß Du Dich eben doch nicht so gut auskennst mit den Puma7-Boxen und da wäre es doch ganz praktisch, wenn Du uns - und zwar sehr ausführlich - an dem teilhaben lassen würdest, was Du da veranstaltest.

Wenn jetzt nicht mal mehr der Inhalt von firmware_info mit der Versionsnummer restauriert wird, dann klemmt es offenbar bereits im Skript /etc/boot.d/core/tffs, denn da steht das hier:
Rich (BBCode):
### puma7-only
sh "/etc/init.d/rc.configspace-v2" || msg_error "rc.configspace-v2 failed."
## cache firmware_info (read once) in front of Puma syncpoint.
fw_info_env=$(grep ^firmware_info "${URLADER_ENV}")
## For Puma, the arm side will be booting a bit slower. This syncpoint will
## be used to avoid a race condition where atom resets firmware_info before
## arm can read it.
. /etc/init.d/rc.core_sync.sh
if [ -n "${Recover_was_here}" ] || case "${fw_info_env}" in *reset=*):;; *) false;; esac ; then
Sync_with_other_cpu FWINFO_up || msg_error "sync firmware_info handling"
fi
## Reset firmware_info to original value
version="$(/etc/version)"
if [ -n "${Recover_was_here}" ]
then
## TAM
if [ -d /data/tam ] ; then
rm -f /data/tam/config
rm -f /data/tam/meta*
fi
fi
case "${fw_info_env}" in *reset=tffs*)
echo werkseinstellung > /proc/tffs
echo cleanup > /proc/tffs
;;
esac
case "${fw_info_env}" in *reset=locale*)
echo "country" > "${URLADER_ENV}"
echo "language" > "${URLADER_ENV}"
;;
esac
case "${fw_info_env}" in *reset=setcountry*)
telefonie_werkseinstellungen "$(echo "$fw_info_env" | sed "s/.*reset=\(setcountry[^,]*\).*/\1/")"
;;
esac
## Reset firmware_info to original value - finalize
echo "firmware_info $version" > "${URLADER_ENV}"
Da muß man also - wenn der Rest funktioniert - GAR NICHTS wieder zurücksetzen an dem Wert in firmware_info. Wenn das nicht von alleine funktioniert, kommt das System offenbar gar nicht erst bis zu dieser Stelle und das ist dann tatsächlich SEHR früh im Startvorgang.

Warum jetzt plötzlich irgendein Core defekt sein soll, erschließt sich (zumindest mir) nicht - deutlich wahrscheinlicher ist es eben, daß da KEIN funktionierendes System installiert ist und da zuvor bereits ein "sync point" auftrat (der rote Teil oben), kann das praktisch beide Systeme betreffen. Und da ist es nun mal am wahrscheinlichsten, daß DU etwas bei den Änderungen bzw. bei der erneuten Installation eines OS falsch gemacht hast ... die Hardware der Box stirbt ja nicht einfach so.

Genau deshalb mein "Wunsch", daß Du eben NICHT einfach nur davon ausgehst, daß Du schon alles richtig machen würdest und uns stattdessen einfach mal die Protokolle (und zwar vollständig, solange sich darin keine "geheimen" Daten befinden) zeigst ... und das bitte in CODE-Kästen, so daß man das auch ohne eigene Anmeldung lesen kann, denn dann braucht man auch (neben dem HTML-Client) keine Zusatzsoftware auf irgendwelchen mobilen Geräten, mit denen man sich diesen Thread ansieht (auch Textdateien sind deutlich umständlicher im Handling).

EDIT:
Wenn man sich ein angepaßtes System auf der Box installiert und/oder in den kernel_args zusätzlich ein no_core_sync setzt, sollten die Punkte für die Synchronisation nicht berücksichtigt werden - allerdings dürfte das dann auch Auswirkungen auf das Zurücksetzen von firmware_info bzw. auf dessen Auslesen auf dem ARM-Core haben (siehe AVM-Kommentar weiter oben), so daß das wohl tatsächlich nur dazu verwendet werden sollte, einen ständigen Neustart zu verhindern, weil die beiden Systeme nicht synchronisiert werden können. Damit kann man ggf. Zeit schinden, um doch noch zu einer Shell-Instanz in der Box (z.B. SSH oder sogar Telnet) zu kommen, mit der man das (auch ohne Bestückung der Seriellen, die ohnehin nur bei einem mute=0 in den Kernel-Parametern etwas ausgibt) genauer beleuchten kann.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1
Hey @PeterPawn

danke für Deine Antwort. Ich muss zugeben, es ärgert mich auch, dass wir hier ein bisschen im Dunkeln tappen. Aber noch mehr ärgert mich gerade die Art und Weise, wie wir darüber kommunizieren. Ich weiss nicht, ob es grad an mir liegt, ob ich Dir irgendwie auf die Füße getreten bin oder an der nonverbalen Kommunikation liegt, aber auf ein paar Punkte möchte ich gern eingehen:

daß Du Dich eben doch nicht so gut auskennst mit den Puma7-Boxen

...
Insgesamt ist das alles nicht so seeehr logisch und systematisch, was hier geschah und was dann an Rettungsversuchen von Dir unternommen wurde.

Ich hab nie behauptet mich gut auszukennen. Ich hab keine Ahnung von den Interna der FB, sonst würde ich hier nicht fragen.
Die zusätzliche Info, was man mit dem reset=something bewirken kann, habe ich Dir nur noch gegeben, weil Du unbedingt der Ansicht warst, mit einem eigenen TFFS-Image hantieren zu müssen - das ist eindeutig NICHT länger erforderlich, wenn auf der Box eine Version >= 07.39 ...
Diesen Tipp habe ich auch nur aus demeinem CrossPost-Thread Und da war ich mir nicht sicher, wie ich hier schon schrieb:
porcupine:

Im anderen Forum wurde noch auf die Methode verwiesen ein clean TFFS image zu erzeugen und das auf mtd3 / mtd4 zu flashen. Die Aussagen dazu sind aber bissl widersprüchlich.

Genau deshalb mein "Wunsch", daß Du eben NICHT einfach nur davon ausgehst, daß Du schon alles richtig machen würdest und uns stattdessen einfach mal die Protokolle (und zwar vollständig, solange sich darin keine "geheimen" Daten befinden) zeigst ... und das bitte in CODE-Kästen

Guter Punkt, den Code-Tag hab ich tatsächlich übersehen. Die Cmds hab ich aber gerade aus dem Grund fett gedruckt mit angehängt, weil ich mir eben nicht sicher war, ob diese so richtig sind.


Wie dem auch sei, lass uns bitte respektvoll und konstruktiv miteinander umgehen.


Und wieder OnTopic: ich schau später mal, dass ich noch nen Flash Vorgang mit Protokoll mache.

Verlinkung zu unseriösen Quellen entfernt - by stoney
 
Zuletzt bearbeitet von einem Moderator:
Hier noch ein paar Details zum Flashen der original Firmware von AVM FRITZ.Box_6591_Cable-07.57.image
Mit fwmod entpackt:
Code:
./fwmod -u images/FRITZ.Box_6591_Cable-07.57.image

Mit uimg entpackt:
Code:
./uimg -u -n part ../images/FRITZ.Box_6591_Cable-07.57.image.mod/original/firmware/var/firmware-update.uimg

Geflasht mit eva_tools:
Code:
.\EVA-Discover.ps1
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { SetEnvironmentValue linux_fs_start 0 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_03_ATOM_ROOTFS.bin mtd0 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_02_ATOM_KERNEL.bin mtd1 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_09_ARM_ROOTFS.bin mtd6 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_08_ARM_KERNEL.bin mtd7 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { SetEnvironmentValue linux_fs_start 1 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_03_ATOM_ROOTFS.bin 'mtd;' }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_02_ATOM_KERNEL.bin 'mtd<' }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_09_ARM_ROOTFS.bin 'mtd=' }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_08_ARM_KERNEL.bin 'mtd>' }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { SetEnvironmentValue linux_fs_start 0 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { RebootTheDevice }

Output:
Code:
PS E:\Workspace\YourFritz\eva_tools> .\EVA-Discover.ps1 
EVA_IP=192.168.178.1
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { SetEnvironmentValue linux_fs_start 0 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
SETENV linux_fs_start 0
================
DEBUG: Response:
200 SETENV command successful

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_03_ATOM_ROOTFS.bin mtd0 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_03_ATOM_ROOTFS.bin' to 'mtd0' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,59,99)

================
DEBUG: Sent
STOR mtd0
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_02_ATOM_KERNEL.bin mtd1 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_02_ATOM_KERNEL.bin' to 'mtd1' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,217,91)

================
DEBUG: Sent
STOR mtd1
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_09_ARM_ROOTFS.bin mtd6 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_09_ARM_ROOTFS.bin' to 'mtd6' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,154,155)

================
DEBUG: Sent
STOR mtd6
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_08_ARM_KERNEL.bin mtd7 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_08_ARM_KERNEL.bin' to 'mtd7' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,66,142)

================
DEBUG: Sent
STOR mtd7
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { SetEnvironmentValue linux_fs_start 1 }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
SETENV linux_fs_start 1
================
DEBUG: Response:
200 SETENV command successful

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_03_ATOM_ROOTFS.bin 'mtd;' }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_03_ATOM_ROOTFS.bin' to 'mtd;' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,101,26)

================
DEBUG: Sent
STOR mtd;
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_02_ATOM_KERNEL.bin 'mtd<' }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_02_ATOM_KERNEL.bin' to 'mtd<' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,31,187)

================
DEBUG: Sent
STOR mtd<
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_09_ARM_ROOTFS.bin 'mtd=' }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_09_ARM_ROOTFS.bin' to 'mtd=' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,6,21)

================
DEBUG: Sent
STOR mtd=
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\part_08_ARM_KERNEL.bin 'mtd>' }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\part_08_ARM_KERNEL.bin' to 'mtd>' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,14,32)

================
DEBUG: Sent
STOR mtd>
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { RebootTheDevice }
DEBUG: Response:
220 ADAM2 FTP Server ready

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

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

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

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

================
True

Nach dem Software-Reboot war die FB nicht erreichbar --> PowerReset danach dann:
Mit eva_get_environment überprüft:
Code:
ubu@home:/mnt/e/Workspace/YourFritz/eva_tools$ ./eva_get_environment
Found AVM bootloader: AVM EVA Version 1.3614 0x0 0xF6001
Environment read from device:
DMC                   RTL=n
HWRevision            233
HWSubRevision         8
ProductID             Fritz_Box_HW233
SerialNumber          *redacted*
annex                 Kabel
autoload              yes
bootloaderVersion     1.3614
country               049
firstfreeaddress      0x3D3C4C00
firmware_info         161.07.57
firmware_version      avm
language              de
linux_fs_start        0
maca                  *redacted*
macb                  *redacted*
macwlan               *redacted*
macwlan2              *redacted*
macdsl                *redacted*
memsize               0x40000000
mtd0                  0x0,0x4800000
mtd1                  0x4800000,0x5100000
mtd2                  0x5100000,0x5300000
mtd3                  0x5300000,0x5B00000
mtd4                  0x0,0x0
mtd5                  0x5B00000,0xDB00000
mtd6                  0xDB00000,0xEE00000
mtd7                  0xEE00000,0xF300000
mtd8                  0x0,0x0
mtd10                 0x0,0x0
mtd11                 0xF300000,0x13B00000
mtd12                 0x13B00000,0x14400000
mtd13                 0x14400000,0x15700000
mtd14                 0x15700000,0x15C00000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
tr069_passphrase      *redacted*
tr069_serial          *redacted*
usb_board_mac         *redacted*
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         *redacted*
webgui_pass           *redacted*
wlan_key              *redacted*
wlan_ssid             FRITZ!Box#6591#Cable#PH
Das geht damit los, daß die Box lt. Environment in #1 niemals als wirklich vollwertige Retail-Box eingerichtet wurde, denn da steht ja (immer noch) ein RTL=n in der DMC-Variablen.
Ich hab den original Bootloader und den gepatchten Bootloader noch da als Backup von meinem DeBranding.

Hab mal beides Files inspiziert:
  • orig. Bootloader RTL=n
  • gepatchter Bootloader RTL=y
 
Könnte es sein, daß das Branding durch Editieren des gesicherten mtd3 und nur RTL=y verändert, sich die Box ein Stock-Image von kdg gezogen hat und aufgrund eines alten BIOS adam2 ins Leere läuft?
Das weiter oben gepostete Command
Es gibt allerdings im Bootloader einen Konfigurationsbereich, der sich m.W. auch bei Puma7-Modellen mit einem kühnen RETR config auslesen lassen müßte und dort findet man dann - neben anderen Daten, u.a. dem CM-Zertifikat der Box - auch die "Geburtsdaten" so einer Box, aus denen die festen Werte beim Start des Loaders restauriert werden und wo es für ein paar andere Werte (DMC sollte u.a. dazu gehören, deshalb sind da auch persistente Änderungen möglich) Standardvorgaben gibt, die man jedoch ändern KANN.
konnte ich nicht zum Laufen zu bewegen, trotz aller zusammengenommer Kühnheit (auf einem Ubuntu 23.04-System)
Code:
jenni@home-desktop-pi4:~$ ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:jenni): adam2
331 Password required for adam2
Password: 
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> debug
Debugging on (debug=1).
ftp> binary
---> TYPE I
200 Type set to BINARY
ftp> quote MEDIA FLSH
---> MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> quote P@SW
---> P@SW
227 Entering Passive Mode (192,168,178,1,176,130)
ftp> quote RETR config
---> RETR config
425 can't open data connection
ftp> quote RETR cfg
---> RETR cfg
501 unknown variable cfg
ftp> quote RETR config
---> RETR config
425 can't open data connection
ftp>

Vielleicht ist der command der seriellen vorbehalten oder mein ftp-client kommt wie angemerkt mit dem command nicht zurecht?
 
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.