7170- FreetzTrunk Dauerreboot nach flaschen

[cybertron]

bin jetzt nach 4 Tagen hin und her langsam am Ende.

Habe Ende letzter Woche meine Trunkversion komplett neu in Stinky angelegt und mir versucht ein neues Image mit der Laborversion zu erstellen.

Anfangs noch mit external. Später dann immer weiter abgespeckt, bis es ohne external passte.
Jedes der erstellten Images konnte ich problemlos erstellen und erstmal über das AVM-WebIF flaschen.
Danach war das WebIF jedoch nicht mehr erreichbar und die Box bootet in einer Tour.
Zwischenzeitliche versuche mit der stable.1.1 hatten den gleichen Effekt.
Gleiches gilt auch für Standard-Firmware/Labor.
Vor jedem neuen Flashen wurde die FBF mit dem Recovertool wieder jungfräulich gemacht.
Zwischenzeitlich hatte ich mal ein ganz minimalistisches Image (ohne jedes Paket), welches lief...
Dann hab ich Dropbear und vsftd hinzugenommen und schon war ich wieder beim Alten...
Die letzten Versuche hab ich jetzt mit wirklich minimalistischem Ausbau gemacht, komme jedoch im keiner Weise weiter.

Mit der orginal Firmware von AVM (Release wie auch Labor) läuft die Box einwandfrei. Von daher würde ich grundlegend erstmal davon ausgehen, dass die Box techn. i.O. ist.
make clean/distclean/dirclean hab ich auch mehrfach hinter mir.

weiss da noch jemand Rat?

greez
Cyby

 

[Silent-Tears]

Und das image läuft jetzt?
Tipp von mir: Minimalimage, was läuft noch einmal auf die Box. Dann Schritt für Schritt an/abwählen, was du brauchst/willst und das Image flashen. Wenn du Stückchenweise dich herantastest, findet sich schnell der Übeltäter. Ich tippe bei dir mal bie dropbear mit sftp-Server, bzw. ssl-Krams bei vsftp oder sowas in der Richtung, was deine Box nicht mag. Ist ein bekanntes Problem übrigens

 

[olistudent]

Hi.
Mit dieser .config sollte das Image laufen. Ich kann darin nichts sehen was zum Reboot führen könnte.

MfG Oliver

 

[cybertron]

@Silent: den Weg, die Pakete einzeln abzuwählen, war meine Beschäftigung der letzten 4 Tage
Bisher lief meine Box mit DropBear, Vsftd, Callmonitor, dnsmaq, syslog, rrdstat.
Bis devel 3409 mit StandardFirmware gab es bis dato eigentlich keine Probleme.

Das Image, welches mit der angehangenen Config erstellt wurde, brachte auch keinen Erfolg. Allerdings liegt zwischen letzten kompletten Clean und diesem Image mindestens 20 erstellte nicht funnktionierende Images.

Könnte eventuell ein zwischenzeitliches Update des Stinky Ursache des ganzen sein ?? (mal dumm gefragt)

 

[Silent-Tears]

Fang von vorne an, dann hast du irgendwelche Altlasten nicht mehr. Nimm die Stable-Version, lass die Finger vom Labor. Dann klappt das wohl auch mit dem Nachbarn.

 

[cybertron]

jetzt bin ich langsam ganz ratlos...

Stinky neu..
aktuelle FW (kein Labor)
Freetz stable 1.1

als erstes ohne jedes Paket, keine Patche... ---> funktioniert
Patche nach und nach wie bisher immer ---> funktioniert

Dropbear ---> dauerreboot

das Gleiche hab ich dann nochmal parallel mit aktuellem Trunk gemacht... völlig identisches Ergebnis...


Da die AMV-Sourcen und die FW nicht gedownloadet werden, sondern ich diese wegen der Dateigröße vor längerem schon in Kopie gespeichert habe und nach einem Kompletten Clean immer händisch in DL-Verzeichnis kopiere vor dem Make, würde ich Änderungen seitens AVM auch ausschliessen.

Hab auch gerde nochmal ein altes Image Devel3409 getestet, bei welchem die Box allerdings noch als IP-Client lief... Das läuft mit Dropbear usw. einwandfrei...

