[Erledigt] LCR-Updater unter Fritz OS 6.30 möglich?

[TelefonSparbuch]

Hallo,

wenn ich die Datein install_telnet.tar als Update auf meine FritzBox 7390 mit FW 06.30 aufspiele, dann bekomme ich eine Fehlermeldung:

Das könnte vermutlich behoben werden, in dem das Script mit exit 1 beendet wird (an Stelle mit exit 0).

Hier das Installations-TAR mit exit 1
http://telefonsparbuch.de/software/fritzbox/install_telnet1.tar

 

[LevelOneXX]

Also telnet funktioniert mit dem "Update" ich rufe die fritz.box Seite einfach neu auf, und kann mich wieder anmelden. Obwohl telnet funtkioniert, kann ich dies nicht mehr ausführen:

http://www.wikimatic.de/wiki/ShellScript:FritzBox

wenn ich z.B. "sh /usr/local/addons/cuxd/user/FritzBox.sh WLAN 0" ausführe, dann sagt mir das Script "Erfolgreich" aber es kommt scheinbar nichts an der FritzBox an, aber irgendwas muss passieren, denn in den Ereignissen der FritzBox steht, dass ein Login stattgefunden hat

 

[TelefonSparbuch]

Obwohl telnet funtkioniert, kann ich dies nicht mehr ausführen: ...

Liegt vermutlich dann an dem Script, was mit der neuen Firmware noch nicht richtig umgeht.

Hat die Installation mit dem exit 1 dann ohne Fehlermeldung geklappt? Bei mir kam in der 6.30 noch nie eine Meldung, bzw. die Seite lädt ewig ... Im Prinzip kann die Seite nach Update fortsetzen geschlossen werden, der Updatevorgang läuft dann bis zum Ende. Wichtig ist nur, dass die Bestätigung für Update fortsetzen innerhalb von einer Minute geklickt wird, da sonst der Neustart ausgelöst wird.

 

[koyaanisqatsi]

Uiuiui, das würde jetzt das Thema LCR sprengen.
Ich vermute erstmal so auf die Schnelle, dass was mit UPnP/TR-064 hakt.
...obwohl die Dienste (auch AHA) gestartet sind und HTTP/HTTPS anbieten. :gruebel:

 

[PeterPawn]

Hat die Installation mit dem exit 1 dann ohne Fehlermeldung geklappt?

Funktioniert das wirklich, wenn das "install"-Skript einen Exit-Code von 1 liefert?

Eigentlich hätte ich beschwören wollen, daß dann die Firmware schon vor dem Ablauf des Timeouts einen Neustart auslöst.

Vielleicht hat sich das ja ein wenig verschoben, weil ja der Restart-Prozess durch das Beenden des für den Upload zuständigen "firmwarecfg"-Prozesses auch abgebrochen wird ... aber solange diese Fehlermeldung mit dem "unspezifizierten Fehler" bereits beim ersten Upload-Aufruf auftritt (und nicht erst nach "Update fortsetzen"), solange sollte der Exit-Code von "install" noch keine Rolle spielen, weil die Datei eigentlich noch gar nicht aufgerufen werden dürfte, solange der Nutzer die "nicht freigegebene Firmware"-Warnung noch nicht abgenickt hat. Meines Wissens kommt diese Fehlermeldung mit dem "unspezifizierten Fehler" nicht nach der "nicht signierte Firmware"-Warnung, sondern an ihrer Stelle. Ist das hier in diesem Kontext anders?

 

[TelefonSparbuch]

Firmware-Update Scripte mussten damals (ältere Firmwares) auch mit exit 1 beendet werden um keine Fehlermeldung zu erzeugen (so habe ich es zumindest noch in Erinnerung).

Es fehlt noch ein Dienst (UPnP?), der Port ist nach dem Update nicht mehr aktiv:

8181/tcp open unknown

 

[PeterPawn]

Das ist der "contfiltd" - Bestandteil der Kindersicherung/der Zugriffsbeschränkungen:

root@FB7490:~ $ netstat -anp | grep 8181
tcp        0      0 :::8181                 :::*                    LISTEN      2667/contfiltd

