[SupportThread]Kiwi++Kernel

  • 479 Antworten
  • Letztes Antwortdatum
W!ldGunM@n schrieb:
Kann ich Dir nicht sagen... meine Änderungen im Updater-script erlauben mir momentan kein init.d wenn Busybox auf /bin liegt...
Ich würde in den Kernel Diskussionsthread ausweichen... weil nochn Thread... dann wirds langsam zu unübersichtlich...

Ich hätte es für unübersichtlich angesehen wenn es in einem Thread liegt, dessen Titel nicht angibt, daß es sich um init.d support handelt, aber wenn Du meinst, ich muss mich da NICHT durchsetzen... (In anderen Foren hätten wir ggf auch eines vom Mod mit der Anti-OT Keule gekriegt... Aber in anderen Foren herrscht auch ein ruppigerer Ton als hier (Kuschelforum?))

Zum init.d:

Ich habe zur Zeit LB-Rom 1.6.0, eine Ramdisk mit
Code:
# Execute files in /etc/init.d before booting
service userinit /system/bin/busybox run-parts /system/etc/init.d
    class main
    user root
    oneshot

Damit sollte m.E. folgendes gehen:

Eine Datei im /etc/init.d
Code:
echo "Test" > /data/local/tmp/test.txt
insmod /system/lib/modules/kiwi_oc.ko CPU=1400 GPU=437

Tut aber nicht.

Halt!!! Da fällt mir gerade ein, ich Depp habe noch garnicht die Rechte geprüft. Wenn ich mit dem ES-Datei-Explorer eine neue Datei anlege, was hat die für Rechte und was braucht ein init.d-Script? Ich vermute hat:
rw- --- ---
Aber braucht:
rwx r-- r--

Werde ich zuhause prüfen...
 
Zuletzt bearbeitet von einem Moderator:
Nee, war nur nen Vorschlag... mal nen neuen Thread auf... ist schließlich dein Projekt...
Ich dachte nur, das man den Threadtitel anpassen könnte...egal.
Also mir ist nicht bekannt, das so ein script überhaupt Berechtigungen braucht... zumal ich die eh nicht setzen kann bei Estellen des Roms.
Ich denke mal, Du meinst james rom 3.0... da es dir LB Rom noch nicht in dieser Version gibt ;-)
 
W!ldGunM@n schrieb:
...
Also mir ist nicht bekannt, das so ein script überhaupt Berechtigungen braucht... zumal ich die eh nicht setzen kann bei Estellen des Roms.
Die Rechte sind in Linux-artigen Systemen essentiell.

Ohne das x-Attribut darf eine Datei nicht ausgeführt werden, auch kein Script.

Erst ab der Dalvik-Ebene geht es ohne x, da ein .apk nicht im Linux-Sinn ausgeführt wird, sondern von der Dalvik-VM gelesen wird, im Linux-Sinn wird die Dalvik-VM ausgeführt.

Wie das beim Erstellen von ROMs geregelt wird, ist eine gute Frage...

W!ldGunM@n schrieb:
Ich denke mal, Du meinst james rom 3.0... da es dir LB Rom noch nicht in dieser Version gibt ;-)

Jetzt hast Du mich erwischt, ich meinte schon LB aber nicht 3.0 sondern 1.6.0

LB ist so schön BAREBONE :thumbup:

Grüsse Uwe
 
mikle_01 schrieb:

LB steht für Lightning Barebone -> Will sagen, ich habe das ROM von W!ldGunM@n auf dem Tab, weil es eben so schön schlicht und schnörkellos ist.

Grüsse Uwe
 
  • Danke
Reaktionen: W!ldGunM@n
u.k-f schrieb:
Die Rechte sind in Linux-artigen Systemen essentiell.

Ohne das x-Attribut darf eine Datei nicht ausgeführt werden, auch kein Script.

Erst ab der Dalvik-Ebene geht es ohne x, da ein .apk nicht im Linux-Sinn ausgeführt wird, sondern von der Dalvik-VM gelesen wird, im Linux-Sinn wird die Dalvik-VM ausgeführt.

Wie das beim Erstellen von ROMs geregelt wird, ist eine gute Frage...

Grüsse Uwe

Und wieder was gelernt ;-)
 
Ja...hab's jetzt auch gefunden....werde ich mir mal flashen, weil ich mit der James 3.0 und dem Kiwi Kernel WLAN und Battery Drain Probleme habe...
 
Init.d ging bei mir. Testdatei wurde erstellt. Sysctl.conf entsprechend geändert. Habs schon ewig drin für mich. bin würde sich gehen Webb man keine toolbox simlinks ändert. Scriptrechte 755. Cm machts aktuell über sysinit (wird mit init.rc aufgerufen und führt bb run-parts aus xbin aus).
@uwe
#!/system/bin/sh is schon drin?