Gibt es denn dereit gar keine Chance ein Image mit Dropbear und vsftp lauffähig zu erstellen?

 

[Zwergnase]

Hi,

was mir aufgefallen ist, daß für dropbear anfangs die ssh keys erzeugt werden. Ich habe zum Beispiel ein Image für USB Root in dem nur die Pakete usbroot & dropbear drin sind. Wenn ich das nach einem recover einspiele, dann gibt es mindestens zwei reboots. Mir scheint, daß das Erzeugen der keys beim Startup zu lange dauert und da irgendein Watchdog zuschlägt.

Ähnliches habe ich, wenn ich in die rc.customs meine NTFS NDAS Platte mounten will. Auch das dauert wohl zu lange und führt zu Dauerreboots. Interessant ist, daß ich den Befehl später über SSH absetzen kann, es auch lange dauert aber nicht zum Reboot führt.

Ist es vielleicht so, daß während des Bootens ein watchdog läuft, der eine kürzere Triggerzeit hat als im späteren Betrieb?

Gruß

Zwergnase

 

[Silent-Tears]

Tja, und wieder mal fehlt die .config, ich rate, und komme auf SSL-Sachen, vsftp mit ssl, nicht statisch gebaut und dropbear als sftp-Server als mögliche Ursachen. Egal welches von beiden, beide funktionieren _nicht_ wie ich komischerweise gestenr schon geschrieben hatte.

Also, noch einmal langsam für dich: Image erzeugen, _ohne_ alles, flashen. Funktioniert? Gut. Dann .config anhängen.
Schritt 2: Image erzeugen mit dropbear, ohne sonst etwas. (Nein, auch kein sftp und was weiss ich...), flashen. Funktioniert? Fein, die .config nehme ich auch hier als Anhang. Und so weiter, bis es eben _nicht_ mehr klappt. Und der Unterschied zwischen der einen .config, die es tut, und der nächsten bringt den Punkt, der bei dir stört. Und ich bin wirklich sicher, dass von mir genannte Kandidaten Schuld sind( tr069, ssl, libcrypto).

 

[Zwergnase]

Ok...ok...ich weiß ja, daß ich keine .Config beigefügt habe. Ich habe gestern in dem anderen Thread zu 7270 erst die Thematik mit der ss lib verstanden und werde das heute abend mal korrigieren indem ich die ssl libs statisch linken lasse und Pakete abwähle, wo das nicht geht.

Gruß

Zwergnase

 

[olistudent]

Ist es vielleicht so, daß während des Bootens ein watchdog läuft, der eine kürzere Triggerzeit hat als im späteren Betrieb?

Der Watchdog ist auf 240 Sekunden (4 Minuten) eingestellt. So lange sollte das Booten eigentlich nicht dauern!?

MfG Oliver

 

[Zwergnase]

Habe ich noch nie so genau drauf geachtet, aber es dauert schon relativ lang, insbesondere wenn man usbroot verwendet. Wie wir der Watchdog denn bedient? Ich meine wird er während des Bootprozesses gar nicht bedient? und wie dann später, wenn das Booten erledigt ist?

 

[olistudent]

echo init-done >/dev/watchdog

MfG Oliver

 

[Zwergnase]

Ah. Heißt das, daß mit

echo init-start 240 >/dev/watchdog

der WD mit 4 Minuten in rc.S gestartet wird und am Ende von rc.customs mit

echo init-start >/dev/watchdog

deaktiviert wird? Oder wird er durch den obigen Befehl bedient? Läuft der Watchdog später gar nicht mehr?

Gruß

Zwergnase

 

[RalfFriedl]

Schau doch mal direkt in /etc/init.d/rc.S nach /dev/watchdog. Das Ende wird durch "init-done" angezeigt, nicht nochmal init-start.

Nach dem Booten reagiert der Watchdog darauf, wenn bestimmte Programme unerwartet beendet werden.

 

[Zwergnase]

Naja, da habe ich doch

echo init-start 240 >/dev/watchdog

gefunden....

EDIT: Ah...ich hatte das start/done nicht gesehen.