[Problem] AVM überschreibt 6.60 freetz Version mit 6.60

Bahnhof

Ja, meine Adapter liegen in /sys/class/net

busybox sh eva_switch_system eno1 192.168.2.1 bringt das gleiche ergebnis hervor.
Seltsam finde ich dass wenn die shell schuld ist, dass ich diese Fehler nicht bekomme, wenn ich die eva_discover nicht bearbeite...
 
Das Problem tritt ja immer wieder auf, eben meist auf Fremdlinuxen, und es ist ja auch nicht so dass du das einfach ignorierst. :)
Ein SHEBANG-Hack ist ja auch nicht nötig, wenn zumindest durch eine Abhängigkeitsprüfung darauf hingewiesen wird.
Nach dem Motto: Igitt! /bin/sh ist eine dash, ändern nach bash, sonst gibts keine Kekse
...dann kann der User tätig werden.
 
Code:
busybox sh eva_switch_system eno1 192.168.2.1
Seltsam finde ich dass wenn die shell schuld ist, dass ich diese Fehler nicht bekomme, wenn ich die eva_discover nicht bearbeite...

Frage: Und was steht in der eva_switch_system.log ?
hier ist das Kommunikationsprotokoll mit der Fritzbox enthalten;
 
@koy:
Ja, das mit dem Test wäre eine Idee ... sollte es eine (belastbare) Möglichkeit der Unterscheidung geben, könnte man das einbauen.

Auch hier müßte man aber wieder weitere Arbeit investieren in die Tools - die waren auch wieder "proofs of concept" und "eva_discover" hat nicht einmal einen "usage screen", iirc. Schon die Parameter-Prüfung und ggf. die automatische Erkennung der richtigen Netzwerkschnittstelle ist ja auch noch nicht fertig - das ist (rein theoretisch immer noch) "preview": http://www.ip-phone-forum.de/showthread.php?t=273304&p=2151796&viewfull=1#post2151796
 
@PeterPawn: Stimmt allerdings, sowas "belastbar" hinzukriegen ist schon eine Kunst für sich.
...mal so auf die "Schnelle" ist da nicht, weil es auch noch in verschiedenen Umgebungen getestet werden müsste.
 
@JokerGermany:
Wenn Du willst, könntest Du noch einmal probieren ... ich habe die Interface-Erkennung in der verwendeten Library umgebaut, so daß auch physikalische Interfaces erkannt werden.

Damit sollte nach einem frischen "checkout" oder "clone" und auf einem System, wo "/bin/sh" auf eine Bash-Version oder auf die "ash" der BusyBox zeigt, der Aufruf (aus dem eva_tools-Verzeichnis heraus, ansonsten muß man die Variable "YF_SCRIPT_DIR" auf den Pfad zum Verzeichnis "helpers" setzen beim Aufruf) funktionieren, solange das aktuelle Verzeichnis in der PATH-Variablen hinterlegt ist (damit interne Aufrufe weiterer Skript-Dateien in "eva_switch_system" die Dateien auch finden können).
 
Hoi allerseits,

ich weiss ja nicht, ob der Papa das Bootsystem schon umschalten konnte, aber als stolzer Besitzer einer kürzlich erstandenen 7272 kann ich vermelden, dass es total einfach ist, mit Bordmitten in Adam2/Eva einzusteigen. Mit einem Recovery-Programm einer anderen Box dagegen hat es überhaupt nicht geklappt - selbst das Recovery für die 7272 v6.30 fand die Box nicht (es ist eine 6.50 installiert). Es ging /nur/ das Recovery für die 6.50 - was aber dann durchläuft und das System flasht, was ja nicht in eurem Sinne ist.

Der Trick ist

1. der Ethernet-Schnitte am Compi eine IP aus 192.168.178.xxx zu geben,
2. ein ftp 192.168.178.1 Kommando in einem Cmd Prompt Window vorzubereiten, ohne mit Enter abzuschliessen
3. Die Fritzbox einzuschalten
4. den Status der Schnittstelle in Control Panel\Network and Internet\Network Connections zu beobachten. Wenn sich dieser von "Network cable unplugged" auf "Unidentified network" ändert, auf die Return-Taste im Cmd Prompt Fenster drücken.

So landet man zuverlässig am Login Prompt von Adam2.

Habe dann mal linux_fs_start umgestellt von 0 auf 1 nach Peters Anleitung, und siehe da, es ist neben der Version 6.50 wohl auch eine 6.30 vorhanden :)

