[erledigt] modulare init-skripte anstatt monolithischer rcS

[rhabarber1848]

rcS ist bisher total maschinenunabhängig

Das ist sie jetzt immer noch:

Code: Alles auswählen

#!/bin/sh

. /etc/init.d/functions

get_TZ
get_KMINOR
get_KV
export TZ KMINOR KV

[ -x /etc/init.d/drivers.hdd ] && /etc/init.d/drivers.hdd
/etc/init.d/drivers

run_initscripts start

/etc/init.d/start

/etc/init.d/start startet die GUI.

deswegen habe ich S05drivers extra gemacht.
In sysinit wollte ich nicht die ganzen Treiber laden, weil sysinit nicht im /var/ liegen kann, sysinit macht nur die minimale Initialisierung.

Ok, deshalb starte ich drivers, und optional drivers.hdd, von rcS aus.
Der in drivers enthaltene Code ist maschinenabhängig, wenn
in Makefile.am Konstruktionen dieser Art enthalten sind:

Code: Alles auswählen

if BOXTYPE_DBOX2
FILES_FLASH_RO_EXEC += drivers
endif
if BOXTYPE_IPBOX
FILES_FLASH_RO_EXEC += drivers.ipbox
endif

drivers.ipbox wird während der Skriptinstallation automatisch in drivers umbenannt.

[seife]

rcS ist bisher total maschinenunabhängig

Das ist sie jetzt immer noch:

Code: Alles auswählen

#!/bin/sh

. /etc/init.d/functions

get_TZ
get_KMINOR
get_KV
export TZ KMINOR KV

[ -x /etc/init.d/drivers.hdd ] && /etc/init.d/drivers.hdd
/etc/init.d/drivers

run_initscripts start

/etc/init.d/start

aber "drivers" kann nicht mehr editiert werden (in SquashFS-Images)

/etc/init.d/start startet die GUI.

Und kann auch nicht mehr editiert werden. Das mit den initskripten habe ich extra so gemacht, dass die im /var/ immer "Vorrang" haben. Nur die ganz kritischen Sachen (sysinit, rcS) sind fest im /etc/ und können nicht editiert werden. Darum ist es auch so wichtig, dass nach dem sysinit schon die Konsole da ist

Man könnte ja Konventionen aufstellen wie "alles von 00 bis 09 ist für Treiber, ab 10 ist die Festplatte, falls vorhanden, initialisiert" etc.
Aber wichtig wird das erst, wenn es externe "Pakete" zum Nachinstallieren gibt.

Warum "start" aussagekräftiger ist als "S75_neutrino" weiss ich auch nicht

Ok, deshalb starte ich drivers, und optional drivers.hdd, von rcS aus.
Der in drivers enthaltene Code ist maschinenabhängig, wenn
in Makefile.am Konstruktionen dieser Art enthalten sind:

Code: Alles auswählen

if BOXTYPE_DBOX2
FILES_FLASH_RO_EXEC += drivers
endif
if BOXTYPE_IPBOX
FILES_FLASH_RO_EXEC += drivers.ipbox
endif

drivers.ipbox wird während der Skriptinstallation automatisch in drivers umbenannt.

Ich würde es trotzdem als init-Skript machen. Wo es herkommt, ist ja egal, aber starten würde ich es über den schon vorhandenen Mechanismus, dann spart man sich den check auf /var mehrmals zu implementieren.

Ausserdem gibt es dann keine "magic"-Dateinamen (ausser rcS und sysinit), im prinzip können die skripten dann nach Lust und Laune benannt werden, sie müssen nur mit "S" und "K" anfangen.

Wegen der Reihenfolge: es ist nicht richtig, dass die Dienste immer in der umgekehrten Reihenfolge ihres Starts wieder angehalten werden, insofern ist es nicht nötig, die bei K* "rückwärts" anzuhalten, es macht aber auch nichts aus. Man muss es halt nur wissen und dokumentieren

