7270 v2: Reboot-Schleife nach Update

nightshade78

Neuer User
Mitglied seit
24 Sep 2008
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

seit der Labor-Version .85-17828 kriege ich kein funktionierendes freetz-Image mehr zusammen. Die genaue svn-Revision weiß ich allerdings leider nicht mehr. Zunächst habe ich einen Fehler in der Preview vermutet, aber nachdem nun auch die aktuelle .85-17891 ebenfalls nicht funktioniert, wundere ich mich dann doch etwas.

Wenn ich die erzeugte Firmware auf die Box lade (egal ob über WebGUI oder das Urlader-Flash-Skript) hängt diese anschließend in einer Reboot-Schleife fest.

make config-clean-deps habe ich bereits ausgeführt und in meiner Config wird auch nichts mittels remove-Patches entfernt.

Könnte das vielleicht daran liegen, dass ich vor kurzem auf OpenSUSE 11.3 (64Bit) aktualisiert habe? Meine letzte funktionierende Freetz-Firmware (basierend auf .85-17761) hatte ich noch unter 11.2 (auch 64Bit) erzeugt...

Gruß, Nightshade
 
Zuletzt bearbeitet:
Moin,
make config-clean-deps habe ich bereits ausgeführt
Und was ist bei trunk-nutzung der nächste Schritt wenns so nicht funktioniert?!
Richtig, den freetz-Ordner wegwerfen, per svn co... neu auschecken und anschliessend ein Image bauen bei dem du im menuconfig NUR deine Box ausgewählt hast.

Beim trunk kann es immer mal wieder zu Problemen kommen, da Entwicklerversion.
Vielleicht schleppst du diesen Fehler jetzt in deinem checkout mit dir mit
 
Und was ist bei trunk-nutzung der nächste Schritt wenns so nicht funktioniert?!
Richtig, den freetz-Ordner wegwerfen, per svn co... neu auschecken und anschliessend ein Image bauen bei dem du im menuconfig NUR deine Box ausgewählt hast.

Ich werde das nochmal ausprobieren. Allerdings mache ich mir da wenig Hoffnung, da das Checkout durch die Linux-Neuinstallation ziemlich frisch war...

Was genau meinst du mit "NUR deine Box"...? Zwischendurch keine andere Box ausgewählt, oder Standardauswahl ohne weitere Patches, Pakete, etc?
 
... Allerdings mache ich mir da wenig Hoffnung, da das Checkout durch die Linux-Neuinstallation ziemlich frisch war...
[...]
"Ziemlich frisch" kann hier schon nicht ausreichend sein. Das Checkout muss neu (d. h. ganz frisch;)) sein. Was für einen Zusammenhang meinst Du, zwischen Checkout und Linux-Neuinstallation zu erkennen?
 
Vielleicht sollten wir im Wiki schreiben: "Wer dies und jenes _nicht_ tut, wird fürs trac, den trunk und das forum gesperrt, bis er/sie/es gelernt hat zu lesen" ^^

Das schafft - nach einigen Wochen - echt Ruhe ^^ :D
 
"Ziemlich frisch" kann hier schon nicht ausreichend sein. Das Checkout muss neu (d. h. ganz frisch;)) sein. Was für einen Zusammenhang meinst Du, zwischen Checkout und Linux-Neuinstallation zu erkennen?

Ich hatte mich vielleicht nicht völlig klar ausgedrückt: Linux ist bei mir nur ein Sekundärsystem, ergo überlebt da auch nichts an Daten bei einer Neuinstallation... D.h. dass ich nach der Neuinstallation auch wieder frisch ausgecheckt habe.

Wie auch immer, es hängt definitiv mit dem neuen OpenSUSE zusammen, ich habe die 11.3 nochmal komplett neuinstalliert und die fabriziert immer noch nichts brauchbares (ja, neues Checkout!). Alternativ habe ich auf meinem Windows mit VMPlayer und dem freetz-linux eine Firmware mit *exakt* der gleichen Config (und SVN-Revision) gebaut und die läuft.

Das funktionierende Image ist dabei etwa 12KB größer als das defekte. Ich habe beide Images mal entpackt und der Unterschied liegt im enthaltenen kernel.image. Eventuell untersuche ich nochmal genauer, wo innerhalb des SquashFS-Image denn nun der Unterschied liegt.

Jedenfalls vermute ich nun, dass irgendeines der mit OpenSUSE 11.3 gelieferten Tools, die beim Ausführen von freetz benutzt werden, irgendwelchen freetz-inkompatiblen Output erzeugt...


