[SupportThread]Kiwi++Kernel

  • 479 Antworten
  • Letztes Antwortdatum
u.k-f schrieb:
Btw: ist ne Ramdisk einfach ein tar.gz File oder braucht man dafür ein besonderes Tool?

Erst mit gzip dann mit cpio entpacken, warum weiß ich wieder auf anhieb nicht :D

u.k-f schrieb:
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


Das sollte imo nicht passieren (hat ziemlich sicher, beim handy oder tablet, schonmal den falschen pfad drin bzw. busybox woanders) passiert einfach nix, aber zur sicherheit nicht flashen sondern erstmal nur booten.

u.k-f schrieb:
Für exist (egal ob file oder dir)

Uwe

Danke

u.k-f schrieb:
..., aber jetzt muss ich mit meinem Weibchen Fernseh gucken, sonst gibt Haue :)
W!ldGunM@n schrieb:
Fernseh schauen mit Frauchen ist ne idee... sonst werde ich auch gesteinigt... bis morgen, die Herren :sleep:

Gibt ja auch wichtigeres als den schwachsinn :D
 
Leider hat das if nicht geklappt. Im /proc/kmsg war zu lesen:
Code:
init: /init.rc: 453: invalid option 'if'
init: /init.rc: 454: invalid option 'then'
init: /init.rc: 458: invalid option 'else'
init: /init.rc: 462: invalid option 'fi'

Aber da Du meintest, ein falscher Pfad führt nicht zum Absturtz habe ich einen anderen Weg gewählt:

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

# Execute files in /etc/init.d before booting
service userinitx /system/xbin/busybox run-parts /system/etc/init.d
    class main
    user root
    oneshot

Ich starte einfach zwei Services (userinit und userinitx) Jetzt wird mein init.d ausgeführt, egal wo ich die busybox habe (habe beide Varianten getested...)

Ich habe neue boot.img erzeugt und hochgeladen...(Siehe ersten Post)

Grüsse Uwe
 
  • Danke
Reaktionen: W!ldGunM@n
Da ich bisher noch kein if in ner init.rc sah wunderts mich nicht. Aber nen Versuch wars wert. Was ist mit postboot.sh eigentlich rausgekommen?

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App
 
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.

Geschichtsklitterei! Wenn, dann schon Unix-artige Systeme.
Und eine Ausführungsberechtigung brauchen Programme auch in Windows seit NT (und eigentlich jedem ernsthaften OS seit Multics).



Gesendet von meinem A210 mit Tapatalk 2
 
Also iwie will init.d. bei mir nicht funktionieren...

Hat jemand Tipps ?
 
Zuletzt bearbeitet:
W!ldGunM@n schrieb:
Also iwie will init.d. bei mir nicht funktionieren...

Hast Du die Diskussion zwischen Vetzki und mir gestern verfolgt?

Der gute Vetzki musste ir erst noch ein paar Dinge klar machen, dass ich init.d zum laufen gekriegt habe.
  • Ich muß meinen init.d scripten die richtigen Rechte setzen (755)
  • Das Script muß mit #!/system/bin/sh beginnen

Also probier mal folgendes Script
Code:
#!/system/bin/sh
echo "Test" > /data/local/tmp/test.txt

Und gib dem Script volle Rechte (Welchen Dateimanger verwendest Du)

Grüsse Uwe

jpo234 schrieb:
Geschichtsklitterei! Wenn, dann schon Unix-artige Systeme.
Und eine Ausführungsberechtigung brauchen Programme auch in Windows seit NT (und eigentlich jedem ernsthaften OS seit Multics).



Gesendet von meinem A210 mit Tapatalk 2

Sicher hast Du damit Recht, aber Ich habe ja nicht behauptet das es NUR in Linux und NICHT in UNIX nicht so wäre. GGF man könnte a jetzt auch auf Posix erweitern.

Also: Wenn man eine Aussage über eine Gruppe (sofern es sich nicht um eine AUSSCHLIESLICHKEIT handelt) macht ist diese NICHT falsch, wenn sie auch für eine größere Gruppe gilt...

Grüsse Uwe
 
u.k-f schrieb:
Hast Du die Diskussion zwischen Vetzki und mir gestern verfolgt?

Der gute Vetzki musste ir erst noch ein paar Dinge klar machen, dass ich init.d zum laufen gekriegt habe.
  • Ich muß meinen init.d scripten die richtigen Rechte setzen (755)
  • Das Script muß mit #!/system/bin/sh beginnen

Also probier mal folgendes Script
Code:
#!/system/bin/sh
echo "Test" > /data/local/tmp/test.txt

Und gib dem Script volle Rechte (Welchen Dateimanger verwendest Du)



Grüsse Uwe

Meine Scripte fangen alle mit #!/system/bin/sh an... daran sollte es nicht liegen...

Ich hab dem Script volle Rechte gewährt: UID und GID: 0 (root) der Rest 755... keine Reaktion...

Auch wenn ich die GID auf 1000 oder 2000 ändere passiert nix...

Der ursprüngliche Beitrag von 11:01 Uhr wurde um 11:03 Uhr ergänzt:

Ich verwende Totalcommander
 
Zuletzt bearbeitet:
Kannst Du mal einen Cross-Check machen und LB1.6 und meinen neuesten Kernel nehmen, ob es damit geht? (Bei mir geht es damit...)

Ich habe dann auch noch einfach in der LB 1.6 mit 'Cut und Paste' die busybox aus /system/bin ausgeschnitten und nach /system/xbin eingefügt, damit gings immer noch...

Grüsse Uwe
 
