Automatisches starten von Skripte bei Systemneustart

  • 31 Antworten
  • Letztes Antwortdatum
R

RainerWP

Fortgeschrittenes Mitglied
17
Hi,

es gibt ja immer wieder Situationen bei denen man aus verschiedensten Gründen etwas testen will (Module beim Start laden, Dienste starten etc.).
Im Normalfall geht dies nur wenn die init.rc im boot.img oder system.img angepasst wird. Und das bedeutet jedesmal ein bischen Arbeit und flashen des Gerätes.
In Anlehnung an das Verfahren der Kollegen die "optware" für Embedded Devices entwickeln habe ich mir für das Loox (oder auch andere Odys Geräte) folgendes ausgedacht.

1. In jedes Custom Rom das hier entwickelt wird, wird die Datei rc.optware in /system/etc/init.d/ erstellt
Inhalt:
Code:
#
#        
#        Starte Skripte in $OPTWAREINITD 
#        Skripte werden in numerischer Reihenfolge ausgefuehrt
#
#        Datei mit dem Pfad zu dem optware Verzeichnis welches auf der SD-Karte liegt
#
OPTWAREDIR=`cat /sdcard/optware.ini`
#
#        init.d Verezeichnis
#
OPTWAREINITD=$OPTWAREDIR"/etc/init.d"
#
#        shell definieren
#
SH=/system/bin/sh
if [ -d $OPTWARE ]
then
        for script in $OPTWAREINITD/S??*
        do
                [ ! -f "$script" ] && continue # Keine Symlink Dateien ausfuehren
                $SH $script start        
        done
        #
        #        Symbolischen Link auf /opt setzen
        #        macht das Tippen einfacher :-)
        #
        if [ ! -d /opt ]
        then
                /system/bin/busybox ln -s $OPTWAREDIR /opt        
        fi
else
        #
        #        Kein optware Verzeichniss auf der SD-Karte vorhanden
        #
        exit
fi

2. In der init.rc der boot.img muss das Skript /system/etc/init.d/rc.optware aufgerufen werden.

---> Wer weiß an welcher Stelle dies geschehen muss ?

3. Auf der SD-Karte liegt im Hauptverzeichniss die Datei optware.ini
Inhalt:
Code:
/sdcard/optware
Dieser Eintrag legt den Pfad zum optware Verzeichnis auf der SD-Karte fest.

Ich habe bei mir z.B. folgende Struktur angelegt :

Code:
/sdcard/opt
/sdcard/opt/etc
/sdcard/opt/etc/init.d
/sdcard/opt/usr
/sdcard/opt/usr/local
/sdcard/opt/usr/local/bin
/sdcard/opt/usr/bin
/sdcard/opt/var
/sdcard/opt/var/log
/sdcard/opt/module

Wenn Punkt 1 - 3 erledigt sind werden jedesmal bei einem Neustart die entsprechenden Skripte ausgeführt.
Hier ein Beispiel für das Modul "hubenable.ko" (/sdcard/opt/etc/init.d/S01usb-hub)

Code:
#!/system/bin/sh
#
#       Lade Modul "hubenable.ko"
#
get_status()
        {
        /system/bin/lsmod | /system/bin/grep "hubenable" > /dev/null
        STATUS=$?
}
start ()
        {
        get_status
        case $STATUS  in
                1)
                        echo "Lade hubenable"
                        /system/bin/insmod /sdcard/opt/modules/hubenable.ko
                ;;
                0)
                echo "Modul schon geladen"
                ;;
        esac
}
stop()
        {
        get_status
        case $STATUS in
                0)
                        echo "Entlade hubenable"
                        /system/bin/rmmod hubenable
                ;;
                1)
                        echo "Modul nicht geladen"
                ;;
        esac
}
status()
        {
        get_status
        case $STATUS in
                0)
                        echo "Modul geladen"
                ;;
                1)
                        echo "Modul nicht geladen"
                ;;
        esac
}
force_reload()
        {
        stop
        start
}

case $1 in                                        
        start)                                    
                start                             
        ;;                                        
        stop)                                     
                stop                              
        ;;                                        
        status)                                   
                status                            
        ;;            
        force_reload) 
                force_reload
        ;;                  
        *)                  
                echo "Usage: $0 start|stop|status|force_reload"
                exit                                           
        ;;                                                     
esac

Wäre toll wenn wir das für alle ROM hinkriegen würden :thumbsup:
Wer hilft mit und bei was ?

Bis dann................

Rainer
 
Frage: Warum /sdcard als Verzeichnis für Optware und nicht eine ext3-Partition? Wenn die SD-Karte entfernt wurde, dann laufen evtl. benötigte Skripte nicht mehr, richtig?

/data wäre doch schreibbar, ext3 und für jeden zugänglich und es müsste nur die boot.img und nicht auch noch die system.img geändert werden!?