Der wird normalerweise vom "ctlmgr" mit gestartet ... ich habe noch nicht nachgesehen, was Du da so machst in dem Skript. Eventuell wäre ja ein Beenden des ctlmgr (ctlmgr -s) mit anschließendem Neustart desselben (i.d.R. reicht ein "ctlmgr", wenn man keine weiteren Protokolle haben will) als allererster Schritt eine gute Idee, wenn man die Box danach "dauerhaft" weiterbetreiben will?

Das könnte sich auch positiv auf einige Named-Pipes und Shared-Memory-Kommunikation auswirken, die ansonsten (ich habe es nicht getestet) ggf. nicht mehr funktioniert.

 

[koyaanisqatsi]

Hm, den ctlmgr im /var/install Skript zu Beenden ist eine ganz schlechte Idee.
Dann stoppt das Installskript anscheinend und das Webinterface ist nicht erreichbar.
Offenbar ist hier der Neustart des ctlmgr ausserhalb des Skripts nötig (delay).

Den contfiltd startet der ctlmgr? Danke, werde das mal beobachten.

 

[PeterPawn]

U.a. deshalb hantiere ich in meinen Skripten auch so oft mit "delay".

Wenn natürlich die Abarbeitung des Skripts ein "child" des ctlmgr ist (pstree gibt Auskunft, wenn AVM es nicht auch aus der BB entfernt hat), dann sollte man diese ctlmgr-Instanz erst dann abbrechen, wenn man nicht mehr automatisch selbst dabei gekillt wird.

Ich kann mich nicht mehr so genau erinnern, wie da der Baum aussieht (verdammt lange her) ... aber da das "delay" über den multid läuft, sollte das auch ohne ctlmgr klappen.

Wobei ich schon etwas überrascht bin (natürlich nicht davon, daß der ctlmgr auch das Webinterface bedient, das ist "Basiswissen") ... eigentlich hätte ich erwartet, daß das install-Skript ziemlich "detached" läuft, denn den direkten "parent"-Prozess hätte ich jetzt in "firmwarecfg" sehen wollen und das Skript überlebt ja offenbar sogar ein "killall firmwarecfg".

Ich finde jetzt bestimmt den Thread wieder nicht, in dem ich den "komplizierten Weg" mit (verzögerter) Anzeige einer eigenen Seite anstelle von "update_result.html" mal gezeigt hatte, aber da sind eben u.a. diese ganzen "delay"-Aufrufe drin, damit der Prozess entsprechend von anderen abgekoppelt wird.

 

[koyaanisqatsi]

Juhu, das bedeutet: Wieder einen Schritt weiter

Ich hab also mal delay ausgiebig am Ende des Skripts eingebaut...

# kill firmwarecfg or box will reboot after about one minute
/sbin/delay -D 10 INSTCMD '/usr/bin/killall firmwarecfg'
# Webinterface warning message clean up
/sbin/delay -D 12 WWMCMD 'echo "clear_id 87" > /proc/tffs'
/sbin/delay -D 14 CTLTCMD '/usr/bin/ctlmgr -s ; /usr/bin/ctlmgr'
/sbin/delay -D 16 LEDTCMD '/bin/update_led_off'
exit 0

Ergebnis: Sieht noch besser aus, contfiltd wird wie erwartet gestartet (ctlmgr) und das Webinterface "hängt" nicht mehr rum, sondern es wird nach kurzer Zeit die Loginseite präsentiert.

Das gefällt jetzt auch garantiert jeden User besser der dass zum Erstenmal macht. :silly:

...ich teste noch weiter, vielleicht fällt mir/uns ja nochwas ein, bevor ich Post #4 aktualisiere.

denn den direkten "parent"-Prozess hätte ich jetzt in "firmwarecfg" sehen wollen und das Skript überlebt ja offenbar sogar ein "killall firmwarecfg".

Ja, das tu ich auch, deswegen kam der Befehl ja auch immer am Ende des Skripts.
Demzufolge gehe ich davon aus, dass exit 0 nie ausgeführt wurde.
Die Frage, ob jetzt ohne firmwarecfg zu Killen, kein Neustart stattfindet, klär ich noch.

