@init_done/init-done: man beachte den feinen Unterschied - in rc.tail.sh heißt es "init-done" (Bindestrich), in start_plugin.sh dagegen "init_done" (Unterstrich).
Das ist ja kein direkter Aufruf ... die msgsend-"Kommandos" für den ctlmgr heißen tatsächlich "init-done", "check-plugins" und "plugins-langdb_changed" (letzteres besonders schön :mrgreen
.
Das mit dem Einmal-Initialisieren kann ich auch nicht richtig glauben, denn an der Feststellung
Code:
# AVM/RSP 20150923 prevent wland from loading when plugin is pending
if [ $CONFIG_PLUGINV2_WLAN == "y" ]; then
if mount | grep /dev/loop | grep -q plugin-wlan ; then
echo "rc.wlan: WLAN plugin loaded" > /dev/console
else
echo "rc.wlan: WLAN plugin not yet loaded, taking no action" > /dev/console
[COLOR="#FF0000"] exit[/COLOR]
fi
fi
führt in meinen Augen kein Weg vorbei (es kommt ja nicht einmal zur Auswertung des Parameters für das Skript, wenn da kein Eintrag in /proc/mounts existiert, der "plugin-wlan" enthält).
Wie da das WLAN auch ohne gemountetes Image funktionieren soll (selbst wenn man die Symlinks für die Libraries und die Treiber ignoriert, die ohne Plugin ja auch ins Leere zeigen), erschließt sich mir nicht, auch in der Ausgabe von "mounts" bei der Busybox ist da (im Quelltext) nichts mit irgendeiner Filterung von Loop-Devices zu finden, genauso wenig wie ich etwas zu unterschiedlichen Namespaces finden kann.
Damit müßten auch bei blackstar - wenn das WLAN funktioniert - die Images gemountet sein. Auch findet sich der Aufruf des Skripts "/etc/rc.d/rc.wlan" (wo die Treiber erst geladen werden) nur in der "libwland_hal.so.1.0.0" und die steht nun mal nur im Plugin ... das ist alles sehr mysteriös, wenn das ohne gemountetes Image funktionieren sollte.
Die Zeile
Code:
mount -t squashfs /var/plugins/plugin-${ii}.image /var/plugin-${ii} -o loop[COLOR="#FF0000"]=/dev/loop${loop_count}[/COLOR],ro
paßt m.E. ohnehin nicht zum derzeitigen Code von "util-linux/mount.c" aus der BB 1.24.1, wobei ich erst einmal nachsehen müßte, was beim Mounten jetzt Original und was das Ergebnis Deiner Erweiterung um "loop,offset=" ist. M.E. ist das aber auch bei der originalen BB so, daß die "loop"-Option praktisch umsonst ist (wird bei einer Datei als "device" automatisch angenommen) und sich der Code das nächste freie Device sucht.
Der Teil mit dem Setup eines Loop-Devices hat sich wohl auch zur 1.24.1 hin geändert (zumindest die Maske für das sprintf für den Namen (jetzt "unsigned" für die Nummer des Loop-Devices), für den Rest muß man erst mal in Ruhe in die Quellen sehen) - dann kommt noch der 411-Patch dazu.
Braucht es den wirklich? Ich verstehe ja, daß Du die Arbeit, die Du Dir damit gemacht hast, nicht einfach wegwerfen willst, aber mit "losetup" + Offset-Option auf der einen und Deiner neuen Syntax auf der anderen Seite ist das praktisch doppelt und hier führt es zumindest in denselben Zweig und zu Mehraufwand bei der Analyse der Abläufe - da bei AVM CONFIG_DESKTOP schlicht nicht gesetzt ist, kann man da den if-Zweig leichter ausschließen, was mit der Auflösung der IF-Makros in die Variablen (auch wenn das alles wegoptimiert werden mag mit den "1"-Konstanten) m.E. deutlich unübersichtlicher wird.
Nimmt man mal die Zeichenkette "-o loop=/dev/loop0,ro" als Eingabe an, würde bei einer unveränderten Busybox die "loop"-Option über "unrecognized" delegiert werden, weil das Gleichheitszeichen hinter dem "loop" stört. Im Ergebnis würde die "loop"-Option in voller Schönheit als Zeichenkette (auf die der "data"-Parameter beim "mount" zeigt) an den Kernel weitergereicht ... und hier endet jetzt die Odyssee, da suche ich nicht weiter, ob sich der loop-Device-Treiber davon beeindrucken ließe, wenn da etwas Unbekanntes stünde - solange nicht einmal klar ist, ob da AVM nicht irgendetwas gepatcht hat.
Der reinen Hex-Ansicht der AVM-Busybox nach (ab Offset 0x637bc sollte die Tabelle der Mount-Optionen stehen), hat AVM da zumindest beim mount-Applet aber auch nichts gepatcht.
Wenn ich den restlichen Code in mount.c richtig sehe, wäre die AVM-Syntax mit der Angabe des Loop-Devices für das originale Applet nicht relevant für die Zuordnung eines
bestimmten Loop-Devices, denn hier
Code:
if (ENABLE_FEATURE_MOUNT_LOOP && S_ISREG(st.st_mode)) {
loopFile = bb_simplify_path(mp->mnt_fsname);
[COLOR="#FF0000"]mp->mnt_fsname = NULL;[/COLOR] // will receive malloced loop dev name
if (set_loop(&mp->mnt_fsname, loopFile, loopOffset, /*ro:*/ (vfsflags & MS_RDONLY)) < 0) {
if (errno == EPERM || errno == EACCES)
bb_error_msg(bb_msg_perm_denied_are_you_root);
else
bb_perror_msg("can't setup loop device");
return errno;
}
// Autodetect bind mounts
} else if (S_ISDIR(st.st_mode) && !mp->mnt_type)
vfsflags |= MS_BIND;
wird an "set_loop" kein Device-Name übergeben und damit sucht sich der Code in "libbb/loop.c" selbst das nächste freie Device und zwar eben immer, was für mich den Aufwand mit dem "get_next_free_loop_device" fraglich erscheinen läßt, außer der impliziten Begrenzung auf max. 8 Loop-Devices bzw. Plugins bringt das m.E. nichts.
Da das Plugin nur nach einem "$? -eq 0" vom "mount"-Kommando in die Liste der zu startenden Plugins aufgenommen wird (newplugin), könnte es auch dort noch scheitern, wenn irgendetwas dem mount()-Syscall an Optionen nicht paßt.
Ich habe letztens schon mal falsch gelegen, als ich die von AVM verwendeten Optionen für die Kompressionsstärke beim "gzip" der Busybox angezweifelt habe (beim Packen von TFFS-Dumps in /bin/supportdata.tffs, wo unnötige Zeitverschwendung mit "-1" vermieden werden soll, weil das eigentlich alles schon gepackt ist) ... AVM hat aber wohl einfach einen passenden
Patch verwendet (Freetz jetzt wohl auch, wenn ich das richtig sehe oder es kam automatisch mit der 1.24.1 mit).
Wenn es jetzt für dieses Mounten auch irgendetwas geben sollte, was da geändert wurde, dann sucht man sich einen Wolf.
So rein aus dem Trockentest ist mir nicht klar, was das Ergebnis bei den ersten Aufrufen aus Freetz heraus ist ... wenn da kein rc=0 beim Mounten kommt (warum dann aber bei späteren Versuchen, das ist ja auch wieder unklar), würde das Plugin ja nicht in die Liste aufgenommen.
Vielleicht hilft es ja, da mal im Skript eine permanente Protokollierung irgendwo nach /var/tmp zu hinterlegen und es generell im SheBang mit "-x" aufrufen zu lassen. Ich würde annehmen wollen, daß es keinen expliziten Aufruf mit "/bin/sh" gibt, damit sollte das SheBang wirken und stderr kann man mit "exec" ja entsprechend verbiegen. Das klärt dann nebenbei gleich noch die Reihenfolge der Aufrufe mit entsprechenden Parametern.
Ansonsten sollte auch der Aufruf mit "start_plugin.sh test_lock" anhand des Errorlevels Auskunft darüber geben, ob die Sperre nach der Initialisierung des Systems noch gesetzt ist oder nicht.
Die letzte Theorie, warum es im ersten Anlauf nicht klappen will, wäre das Fehlen der "plugins.update" nach der Installation (aus Freetz heraus) und der spätere Download über start_plugin.sh ... das sollte sich aber bei einer Box, die das Internet erreichen kann, auch relativ schnell von alleine legen, außer daß es (wenn das Kopieren beim Update nicht klappt) die Einrichtung über WLAN natürlich unmöglich macht - sicherlich daher auch der Aufwand beim Vermeiden des Löschens eines einmal installierten Plugin-Images beim Werksreset auf der AVM-Seite. Wenn allerdings das "flash_mount" gar nicht rechtzeitig oder in der falschen Reihenfolge aufgerufen wird (weil z.B. noch verriegelt ist), dann kann das ja auch grandios scheitern. Da bei jedem weiteren Aufruf ja auf einen Mountpoint mit "plugin-" getestet wird, würde wohl auch ein Fehler bei der Installation des ersten Plugins (was wohl wegen der alphabetischen Sortierung beim "ls" wohl immer das "wecm-interpreter" wäre) dazu führen, daß nach dem ersten erfolgreichen Mounten alle weiteren Aufrufe von "start_plugin.sh" am Ergebnis von "test_plugins_installed" scheitern.