Oder denke ich da komplett falsch?

Thomas.
 
Hi Thomas,

fluxflux schrieb:
Wenn die SD-Karte entfernt wurde, dann laufen evtl. benötigte Skripte nicht mehr, richtig?
Das ist richtig, daran habe ich in meiner Euphorie nicht gedacht :-(

fluxflux schrieb:
/data wäre doch schreibbar, ext3 und für jeden zugänglich
Auch der nicht ganz so gewiefte Benutzer ?

fluxflux schrieb:
und es müsste nur die boot.img und nicht auch noch die system.img geändert werden!?
Müsste die system.img nicht für das Skript /system/etc/init.d/rc.optware angepasst werden ?

fluxflux schrieb:
Oder denke ich da komplett falsch?
Let's talk about it :)

Bis dann,

Rainer
 
Hi Rainer,
zunächst mal guter Ansatz, und schon komisch, aber genau damit war ich gestern auch ne Weile beschäftigt ... ;)
ich habe mehrfach gelesen in anderen Foren dass einige ROMs eine /data/init.sh oder /data/userinit.sh unterstützen; ich denke wir sollten den gleichen Weg wählen; von da aus kann man dann immer noch solche Sachen treiben mit der SD-Card wie Du hier vorschlägst ...
lasst uns ein cooles Plätzchen in einer der vorhandenen inits finden wo wir einfach testen ob /data/userinit.sh vorhanden und ausführbar ist, und dann starten ...
 
Hi Wusel,

wusel schrieb:
dass einige ROMs eine /data/init.sh oder /data/userinit.sh unterstützen; ich denke wir sollten den gleichen Weg wählen;
Jupp, kein Problem, kommt ja drauf an was diese Skripte dann ausführen.
Ich habe auf meinem System keine von den beiden Dateien.
Ob dieses Skript dann rc.optware oder init.sh heißt ist eigentlich egal, hauptsache wir können dann über dieses Skript Dinge steuern :)

Ich habe mal den Vorschlag von Thomas aufgegriffen und teste mal mit /data/opt . Das hat ja auch den Vorteil das die Skripte direkt ausgeführt werden können da /data ja ext3 ist.

Bis dann.............

Rainer
 
Hi,

da ja unser Lieblingsspielzeug auf Linux basiert, sollten wir uns ggf. an den Linux Filesystem Hierarchy Standard (FHS) halten. Siehe z.B. Verzeichnisstruktur
und das würde bedeuten das solche Skripte in /etc/init.d/ liegen sollen.

Bis dann...........

Rainer
 
RainerWP schrieb:
Hi,

da ja unser Lieblingsspielzeug auf Linux basiert, sollten wir uns ggf. an den Linux Filesystem Hierarchy Standard (FHS) halten. Siehe z.B. Verzeichnisstruktur
und das würde bedeuten das solche Skripte in /etc/init.d/ liegen sollen.

Bis dann...........

Rainer
prinzipiell würde ich da ja zustimmen, aber andererseits bevorzuge ich dass /system RO gemountet bleibt fürs normale Benutzen ...
daher währe ein Platz auf /data schon besser denke ich; außerdem könnte man das dann auch auf alle Systeme (also auch die mit cramfs) übertragen ...
 
  • Danke
Reaktionen: fluxflux
wusel schrieb:
prinzipiell würde ich da ja zustimmen, aber andererseits bevorzuge ich dass /system RO gemountet bleibt fürs normale Benutzen ...
daher währe ein Platz auf /data schon besser denke ich; außerdem könnte man das dann auch auf alle Systeme (also auch die mit cramfs) übertragen ...

also ich würde da lieber /etc/init.d bevorzugen.
Die Data Partition wird beim neuflashen formatiert und und die Verzeichnisse in Data werden durch die init.rc neu angelegt. Das würde heisen wenn man Module in das Image integrieren möchte, muss man die ja irgendwo hinterlegen und dann in die Data kopieren (Doppelter Speicher).

/etc/init.d klingt vernünfitger für mich, da es ja auch linux standard ist.
 
netlars schrieb:
Die Data Partition wird beim neuflashen formatiert und und die Verzeichnisse in Data werden durch die init.rc neu angelegt.

Hi,
passiert das nicht auch mit /system ?

Bis dann.........

Rainer
 
ja aber da kann ich standard module ja dann in das rom integrieren z.B. hubenable.ko

die sind dann immer da und jeder kann was bei nem ext3 system.img selber hinzufügen

alternative zusätzlich das opt verzeichniss in data anlegen, somit wäre es dann auch bei cramfs nutzbar
 
Hi Leute,