Achso: Da meine Sicherung/fx_conf einen aktiven telnetd enthält hab ich dass mal gecheckt und es ist tatsächlich dann nicht nötig den telnetd extra zu Starten.
Deswegen hab ich gleich zwei Funktionen gemacht mksl und sttd.
mksl = Macht nur das Reaktivieren des Softlinks /usr/sbin/telnetd
sttd = Ruft mksl auf und startet den telnetd

 

[meierchen006]

Hallo,

und das funktioniert dann auch mit 7490 und 7390?

 

[koyaanisqatsi]

Dieses mal invasiv anzutesten kostet keinen Cent, außerdem ists immernoch BETA pur und jede Rückmeldung mit Boxmodell/Firmwareversion kann zu einer Liste der kompatiblen Modelle führen.
Diese Liste wird dann zumindest in der /var/install im Header verewigt.

 

[PeterPawn]

Die Frage, ob jetzt ohne firmwarecfg zu Killen, kein Neustart stattfindet, klär ich noch.

Das sind zwei unabhängige Prozesse. Der Neustart nach Upload eines Images läuft über den Prozess, dessen PID in der Datei /var/run/delayed_reboot.pid steht (oder so ähnlich, habe ich inzwischen oft genug irgendwo geschrieben). Dieser Prozess ist auch für das Senden der Antwort "keine signierte Firmware" zum Browser des Benutzers verantwortlich, danach bleibt er aktiv und wartet darauf, daß das Timeout für den Neustart abläuft. Kommt es zu diesem "Trigger", wird ein Reboot ausgelöst ... so richtig mit "Herunterfahren" und allem Pipapo, deshalb sollte auch das Dismounten funktionieren und da nichts hängenbleiben, sonst hängt eben die Box - das ist mit einiger Wahrscheinlichkeit auch bei vielen Boxen ein Grund, die dann eben mit blinkender Info-LED "stehenbleiben" und einen Schubs in Form eines PoR brauchen.

Der zweite Request, der durch das Drücken auf "Update fortsetzen" ausgelöst wird, startet ja nun eine neue CGI-Instanz von firmwarecfg, die diesen zweiten Request dann verarbeitet. Die ruft dann auch das install-Skript auf (jedenfalls sollte das so sein) und ist eigentlich der Parent dieses Skripts. Wenn Du also aus "install" heraus ein "killall firmwarecfg" machst, sollte das eigentlich immer zwei Prozesse betreffen ... den oben erwähnten, der den Restart auslöst und den Parent-Prozess des install-Skripts. Deshalb habe ich auch immer wieder betont, daß ein "killall" eher keine so gute Idee ist ... dafür gibt es ja die PID in der Datei.

Zum Start des Telnet-Daemons gilt im Moment auch noch das, was über viele Jahre gegolten hat ... der wird von "telefon" gestartet, wenn das Flag (zum Offset habe ich auch oft genug geschrieben, in verschiedenen Threads) für den Start von Telnet gesetzt ist. Wenn man den Symlink anlegt, kann man das jederzeit wieder über den Tastencode ein- und ausschalten. Warum man da einen gesonderten Telnet-Start veranlassen sollte, wenn der "telefon"-Daemon ohnehin neu gestartet wird und somit auch der Telnet-Daemon (bei aktivem Flag, was auch bei der 06.30 noch problemlos per Telefon gesetzt werden kann) mit "hochgezogen" wird, verstehe ich ohnehin nicht.

Solange man nicht auf die Idee kommt, das irgendwie auf einem anderen Port o.ä. machen zu wollen, ist ein zusätzlicher Start einfach Humbug, weil die zweite Instanz auf demselben Port eigentlich den Dienst verweigern sollte (welches dann die zweite ist, hängt von der Reihenfolge des "Wiedereinschaltens" ab). Auch sonst (falls AVM das aus "telefon" ausbauen sollte) wäre es u.U. schlauer, den Telnet-Daemon nicht direkt zu starten und an dieser Stelle einfach die inetd-Konfiguration (die ist beschreibbar) zu ändern und ggf. auch den inetd neu zu starten, wenn der nicht von "prepare_fwupgrade" ohnehin mit gestoppt wurde.

 