Ja, das versuche ich später mal, muss jetzt erstmal bissl was machen (das böööööse A- Wort)... Ja, sogar wenn man mit nen 4-fachen Bandscheibenvorfall zu Hause sitzt, lässt einem die Arbeit nicht in Ruhe :-D

Ich denke mal, das sich auch bei mir im neuen Updater-Script ein Fehler eingeschlichen hat, aber wie gesagt... schepäter (später) mehr dazu...
 
W!ldGunM@n schrieb:
...Ja, sogar wenn man mit nen 4-fachen Bandscheibenvorfall zu Hause sitzt, ...
:scared:

Dann wünsche ich Dir gute Besserung!!!

Uwe
 
Danke :D
 
Also hab ein Crossflash gemacht... geht auch nicht...
 
W!ldGunM@n schrieb:
Also hab ein Crossflash gemacht... geht auch nicht...

Bist Du Dir der Vergabe Deiner Rechte wrklich sicher?

Guckst Du hier (Deine Datei im init.d):
attachment.php


Guckst Du hier (Meine Datei im init.d):
attachment.php


Grüsse Uwe
 

Anhänge

  • RechteWGM.png
    RechteWGM.png
    15,3 KB · Aufrufe: 368
  • RechteUKF.png
    RechteUKF.png
    14,7 KB · Aufrufe: 363
Die Berechtigungen hatte ich schon bedacht... hatte die auch schon auf 755 geändert...
 
Und Du hast nach dem flashen des LB 1.6 ROMs auch den neuesten Kernel von Post1?

Wenn Du erst die Rechte von /etc/init.d recursiv auf 755 setzt, und DANACH die Rechte von /system recursiv auf 644, dann werden die von /ect/init.d auf 644 überschrieben weil /etc/init.d identisch mit /system/etc/init.d ist

Könnte es sowas sein?

Grüsse Uwe
 
Der Kernel ist mit drinnen und an den Rechten solls nicht liegen... ab /system abwärts hat alles 755...
 
In den Kernelmessages steht was drin, ob userinit nicht ausgeführt wurde.

Kannst Du mal UNMITTELBAR nach dem rebooten:

ENTWEDER in einer Konsole auf dem Tab:
Code:
su
cat /proc/kmsg > /sdcard/kmsg.txt
und kurz danach mit Strg+c abbrechen...

ODER über adb auf dem Computer:
Code:
adb shell
cat /proc/kmsg > /sdcard/kmsg.txt
und kurz danach mit Strg+c abbrechen...

... und dann die Datei /sdcard/kmsg.txt posten?

Danke Uwe

Der ursprüngliche Beitrag von 16:37 Uhr wurde um 16:45 Uhr ergänzt:

In den kmsg.txt sollte eine passage haben, die etwa so aussieht:
Code:
<4>[    5.136109] init (1): /proc/1/oom_adj is deprecated, please use /proc/1/oom_score_adj instead.
<4>[    5.503487] AC = 0, Level = 69, RSOC = 69, Bat_temp = 29, CPU_temp = 39, LT = 0, Count = 0
<6>[    5.582714] keychord: using input dev gpio-keys for fevent
<6>[    5.896815] EXT4-fs (mmcblk0p3): INFO: recovery required on readonly filesystem
<6>[    5.897007] EXT4-fs (mmcblk0p3): write access will be enabled during recovery
<6>[    5.909417] EXT4-fs (mmcblk0p3): recovery complete
<6>[    5.911404] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
<6>[    5.927632] EXT4-fs (mmcblk0p4): recovery complete
<6>[    5.929496] EXT4-fs (mmcblk0p4): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,noauto_da_alloc,errors=panic
<6>[    6.589016] EXT4-fs (mmcblk0p9): recovery complete
<6>[    6.589963] EXT4-fs (mmcblk0p9): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,noauto_da_alloc,errors=panic
<3>[    6.710430] init: cannot find '/system/bin/busybox', disabling 'userinit'
<3>[    6.710578] init: cannot execve('/system/etc/install-recovery.sh'): Permission denied

Dort finden sich auf jeden Fall die erste Zeile des Ausschnittes und die Letzte Zeile es Ausschnittes.

Dazwichen findet sich auch:

<3>[ 6.710430] init: cannot find '/system/bin/busybox', disabling 'userinit'

Das ist i.O. da ich sowohl unter /system/bin nach busybox suche als auch unter /system/xbin

Nur wenn sich zwei Zeilen finden würden:

<3>[ 6.710430] init: cannot find '/system/bin/busybox', disabling 'userinit'
<3>[ 6.710430] init: cannot find '/system/xbin/busybox', disabling 'userinitx'

Dann hätten wir das Problem, dass die busybox nirgends gefunden wird...

Grüsse Uwe
 
moment... ich checks mal...
 
W!ldGunM@n schrieb:
moment... ich checks mal...

Weist Du, was mir an der Forumssoftware nicht wirklich gefällt?

Das wenn ich was gepostet habe, und dann nochwas poste, es an meinen ersten Post angehängt wird. Ich bin mir nicht sicher, ob Dir mein zweiter Post als neuer Post gezeigt wurde...

Grüsse Uwe
 
Nee, ist so, wie Du es gepostet hast... also nur einmal cannot find...

Der ursprüngliche Beitrag von 16:59 Uhr wurde um 17:00 Uhr ergänzt:

doch, wird er zumindest am Datum sieht man das...
 

Ähnliche Themen

B
Antworten
7
Aufrufe
1.585
bejonwe
bejonwe
U
Antworten
22
Aufrufe
3.142
vetzki
vetzki
U
Antworten
10
Aufrufe
2.340
chef_de
C
Zurück
Oben Unten