Wie funktioniert's?
Und nun kommen wir dazu, wie das Ganze am Ende funktioniert und warum da vollkommen ohne Auspacken, Modifizieren und wieder Einpacken des Root-Filesystems ein "bleibender Eindruck" im FRITZ!OS hinterlassen wird. Ab hier wird es technisch, weitere Informationen zum Einsatz kommen nicht mehr ... wer verstehen will, was beim "Update" passiert und das ggf. für eigene Zwecke anpassen will, der sollte aber weiterlesen.
Die FRITZ!Boxen, über die wir hier reden, haben ja (m.W.) alle zwei verschiedene Systeme in ihrem NAND-Flash, für jedes System gibt es eine 4 MB große Kernel-Partition und eine 48 MB große Partition für das Dateisystem. Das ist ja jede Menge Platz ... und bei der 06.50 für die 7490 belegt das eigentliche Root-Filesystem als SquashFS-Image gerade mal 18,4 MB von diesen 48 vorhandenen - mit ein paar Files "außen herum" ergibt sich dann immer noch eine Belegung kleiner 22 MB in dieser Partition (das ist praktisch dieselbe Größe, wie sie die Datei "filesystem.image" in einem originalen Update-Image hat). Den schönen Platz in dieser Partition ungenutzt zu lassen, wäre ja fast sträflich - also nutzen wir ihn ab heute für die Speicherung unserer Erweiterungen.
Wenn wir eigene Dateien in diese Partition schreiben, überleben die weder ein Firmware-Update (bzw. sie stehen dann nur noch in der inaktiven Partition) noch die Verwendung des Recovery-Programms für die FRITZ!Box (hier sind sie dann wirklich weg). Egal ob mit Freetz, dem AVM-Original oder "modfs", jedes Update löscht auch wieder den hier installierten Zusatz (und zwar absichtlich, das soll sich gar nicht "festkrallen" im System).
Diese Dateisystem-Partition verwendet als Filesystem
yaffs2, das ist ein Dateisystem extra für NAND-Flash ... aber eben eines, was auch Schreibzugriffe gestattet und genau das machen wir uns zunutze.
Jetzt muß ich etwas ausholen und den Bootvorgang bei einer solchen Box erklären. Der Kernel wird "ganz normal" geladen und greift als erstes auf die yaffs2-Partition als root-Device zu. Dort liegt neben ein paar wenigen Dateien (in erster Linie eine Busybox mit benötigten Libraries) ein SquashFS-Image, das unterhalb des Wurzelverzeichnisses gemountet wird (als /core) und dann wird mit "pivot_root" auf dieses SquashFS-Filesystem umgeschaltet. In der /etc/inittab in der yaffs2-Partition sieht das so aus:
Rich (BBCode):
null::sysinit:/bin/mount -t squashfs /filesystem_core.squashfs /core -o loop <=== neues root-Dateisystem mounten
null::sysinit:/sbin/pivot_root /core/ /core/wrapper/ <=== Umschalten auf dieses Dateisystem als neue Wurzel, das alte landet unterhalb von /wrapper
null::sysinit:/bin/mount /wrapper/dev /dev -o bind <=== "Spiegelung" von /dev aus dem originalen Dateisystem unterhalb der neuen Wurzel mounten, ist nur bei 06.50 bisher so meines Wissens
null::sysinit:/wrapper/sbin/flash_update <=== darauf kommen wir gleich im Text zurück
#
/dev/ttyS0::sysinit:/etc/init.d/rc.S <=== hier startet jetzt "init" die Initialisierung des FRITZ!OS
# Start an "askfirst" shell on ttyS0
/dev/ttyS0::askfirst:-/bin/sh
# Stuff to do before rebooting
/dev/ttyS0::shutdown:/bin/sh -c /var/post_install
Die Einträge in der "inittab" werden streng in dieser Reihenfolge abgearbeitet (für die jeweilige Aufrufbedingung, in diesem Falle eben "sysinit") - damit startet jedes folgende Kommando erst dann, wenn das vorhergehende beendet wurde.
Das macht sich AVM an dieser Stelle auch bei Recovery zunutze, dort werden ein Kernel und ein Dateisystem ins RAM geladen und direkt von dort gestartet. Im Rahmen der Abarbeitung der /etc/inittab kommt dann irgendwann auch das Shell-Skript /sbin/flash_update an die Reihe, das nur dann eine echte Funktion erfüllt, wenn es von eben diesem System (nach Recovery) im RAM der Box aufgerufen wird. Dann beendet es sich nämlich nicht einfach, damit die Abarbeitung der "inittab" weitergehen kann ... nein, in diesem Falle schreibt es sowohl den Kernel als auch das Dateisystem aus dem RAM in die gerade aktiven Partitionen im Flash (deshalb wird bei Recovery auch immer die aktive Partition beschrieben) und startet anschließend die Box noch einmal neu, diesmal dann natürlich aus dem Flash-Speicher. Dieser Zwischenschritt ist auch der Grund, warum man eine solche Box nach dem Ende des Recovery-Programms erst einmal von selbst starten lassen muß und ihr nicht einfach den Stecker ziehen darf (z.B. um sie wieder vom PC an ihren eigentlichen Aufstellort zu schaffen) - solange das System nicht erfolgreich in den Flash-Speicher kopiert wurde, ist Recovery nicht abgeschlossen.
Abseits von einem solchen Aufruf bei Recovery hat das Skript "flash_update" dann aber gar keine Funktion mehr und beendet sich unmittelbar wieder, wenn es feststellt, daß das System nicht aus dem RAM gestartet wurde. Man könnte also genauso gut hingehen und diese Zeile aus der /etc/inittab im Rahmen des Recovery-Laufs auch noch löschen, aber das wäre nur Kosmetik. Wenn so ein Eintrag aber schon mal existiert, können wir ja auch in diese Datei einfach unsere eigenen Befehle schreiben ... gäbe es den Eintrag in der "inittab" nicht, müßten wir halt einen eigenen anlegen.
Genau so geht dieses "Update" jetzt auch vor ... es schreibt einfach eine neue Datei /sbin/flash_update in das yaffs2-Dateisystem, die dann im Rahmen der Initialisierung des Systems aufgerufen wird. Dort kann man natürlich jetzt nicht einfach eigene Programme starten, denn das FRITZ!OS ist zu diesem Zeitpunkt noch im Embryonal-Stadium und muß wenigstens erst mal bis zur Einschulung kommen, bevor wir mit ihm irgendetwas anfangen können. Daher wird die Datei mit folgendem Inhalt gefüllt:
Rich (BBCode):
#! /bin/sh
#
# version for kernel 3.10.73 - AVM firmware 06.50+ (assumption only)
#
# create a shell script to be called from a detached shell
# only /dev is writable here, it's very early after kernel was loaded
#
cat >/dev/delayed_start.sh <<'EOT'
#
# let the OS settle a bit
#
sleep 5
#
# wait until tmpfs is mounted on /var
#
while true; do
grep -q "^tmpfs /var tmpfs" /proc/mounts 2>/dev/null && break
sleep 2
done
#
# check for "uninstall" request
# wait until start has finished in this case, we'll use the running "run_clock"
# as "decision helper"
#
if [ -f /wrapper/remove_custom.flag ]; then
while true; do
pidof run_clock >/dev/null 2>&1 && break
done
mount -o remount,rw /wrapper
rm /wrapper/remove_custom.flag
rm /wrapper/remove_custom.sh
rm /wrapper/filesystem_custom.squashfs
echo "exit 0" >/wrapper/sbin/flash_update
sync
mount -o remount,ro /wrapper
exit 0
fi
#
# mount our additional SquashFS image to /var/custom
#
mkdir -p /var/custom
mount -t squashfs /wrapper/filesystem_custom.squashfs /var/custom
grep -q "^/dev/loop[0-9] /var/custom squashfs" /proc/mounts || exit 1
#
# wait until lan device was started
#
while true; do
ifconfig lan 2>/dev/null | grep -q ".*UP.*RUNNING.*" && break
sleep 2
done
#
# start the init script (etc/init.d/rc.custom) of the mounted extension
#
nohup sh /var/custom/etc/init.d/rc.custom >/var/tmp/rc.custom.log 2>&1 &
EOT
#
# start a detached shell to execute the created script, we've to exit here
# to let the init process continue
#
nohup sh /dev/delayed_start.sh >/dev/delayed_start.out 2>&1 &
exit 0
Das erste Problem ist es schon einmal, daß es zu diesem Zeitpunkt nur begrenzte Möglichkeiten gibt, irgendwo eigene Dateien zu erzeugen ... selbst das tmpfs unter /var ist noch nicht gemountet und kommt erst später im Rahmen der Initialisierung des Systems dazu. Gleichzeitig können wir aber nicht einfach abwarten, bis es soweit ist, denn - wir erinnern uns - die Abarbeitung erfolgt zu diesem Zeitpunkt streng sequentiell und das System wird erst initialisiert, wenn wir unser Skript beendet haben. Also müssen wir irgendwie einen gesonderten Prozess erstellen, der beim Ende unseres Skripts nicht ebenfalls abgeräumt wird. Dazu schreiben wir den grün markierten Teil in eine Datei unterhalb von /dev (da können wir nämlich schon hineinschreiben bei der 06.50) und starten eine weitere Shell-Instanz, die beim Beenden von "flash_update" nicht beendet wird (nohup), anschließend wird "flash_update" beendet, damit "init" weitermachen kann. Bei früheren Versionen ist /dev nicht beschreibbar, daher wird dort das Skript zum Starten nicht inline vorgehalten und dynamisch erzeugt, dort gibt es ein gesondertes Skript im yaffs2-Dateisystem, das dann gestartet wird. Da das "nohup"-Kommando einen sinnvollen File-Descriptor für stdout und stderr benötigt, werden diese beiden Kanäle bei der "vor 06.50"-Version nach /dev/null umgeleitet.
Im grünen Teil (der steht bei < 06.50 als feste Datei "start_custom.sh" unterhalb von "/wrapper" und liegt nicht mehr inline vor) geben wir dann dem Initialisierungsprozess erst einmal 5 Sekunden Zeit, ein paar grundlegende Arbeiten zu verrichten und anschließend prüfen wir im Abstand von 2 Sekunden, ob inzwischen das tmpfs unterhalb von /var gemountet wurde (das sollte schon nach den 5 Sekunden Warten passiert sein, aber Testen schadet nicht). Haben wir dann ein beschreibbares Verzeichnis, legen wir uns einen Mount-Point /var/custom an und mounten dort ein weiteres SquashFS-Image, welches wir parallel zur Änderung der "flash_update" in das yaffs2-Dateisystem kopiert haben und das unsere zusätzlich benötigten Dateien enthält. Das müßte zwar kein SquashFS sein, aber erstens sind alle notwendigen "Zutaten" dafür bereits im FRITZ!OS vorhanden und zweitens kriegt man so wesentlich mehr in dieser Partition unter (auch wenn es in diesem konkreten Fall noch keine Rolle spielt). Nach einer Prüfung auf erfolgreiches Mounten unseres Zusatz-Images prüfen wir jetzt, ob das LAN-Interface der Box (genauer die "lan"-Bridge) initialisiert wurde - ansonsten warten wir in 2-Sekunden-Intervallen, bis es soweit ist. Auch das müßte eigentlich nicht sein ... aber ehe jetzt jemand auf die Idee kommt, gleich als erste Aktion im weiteren Verlauf irgendeinen Service zu starten, der ein funktionierendes lokales Netz braucht und das Warten darauf "vergißt", sorgen wir lieber gleich dafür, daß man da nichts falsch machen kann.
Ach so ... innerhalb des Start-Skripts prüfen wir auch noch, ob vor dem letzten Neustart das Entfernen unserer Erweiterung angeordnet wurde. In diesem Fall installieren wir sie nicht, sondern löschen alle "Dateireste" aus dem yaffs2 und nach dem nächsten Neustart ist dann wirklich alles restlos entfernt und man sieht nur noch an der leeren "flash_update", daß da jemals etwas vorhanden war. Zurück zum "Normalfall" ...
Steht dann irgendwann auch das Netzwerk zur Verfügung, wird ganz simpel (in einem weiteren "detached process") ein Initialisierungsskript aus unserem Zusatz-Image gestartet ... das ist dann - bis auf den etwas früheren Zeitpunkt - im Prinzip dasselbe wie die "rc.custom" im Freetz oder die "debug.cfg" in früherer Firmware. Die im verlinkten Archiv enthaltene Datei sieht ganz simpel so aus:
Rich (BBCode):
#! /bin/sh
#
# we need some additional libraries from our custom extension
#
export LD_LIBRARY_PATH=/var/custom/lib:/lib
#
# start a ShellInABox instance on Port 8010 only supporting TLS connections to establish a secure handling from LAN
#
/var/custom/usr/bin/shellinaboxd --port=8010 --user=0 --group=0 --cert-from-box --background --pidfile=/var/run/shellinaboxd.pid --no-sni --disable-ssl-menu --service=/:0:0:/var/media/ftp:/sbin/ar7login
#
# it's possible to start a telnet instance too, but we should avoid it due to password submission as clear-text
# uncomment the lines below to establish a permanent telnet service, which isn't controlled by the 'telefon' daemon
#
#/var/custom/bin/busybox telnetd -l /sbin/ar7login
Es wird also nur die vorliegende ShellInABox-Version gestartet, mehr soll dieses Image gar nicht leisten ... was man damit noch bauen kann/könnte, bleibt der Phantasie des Lesers überlassen. Daher gibt es in dem zusätzlichen SquashFS-Image auch nur folgende Dateien (hier aus der Variante für SquashFS 4):
Rich (BBCode):
-rwxr-xr-x 1 root root 917748 Dec 15 10:23 ./bin/busybox eine besser ausgestattete Busybox
-rw-r--r-- 1 root root 727 Dec 15 13:37 ./etc/init.d/rc.custom das oben gezeigte Start-Skript
-rwxr-xr-x 1 root root 9298 Dec 15 10:27 ./lib/libprivatekeypassword.so wird für die Nutzung des FRITZ!Box-Zertifikats benötigt
-rwxr-xr-x 1 root root 4688 Dec 15 10:24 ./usr/bin/privatekeypassword ebenfalls für die Benutzung des Zertifikats, eigentlich aber sogar überflüssig, weil die lib reichen würde
-rwxr-xr-x 1 root root 339964 Dec 16 06:57 ./usr/bin/shellinaboxd das ShellInABox-Programm
Die Patches gegen den Freetz-Trunk zur Erzeugung meines privatekeypassword-Pakets in Version 0.5 und für die Verwendung des FRITZ!Box-Zertifikats mit ShellInABox habe ich schon früher hier irgendwo veröffentlicht, sie stehen aber auch noch einmal "frisch" auf dem Server unter der URL
http://yourfritz.de/shellinabox_freetz_13504.patch - werden aber von mir an Änderungen der Basispakete im Freetz nicht mehr angepaßt. Die Konfiguration der Busybox ist "selbsterklärend", dort ist "bbconfig" als Applet enthalten und sie wurde extra mit dem Freetz-Trunk erstellt, damit die Build-Umgebung auch stimmt. Damit sind die Forderungen der GPLv2 hoffentlich auch erfüllt.
Bleibt also nur noch die Frage, wie wir diese Änderungen jetzt in das yaffs2-Dateisystem bringen ... dazu enthält das Archiv das folgende "install"-Skript:
Rich (BBCode):
#! /bin/sh
export INSTALL_SUCCESS_REBOOT=1
export INSTALL_OTHER_ERROR=6
wrapper=/wrapper
custom=custom
mount -o remount,rw $wrapper
grep -q "^/dev/root $wrapper yaffs rw.*" /proc/mounts || exit $INSTALL_OTHER_ERROR
[ -r /var/tmp/filesystem.image ] || exit $INSTALL_OTHER_ERROR
cp -a /var/tmp/filesystem.image $wrapper/filesystem_$custom.squashfs
[ $? -ne 0 ] && exit $INSTALL_OTHER_ERROR
cat >$wrapper/sbin/flash_update <<ENDOFSCRIPT
#! /bin/sh
#
# version for kernel 3.10.73 - AVM firmware 06.50+ (assumption only)
#
# create a shell script to be called from a detached shell
# only /dev is writable here, it's very early after kernel was loaded
#
cat >/dev/delayed_start.sh <<'EOT'
#
# let the OS settle a bit
#
sleep 5
#
# wait until tmpfs is mounted on /var
#
while true; do
grep -q "^tmpfs /var tmpfs" /proc/mounts 2>/dev/null && break
sleep 2
done
#
# check for "uninstall" request
# wait until start has finished in this case, we'll use the running "run_clock"
# as "decision helper"
#
if [ -f $wrapper/remove_$custom.flag ]; then
while true; do
pidof run_clock >/dev/null 2>&1 && break
done
mount -o remount,rw $wrapper
rm $wrapper/remove_$custom.flag
rm $wrapper/remove_$custom.sh
rm $wrapper/filesystem_$custom.squashfs
echo "exit 0" >/wrapper/sbin/flash_update
sync
mount -o remount,ro /wrapper
exit 0
fi
#
# mount our additional SquashFS image to /var/$custom
#
mkdir -p /var/$custom
mount -t squashfs $wrapper/filesystem_$custom.squashfs /var/$custom
grep -q "^/dev/loop[0-9] /var/$custom squashfs" /proc/mounts || exit 1
#
# wait until lan device was started
#
while true; do
ifconfig lan 2>/dev/null | grep -q ".*UP.*RUNNING.*" && break
sleep 2
done
#
# start the init script (etc/init.d/rc.$custom) of the mounted extension
#
nohup sh /var/$custom/etc/init.d/rc.$custom >/var/tmp/rc.$custom.log 2>&1 &
EOT
#
# start a detached shell to execute the created script, we've to exit here
# to let the init process continue
#
nohup sh /dev/delayed_start.sh >/dev/delayed_start.out 2>&1 &
exit 0
ENDOFSCRIPT
cat >$wrapper/remove_$custom.sh <<ENDOFREMOVE
mount -o remount,rw $wrapper
touch $wrapper/remove_$custom.flag
sync
echo "The $custom extension will be removed during next restart."
exit 0
ENDOFREMOVE
sync
mount -o remount,ro $wrapper
exit $INSTALL_SUCCESS_REBOOT
Der grüne Teil ist genau der gewünschte Inhalt der "flash_update"-Datei, der wird halt von "inline" in die Datei geschrieben im Rahmen der Installation, der blaue Part dient zur optionalen Deinstallation der gesamten Erweiterung (siehe weiter oben). Wichtiger ist aber der Beginn der /var/install ... wir müssen nämlich erst einmal das eigentlich nur read-only gemountete yaffs2-Dateisystem beschreibbar machen, das geht ganz einfach mit der "remount"-Option. Ergibt die anschließende Überprüfung, daß es jetzt beschreibbar ist und existiert die Datei /var/tmp/filesystem.image aus unserem Update-Image, wird diese unter dem Namen "filesystem_custom.squashfs" in die Wurzel des yaffs2-Filesystems kopiert. Anschließend noch den neuen Inhalt nach /sbin/flash_update geschrieben nebst dem Skript zum Entfernen der Erweiterung und - nach einem Schreiben der noch ausstehenden Buffer - wir versuchen das yaffs2-Dateisystem der Ordnung halber (eigentlich umsonst) noch zurück auf "read-only" zu mounten (der Erfolg ist uns aber egal). Anschließend startet dann das FRITZ!OS die Box neu.
Das war dann auch schon die ganze Geschichte ... wie man beim "Mitdenken" sicherlich sofort erkennen konnte, ist das wieder eine Art "Framework" - was am Ende installiert und ausgeführt wird, entscheidet allein der Inhalt der Datei "filesystem.image" im tar-Archiv. Tauscht man das gegen eigene Sachen aus und paßt die rc.custom darin entsprechend an, kann man praktisch wieder alles machen, was einem so in den Sinn kommt - der Vorteil ggü. der Verwendung von /var/media/ftp (also des offiziell nach außen zur Verfügung gestellten internen Flash-Speichers) ist es für meinen Anwendungszweck gewesen, daß man systemspezifische Erweiterungen eben genau dem jeweiligen System zuordnen kann und unter /var/media/ftp dann eben nur das ablegt, was beide Versionen in der FRITZ!Box benutzen können und sollen ... bei mir waren es ja seit dem Erscheinen der 06.35-Laborreihe immer zwei verschiedene Systeme, damit ich ohne Reue testen konnte.
Damit könnte man z.B. ein richtiges "install image" für den LCR bauen oder auch wieder Perl und FHEM auf die Box bringen, wobei für FHEM vielleicht der Platz im yaffs2 schon wieder etwas eng wird und man das ggf. teilen muß.
EDIT: 22.07.2020 - Ich bin bei der Suche nach etwas anderem wieder über diesen Thread gestolpert - da mittlerweile Farben wieder funktionieren und die Beiträge hier auch das Limit der max. Zeichenanzahl nicht erreichen, habe ich die Kolorierung in den CODE-Kästen wieder aktiviert.