@all
bash wär schön
Schreib nochmal ausführlicher, fahr grad auto, google swipe ime is scheiße iwie.

@w!ldgunm@n
Näturlich kannst du die entsprechenden rechte für die rom setzten, im update-script set_perm_recursive(0, 0, 755, "system/etc/init.d")

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App
 
Zuletzt bearbeitet:
Vetzki schrieb:
@w!ldgunm@n
Näturlich kannst du die entsprechenden rechte für die rom setzten, im update-script set_perm_recursive(0, 0, 755, "system/etc/init.d")

Stimmt, daran habe ich gar nicht gedacht.
 
Vetzki schrieb:
Init.d ging bei mir. Testdatei wurde erstellt. Sysctl.conf entsprechend geändert. Habs schon ewig drin für mich. bin würde sich gehen Webb man keine toolbox simlinks ändert. Scriptrechte 755. Cm machts aktuell über sysinit (wird mit init.rc aufgerufen und führt bb run-parts aus xbin aus).
Das kapiere ich nicht ganz, da sind Dinge drin (über die Du schreibst), die ich nicht kenne...

@uwe
#!/system/bin/sh is schon drin?

Oh war mir nicht klar, dass diese Zeile eine Bedeutung hat (dachte # wäre der Kommentar...)

Danke Uwe
 
Ich hatte schon seit ewig zeiten (als ich für mich init.d einbaute) in /system/etc eine sysctl.conf Datei sysctl
und in init.d ein Script mit sysctl -p (und die in die sysctl.conf geschriebenen Werte wurden übernommen)

#! ist entscheidend, sonst gehts nicht (warum kann ich jetzt auch nicht genau sagen).

Hab noch ne neue, alte ramdisk hochgeladen (ohne das /system/lib/modules bzw. auskommentiert zeug), 2 Test Skripte & ein perl skript zum entpacken der bootimages (dann kann w!ldgunm@n ohne groß suchen ggf. auch ne andere ramdisk nehmen & uwes zImage (= kernel), falls das von uwe aus geht)
 

Anhänge

  • xbinramdisk.7z
    191,5 KB · Aufrufe: 147
Zuletzt bearbeitet:
Vetzki schrieb:
Ich hatte schon seit ewig zeiten (als ich für mich init.d einbaute) in /system/etc eine sysctl.conf Datei sysctl
und in init.d ein Script mit sysctl -p (und die in die sysctl.conf geschriebenen Werte wurden übernommen)
Danke, jetzt verstehe ich mehr...
#! ist entscheidend, sonst gehts nicht (warum kann ich jetzt auch nicht genau sagen).
Rechte gesetzt und !# eingefügt -> Datei geschrieben, Kernel Modul geladen :thumbup: Irgendwie ja auch langweilg, kaum macht man's richtig, schon klappts...:cool2:

Ich probiere es jetzt noch mal mit Deiner Ramdisk ohne Pfad, den in dem script das ich gestern W!ildGunM@n geschickt habe, waren die Fehler von eben auch mit drin...
Hab noch ne neue, alte ramdisk hochgeladen (ohne das /system/lib/modules bzw. auskommentiert zeug), 2 Test Skripte & ein perl skript zum entpacken der bootimages (dann kann w!ldgunm@n ohne groß suchen ggf. auch ne andere ramdisk nehmen & uwes zImage (= kernel), falls das von uwe aus geht)
Von mir aus gerne... Beim wiederherstellen des boot.img bitte auf die Command-Line achten!

Ich habe es nochmals mit der Ramdisk von gestern probiert, das hat aber leider nicht funktioniert.

Wie wäre es, wenn man in dem script sowas drin hat:

Code:
if (-e /system/bin/busybox)
  service userinit /sytem/bin/busybox run-parts /system/etc/init.d/
    class main
    user root
    oneshot
fi
if (-e /system/xbin/busybox)
  service userinit /sytem/xbin/busybox run-parts /system/etc/init.d/
    class main
    user root
    oneshot
fi

Grüsse Uwe

Der ursprüngliche Beitrag von 20:59 Uhr wurde um 21:05 Uhr ergänzt:

mikle_01 schrieb:
Ja...hab's jetzt auch gefunden....werde ich mir mal flashen, weil ich mit der James 3.0 und dem Kiwi Kernel WLAN und Battery Drain Probleme habe...

Hallo mikle_01,

Ist Dein WLan Problem noch immer existent?

Wenn ja, dann würde ich mal einen Kernel bauen, in dem ich das WLan Modul nicht mit rein baue, so dass Du das WLan modul das unter /system/lib/modules/ liegt verwendest. Wenn dann das Problem nicht mehr auftritt, lag es an dem Modul das ich mit in den Kernel eingebunden habe.

Wenn das Problem immer noch auftritt, liegt es nicht an meinem Kernel.

Grüsse Uwe
 
Ich werde die Berechtigungen für init.d. auch mal ins updater-script morgen einpflegen, dann sollte es - mit dem "richtigen" Kernel (also mit Busybox unter xbin) - auch klappen.
 
u.k-f schrieb:
...
Wie wäre es, wenn man in dem script sowas drin hat:

Code:
if (-e /system/bin/busybox)
  service userinit /sytem/bin/busybox run-parts /system/etc/init.d/
    class main
    user root
    oneshot
fi
if (-e /system/xbin/busybox)
  service userinit /sytem/xbin/busybox run-parts /system/etc/init.d/
    class main
    user root
    oneshot
fi

Grüsse Uwe

Der ursprüngliche Beitrag von 20:59 Uhr wurde um 21:05 Uhr ergänzt:



...

Grüsse Uwe

:) An sowas hat ich auch schon gedacht. Dann wiederum dacht ich xbin reicht auch :D.
Kanns gerne machen (hätt aber so gesagt: )
...
if [ -f /system/xbin/busybox ]
then service userinit /system/xbin/busybox run-parts /system/etc/init.d
class main
user root
oneshot
else ervice userinit /system/bin/busybox run-parts /system/etc/init.d
class main
user root
oneshot
fi
...
oder hab ich nen Denkfehler? (denk aber es wär egal wie)
 