[dbt]

- neue Datei drivers.hdd, HDD-Code aus drivers dorthin verschoben
(@dbt: Der Name gefällt mir besser als init.drives, kannst Du mit der Datei etwas anfangen?)

Die Bezeichnung ist relativ egal. Da muss nur ein define geändert werden, würde aber trotzdem mounts auch extra machen.
Du musst nur dafür sorgen dass immer eine var/ variante bevorzugt wird. So habe ich das mit dem cdk-Patch vom HDD-Menü auch gemacht. Das geht sogar soweit, das ich diese Datei 2x aufrufe, nur um zuerst alle wichtigen Mounts über fstab zu erwischen. Im 2 Gang wird dann alles an Hddzeugs mit der /var Variante fertig gemountet. Das ging einfach nicht anders. Bei Yadd und jffs ist das natürlich anders. Musst mal schauen wie ich das gemacht habe.
Nebenbei habe ich in deinem Patch die Liste der zu ladenden fs-Module gesehen. Die fs treiber müssen teilweise in der richtigen Reihenfolge geladen werden. Das müsstest du noch für ext3 bzw. vfat ändern.

[rhabarber1848]

Nebenbei habe ich in deinem Patch die Liste der zu ladenden fs-Module gesehen. Die fs treiber müssen teilweise in der richtigen Reihenfolge geladen werden. Das müsstest du noch für ext3 bzw. vfat ändern.

Den Code, den Du da gesehen hast, habe ich per copy en epaste aus
einem anderen Skript übernommen, er muss garantiert noch
angepasst werden. Mir ging es erstmal nur um den Dateinamen.

[rhabarber1848]

Warum "start" aussagekräftiger ist als "S75_neutrino" weiss ich auch nicht

"start" existiert bereits im CVS, um den Patch kleinzuhalten,
habe ich die Datei erstmal nicht umbenannt, außerdem startet
"start" nicht nur Neutrino.

[dbt]

Hast du schon überelegt, wie das mit dbox mmc läuft? Habe nur mmc.ipbox gesehen. Eigentlich würde das in drivers.hdd passen aber default sollte man die glaube ich nicht laden, oder?

[rhabarber1848]

Hast du schon überelegt, wie das mit dbox mmc läuft?

Nein, da ich kein IDE-Interface habe(n will).

[dbt]

Kein Problem, muss man dann hinterher schauen.

[rhabarber1848]

@seife:
Unabhängig von der Umstellung der Init-Skripte gefällt mir
folgender Patch in Deinen Skripts so gut, dass ich ihn schon
jetzt gerne einchecken möchte. Ein Yadd zeigt damit 3s
früher ein Bild an:

Code: Alles auswählen

--- cdk/root/etc/init.d/start_neutrino	2009-06-26 15:22:34.000000000 +0200
+++ cdk/root/etc/init.d/start_neutrino	2009-09-28 09:06:19.000000000 +0200
@@ -22,7 +22,9 @@
 fi
 zapit $ZAPIT
 
-nhttpd
+# start nhttpd a bit later, for faster startup
+{ sleep 20; nhttpd; } &
+
 until neutrino -f -u ; do
     echo "Neutrino exited with nonzero exit status, restarting..."
     pidof sectionsd >/dev/null && sectionsdcontrol --nopause || sectionsd $SECTIONSD

Einwände?

[dbt]

Warum nicht?

[seife]

Tatsächlich habe ich typischerweise gar keinen nhttpd im image, dann ist auch mehr flash und Speicher frei

Das funktioniert bei mir seit Jahren so, sollte also kein Problem sein.

[rhabarber1848]

Code: Alles auswählen

+# start nhttpd a bit later, for faster startup
+{ sleep 20; nhttpd; } &

committed: http://article.gmane.org/gmane.comp.vid ... x.scm/1186

[dwilx]

Wie ist denn der Stand? Nur wegen dem hier:

