[Problem] Freetz entfernen schlägt fehl

Miyamoto

Neuer User
Mitglied seit
11 Nov 2006
Beiträge
121
Punkte für Reaktionen
0
Punkte
16
Moin!
Ich muß wg. eines Problems mit der FB für den AVM-Support mal ein vanilla FritzOS auf die Box spielen. Dummerweise funktioniert das nicht so ohne weiteres...

Ablauf bisher:
  • Recovery der 7490 mittels AVM-Recovery, anschließend Aufspielen der aktuellen Labor-FW
  • komplettes Neuaufsetzen der Box
  • manuelles Löschen der Datei /var/flash/freetz über Telnet
  • Einspielen des uninstall.image aus dem Verzeichnis tools/images/ des Freetz-Sourcen
  • Zurücksetzen auf Werkseinstellungen

Dennoch habe ich weiterhin diesen blöden Hinweis über nicht unterstützte Änderungen im WebUI, und der AVM-Support beschwert sich, daß ich immer noch kein cleanes FritzOS nutze.

Wie zur Hölle bekomme ich die Spuren von Freetz entfernt ???
 
Dennoch habe ich weiterhin diesen blöden Hinweis über nicht unterstützte Änderungen im WebUI, und der AVM-Support beschwert sich, daß ich immer noch kein cleanes FritzOS nutze.
Wenn das nur der Hinweis aus der Minor-ID 87 aus dem TFFS ist (einfach mal mit Telnet den Inhalt in hex anzeigen lassen, da steht normalerweise der Auslöser auch drin), dann einfach mit "echo clear_id 87 >/proc/tffs" den Inhalt _vor_ dem Recovern schon löschen und das "uninstall-image" weglassen. Solange das nicht signiert ist, setzt es ja das entsprechende Flag immer wieder neu.

Auch ist nicht so ganz klar, was Du unter "manuelles Löschen der /var/flash/freetz" verstehst ... auch das geht einfach mit einem "echo clear_id minor >/proc/tffs" problemlos, wobei "minor" durch die richtige ID (bei /var/flash/freetz meines Wissens die 60, aber da solltest Du lieber noch einmal nachsehen) zu ersetzen ist. Das natürlich auch noch vor Recovery ... wobei ich ohnehin nicht verstehe, warum die Minor-ID 87 Recovery überleben sollte (Werkseinstellungen ist wieder etwas anderes). Wenn die Minor-ID der Freetz-Settings leer ist, sollte es schon ausreichend sein, einfach auf das "uninstall.image" zu verzichten ... was macht das eigentlich genau? In jedem Falle setzt es das "UNSIGNED"-Flag ... und das stößt AVM dann sauer auf.

EDIT: OK, dieses "uninstall.image" löscht also genau mit "clear_id" einige Minor-IDs ... aber gerade die 87 eben nicht. Das sind nur 0x3B, 0x3C, 0x62, 0x90, 0x91 ... da ist also die "freetz" theoretisch dabei (0x3C = 60) und damit macht das zusätzliche Löschen über Telnet für die noch weniger Sinn. Wenn Du die var/install in diesem Image noch um ein Löschen der ID 87 ergänzt, kannst Du das sogar nach Recovery noch aufrufen, weil das "UNSIGNED" dann gleich wieder zurückgesetzt wird.
 
Zuletzt bearbeitet:
@PeterPawn: würdest Du vielleicht das uninstall.image entsprechend erweitern? Ich weiss leider nicht wie, aber ich bin darüber letztens auch gestolpert.
 
@Whoopie:
Ich kann zumindest einen Vorschlag machen, wie ein aktuelles "uninstall.image" aussehen könnte (die Dateien dort sind ja alle 9 Jahre alt und ein wenig hat sich das schon getan bei AVM), aber selbst ändern kann ich es nicht.

Da es mehrere Ansätze gibt (uninstall.image (a) vor, (b) anstelle oder (c) nach Recovery ausführen), wäre eine Einigung auf das "richtige Vorgehen" vorher erforderlich.

