PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Irgendwie nimmt das "SILENT_UPDATE" wohl immer mehr Gestalt an ... das soll wohl ein "echtes" Erlebnis nach dem Motto "set and forget" werden, wo die FRITZ!Box zu einer einstellbaren(?) Zeit dann ihr Update "durchzieht", was zuvor mittels der "/var/install" vorbereitet wurde in Form zweier Shell-Skripte unter "/var/updatestore/update_action_{flash,convert}".
Wobei das "update_action_flash" dann wohl auch sofort ausgeführt wird, wenn die "/var/install" läuft (was aber auch verzögert sein könnte und nicht direkt nach dem Download, obwohl die Signaturprüfung vermutlich auch wieder direkt beim Download erfolgt).
Der Aufruf von "update_action_convert" wird hingegen zur "/var/post_install" hinzugefügt und erst wenn dieses Skript bei einem Neustart (bzw. davor, denn es wird durch den Reboot-Request ja ausgelöst) auch erfolgreich war, wird "linux_fs_start" umgeschaltet aus der (fortgeschriebenen) "/var/post_install" heraus.
Ich halte es auch für denkbar, daß diese spezielle Inhouse-Version zum Testen ebendieses Features dienen soll (wobei ich die Inhouse-Reihe wirklich nicht weiter beobachte, daher auch nicht weiß, seit wann die "/var/install" in dieser Art und Weise anders "strukturiert" ist) und "normale" Updates weiterhin das etablierte Format nutzen.
Immerhin versteht auch der Kernel dieser Inhouse-Version offenbar weiterhin das Format mit dem "ext2"-Image ... jedenfalls ist der entsprechende Parser in den Setup-Routinen des Kernels wohl noch enthalten, zumindest dem Namen nach:
Spätestens mit der nächsten offiziellen Labor-Version wird sich dann herausstellen (weil die wohl kaum als "SILENT_UPDATE" daherkommen wird), ob das Format tatsächlich wieder auf "SquashFS" für den Wrapper wechselt ... am Ende ist es ohnehin nur das "mount"-Kommando in der "/var/install", was da abweicht - bei der "Auto-Installation" aus dem RAM wird weiterhin einfach von "/wrapper" kopiert, denn da ist das Dateisystem ja bereits (egal, ob es "ext2"- oder SquashFS-Format verwendet) unter diesem Pfad gemountet nach dem "pivot_root" auf das eigentliche RootFS.
Wobei das "update_action_flash" dann wohl auch sofort ausgeführt wird, wenn die "/var/install" läuft (was aber auch verzögert sein könnte und nicht direkt nach dem Download, obwohl die Signaturprüfung vermutlich auch wieder direkt beim Download erfolgt).
Der Aufruf von "update_action_convert" wird hingegen zur "/var/post_install" hinzugefügt und erst wenn dieses Skript bei einem Neustart (bzw. davor, denn es wird durch den Reboot-Request ja ausgelöst) auch erfolgreich war, wird "linux_fs_start" umgeschaltet aus der (fortgeschriebenen) "/var/post_install" heraus.
Ich halte es auch für denkbar, daß diese spezielle Inhouse-Version zum Testen ebendieses Features dienen soll (wobei ich die Inhouse-Reihe wirklich nicht weiter beobachte, daher auch nicht weiß, seit wann die "/var/install" in dieser Art und Weise anders "strukturiert" ist) und "normale" Updates weiterhin das etablierte Format nutzen.
Immerhin versteht auch der Kernel dieser Inhouse-Version offenbar weiterhin das Format mit dem "ext2"-Image ... jedenfalls ist der entsprechende Parser in den Setup-Routinen des Kernels wohl noch enthalten, zumindest dem Namen nach:
Rich (BBCode):
pi@pi4:/tmp $ grep -abo "find_[a-z0-9]*fs[a-z0-9]*" kernel.image.unpacked
6617477:find_vfsmount
7455768:find_jffs2
7455780:find_squashfs
7455796:find_ext2fs
pi@pi4:/tmp $
