@koy:
Ich fände es ohnehin schön, wenn Du das mal systematisieren würdest.
Du packst immer wieder mal ein paar Befehle für Pseudo-Images in verschiedene Beiträge ... wie bei mir auch, wechselt das immer wieder mal mit neuen Erkenntnissen und (wie gesagt, mir geht es auch so) die Faulheit siegt, wenn es um das Korrigieren früherer "Verfehlungen" geht.
Wenn man einen dedizierten Thread dafür hat (ich will keinen solchen selbst eröffnen), kann man dort ändern und alle Verweise von anderen Stellen stimmen automatisch ebenfalls.
Irgendwo bei einem Thema "3490 und Pseudo-Images für das Aktivieren von Telnet, weil es per Telefon nicht geht" haben wir das letztens durchdekliniert ... da habe ich u.a. geschrieben, wie das anstelle eines "killall firmwarecfg" besser laufen könnte (bzw. m.E. sogar sollte, wenn man die Box anschließend noch länger laufen lassen will). Ein "killall" ist weder notwendig noch in jedem Falle "safe", die PID des "Restart-Kandidaten" kann man ja gezielt ermitteln und solange die AVM-Komponenten sich auf dieses Vorgehen stützen und Du die Datei mit der PID nicht löschst, "denken" einige AVM-Komponenten eben weiterhin, es stünde ein Restart an. Du brichst praktisch nur den Prozess ab, der den Neustart ausführt ... alle Semaphoren, die da noch existieren, werden ignoriert.
Auch weitere Befehle, um die Box wieder in einen funktionsfähigen Zustand zu versetzen, könnte man in so einem Thread ordentlich dokumentieren. Ein weiterer Aspekt beim Pseudo-Image ist es ja, daß dort eine "Verriegelung" gegen das doppelte Starten eines Update-Prozesses (durch zwei verschiedene Admins) gibt und für ein wiederholtes "Pseudo-Update" (weil man u.U. nur Images für "einzelne Aufgaben" hat und damit mehrere Uploads braucht) sind - je nach Situation - schon noch einige zusätzlichen "Aufräumarbeiten" parallel zum "kill $(cat /var/run/delayed_reboot.pid)" (das wäre die kurze Variante, um den richtigen Prozess abzuschießen, leider bleibt dann die Semaphore immer noch übrig und der nächste Anlauf würde noch einmal ein "kill" probieren, deshalb sollte die auch noch gelöscht werden und damit wird das - ein wenig - länger, wenn man auch noch Existenz und Inhalt der Datei vor dem "kill" testen will) notwendig.
Code:
#
# 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 -TERM $rpid
fi
... nur als
eine mögliche Umsetzung des "kill"-Themas, die auch mehrfach schadlos abgearbeitet werden kann (in Grenzen sogar parallel, wobei das nicht 100%ig ist, dafür bräuchte es noch ein flock).
Eine kleine Auswahl an Dateien, die man auch noch löschen sollte, wenn man wirklich sicher sein will, daß diese "Reste" das Verhalten anderer Komponenten oder auch von firmwarecfg bei einem zweiten Anlauf nicht beeinträchtigen, wären folgende Files:
/var/tmp/fw_ip
/var/tmp/firmware_update_started
/var/tmp/firmware_stream_result
/var/tmp/firmware_error_status
/var/tmp/install_out.log
/var/tmp/install_error.log
Damit nicht ständig neue Images für alle möglichen Zwecke gebaut werden müssen (das ist auch nicht für jeden klar, wie so ein tar-File aussehen muß, vom "Unverständnis" des Busybox-Applets für PAX-Header mal vollkommen abgesehen), wäre mal ein etwas ausgefeilteres Image schön, wo z.B. entweder gleich eine ShellInABox-Instanz gestartet wird, mit der der Uploader dann weiterarbeiten kann oder wo man eine - auf einem anderen Weg (FTP/Samba/NAS-GUI) auf der Box abgelegte - Skript-Datei "nicht blind" abarbeiten kann, d.h. die Ausgabe des Skripts (optimalerweise mit Shell-Debug-Ausgaben) an einer definierten Stelle abgelegt wird (und idealerweise auch noch dem Benutzer angezeigt wird als "Ergebnis" des Uploads). Das braucht zwar etwas "Gehirnschmalz" und es gibt auch garantiert mehr als eine Lösung (man kann so etwas ja auch Stück für Stück zusammen optimieren), aber das wäre mal eine echte Hilfe für Leute, die sich mit der Thematik nicht auskennen. Solange man das auf Skript-Code (und ggf. auf anderem Wege - s.o. - bereitsgestellte Binaries) beschränkt, ist das sogar soweit "universell", daß man es für mehrere Modelle und Architekturen verwenden kann.
Das noch in einem Thread mit den richtigen Informationen angereichert (z.B. daß und wie (prepare_fwupgrade) die Box teilweise heruntergefahren wird, wenn man ein Image hochlädt) und es ist eine wesentlich bessere Informationsquelle für andere Leser, als das immer erneut wiederholte Thema in verschiedenen Threads ... da bleibt das immer nur ein Code-Block ohne jede Erläuterung, der den meisten ohnehin nur die Fragezeichen in die Augen treibt.
Ich will das nicht selbst machen, aber ich stelle gerne den Server für die Ablage solch eines Images bereit und helfe auch gerne bei der Optimierung eines solchen Skripts. So ein "Sammlung-Thread" spart auch an anderen Stellen viel Schreibarbeit und ein Thema: "Anwendungsmöglichkeiten von Pseudo-Updates und wie macht man das (heutzutage) richtig?" gibt es meines Wissens noch nicht bzw. die dort vorhandenen Informationen stammen noch aus den seligen Zeiten, als es "prepare_fwupgrade" noch nicht gab (bzw. in viel weniger invasiver Form) und ein automatischer Neustart nur bei erfolgreichem Flash-Vorgang erfolgte.
Ich
hättehabe das auch in Ansätzen schon einmal probiert (u.a. das "responsive behavior" nach dem Upload, wo ja die Datei /usr/www/$OEM/tools/update_result.html angezeigt wird, mit deren Änderung man dem Uploader ein passendes Feedback geben kann, wenn man von dort entsprechende Weiterleitungen im Browser organisiert) und bin eigentlich nur irgendwann davon abgekommen, weil eben ein Telnet-Start immer noch wesentlich einfacher war.
Wenn das jetzt wegfällt bei der Stock-Firmware, ist das wieder ein sinnvolles Betätigungsfeld, wenn man es erstens variabel gestaltet und zweitens so ausführt, daß es auch Leute ohne Linux-PC (im Idealfall auch ohne Windows-PC, das kommt immer häufiger vor) irgendwie nutzen können. Da könnte ich mir z.B. sogar einen "Webgenerator" für solche Images vorstellen (das gab es ja auch schon mal, ist also nicht meine Idee), wo die auszuführenden Kommandos in einem "textarea"-Input-Control eingegeben werden und per Knopfdruck ein Image erzeugt wird (ggf. noch mit Einstellung von Box-Modell und Firmwareversion, wenn es da spezielle Fälle gibt und man den Skript-Code in "install" übersichtlich halten will). Dieses Image kann der Benutzer dann für seine Box verwenden ... so in etwa würde ich mir das vorstellen, in einer modernen Variante, die eben auch berücksichtigt, daß die Entwicklung beim "Personal Computer" rückläufig ist und es inzwischen Haushalte gibt, wo zwar Router, Smartphones, Tablets uvm. vorhanden sind, es aber keinen "klassischen PC" (nicht mal mehr in der mobilen Version) gibt, was vor einigen Jahren noch Unsinn war, weil dann ja niemand den Router hätte nutzen können.
Freetz ist zwar ein schönes Projekt (und wird für das Erstellen von Binaries ja von mir selbst auch verwendet), aber eben auch für viele Anwender zu kompliziert, das merkt man an verschiedenen Fragen ja immer wieder und bei den derzeitigen Abläufen für das Modifizieren der FRITZ!Box kommt das (meine Meinung) so nie aus der "Geek-Ecke" heraus ... zumindest nicht mehr, seitdem auch auf ein Linux-System eine "bunte Oberfläche" mit Icons und Buttons gehört, damit "die Leute" damit umgehen können. Da ist etwas die Zeit stehengeblieben beim Freetz-Image-Bauen und die Thematik, daß Freetz vielen zu invasiv ist beim Ändern der Abläufe auf der Box, ist ja auch nicht so ganz neu.
Wenn die Freetz-Developer da nicht so richtig ran wollen (u.a. wegen der Rückwärtskompatibilität mit älteren Modellen), kann ich das durchaus verstehen ... aber wenn AVM wieder mal einen "großen Umbruch" wagt (das könnte - muß man halt abwarten - in die Nähe des Wechsels von der 2.4 auf die 2.6 rücken, wenn auch wahrscheinlich eine Nummer kleiner), dann kann man ja auch mal über neue Wege nachdenken.
Ich halte zwar Pseudo-Updates immer noch für einen Weg, den man dann beschreiten kann und soll, wenn man mal "ausnahmsweise" etwas auf der Box machen will und nicht für "echte Modifikationen", die auch unbeaufsichtigt gestartet werden ... aber als "Einstieg" für eine permanente Modifikation oder für einzelne gezielte Aktionen (z.B. eben auch das Umschalten des zu bootenden Systems, wenn das laufende weder Telnet noch eine andere Möglichkeit (z.B. in Form eines modifizierten GUI) bietet) ist das auch ein möglicher Weg. Die Alternative über das Laden eines Kernels und eines Filesystems per EVA (praktisch analog zum Recovery-Vorgang, nur ohne Flashen eines Systems) ist zwar auch vorhanden, aber solange da noch ein System auf der Box arbeitet, ist das nur für die "hartnäckigen Fälle" notwendig und mit dem zusätzlichen Aufwand (direkte Verkabelung, Strom aus/an) für die meisten Nutzer auch eher wieder abschreckend.
Meine ich das nur, oder waren in deinem Pseudo-Image gestern noch einige Fehler? (Port 223 unten, oben 23 - doppelt zudem und jetzt weg?)