Variante (b) ist sicherlich schnell aus dem Rennen (wenn nicht doch irgendwann die direkte Unterstützung für "Auspacken, Ändern, Einpacken" in Freetz Einzug hält, denn dann ist das nur ein kleiner Zusatz zur /var/install und am Ende klappt das alles in einem Zug und ohne "direkte Verkabelung") ... aber zwischen (a) und (c) muß man erst einmal eine Wahl treffen.

Eigentlich reicht schon eine Datei /var/install im Image mit dem folgenden Inhalt aus:
Code:
#! /bin/sh
# remove all Freetz related settings from a FRITZ!Box and reset the "modified" flags
#
# TFFS control interface
PROCTFFS=/proc/tffs
#
# TFFS minor IDs < 100 to be cleared
ID_LIST="60 98 97 87"
#
# 60 - /var/flash/freetz
# 98 - /var/flash/debug.cfg aka /var/flash/rc.user
# 97 - additional ID reserved (by TI some years ago) for data needed by rc.user
# 87 - AVM's "modified" flag container
# 
# - don't hesitate to expand the list above to suit your needs
# - resetting the "modified" container is described here:
#   http://freetz.org/wiki/help/howtos/development/manipulation_detection
#
for id in $ID_LIST; do
    echo "clear_id $id" >$PROCTFFS
done
#
# uncomment this line to force an immediate factory reset:
# /bin/setfactorydefaults
# 
# to remove any own content from the NAND flash mounted on /var/media/ftp, add 
# one parameter to the line above or uncomment the line below:
# /bin/setfactorydefaults internalflash_clear
#
# ! Please remember, that clearing the NAND flash may be delayed until the device is
# rebooted next time!
#
# now restart the device, the remaining job is done by our parent (firmwarecfg)
exit 1
Das dann in ein passendes "tar"-File verpackt (Pfad "var/install", die Erweiterung "image" für das Archiv ist auch nicht zwingend) und man hat ein moderneres "uninstall.image", das - je nachdem, was man oben mit den Kommentaren macht - einige Aktionen gleich in einem Zug ausführen kann.

Wenn man das vor Recovery laden will, braucht es eigentlich kein "setfactorydefaults" mehr und wenn man das nach Recovery ausführt, erspart es einen Neustart, weil das Werksreset in demselben Schritt mitgemacht werden kann (was auch total unnötig ist, weil bei Recovery ja auch "Werkseinstellungen" aktiv werden, selbst die IDs < 100 "überleben" das eigentlich nicht).

Wenn man auf Recovery verzichten will, führt man einfach nur ein Update auf ein AVM-Image aus und lädt hinterher einmal das o.a. Image.

Am Ende passiert beim Recovern auch nichts wesentlich anderes ... aber im Gegensatz zu Recovery braucht eben ein Update nicht unbedingt ein LAN-Kabel zur Box. Solange das aktuelle System in der Box noch ansprechbar ist, kann man das "Deinstallieren" von Freetz auch über eine WLAN-Verbindung machen.

EDIT: Um es noch einmal klarer zu schreiben: Das Laden von Werkseinstellungen im Zusammenhang mit Recovery ist unnötig, das wird dabei automatisch mit erledigt. Die Zeilen für "setfactorydefault" braucht man also nur dann, wenn man auf Recovery verzichtet und es bleibt - je nachdem, ob man die Zeile mit oder ohne "internalflash_clear" verwendet - der NAND-Flash (bei 7390 und Modellen mit NAND- anstelle von NOR-Flash) auf Wunsch unangetastet. Dort liegen u.U. aber noch AB-Nachrichten und Faxe (die allerdings von der Box ohnehin nicht mehr angezeigt werden, wenn man nicht wieder eine gesicherte Anrufliste einspielt per Import), aber ja nachdem, was anschließend mit der Box passieren soll (z.B. Garantietausch bei AVM) sollte man das mit löschen lassen oder eben auch nicht (wenn man seine gesicherte fx_cg importieren will).
 
Zuletzt bearbeitet:
Werden damit auch Einträge wie z.B.
Code:
kernel_args	init=/etc/init.d/rc.usbroot
aus der environment gelöscht?
Daran hatte ich gemerkt, daß eine gebraucht gekaufte FB schon mal gefreetzt war.
 