[koyaanisqatsi]

Nun, das versuch ich ja auch (fast) mit 1:1 copy and paste umzusetzen...

# stop delayed reboot from firmwarecfg
cleanup () {
rpid_name=/var/run/delayed_reboot.pid
if test -e $rpid_name; then
        rpid=$(cat $rpid_name)
        /bin/rm $rpid_name 2>/dev/null
        [ ${#rpid} -gt 0 ] && /bin/kill -TERM $rpid
fi
/bin/rm /var/tmp/fw_ip
/bin/rm /var/tmp/firmware_update_started
/bin/rm /var/tmp/firmware_stream_result
/bin/rm /var/tmp/firmware_error_status
/bin/rm /var/tmp/install_out.log
/bin/rm /var/tmp/install_error.log
}

...aber leider stört sich die Box* nicht daran und macht einen sauberen Neustart.

Nur mit dem killall firmwarecfg, dann eben wohl mit delay und entsprechenden Timeout, wegen der Installabarbeitung, gelingt es soweit bei mir. :noidea:

* 7360SL

 

[PeterPawn]

Ich habe noch nirgendwo hineingesehen, was da wer wie macht ... aber am o.a. Code-Schnipsel fällt mir auf, daß Du das alles in eine Unterfunktion mit dem Namen "cleanup" gepackt hast. Ich kann mir (wenn Du schreibst, daß die Box davon unbeeindruckt ist) die Frage nicht verkneifen, ob Du "cleanup" denn auch irgendwo aufrufst? Klingt banal, aber wäre eine mögliche Erklärung ... vielleicht ist der Name "cleanup" auch nicht allzu glücklich von mir gewählt, aber dazu stand wahrscheinlich der Kommentar vor der Funktion.

EDIT: Auch bin ich mir nicht wirklich sicher, ob sich ash an dem Leerzeichen zwischen "cleanup" und den runden Klammer stört oder nicht. Das müßtest Du einfach mal mit einer "normalen Shell" testen ... von der Abarbeitung der /var/install siehst Du ja nicht allzu viel, solange Du nicht mit "set -x" startest und die stderr-Ausgabe des Skripts irgendwo in eine Datei umleitest.

 

[koyaanisqatsi]

Klar, ich hab cleanup in install definiert, lasse sie von install am Ende aufrufen, und ich schau auch hinterher nach ob...
1. Die Pidfile gelöscht wurde
2. Die angegebenen Dateien auch weg sind
...manchmal kommentiere ich den Funktionsaufruf um mir halt diese Dateien anzuschauen.

Die Generelle Funktionalität teste ich meistens sowieso in einer Konsole wo ich mich von deren allgemeiner Lauffähigkeit überzeuge. Das muss ich auch, sonst glaub ich es nicht.

Deswegen auch als Funktion, lässt sich easy nachladen in die laufende Konsolensitzung und einfach aufrufen wie jedes andere Shellprogramm.

 

[PeterPawn]

OK, ich habe nur die Hälfte verstanden, aber die entscheidende Frage bleibt doch: Steht nun in der /var/tmp/delayed_reboot.pid eine PID drin? Ist es die von einer "firmwarecfg"-Instanz? Wird diese Instanz ordentlich beendet (ps vorher/hinterher)? Ändert es etwas, wenn Du das "-TERM" (Signal 15) beim "kill" wegläßt? Sollte es eigentlich nicht, aber man weiß ja nie ... wenn das über einen Watchdog realisiert ist mit dem Neustart, kommt der beim "TERM" vielleicht nicht mehr dazu, diesen Watchdog abzuräumen. Denkbar, daß ich da etwas übertrieben habe mit dem "Holzhammer".

Wenn ich das ohne Unterfunktion irgendwo geschrieben habe, ist meine ursprüngliche Vermutung, der Name "cleanup" wäre von mir, ja hinfällig, dann bin ich auch nicht für diesen (in meinen Augen eben unglücklich gewählten, s. #35) Namen verantwortlich, was mich in gewisser Weise wieder erleichtert.

Das "killall"-Problem besteht trotzdem ... wenn Du das als "workaround" ansiehst und das Problem in Deinem "cleanup" nicht findest/nicht suchst, kann ich ja auch nichts machen. Es bleibt aber ein nicht ganz sauberer Weg, erst recht dann, wenn Du damit quasi bewußt auch das "install"-Skript abbrichst.

Ich habe mir das ja auch nicht aus den Fingern gesogen ... genau so habe ich das selbst benutzt (allerding mit -KILL bzw. nichts anstelle des -TERM) und es hat (bis zur 06.23 der 7390) auch immer funktioniert - wenn es jetzt aus irgendwelchen Gründen nicht funktionieren will, muß man halt mal an der Stelle debuggen.

Dazu startet man einen "nc" mit einem FIFO als Eingabedatei und schreibt alles, was dort ankommt, auf eine IP-Adresse und einen Port ins LAN, wo man dann wieder eine nc-Instanz laufen läßt, die das anzeigt. In den FIFO läßt man dann die Ausgabe des install-Skripts schreiben, das kann man ja auch später mit "exec" erst auf diesen FIFO umlenken, dann kann man den nc-Start und das mkfifo auch noch im install-Skript machen. Dann hat man auch für die Zukunft einen Protokoll-Mechanismus (wenn man ihn nicht braucht, kommentiert man ihn eben aus), der weder auf USB baut (was u.U. nicht läuft) noch in das tmpfs schreibt, wo die Daten beim Reboot dann auch weg sind. Wenn die eigene Box dann auch keinen NAND-Flash hat (der auch sehr spät dismountet wird und dafür verwendet werden könnte), ist das einer der wenigen Wege, wie man doch noch zu einem Protokoll kommt. Die Alternative wäre "logger" (wenn das vorhanden ist), wobei das ohne einen laufenden "syslogd" auch nicht ins Netz protokollieren kann. Anstelle von "nc" kann man natürlich auch "socat" nehmen oder was sonst noch so rumliegt.

BTW: Wenn Du in der Zeit bis zum Neustart des ctlmgr den Benutzer nicht im Regen stehen lassen willst, könnte das in etwa so aussehen (von meinen alten Tests übrig geblieben):

<? include tools/static_html_head.html ?>
<? include tools/static_page_head.html ?>
<div class="blue_bar_back">
<h2>FRITZ!Box Pseudoimage-Upload</h2>
</div>
<div id="page_content" class="page_content">
<div class="formular">
Im Hintergrund werden jetzt die gestoppten Dienste der FRITZ!Box wieder gestartet.<br /><br />
<p class="ErrorMsg">
In <span id="waittime">30</span> Sekunden erfolgt die Weiterleitung auf die &Uuml;bersichtsseite der FRITZ!Box.
</p>
<p>
Die im Pseudo-Image enthaltenen Kommandos werden nach dem Start der FRITZ!Box-Dienste ausgeführt.
<script type="text/javascript">
var displaytime = document.getElementById("waittime");
var intvl;
function init() {
        intvl = window.setInterval("countdown()", 1000);
}
function countdown() {
        var count = displaytime.innerHTML;
        count--;
        if (count > 0) {
                displaytime.innerHTML = count;
        }
        else {
                clearInterval(intvl);
                window.location.assign("/home/home.lua?sid=<? SID ?>");
        }
}
window.onload = init;
</script>
<? include tools/static_foot.html ?>

Das rechtzeitig per bind-Mount über die Datei /usr/www/$OEM/tools/update_result.html gemountet und da läuft ein sauberer Countdown bis zum Redirect.

Ich habe das "abgekoppelte" Ausführen der Skript-Anweisungen bei mir so realisiert:

#! /bin/sh
export INSTALL_SUCCESS_NO_REBOOT=0
cat >/var/pseudo/install <<'EOT'
#! /bin/sh
#
# let firmwarecfg settle a little bit
#
sleep 5
#
# stop delayed reboot from firmwarecfg
#
rpid_name=/var/run/delayed_reboot.pid
if test -e $rpid_name; then
        rpid=$(cat $rpid_name)
        rm $rpid_name 2>/dev/null
        [ ${#rpid} -gt 0 ] && kill $rpid
fi
#
# remove the replaced update_result.html file
#
umount /var/pseudo/updres.html
#
# restart the stopped services to return to "normal" state
#
# restarts avmipcd, l2tpv3d, ctlmgr, upnpd, multid, ddnsd, upnpdevd, lltdd (if present), wlan and dsld
#
/etc/init.d/rc.net reload
#
# restarts the VoIP telephonie
#
/etc/init.d/rc.voip restart
#
# restart the USB subsystem, it has been stopped, if the update was done via GUI upload
#
/etc/init.d/rc.usbhost start
/sbin/udevadm trigger
#
# and start our customized command script now (needs multid for delay)
#
if pidof multid >/dev/null 2>&1; then
        delay -d 1 RUNME "/bin/sh /var/pseudo/run_me.sh >/var/pseudo/run_me.log 2>&1"
else
        nohup (sleep 1;/bin/sh /var/pseudo/run_me.sh >/var/pseudo/run_me.log 2>&1) &
fi
EOT
mount -o bind /var/pseudo/updres.html /usr/www/$OEM/tools/update_result.html
nohup /bin/sh /var/pseudo/install > /var/pseudo/install.log 2>&1 &
exit $INSTALL_SUCCESS_NO_REBOOT

Mal abgesehen von der bei mir nicht ganz vollständigen Reanimation von Diensten (Was ist bei TSB und Dir eigentlich mit "capiotcp_server"? Wird der mitgestartet?) befindet sich bei mir eben das "worker script" in einem gesonderten Unterverzeichnis im Image. Damit ändert sich das install-Skript selbst nicht und ich kann ziemlich einfach (durch neue Kommandos in "run_me.sh") ein komplett anderes Image erzeugen, ohne irgendwie mit einem Editor in den sensiblen Eingeweiden der /var/install herumfummeln zu müssen. Wenn ich selbst den ctlmgr neu starten will, gibt es ein weiteres Skript in /var/pseudo, was genau diese Funktion übernimmt (die wird ja auch an anderen Stellen benötigt, z.B. nach dem Editieren von ar7.cfg per vi) und dieses muß dann eben von "run_me.sh" aus aufgerufen werden. In diesem /var/pseudo-Verzeichnis liegen dann auch noch weitere Skripte (z.B. das irgendwo bei der 7490-Laborversion gezeigte Umschalten zwischen den Partitionen) ... dadurch, daß ich nur die run_me.sh anpassen muß vor dem Einpacken, ist die leichte Auswahl einer Funktion für das Pseudo-Image machbar.

Wenn Du das von x verschiedenen Versionen Deines Skripts (hier haben wir ja auch wieder zwei verschiedene, einmal mit und einmal ohne expliziten Telnet-Start) auf eine universelle zurechtstutzen willst, dann bietet es sich ja an, anstelle der "Countdown"-Seite in HTML eine Auswahlliste verschiedener Möglichkeiten anzubieten und nur den "submit"-Button solange zu sperren, bis das GUI der Box im Hintergrund wieder auf eine Ajax-Abfrage der Login-Seite reagiert (dann ist der ctlmgr wieder da). Dann den richtigen Radiobutton ausgewählt und den "submit"-Button gedrückt ... und schon hat man die gewünschte Funktion ausgeführt (das ist auch nur eine weitere Lua-Seite, die ein "OS-Kommando" ausführt, wie die Modifikation der "reboot"-Seite in modfs) und kann das alles mit einem einzigen Image realisieren und braucht dafür nicht mehrere spezialisierte für jeden Anwendungsfall.

PS: Das zusätzliche Leerzeichen zwischen Funktionsnamen und den runden Klammern bei der Definition einer Funktion bei Dir weiter oben stört aber tatsächlich nicht ... macht absolut keinen Unterschied, eben noch einmal getestet.

 

[koyaanisqatsi]

Moins

Ja, wenn die cleanup() nicht ausgeführt wird, konnte ich mich in der kurzen Zeit die mir blieb, davon überzeugen, dass die Pidfile existiert, mit Nummer auf einen existierenden firmwarecfg Prozess.
Mit ausgeführter cleanup() existiert nichts davon. Das selbe Ergebnis mit simulierten/gestarteten Prozess dessen PID in gleichnamiger Pidfile eingetragen wurde. Nach ausgeführter cleanup() wird auch dieser sauber entfernt.

Wer weiss, vielleicht wäre das einfach nur eine weitere Macke der 7360SL, dass das nicht so funktioniert wie es soll.

Auf jeden Fall ein Dankeschön für deine Posts, ich werd mir das reichlich zu Gemüte führen und hoffe auf den entscheidenden Geistesblitz.

Ich wäre auch nicht abgeneigt dieses Projekt an dich zu übergeben.
...du kannst sowas eindeutig besser als ich.

Dann würd ich dir zumindest mit meiner abgespeckten/subventionierten Ausnahmebox als Betatester zur Seite stehen und zurückmelden was nicht geht.

 

[PeterPawn]

Nope ... keine Chance. Mein längerer Post in dem anderen Thread wollte ja gerade Dich dazu animieren, das etwas systematischer anzugehen und nicht nur mit "von Fall zu Fall"-Lösungen. Wenn Du keine Lust dazu hast ... PGH. Vielleicht macht es ja jemands anderes; ich habe definitiv (vorerst) keine Zeit dafür, so etwas zu warten. Ich gebe gerne meinen Senf dazu, wenn ich der Meinung bin, daß da etwas nicht richtig ist oder besser geht ... ob man das dann umsetzt, steht ohnehin auf einem anderen Blatt.

Wenn das ein Problem der 7360SL ist, sollte es ja auf anderen Boxen funktionieren - es ist ja auch nur ein "Abklatsch" des Vorgehens von AVM im "richtigen /var/install-Skript" eines Firmware-Updates (am Ende der Datei). Was steht denn bei einer solchen Datei für die 7360SL in diesem Skript? Wie gesagt, mein "hau drauf" mit dem TERM-Signal könnte sogar die Ursache sein, daß da das beendete firmwarecfg nicht mehr richtig aufräumen kann und damit der Neustart dann trotzdem erfolgt. Wenn das kein normaler Timer, sondern ein Watchdog-Timer ist, der nicht abgebrochen wird bei "SIGTERM", dann ist das einfach zu aggressiv, was ich da (nach Kopieren und etwas "aufhübschen") irgendwoanders geschrieben habe - bei mir ist das auch kein "[ ... ] && kill -TERM $rpid", sondern ein "if"-Zweig ... wenn ich beim Ändern mit dem -TERM dann etwas zu eifrig war, sollte da ein einfaches "kill" besser funktionieren (-KILL für SIGKILL(9) ist Standard bei diesem Kommando und kann eben entfallen).

 

[koyaanisqatsi]

Ja, war nur nee Idee.

OK.

Der betreffende Block in der letzten Labor enthält...

##################################################################################
#  returnwerte:  0 kein reboot,  1 reboot
##################################################################################
exit $need_reboot
##################################################################################
echo "****INSTALLSCRIPT STOPPED ON DEVICE FOR TESTING (disabling watchdog)****"
if [ -e /dev/watchdog ] ; then
    echo "disable" > /dev/watchdog
fi
if [ -f /var/run/delayed_reboot.pid ] ; then
    ## Terminate any scheduled delayed reboot from firmwarecfg-CGI
    local REBOOT_PID=`cat /var/run/delayed_reboot.pid`
    rm /var/run/delayed_reboot.pid
    if [ "$REBOOT_PID" != "" ] ; then
        kill -9 $REBOOT_PID
    fi
fi
echo "****$need_reboot****"
exit 0
##################################################################################

...und wird nie ausgeführt, wie es aussieht wird vorher der /dev/watchdog deaktiviert.
Ja, klar, und kill macht -9 :silly: