Freetz trunk / 7390: kein Reboot und kein weiteres Update mehr möglich

[sf3978]

...Dass alles so streng deterministisch ist, Zusammenhänge klar und deutlich hervortreten und alles immer eindeutig ist. :lach:
...

So ist es. Leider hat man nicht immer die erforderliche Zeit oder das erforderliche Wissen oder die Lust, diese Zusammenhänge zu klären bzw. festzustellen.

 

[RalfFriedl]

- funktioniert zum einen der Neustart nicht mehr (es findet einfach kein Neustart statt, weder über die Weboberfläche noch bei "reboot" via SSH) und zum anderen
- ist kein Firmwareupdate mehr möglich, weder über die AVM- noch über die Freetz-Oberfläche.

Das hängt miteinander zusammen. Der Flash-Vorgang beim Update findet erst statt, nachdem alles heruntergefahren wurde. Wenn da etwas hängt, kommt die Box nicht soweit, die Firmware ins Flash zu bringen.

Push_firmware ist übrigens eine Alternative zu Recover, bei der die Einstellungen erhalten bleiben.

 

[imamalu]

Push_firmware ist übrigens eine Alternative zu Recover, bei der die Einstellungen erhalten bleiben.

Danke für die Info! Dann muss ich vor allem nicht deswegen Windows hochfahren und kann bei meinem Linuxsystem bleiben.

 

[Toadie]

Hi,

das gleiche Problem hatte ich nach einem update auf trunk mit meiner 7170 auch.
Der Reboot bleibt (zumindest bei mir) im post_install in der Zeile

/etc/init.d/rc.dsl.sh stop

stecken.

Scheinbar wird die Ausgabe des Scriptes nicht mehr auf eine Console umgeleitet, sondern füllt einen Puffer. Wenn der voll ist, bleibt das Script stecken. Bei mir wirft rc.dsl.sh 'ne Menge Meldungen aus und ist dann der Tropfen, der das Fass zum überlauf bringt.

Folgende Änderung in /patches/110-inittab.sh hat bei mir geholfen:

-::shutdown:/bin/sh -c /var/post_install
+::shutdown:/bin/sh -c /var/post_install &>/dev/null

Wäre interessant zu erfahren, was sich da geändert hat. In älteren Versionen wurden die Ausgaben von Reboot immer auf die Console geschrieben.

Viele Grüße

Dirk

 

[hermann72pb]

Jetzt hatte ich gerade eine Remote-7170 mit dem aktuellen Trunk upgedatet. Reboot hat mir die Box ins Nirvana geschickt. Die Box ist weg. Derjenige, der den Stecker ziehen kann ist nicht erreichbar....

Also Jungs, wir haben ein sehr ernsthaftes Problem mit dem aktuellen Trunk! Box MUSS rebooten, dass ist die wichtigste Funktion, die IMMER gehen muss.

Ich muss jetzt etwas Gehirnschmalz in die Sache reinpacken und wahrscheinlich "mount -o bind" zur Hilfe ziehen, um die Box per remote mit dem Tipp vom Toadie zu flashen.

 

[cuma]

Reboot funktioniert momentan nicht bei den 7xxx Boxen. Kann aber sein dass ein paar Dienste beendet sind. Hier steht am Ende was davon: http://freetz.org/ticket/1163

 

[Toadie]

Zumindest das Hängen von

/var/post_install und
/bin/sh /etc/init.d/rc.dsl.sh stop

deuten auf die gleiche Ursache im Trac-Eintrag hin. Die Probleme beim Laden von tiatm o.ä. scheinen 'was anderes zu sein.
Falls sich sonst nichts geändert hat, würde ich mal (ohne dass ich wirklich Ahnung davon habe), auch die neue Version der BusyBox verdächtigen

 

[hermann72pb]

Workarround von Toadie aus #24 funktioniert nachweislich bei 2x 7170, die ich gestern mit dem aktuellen Trunk geflasht hatte. Ich bin dafür Workarround aus #24 bis auf Weiteres in Trunk aufzunehmen, denn es gibt es nichts schlimmeres, als eine Box, die nicht rebooten kann.
Ich hatte mich mittlerweile an ein ähnliches Phänomen mit dem ftpd-Binary erinnert. Wenn ihr genauer in rc.ftpd reinschaut, werdet ihr feststellen, dass dort auch eine Umleitung von Ausgaben zu /dev/null statt findet. Sonst bleibt ftpd nämlich hängen und lässt sich nicht beenden. Diese hängende Geschichte wird durch komische sed-Sequenzen in ps-Ausgabe begleitet. sed-Sequenzen sind in dem Sinne relativ komisch, weil sie diverse & beinhalten. Vielleicht sind diese & in sed das Problem und nicht die Binaries an sich. Ich weiß allerdings nicht, wer der Verursacher von diesen sed-Sequenzen ist, hatte leider nicht nachgeforscht.

