[ROM][JB][JLS36G][4.3] CyanogenMod 10.2.1 (S | N | M1 | RC1) - Diskussion

Du kannst versuchen vom recovery aus deine daten zu retten. "adb pull /data C:\backupfolder"

Das mit dem Kernel ist kein Wunder, CM hat irgendwelche Qualcomm Patches gemerged, d.h. die Kernels müssten am CM Kernel basiert sein und Custom Kernels zu flashen kann einen Bootloop und damit Datenverluste verursachen.

Deshalb nochmal: Vorsichtig mit Kernels bei CM!

pull klappt laut man-page nur mit dateien nicht mit verzeichnissen, müsste ich ein script schreiben und in einer Schleife datei für datei einzeln pullen.
Den ganzen Aufwand könnte ich mir sparen wenn mir jemand sagen könnte wos klemmt, jetzt klemmts schon am Bootscreen.

EDIT:
Scheinbar klappt das mit pull auch so, er hat angefangen aber in welcher Reihenfolge er die Verzeichnisse kopiert ist völlig unverständlich, alphabetisch, nach Größe oder Änderungsdatum kanns schonmal nicht sein zumal der auch mitten im Verzeichnis manchmal wechselt. Mal schauen.

Leider löst das nicht das Kernproblem.

Vielleicht hilft es zu wissen was er tut wenn er anzeigt "Apps werden gestartet" nachdem er den dalvik neu aufgebaut hat und die Apps zurückgespielt hat. Weiß das einer?

Data korrupt

Aha

Flextrick schrieb:

Das mit dem Kernel ist kein Wunder, CM hat irgendwelche Qualcomm Patches gemerged, d.h. die Kernels müssten am CM Kernel basiert sein und Custom Kernels zu flashen kann einen Bootloop und damit Datenverluste verursachen.

Zum Vergrößern anklicken....

Bootloop heißt nicht Datenverlust, zumindest dann nicht, wenn man nicht kranke Dinge wie "Dynamic Fsync" o.ä. verwendet.

NoNickFound schrieb:

Vielleicht hilft es zu wissen was er tut wenn er anzeigt "Apps werden gestartet" nachdem er den dalvik neu aufgebaut hat und die Apps zurückgespielt hat. Weiß das einer?

Zum Vergrößern anklicken....

Nein, aber mit der Ausgabe von 'adb logcat' könnte man es herausfinden

maniac103 schrieb:

Bootloop heißt nicht Datenverlust, zumindest dann nicht, wenn man nicht kranke Dinge wie "Dynamic Fsync" o.ä. verwendet.

Zum Vergrößern anklicken....

Nein, damit meinte ich: Datenverlust dann, wenn man keine Chance hat, ohne data wipe aus dem Bootloop herauszukommen.

Warum ist " Dynamic Fsync " krank?

maniac103 schrieb:

Nein, aber mit der Ausgabe von 'adb logcat' könnte man es herausfinden

Zum Vergrößern anklicken....

Logcat kam keins mehr. Hatte letztens auch einen interessanten Bug mit kompletten Logcat gepostet, da da auch keiner drauf einging hab ich mir da gar keine Mühe mehr gegeben und gleich per adb den Speicher ausgeräumt.

Hab aber die Appdaten zurück gepusht und hatte sofort wieder diesen Fehler.

Hatte demletzt auch den Fehler, dass nix mehr ging und konnte mir mit diesem Toolkit die Daten auf'n PC sichern. also der adb pull befehl wird da ausgeführt.

Im N-Cry Toolkit fehlt dieser Befehl.

c@p schrieb:

Warum ist " Dynamic Fsync " krank?

Zum Vergrößern anklicken....

Eine App, die fsync aufruft, kann sich laut Man-Page sicher sein, dass die Daten im Flash gespeichert sind. 'Dynamic Fsync' sorgt dafür, dass diese Zusicherung nicht mehr stimmt. Es macht also die Posix-API kaputt und sorgt dadurch dafür, dass bei an sich harmlosen Reboots jederzeit Datenverlust droht.

NoNickFound schrieb:

Logcat kam keins mehr.

Zum Vergrößern anklicken....

'Kam keins mehr'?

Hab aber die Appdaten zurück gepusht und hatte sofort wieder diesen Fehler.

Zum Vergrößern anklicken....

Na dann her mit dem Logcat

maniac103 schrieb:

'Kam keins mehr'?

Zum Vergrößern anklicken....

Ja, ich weiß ja nicht wie ihr das macht aber ich machs mit Mint und lass mir das Logcat via ADB jit auf die Platte schreiben, in dem Moment wo der Mist losging schrieb er nichts mehr.

maniac103 schrieb:

Na dann her mit dem Logcat

Zum Vergrößern anklicken....

Hab /data dann formatiert und mir meine 15 Apps dann einfach aus Titanium wieder geholt. Ich bin keiner der dann 6856845 Apps und 168451 Spieleständen hinterherweinen muss