Vetzki schrieb:
@w!ldgunm@n
Näturlich kannst du die entsprechenden rechte für die rom setzten, im update-script set_perm_recursive(0, 0, 755, "system/etc/init.d")

Bei mir stehts schon so drinnen...

Code:
set_perm_recursive(0, 0, 0755, 0755, "/system/etc/init.d");

passt das auch ?
 
W!ldGunM@n schrieb:
Bei mir stehts schon so drinnen...

Code:
set_perm_recursive(0, 0, 0755, 0755, "/system/etc/init.d");

passt das auch ?

Sollte passen. 0 = root {USER}, 0 = root {GROUP} (hier ggf. 2000 = shell sollte aber egal sein), 0755 {ORDNER}, 0755 {DATEIEN}. Wobei ich auf anhieb nicht genau weiß wofür die 0 vor 755 steht?
Was sagt den ls -l ?
 
Ramdisk mal so wie oben geschrieben (if/else) ohne den Schreibfehler

edit:
Aber zu Sicherheit nicht flashen, erstmal mit boot testen...
 

Anhänge

  • newramdisk_initd_xbin-bin_initrc.cpio.gz
    188 KB · Aufrufe: 190
Zuletzt bearbeitet:
Baue nachher ein boot.img, aber jetzt muss ich mit meinem Weibchen Fernseh gucken, sonst gibt Haue :)

Btw: ist ne Ramdisk einfach ein tar.gz File oder braucht man dafür ein besonderes Tool?

Ich hatte mit den zwei ifs gearbeitet, um den Fall von keiner busybox ohne Fehler abzuarbeiten (weiss nicht was passiert, wenn busybox gerufen wird, obwohl es die nicht gibt. Bricht dann init.rc ab?)

Grüsse Uwe

Der ursprüngliche Beitrag von 21:43 Uhr wurde um 21:45 Uhr ergänzt:

Vetzki schrieb:
Mal ne ganze blöde Frage: Für was steht denn -e ?
danke

Für exist (egal ob file oder dir)

Uwe
 
Vetzki schrieb:
Sollte passen. 0 = root {USER}, 0 = root {GROUP} (hier ggf. 2000 = shell sollte aber egal sein), 0755 {ORDNER}, 0755 {DATEIEN}. Wobei ich auf anhieb nicht genau weiß wofür die 0 vor 755 steht?
Was sagt den ls -l ?

Die Nullen hatte Android Kitchen erzeugt... warum ? Keine Ahnung

ls -l sagt nix... hab kein Linux, nur Windoof :razz:

Fernseh schauen mit Frauchen ist ne idee... sonst werde ich auch gesteinigt... bis morgen, die Herren :sleep:
 

Ähnliche Themen

B
Antworten
7
Aufrufe
1.590
bejonwe
bejonwe
U
Antworten
22
Aufrufe
3.150
vetzki
vetzki
U
Antworten
10
Aufrufe
2.360
chef_de
C
Zurück
Oben Unten