MfG

 

[cuma]

In #24 ist auch ein "&" drin, wodurch der Befehl nur noch im Hintergrund läuft. Dies kann unangenehmen Folgen haben, wie dass Laufwerke nicht richtige/gar nicht ausgehängt werden. Funktioniert es auch nur mit der Umleitung nach /dev/null?

 

[hermann72pb]

@cuma: mit & gebe ich dir Recht, ich hatte darüber auch nachgedacht, dass vielleicht & die eigentliche Lösung ist und nicht die Umleitung. In meinem Spezialfall handelte es sich um zwei 7170 ohne USB-Stick mit Minimalkonfiguration. Also in diesem Fall wäre es mir eigentlich unwichtig, wie es mit dem Aushängen der Laufwerke vor sich geht.
Wenn ich nächste Woche etwas Zeit finde, spiele ich vielleicht mit meiner 7170-Testbox und versuche das Phänomen genauer zu untersuchen. Jetzt ginge mir aber darum, zwei Produktivboxen "wiederzubeleben". Und dafür war die Workarround-Lösung völlig ausreichend.

MfG

 

[Toadie]

Das '&>' soll dafür sorgen, dass sowohl stdout wie stderr umgeleitet werden. Hab's vorsichtshalber gerade noch'mal ausprobiert und die shell scheint's auch so zu verstehen.

sleep 5 &> /dev/null                # wartet 5s mit Umleitung auf /dev/null und kehrt dann zum Prompt zurueck
sleep 5 & > /dev/null               # startet sleep im Hintergrund, leitet dann um und kehrt sofort zurueck (wahrscheinlich sinnlos)

Alternativ ist wohl auch:

sleep 5 > /dev/null 2>&1

möglich

 

[hermann72pb]

Daran hatte ich auch gedacht, aber wie auch immer:
1:0 für dich, Toadie!
Wobei die alternative Schreibweise eher die klassiche Art ist. Ist auch egal, wir haben alle wieder was dazu gelernt.

MfG

 

[Toadie]

Sorry - manchmal geht der "Krümelkacker" mit mir durch

 

[Whoopie]

Hi,

jetzt mal Klartext.

Welche Variante wollt Ihr übergangsweise im Trunk haben? Bitte den entsprechenden Patch an das Ticket 1163 anhängen. Danke!

Beste Grüße,
Whoopie

 

[-ChriZ]

Kurze Frage zum Verständnis zu http://freetz.org/changeset/6445:
Muss ich noch irgendwas von Hand eingeben vor einem reboot oder wird durch den Fix das automatisch übernommen wenn ich jetzt "reboot" eintippe oder auf den Reboot-Button klicke?

 

[cando]

Du musst

svn up

machen, danach Firmware neu mit dem Patch bauen, flashen und dann sollte es gehen.

Die Änderung muss ja irgendwie in Deine Box, oder?

 

[-ChriZ]

Sorry, hätte vielleicht noch dazu schreiben sollen, dass sich die Frage auf eine FritzBox mit aktuellem Trunk bezieht...

 

[RalfFriedl]

Die Änderung muß trotzdem auf die Box kommen.

Unabhängig davon, weiß jemand, warum die Verbindung zur Konsole nicht mehr da ist?

 

[olistudent]

Kann man das irgendwie erkennen? Müsste strace auf den hängenden Prozess was bestimmtes ausspucken?

Gruß
Oliver

 

[cando]

@RalfFriedl

Das muss wieder ein Patch sein, bei mir kommen seit dem Letzten Firmware Upgrade auch keine Meldungen mehr auf der Konsole an und der printk leitet alles nach /dev/debug um - im syslog kommen keine kernel log Meldungen mehr an.

Manuell kann man sie aber mit echo STD_PRINTK > /dev/debug wieder einschalten und mit AVM_PRINTK wieder ausschalten.

Ist schon etwas ärgerlich.

mit dmesg kann man aber den buffer auslesen oder auch mit cat /dev/debug auf die Konsole ausgeben.