Vielleicht sollten wir im Wiki schreiben: "Wer dies und jenes _nicht_ tut, wird fürs trac, den trunk und das forum gesperrt, bis er/sie/es gelernt hat zu lesen" ^^

Das schafft - nach einigen Wochen - echt Ruhe ^^ :D

Danke, ich hab hier zwar noch nicht viel gepostet und mich im Originalposting etwas unklar ausgedrückt *mea culpa*. Dennoch bin ich weder mit freetz noch mit Linux ein Anfänger (was ja indirekt unterstellt wurde). Insofern hab' ich nach dem Kommentar jetzt nicht unbedingt noch große Motivation, nach der relevanten Fehlerquelle weiterzusuchen (und damit dem Projekt zu helfen) - besten Dank auch dafür. :spocht:
 
Insofern hab' ich nach dem Kommentar jetzt nicht unbedingt noch große Motivation, nach der relevanten Fehlerquelle weiterzusuchen (und damit dem Projekt zu helfen) - besten Dank auch dafür.
Und nach der Aussage wohl diverse Leute mit Ahnung weniger Lust, dir zu helfen. Von daher...
 
nightshade78;1577571[... schrieb:
Könnte das vielleicht daran liegen, dass ich vor kurzem auf OpenSUSE 11.3 (64Bit) aktualisiert habe?
[...]
Versuch mal ob es unter OpenSUSE 11.3 (64Bit), mit "linux32 bash" funktioniert.
 
Das funktionierende Image ist dabei etwa 12KB größer als das defekte. Ich habe beide Images mal entpackt und der Unterschied liegt im enthaltenen kernel.image. Eventuell untersuche ich nochmal genauer, wo innerhalb des SquashFS-Image denn nun der Unterschied liegt.

So, ein kurzer Zwischenstand schonmal: Unter dem freetz-linux schlägt
Code:
unsquashfs3-lzma kernelsquashfs.raw
beim OpenSUSE-image mit der Meldung
Code:
0 inodes (0 blocks) to write
Floating point exception
fehl, das gleiche beim freetzlinux-image funktioniert dagegen einwandfrei...

Jetzt starte ich nochmal OpenSUSE und schaue, was er da sagt - und vor allem, vorauf er da beim image-Build so alles zugreift...
 
Welche gcc Version nutzt dein Suse 11.3?

MfG Oliver
 
OpenSUSE 11.3 hat gcc 4.5.
 
...
Wie auch immer, es hängt definitiv mit dem neuen OpenSUSE zusammen, ich habe die 11.3 nochmal komplett neuinstalliert und die fabriziert immer noch nichts brauchbares (ja, neues Checkout!).
[...]
Kannst Du inzwischen mit OpenSUSE 11.3, ein brauchbares/funktionierendes Freetz-Image erzeugen?
 
Hallo,

ich häng mich hier mal ran. Ich hab heute morgen das gleiche Problem wie nightshade gehabt.

Mein Image übersetze ich mit Fedora13, 64bit. Daran wird es aber wohl nicht gelegen haben, da nach einem Wechseln weg von der Labor-Preview zur 54.08.80 alles wieder fein lief.

In dem nicht laufenden Image hatte ich (im Gegensatz zu der laufenden Variante) nach meiner Erinnerung
* replace kernel abgeschaltet,
* OpenSSH statt dropbear verwendet,
* MediaSrv+minid rausgepatcht
* diverse andere Pakete aus Platzgründen _nicht_ installiert (OpenVPN, VSFTP, wget,...)

Mit dem Image bin ich in einer Dauer-Reboot-Schleife gelandet, die mich zum recovern gezwungen hat.

Bei mir geht's auch um eine 7270v2. Angehängt ist die .config aus dem nicht bootenden image.

-make-
 

Anhänge

  • config.txt
    24.9 KB · Aufrufe: 4
Zuletzt bearbeitet:
Probier bitte nochmal mit aktuellem trunk. Da hatte sich ein Fehler in Verbindung mit IPv6 und "replace kernel" eingeschlichen, der inzwischen behoben ist.

MfG Oliver
 
Danke, dein Tipp hat mir weiter geholfen.

NHIPT und iptables wurden nicht automatisch de-selektiert und haben zu einem Fehler beim Build geführt. Nachdem ich nochmal die Nicht-Labor-Firmware ausgewählt hatte, ließ sich der iptables-Kram auch abschalten und der Build lief durch.

Aktuell hab ich mit der neuen Firmware noch einen LUA-Stacktrace in der Übersicht->Netzwerk, aber ich vermute, dass das eher ein Problem von AVM ist.
 
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.