Anderes Thema: Ich habe euer Dilemma der fehlenden Manpower mitbekommen. Habe im Momemt etwas Zeit und könnte tatkräftig mithelfen, was modfs_starter, modfs und Ähnliches angeht. Ich las, modfs sei für die 7272 noch nicht getestet... Neben der 7272 sind noch eine 7312 sowie zwei 7170 da. Vi, sed, bash und awk machen mir auch keine Angst ;-)

Also, soll ich? Darf ich?
 
Ist zwar das falsche Unterforum ... aber ich habe in "modfs" mal das Modell "192" (7272) aufgenommen. Solange ich keine negativen Rückmeldungen kriege, sollte das bei der 7272 eigentlich laufen, die Unklarheiten bzgl. des Aufbaus sind ausgeräumt.

Warum hier das eine Recovery-Programm die Box nicht finden soll, das andere aber schon (und das galt ja wohl auch für zwei verschiedene Versionen für die 7272 und nicht nur für ein "falsches" Recovery-Programm), ist wohl eher keine wirkliche Frage ... vielleicht müßte man zuerst mal klären, was da jeweils im Einzelnen versucht wurde und wie intensiv die Bemühungen waren. Es kann eigentlich nur an einer komplett fehlenden LAN-Konfiguration im Windows liegen, wenn das Recovery-Programm keine zur Ethernet-Konfiguration von Windows passende IP-Adresse für den Bootloader einstellen kann.

Aber egal ... wenn Du "modfs" für die 7272 testen willst, steht dem mit der aktuellen Version von heute nichts mehr im Wege.


-Wie das mit "Freetz" weitergehen wird, würde mich auch mal interessieren ... inzwischen bin ich selbst wieder auf meine eigene Toolchain zurückgegangen und der bisher bei Binärdateien immer praktizierte Verweis auf Freetz und entsprechende Pakete wird sich vermutlich auch nicht mehr lange aufrechterhalten lassen.

Hier kranken die Forks jetzt wohl daran, daß die Skript-Dateien für die Integration neuer FRITZ!OS-Versionen (ich nehme mal an, daß es solche geben wird - das wird sicherlich/hoffentlich nicht alles Handarbeit sein, gerade bei dem Vorgehen mit den Differenz-Dateien für die verschiedenen OpenSource-/Kernel-Pakete) eben nicht Bestandteil des veröffentlichten Teils sind.

Ich habe mal damit begonnen, im Linux-Subsystem von Windows 10 die notwendigen Anpassungen zu sammeln, um vielleicht eine vernünftige und funktionierende "buildroot"-Toolchain zum Laufen zu bringen. Wird aber wohl noch brauchen, mir ist es schon mit einem einfachen "cd GitHub;mv ../freetz ." nach fehlerhaftem Klonen des Repos (eine Verzeichnisebene zu hoch) das komplette Subsystem so weit aufzuhängen, daß nur noch der Windows-Neustart half.


-Im Gegensatz zu der Ubuntu-Umgebung braucht eben ein System, auf dem man auch tatsächlich als "root" arbeiten kann (mal abgesehen von irgendwelchen daraus resultierenden Risiken), kein "fakeroot" oder irgendwelche anderen Kunstgriffe, um die Firmware zu entpacken, zu modifizieren und wieder zu packen - das macht für mich diese Debian-Abkömmlinge alle irgendwie nur zur zweiten Wahl, wenn es um das Modifizieren der Firmware geht. Aber zumindest die ganzen Skript-Dateien für die Behandlung von TFFS-Images und wohl auch für den Zugriff auf EVA werde ich wohl doch noch so anpassen, daß sie auch auf der Linux-Unterstützung im Windows 10 arbeiten können ... bis inkl. "socat" (das man nachinstallieren muß) habe ich das tatsächlich schon ausprobieren können.
 
Ich kann leider nichts zu Eurem Thema beitragen, wollte aber nur kurz loswerden, dass die 7490 bei meinen Eltern auch von 06.60-freetz auf 06.60 upgedatet wurde.

Ich hatte das Häkchen bei "Über neue FRITZ!OS-Versionen informieren und notwendige Updates automatisch installieren (Empfohlen)" stehen, habe es jetzt auf "Über neue FRITZ!OS-Versionen informieren" gesetzt. Hoffentlich hilft das gegen diese ungewollten Updates!

Beste Grüße,
Whoopie
Gibt es noch andere Wege, solche automatischen und ungewollten Updates sicher zu unterbinden? Mich erinnert das gerade an denselben Mist bei den Amazon Fire TVs...


PS:
Sorry, ich hatte den Grund meiner Frage zu erwähnen vergessen:
... Hintergrund: Meine 7390 hat sich ungefragt (trotz abgeschaltetem Update) auf das aktuelle offizielle Fritz!OS aktualisiert. ...
 
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.