usbroot sollte ja nur optional ältere Boxen betreffen, insoweit ist es m.E. kein sicheres Indiz für eine freetz Installation.

Startet denn die Box nach einem recover überhaupt noch, wenn es den init nicht mehr gibt? (Und kernel_args sollte das obige Skript wie auch ein Recover überleben)
 
Ja älter, es ist eine FB7270v2.
insoweit ist es m.E. kein sicheres Indiz für eine freetz Installation.
Wenn du meinst, daß nicht bei jeder gefreetzten FB der Eintrag vorhanden ist, dann ja.
Aber wenn dieser Eintrag da ist, dann war die FB IMO gefreetzt.

Recovert habe ich sie noch nicht, aber nach Werksreset startet sie noch.
 
Und kernel_args sollte das obige Skript wie auch ein Recover überleben
Ich dachte eigentlich, daß bei den NAND-Modellen dieser Eintrag beim Start aus dem mtdram-Device überschrieben würde, aber da habe ich mich geirrt. Da wird "kernel_args_tmp" verwendet, was offenbar gar nicht wirklich gespeichert wird und nur als Argument an den Kernel beim Start übergeben wird von EVA.

Damit kann/sollte man zumindest noch überprüfen, ob da irgendwelche Rudimente von Freetz im Urlader-Environment stehen. Ich habe allerdings keine vollständige Aufstellung, was da seitens Freetz jemals geschrieben wird ... keine Ahnung, ob es dafür unter freetz.org irgendwo eine solche Auflistung gibt. Es gab mal (vielleicht gibt es das auch noch in einem Freetz-Image) ein Skript mit Helper-Funktionen zum Zerlegen des Inhalts von "kernel_args" in Tupel (ich glaube von kriegaex) ... wo das überall eingesetzt wurde, weiß ich aber nicht. Ich bin mir nicht einmal sicher, ob es beim "Freetz-Not-Aus" zum Einsatz kommt.

Das mit dem "Not-Aus" ist m.E. so alt, daß es noch aus den Zeiten von "ds_mod" stammt ... und auch der usbroot-Code bräuchte (zumindest auf neueren Modellen) vermutlich mal ein Review, denn dort ist das Modifizieren der inittab unter /wrapper/etc der einfachere Weg, um dem System bereits beim Start ein anderes Root-FS unterzujubeln ... nichts anderes macht AVM selbst ja auch, wenn dort mit "pivot_root" vom YAFFS2-FS in /dev/mtdblock{1,3} auf das SquashFS-Image innerhalb des YAFFS2 umgeschaltet wird.

Wenn der Besitzer der Box sich an die korrekte Reihenfolge beim Ausschalten von "usbroot" hält, sollte da aber auch nichts im Environment stehen. Aber da der Kernel eine ungültige Angabe für "init" ohnehin nicht akzeptiert und stattdessen auf die interne Standardangabe zurückgreift, merkt man das am Verhalten der Box nicht wirklich, wenn da (unnötige oder falsche) Argumente für den Kernel irgendwo hinterlegt sind.

Aber zumindest löst dieser Eintrag im Urlader-Environment keine Signalisierung in der Minor-ID 87 im TFFS aus (und damit auch nicht im GUI bzw. den Supportdaten) ... wenn AVM nur an diesem Eintrag im Environment in den Support-Daten feststellt, daß da früher mal eine andere Firmware drauf war, wäre die Fehlerbeschreibung etwas unpräzise ... nichts desto trotz könnte man das noch in das "uninstall" aufnehmen, dann aber bitte mit "kernel_args" und "kernel_args1".

Beide werden beim "normalen Start" des FRITZ!OS nicht benötigt ... wer ganz gründlich sein will, löscht auch noch die "ptest"-Variable, das macht allerdings die Firmware in S42-ptest bei einem Start selbst, wenn das System bis zu diesem Punkt kommt - hier hängt es wieder davon ab, wann man sein "uninstall.image" abarbeiten lassen will.
 
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.