su: am.. Error:No such file or directory

[KisteBier]

der abbruch kommt, wenn die app root voraussetzt und zum laufen braucht. kein root-zugriff, die app bricht ab, da sie ihre aufgaben nicht erledigen könnte. müßte evtl so umgeschrieben werden, daß sie abwartet, bis die rechte vergeben werden. mit ner schleife oder was in der art, hab davon nicht wirklich ahnung ^^
jedenfalls ist´s normal, daß es auch bei always abbricht, weil die rechte in dem moment NOCH nicht vergeben sind - beim nächsten start der app aber schon und dann laufen die root-apps.
100% sauber mag das nicht sein, aber meines erachtens die bisher einzige lösung, die funktioniert. und bisher hatte ich durch always-wahl auch noch nichts destruktives auf´m stein bemerkt.

 

[RobK]

jedenfalls ist´s normal, daß es auch bei always abbricht, weil die rechte in dem moment NOCH nicht vergeben sind - beim nächsten start der app aber schon und dann laufen die root-apps.

Nö - die app läuft ja immer noch, und nur deswegen funktioniert der root-Zugriff. Die App wird also (wie in dem eingangs geschilderten Fall) nicht(!) neu gestartet, sondern nur der root-Zugriff aus der laufenden App heraus neu versucht.

100% sauber mag das nicht sein, aber meines erachtens die bisher einzige lösung, die funktioniert.

Wie gesagt - bei meinem 2.0.1er war's anders: Einmal root angefordert, fertig. Jetzt wird einmal angefordert, und noch mal angefordert. Bei su auf der Shell ist das unwichtig, weil danach alles geht, aber OpenVPN baut einfach den Tunnel nicht auf nach dem ersten su, und benötigt also einen zweiten Klick (oder Tap), und erst dann geht's. So war das vorher nicht, und das nervt. Bei beiden Beispielen schlimmer: das ist nicht richtig

und bisher hatte ich durch always-wahl auch noch nichts destruktives auf´m stein bemerkt.

Always heißt: "Was kümmert's mich, wer Du bist, hau' rein." Das will ich nicht - ich krieg schon das Grausen, wenn eine ChuckNorrisFacts-App meine Telefonanrufe mitlesen will und lass' die Installation dann mal lieber.

Heruntergebrochen auf das Ausgangsproblem: Es ist unsinnig, einer Applikation, die EINMAL root-Rechte anfordert, diese ZWEIMAL NACHEINANDER geben zu müssen. Oder, noch einfacher: Warum muss ich zweimal su[return] schreiben, wenn einmal reichen würde? "Always" würde das wahrscheinlich beheben, aber: a) warum brauche ich jetzt "always"? und b) warum vorher nicht? und c) warum brauchte t(h)oes vorher (wahrscheinlich) auch "always" (obwohl er es mit 2.0.1 mit Sicherheit nie ausprobiert hat, aber die Symptomatik spricht ja dafür, bis auf die fehlende Fehlermeldung?)?

Hat mal eigentlich einer strace/ltrace kompiliert? Damit kämen wir definitiv weiter...

Rob

 

[KisteBier]

ich hab von linux nicht viel ahnung, aber da es mit always bei mir seit jeher funktioniert und mit yes die meisten apps probleme bekamen, lag mir nahe, daß root-rechte anscheinend nur temporär, quasi für die aktuelle "sitzung", vergeben werden.
deine bedenken sind sicherlich nicht unbegründet.. von daher hast du sicher auch nicht unrecht mit einer gsunden vorsicht. allerdings läuft manches dann eben nur eingeschränkt oder mit diversen "widrigkeiten".

 

[RobK]

deine bedenken sind sicherlich nicht unbegründet.. von daher hast du sicher auch nicht unrecht mit einer gsunden vorsicht. allerdings läuft manches dann eben nur eingeschränkt oder mit diversen "widrigkeiten".

Na ja, auf 2.0.1 hat es ja geklappt. Beim t(h)oes zwar genauso schlecht wie jetzt, aber bei mir supi.

Im übrigen hat er heute ein Full SBF drauf gezimmert - selbiges Ergebnis.

Ach, ein strace hab' ich jetzt gefunden:
Android - strace runtime

Rob

 

[RobK]

Neue Erkenntnisse:

"Always" funktioniert. Aber...

Wenn ich im ConnectBot (oder in adb shell, ist egal), "su" abschieße, kommt wie gewünscht der Abfrage-Bildschirm, der Aufruf von "su" ist aber bereits mit der Fehlermeldung des Betreffs dieses Threads beendet!

Ein Tap auf "Yes" lässt dieselbe App beim zweiten Mal durch. Und jetzt kommt's: Selbst, wenn ich auf "No" tappe, bekommt die App root-Rechte, und das ist mal mehr als gruselig!

Mittels strace habe ich herausgefunden, dass zwei Dinge nicht funken: Das lesen von /data/data/koushikdutta.superuser/databases/superuser.sqlite schlägt (warum auch immer) fehl, und der AM (Activity Manager) wird nicht richtig gestartet. Ich hänge mal zwei strace-Outputs an: su.trace.tar.zip ist der strace eines initialen "su", su2.trace.tar.zip nach einem Tap auf "always". Nicht, dass der Zugriff dann geklappt hätte, aber das liegt sicher an strace.

Der Aufruf erfolgte mit:

$ strace -F -ff -s 200 -o /sdcard/su.trace su

Vielleicht wird ja wer schlauer daraus als ich es geworden bin.

Rob

 

[RobK]

Hab' gerade gesehen, dass es noch einen weiteren Thread zum Thema gibt:

[URL="https://www.android-hilfe.de/forum/root-hacking-modding-fuer-motorola-milestone.60/root-not-working-anymore.15212.html[/URL]

Was da mit der Busybox gemutmaßt wird, ist aber leider hier nicht relevant. Meine Busybox liegt weder im Pfad, noch hat sie ein su-Binary.

Hat keiner mehr Ideen?

Rob

 

[-FuFu-]

ich weis ja nicht was schon alles versucht wurde....
busybox ist eine fehlerquelle, wenn man es mit --install installiert hat, gibt es einen su symlink, den man löschen sollte...
ansonsten kann es sein, das du ausversehen in der aufpoppenden "superuser whitelist" ausversehen "allway deny" angewählt hast? wenn ja einfach mal in der superuser whitelist alle bestehenden berechtigungen löschen und dann wieder versuchen...

mehr kann ich auch nicht sagen, ausser vielleicht nochmal mit einer anderen methode rooten (per root update.zip oder mal per adbrecovery v5)

 

[t(h)oes]

Das busybox ein "eigenes" su mitbringt ist glaube ich nicht das Problem.

Bei mir trat das Problem lange bevor mein Stein überhaupt mit busybox in Berührung kam auf.

Eine andere Root-Methode zu verwenden ist glaube ich auch nicht wirklich zielführend, da sowohl RobK als auch ich beide probiert haben.

Wenn wir bei der Abfrage auf always tippen, geht es ab dem nächsten mal. Was nicht funktioniert ist die Abfrage einfach jedesmal mit yes bestätigen zu können.

Sehr erschreckend ist auch das nach "NO" beim zweiten ausführen, trotzdem die Rechte gewährt werden. So muss jede App einfach nur 2 mal fragen und hat die gewünschten Rechte.

Viele Grüße
t(h)oes