Das Problem ist, dass noch tiefgreifende Änderungen am init-System anstehen.

[Grabber66]

Damit die IPBox hier nicht zu kurz kommt, mal mein etc/init.d/
damit kann man denke ich auch auf modulare Dateien bauen.

http://rapidshare.de/files/48505751/etc.tar.gz.html

[Striper]

Wie ist denn der Stand? Nur wegen dem hier:

Das Problem ist, dass noch tiefgreifende Änderungen am init-System anstehen.

*push*

[bellum]

Erste Rohfassung, basierend auf seifes Vorarbeit: newinit-3.diff
Dieser Patch ist eher eine Diskussionsgrundlage denn praxistauglich.
Yadd bootet damit.

To-Do
- IPBox-Support
- fehlende Startskripts nachrüsten (ser2net, djmount, cdkVcInfo, sambaserver, nfsd, ...)
- Skripte nach Kernel 2.4/2.6 trennen und nur die benötigte Version installieren
- Testen, testen, testen

Habe das heute mal ausprobiert und auch bei mir bootet ein YADD.
Das ganze gefällt mir schon jetzt sehr gut!
Wie geht es denn da weiter?
Funktioniert das auch schon aus dem Flash?

Gruß bellum

[rhabarber1848]

3) allerdings werden bei mir immer alle init-skripte installiert

Da besteht noch Verbesserungsbedarf. Einen Teil dieser Arbeit kann
über "if ENABLE_AUTOMOUNT" & Co. erledigt werden, es bleiben aber
noch Makefiles für Programme wie dropbear, die über ein customisation-
Skript installiert werden.

Mein Vorschlag: Zum Zeitpunkt der Installation der init-Skripte sollen
alle optionalen binaries im Zielpfad der init-Skript-Installation vorliegen.
Dies ist normalerweise der Fall, wenn root-local.sh für Flashimages und
yadd-none-local.sh durchgelaufen sind.

In cdk/root/Makefile.inc werden Funktionen hinzugefügt, die jedes
Init-Skript per grep/sed & Co. auf einen hinterlegten Kommentar hin
untersuchen, der einen Dateinamen enthalten kann.
Wenn kein Kommentar vorliegt, wird das Init-Skript installiert, wenn
ein Kommentar vorhanden ist - der so aussehen könnte:

Code: Alles auswählen

# Tuxbox init script for /sbin/dropbear

wird das Init-Skript nur installiert, wenn $(prefix)/sbin/dropbear existiert.

[seife]

Wenn dropbear über customization installiert wird, dann kann doch auch das init-skript per customization installiert werden?
Oder versteh ich da was falsch?

Man kann auch einfach immer alle skripten installieren. Dann müssen die halt prüfen, ob das binary vorhanden ist (kostet evtl. 0,5sek. Bootzeit, aber das sollte zu verschmerzen sein).

Deine Lösung ist auch OK, ich halte sie aber für leicht "overengineered"

[rhabarber1848]

Wenn dropbear über customization installiert wird, dann kann doch auch das init-skript per customization installiert werden?
Oder versteh ich da was falsch?

Das Problem ist, dass "make flash-dropbear" nichts darüber weiß, ob
das Init-Skript in /etc (jffs2-only-Image) oder /var/etc landen soll.
Darüberhinaus deckt meine Idee auch Fälle ab, wo User tuxmaild & Co.
entfernt haben, deren Init-Skripte werden ebenfalls nicht installiert.

Man kann auch einfach immer alle skripten installieren.

Genau das möchte ich vermeiden.

Ein erster Patch funktioniert hier bereits im Yadd.

[rhabarber1848]

Das Problem ist, dass "make flash-dropbear" nichts darüber weiß, ob
das Init-Skript in /etc (jffs2-only-Image) oder /var/etc landen soll.

Mögliche Frage: Warum nicht alle Init-Skripts in /etc ablegen, da
run_initscripts() ein möglicherweise in /var/etc vorhandenes,
gleichnamiges Skript bevorzugt?