Ich hab mir aber ein CWM Backup gemacht um dem Fehler doch nochmal nachgehen zu können wenn das sich das wiederholen sollte.

@maniac103: und was ist dann der Vorteil wenn dynamic fsync enabled ist?

Die Version vom 06.10.13 läuft bei mir seit 18 h ohne Deadlock. Das ist bisher die beste Version seit langem auf meinem Nexus. Hoffentlich bleibt das so.

Bin ich der einzige bei dem diese Version spürbar flüssiger läuft?

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App

NoNickFound schrieb:

Ja, ich weiß ja nicht wie ihr das macht aber ich machs mit Mint und lass mir das Logcat via ADB jit auf die Platte schreiben, in dem Moment wo der Mist losging schrieb er nichts mehr.

Zum Vergrößern anklicken....

Das ist ja klar. Interessant ist, was woher passiert ist.
Aber solange es jetzt wieder geht und du der einzige bist, bei dem das passiert ist, ist es wahrscheinlich erstmal egal

black_bottom schrieb:

@maniac103: und was ist dann der Vorteil wenn dynamic fsync enabled ist?

Zum Vergrößern anklicken....

Angeblich soll dann alles schneller werden, weil die (zeitaufwändigen) Flash-Schreibevorgänge gemacht werden, wenn der Bildschirm aus ist. Selber probiert habe ich das allerdings nicht - Grund: siehe oben.

Seit ich den CM Kernel wieder benutze habe ich Probleme mit dem WLAN, sporadisch verbindet er sich nicht und man kann sich auch nicht händisch verbinden. Habe eine Fritzbox 7390 am werkeln, hängt es damit zusammen das AVM sich nicht zu 100,0 % an den IEEE Standard hält?
Mein WRT4300 läuft mit openWRT, bis neulich hatte ich da noch keine Probleme festgestellt.

Ich habe alle paar Tage das Problem, dass das Handy plötzlich aus ist, kann aber nicht nachvollziehen an was das liegt. Es lässt sich dann nur starten indem ich den Powerbutton lange Zeit drücke. Im Moment bin ich auf der Nightly vom 06.10 (kein custom kernel oder so), ist aber auch schon vorher aufgetreten. Ich habe auch vor ein paar Wochen ein Austauschgerät von Google erhalten, kann also auch einen Hardware Defekt nicht ausschließen. Vielleicht kann jemand was mit der last_kmsg anfangen, sofern die brauchbar ist, habe ich direkt kopiert nachdem ich das N4 wieder gestartet habe. Vielen Dank im Voraus.

@NoNickFound

Ich hatte das auch 2x, da ist mein Handy komplett eingefroren und es musste das ausschalten forcieren. Danach war auch Bootloop. Mit wipe dalvik/cache kam dann auch die Meldung, dass Apps aktualisiert werden und bei "Starten von Apps" hing es dann wieder.

Ich weiß nur nicht ob das am ROM oder am Kernel lag. Beim 1. Crash weiß ich nicht mehr was lief. Beim 2. Crash vorgestern hatte ich auf jeden Fall Hells Kernel. Welchen Kernel hattest du laufen? Will jetzt nicht sagen, daß Hells Kernel Schuld ist, vielleicht liegts auch an CM.

Die nightly vom 05. läuft mit Hells B39-cm-t16 sehr gut. Keine Reboots, keine Deadlocks und gefühlt läuft die Rom mit dem Kernel sehr flüssig. Kein Grund zu Klage...

Lupus schrieb:

Welchen Kernel hattest du laufen? Will jetzt nicht sagen, daß Hells Kernel Schuld ist, vielleicht liegts auch an CM.

Zum Vergrößern anklicken....

Ich hatte den CM Kernel laufen und dann kam über nacht der Franco r189, ich hab mich gefreut das ich wieder TouchControl unter CM verwenden kann und hab das Teil ohne viel mitzudenken blinklinks geflasht. Das er nicht startet hab ich erst stunden später gemerkt als es in der Tasche warm wurde und er immer noch mit dem besagten starten der Apps beschäftigt war.

Ich war vom Nexus zu verwöhnt und hab mir wenn ich Lust hatte immer Updates gezogen, zwar nicht regelmäßig aber wenn ich Lust und Zeit hatte. Vorher habe ich gehandelt wie man es in der Schule/Studium lernt: never change a running system.
Ich bin jetzt wieder auf dem Stand von vor ein zwei Wochen mit einem alten Franco, so funktioniert das TC das ich so liebe und solange mich keine Bugs einschränken wird das sehr wahrscheinlich auch lange lange laufen bis CM mit interessanten neuen Funktionen lockt.

hallo
wollte mal wieder auf die neuste nightly flashen.
habe jetzt von eurem problem mit dem kernel gelesen.
da ich auch einen anderen kernel benutze bin ich jetzt unsicher....
weiß jemand ob es mit dem hells-core kernel probleme gibt?