ich habe eben erstmals erfolgreich das boot.img geaendert. Mit den Tools die
PopEi im Thread "cRoms für den Odys Loox/Xpress mit suRoot und ext3/RW/FullRoot" beschrieben hat. Alles unter Linux. Klappt super. Ich habe jetzt ein
init.sh das mir direkt beim booten ein eigenes user-defined script startet. Das liegt im Moment direkt unter /data. Ich werden damit jetzt fuers Erste
etwas herum spielen, und mir dann den besten Platz dafuer ueberlegen.
Wenn es meine Zeit erlaubt, schreibe ich einmal eine Zusammenfassung der benoetigten Schritte. Oder hat das schon einer von Euch gemacht ?
 
ropa schrieb:
ich habe eben erstmals erfolgreich das boot.img geaendert
hast du nur das boot.img geflasht und wenn ja mit welchem Tool unter Linux.
Habe mir das rkflashtool von xda heruntergeladen, kompiliert und getestet.
Auslesen und Reboot funktioniert. Geflasht habe ich noch nicht, will ich heute abend ran.
ropa schrieb:
Oder hat das schon einer von Euch gemacht ?
nö, noch nicht. Will erstmal testen und wir sollten auf einen gemeinsamen Nenner kommen wo was liegen sollte :)

Danke für die Info, bis dann.........

Rainer
 
ropa schrieb:
ich habe eben erstmals erfolgreich das boot.img geaendert. Wenn es meine Zeit erlaubt, schreibe ich einmal eine Zusammenfassung der benoetigten Schritte.

Wenn du das mal zusammenschreiben könntest, dann wäre das großartig!

Ich würde dann lieber dem Vorschlag von fluxflux und netlars folgen und die generell nötigen Kernelmodule in der
init.rd in dem boot.img hinterlegen. Für die etwas exotischeren Anwendungen dann noch den hook.

:thumbup:
 
Hi fluxflux,

super, dann spar' ich mir das.

Viele Gruesse
ropa
 
Hi,

habe mir jetzt zum testen eine boot.img gebaut und geflashed.
init.sh liegt in der boot.img im / Verzeichniss.
Aus der init.sh wird /etc/init.d/rc.optware gestartet.
Ich habe festgestellt das "/sdcard" noch nicht sofort zur Verfügung steht.
Falls also jemand was mit /sdcard" machen möchte muss in dem Skript eine Warteschleife rein, etwa in der Art wie hier :
Code:
date=`date`
/busybox echo "$date : Skript /etc/init.d/rc.test1 aus Abschnitt  boot  der init.rc wird gestartet" > /data/opt/var/log/start1.log
echo "find /sdcard/ "  >> /data/opt/var/log/start1.log
/busybox find /sdcard/ >> /data/opt/var/log/start1.log
while :
do
        date=`date`
        echo "$date : Warte auf /sdcard/opt" >> /data/opt/var/log/start1.log
        if  [ ! -d /sdcard/opt ]
        then
                sleep 2
        else
                echo "$date : /sdcard/opt gefunden" >> /data/opt/var/log/start1.log
                exit
        fi
done
Output :
Code:
Sun Feb  5 13:57:40 UTC 2012 : Skript /etc/init.d/rc.test1 aus Abschnitt  boot  der init.rc wird gestartet
find /sdcard/ 
Sun Feb  5 13:57:40 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:42 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:44 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:46 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:48 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:50 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:52 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:54 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:56 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:57:58 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:58:00 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:58:02 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:58:05 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:58:07 UTC 2012 : Warte auf /sdcard/opt
Sun Feb  5 13:58:07 UTC 2012 : /sdcard/opt gefunden
Testweise habe ich das starten des Skriptes mal in den Abschnitt "on post-fs" der init.rc geschrieben, gleiches Ergebniss.
Sonst fällt mir im Moment kein Abschnitt ein wo es hingehören könnte .
Hier die verschiedenen Abschnitte der init.rc :


Code:
on early-init
on init
on fs
on post-fs
on boot
on property:ro.secure=1
on property:ro.kernel.qemu=1
on property:persist.service.adb.enable=1
on property:persist.service.adb.enable=0

Bis dann............

Rainer
 
Und die init.sh wird aus der init.rc gestartet?

So wie es ropa aufgezeigt hat?

Thomas.
 
fluxflux schrieb:
Und die init.sh wird aus der init.rc gestartet?

So wie es ropa aufgezeigt hat?

Thomas.

Jupp,

Code:
service init_sh /init.sh
    user root
    oneshot
 
  • Danke
Reaktionen: fluxflux
helft mir mal bitte auf die Sprünge, bei meinem XPRESS werden die Scripte nicht ausgeführt bzw. mit Fehler abgebrochen?

was mache ich falsch? Nutzt ihr noch die originale Busybox oder habt ihr die System eigene mit einer anderen ersetzt?

MfG
 

Ähnliche Themen

Ben2023
Antworten
0
Aufrufe
704
Ben2023
Ben2023
H
Antworten
2
Aufrufe
2.252
hasinn
H
J
Antworten
0
Aufrufe
563
Juergena
J
Zurück
Oben Unten