Antwort: Ich möchte die Möglichkeit nicht verbauen, in den CVS-Makefiles
manche Init-Skripts in /var/etc zu installieren, sofern es sich im ein
Squashfs-Image handelt. Im Yadd- und jffs2-only-Fall landen ohnehin alle
Skripts in /etc.

[seife]

Das Problem ist, dass "make flash-dropbear" nichts darüber weiß, ob
das Init-Skript in /etc (jffs2-only-Image) oder /var/etc landen soll.

Es soll immer in /etc/ landen. Das Design ist ja extra so, dass /etc/ der Fallback und /var/etc der "override" ist.

Beim Image-Bauen ein skript nach /var/etc zu legen macht IMHO keinen Sinn, /var/etc/init.d ist nur dazu da um
a) ein init-Skript auszuschalten
b) ein init-Skript abzuändern, ohne ein neues Image bauen und flashen zu müssen.

Meine Idee ist, dass ein Image, wenn man /var/ komplett löscht, trotzdem mit Defaultwerten funktioniert (die Verszeichnisstruktur muss halt beim ersten boot angelegt werden, aber sonst funktioniert es). Das würde auch ein ordentliches "reset to factory settings" ermöglichen.

Ok. ucodes. Aber die gibts ja nur auf der dbox.

[bellum]

Man kann auch einfach immer alle skripten installieren.

Genau das möchte ich vermeiden.

Ich würde es auch besser finden, wenn nur die benötigten Skripte installiert werden.

Gruß bellum

[rhabarber1848]

EDIT: Patch ist im CVS

Probiert mal diesen Patch aus, ein Flash-Image bootet damit.
Es bleibt noch einiges zu tun, das ist mir bewusst, deshalb
beschränkt Euch bei den Rückmeldungen im Moment bitte
nur auf Erfolgsmeldungen und fehlende Init-Skripte.
Es gibt z.B. im Moment keine Möglichkeit, smbfs/cifs zu
mounten. Sambaserver ist gänzlich ungetestet.

[rhabarber1848]

Das mit den initskripten habe ich extra so gemacht, dass die im /var/ immer "Vorrang" haben. Nur die ganz kritischen Sachen (sysinit, rcS) sind fest im /etc/ und können nicht editiert werden.

Ok, ich habe init.d/drivers nun umbenannt in 05drivers und 06hdd,
zudem habe ich den Inhalt beider Dateien in

Code: Alles auswählen

case $1 in
        start)
[...]
        ;;
esac

Codeblöcke eingefasst, damit diese Skripts beim Herunterfahren
nicht tätig werden. Die Idee mit speziellen Dateinamen gefällt mir
nicht. init.d/start heisst nun 99gui und hat ebenfalls die o.g.
case-esac-Struktur. Ich teste das gerade aus und poste den Patch,
wenn es läuft.
Ein jffs2-only-Image mit der gestrigen Version des Patches
funktioniert ebenfalls, sogar mit

[BOOT] running /etc/init.d/sysinit
Thu Jan 1 01:00:00 UTC 1970
[BOOT] no /var MTD partition found (jffs2-image?)

[rhabarber1848]

Es soll immer in /etc/ landen. Das Design ist ja extra so, dass /etc/ der Fallback und /var/etc der "override" ist.

Ich möchte die Möglichkeit nicht verbauen, in den CVS-Makefiles manche Init-Skripts in /var/etc zu installieren

Das eine schließt das andere nicht aus, momentan ist die Variable
FILES_FLASH_RW_EXEC_START in cdk/root/etc/init.d/Makefile leer,
d.h. die o.g. Möglichkeit wird im Moment überhaupt nicht genutzt.

Mir geht es um die technische Machbarkeit, als Abfallprodukt entstand
die Idee, im Skript einen Dateinamen einzutragen, mit dem geprüft
werden kann, ob das Skript überhaupt benötigt wird.