[Kernel] G3Mod by g3mod-team

[mankokoma]

Ich wollte eigentlich wissen, ob das i5801 Leuchtdioden[...]

ich habe irgendwo gelesen, dass das i5801 diese Leuchtdiodenschalter hat - egal

[...]scheint diese "Data.tar" nicht mit der JPU-Firmware erstellt [...]

meinst Du data.img? Wird bei mir anstandslos erstellt - vielleicht ist Dein Dateisystem fehlerhaft. Das kannst Du in der Datei /g3mod.log sehen.
Um das Dateisystem zu reparieren habe ich schon mal folgendes geschrieben:
Reparatur Dateisystem auf englisch
Dann sollte es auf jeden Fall gehen - egal welches Dateisystem.
Warum eigentlich rfs? Soweit ich gelesen habe, ist das von Samsung selbst entwickelt worden und ist sch schlecht.
Also ich habe nach viel Experimentieren:

• /system ext2 (ist schneller im lesen und mehr macht man auf system normal nicht)
• /data ext4 (ist etwas langsamer im lesen, schreibt dafür aber schneller)
  genauso auf sdext (mmcblk0p2) Allerdings habe ich journaling abgeschaltet - birgt gewisse Risiken...
• /cache ext2 (weil ich da mehr Batterieverbrauch mit ext4 hatte - warum auch immer)

Das jfs, das der Kernel jetzt auch kann, habe ich noch nicht ausprobiert, da habe ich noch einige Zweifel, dass das sinnvoll ist auf unseren Geräten. Ist wohl doch eher was für große Server. Hat auf Dauer Probleme mit Fragmentierung und ich weiß noch nicht, wie das bei uns gelöst werden soll.
Also bleibe ich nun da, wo ich die besten Erfahrungen gemacht habe...

 

[Michael M.]

Danke für den Link zur Reparatur. Werd ich mir heut abend zu Gemüte führen.
Warum rfs? Frag Samsung... Ich hab ja die JPU drauf und da war Step1 erstmal die Daten-Partition in ext2 umzuwandeln.
Die data.img? wird auch bei mir erzeugt, jedoch die Erstellung der *.tar scheitert, aber da muss ich ja nur die multios-Datei entfernen.

Die ext2/ext4/ext2(system/data/cache)-Kombo ging gar nicht bei mir... Weiß nicht mehr was alles die Probleme waren und ob's überhaupt noch gebooted hat. Hab dann neu geflashed und obige Partitionierung eingeleitet.

Aber da passt doch jetzt meine generelle Frage ganz gut. Angenommen ich will die Partitionen zu ext2/ext4/ext2 konvertieren lassen. Wie gehe ich da genau vor. Das einfachste ist ja die fs.convert-Datei unter /sdcard/Android/data/g3mod/ zu erstellen. Sähe ja so aus (Leerzeile am Ende ist drin):

stl6 ext2
stl7 ext4
stl8 ext2

Ab da wird's dann schwammig. Passiert die Konvertierung beim normalen Rebooten des Phones? Passiert die Konvertierung wenn ich in's Recovery boote oder erst danach?
Müssen die Partitionen gemounted sein? Muss ich sie vorher "formatten", also nicht wipen, sondern im Menü "Mounts&Storage" format xxxx auswählen?
Etc. pp.

Wie macht man's zu 100% sauber?`
Dennoch besten Dank für die tollen Anleitungen hier und im xda-Forum!!!


EDIT: Falls das jemand weiß: Spielt das Filesystem auch beim Thema deodexing eine Rolle? Im weitesten Sinne? Hab seit dem deodexing z.B. den "Device Manager", der nach Reboots immer "unerwartet beendet" wird. Aber soll mal nur am Rande das Thema sein, da es ja auch nur angrenzend was mit dem G3-Kernel zu tun hat. Ich versuch mich da auch noch selbst dran das in den Griff zu bekommen, aber vielleicht weiß da ja jemand Bescheid bei der Gelgenheit.

 

[mankokoma]

jedoch die Erstellung der *.tar scheitert[...]

Sorry, jetzt schnall ich erst, was Du meinst... Also bin mir jetzt nicht ganz sicher, ob wir aneinander vorbei reden. Ich war davon ausgegangen, dass Du das "normale" backup aus dem CWM meinst. Du meinst aber das Backup von "multiboot", stimmts?
Also die TAR-Datei wird in /sdext/multios/ erzeugt und dann je nach Wechsel zu CM7 oder FROYO wieder verwendet. Das aber auch nur, wenn die Datei "multiosdata" im /sdcard/Android/data/g3mod Verzeichnis vorhanden ist. Geht aber auch bei JPU ohne Probleme - ist ja nur vom Kernel abhängig, egal welches Grundsystem.

[...] Passiert die Konvertierung beim normalen Rebooten des Phones?[...]

Die Konvertierung passiert beim normalen booten, nachdem Du die fs.convert in /sdcard/Android/data/g3mod angelegt hast.
Bei den neueren Kernels kann das Gerät dabei hängen bleiben. Warte dann einfach ~10 Minuten und starte dann neu (Power lange drücken oder Akku raus), wenn das passiert... Beim nächsten Start ist alles konvertiert.

[...] Spielt das Filesystem auch beim Thema deodexing eine Rolle?[...]

Ich denke nicht... Was bei so einem Quatsch meistens hilft, ist wipe cache, wipe Dalvic cache... wenn das nicht hilft, die App komplett deinstallieren und neu installieren

 

[Michael M.]

Sorry, jetzt schnall ich erst, was Du meinst... Also bin mir jetzt nicht ganz sicher, ob wir aneinander vorbei reden. Ich war davon ausgegangen, dass Du das "normale" backup aus dem CWM meinst. Du meinst aber das Backup von "multiboot", stimmts?

Ja und Nein. Ich dachte bisher auch, dass die tar beim Multi-Boot-Backup erstellt wird, aber die Fehlermeldung (error while creating data.tar oder ähnlich) erschien beim Erstellen eines "normalen" Backups. Da scheint die tar also wohl auch erstellt zu werden.


----------------------------------------------------------------------------------
----------------------------------------------------------------------------------

Zu der ganzen Thematik hab ich 2 Top-Anleitungen von Mankokoma auf Xda gefunden. Da wären:

- HOWTO: optimize filesystems, darin enthalten HOWTO: Complete disabling of journaling und
- problems with my filesystems (und wie man dann beim Konvertieren vorgeht)

Echt klasse die beiden Posts!

 

[mankokoma]

Habs mir nochmal angeschaut.
Also beim normalen CWM backup wird das ganze unter /sdcard/clockworkmod/backup/[datum]/*.img gespeichert. Aber nur da. Da wird keine TAR-Datei angelegt...

Beim Backup von multiboot wird system.img im Ordner /sdcard/Android/data/g3mod/roms/[ausgewählte]_ROM/ gespeichert. Keine TAR-Datei.

Die Dateien data.img & sd-ext.img werden in /sdcard/Android/data/g3mod/data/Froyo_data/ gespeichert, wenn man die Option backup Froyo-Data angibt (weiß jetzt nicht, wie die genau heißt und kann jetzt auch nicht schauen, weil ich vorhin gerade Batterie kalibrieren gemacht habe).... Jedenfalls auch hier keine TAR-Datei...

Die TAR-Dateien in /sdext/multios/ werden nur angelegt, wenn man zwischen CM6/7 und Froyo hin und her wechselt.
Deswegen verwirrt mich Deine Fehlermeldung so.... kann mir das eigentlich nur so erklären, dass in der Fehlermeldung data.img stand und beim Erstellen eben ein Fehler entstanden ist, weil...
- Karte voll...
- Dateisystem beschädigt...
- weiß ich auch nicht...
Vielleicht stand da ja auch wirklich was von TAR, kann ich mir aber dann überhaupt gar nicht erklären

 

[Michael M.]

Ach so ne Fehlermeldung bleibt beim Coden so schnell im Copy&Paste mal hängen und wird dann in einem Abschnitt ausgegeben, wo Sie gar nicht hingehört.

 

[quatschkopf]

2.2.2 is up

 

[hermez]

G3MOD v2.2.2:
Downloads - g3modteam - G3MOD Kernel for the Galaxy 3 - Google Project Hosting
mit neuer lights.GT-I5800.so für die mit den Leuchtdioden Schaltern.

EDIT: Was ich noch erwähnen sollte: die lights.GT-I5800.so sollte man auf jeden Fall in /system/lib/hw hinein kopieren (oder mit update.zip installieren), acuh wenn man nicht das I-5801 hat. Ich habe immer das Problem, dass der Bildschirm nicht mehr angeht, wenn ich die Datei nicht installiert habe

Ja^^

 

[Michael M.]

Also hinsichtlich Filesystems ist bei mir jetzt endlich alles sauber. Hab allerdings nochmal neu die JPU geflashed mit meiner bereits modifizierten factory.fs und bin dann nach Anleitung vorgegangen.

Seltsamerweise hatte und habe ich immer noch das Problem, dass ich keine ADB-Verbindung zum Phone aufgebaut bekomme, wenn ich im CWM bin. Hab schon die unterschiedlichsten Weisen ausprobiert in's CWM zu booten, aber laut ADB ist mein "device offline".

Was ist da der Grund für und was kann/muss ich machen, um im CWM wieder 'ne ADB aufzubauen?

 

[mankokoma]

Also hinsichtlich Filesystems ist bei mir jetzt endlich alles sauber. Hab allerdings nochmal neu die JPU geflashed mit meiner bereits modifizierten factory.fs und bin dann nach Anleitung vorgegangen.

Seltsamerweise hatte und habe ich immer noch das Problem, dass ich keine ADB-Verbindung zum Phone aufgebaut bekomme, wenn ich im CWM bin. Hab schon die unterschiedlichsten Weisen ausprobiert in's CWM zu booten, aber laut ADB ist mein "device offline".

Was ist da der Grund für und was kann/muss ich machen, um im CWM wieder 'ne ADB aufzubauen?

Ja, nervt mich auch...
Meine Lösung: Das Teil "normal" booten bis man die adb shell bekommt und dann sofort "reboot recovery" - dann erkennt der PC auch das Phone wieder im CWM - seltsam...

 

[mankokoma]

Der gute HILLBEAST hat mal wieder Tolles geleistet und eine light*.so rausgegeben, die das ganze BLN für die LED-Losen Telefone abschaltet. So ist das Batterieverbrauchsproblem gelöst und trotztdem die Verwaltung der Hintergrundbeleuchtung gewährleistet.
Er hat die Datei in seinem letzten Update für KYORAROM integriert, die man unter xda-developers - View Single Post - [ROM] Kyorarom Infinity (v0.4.1 - JPU Based)
ganz oben udpate Infinity (v0.4.1) bekommt.
Da muss man aus dem ZIP die Datei /system/lib/hw/lights.s5p6442.so ins entsprechende Pendant auf dem Telefon kopieren und alle anderen Dateien, die *lights* im Namen haben löschen...
Habe schon angefragt, ob ich ein Update.zip für CWM machen darf...

 

[barthezz]

und trotztdem die Verwaltung der Hintergrundbeleuchtung gewährleistet....

was meinst du denn damit?

 

[mankokoma]

was meinst du denn damit?

ich hatte einfach das problem, dass bei mir nach deep sleep der bildschirm dunkel blieb, wenn ich die lights*.so datei nicht installiert hatte. also hatte mein telefon sinnloserweise die BLN funktion, obwohl ich gar keine leuchtdiodentasten habe.

 

[Michael M.]

Also bereits am Dienstag kam ein Update für den Busybox Installer:

What's in this version:
Updated Busybox to include basename, this should help with Clockwork Recovery.
This change affects 1.18.4, 1.19.2, 1.19.3

Zwischendurch ging's mal bei mir, aber dann auch ganz schnell wieder nicht. Aber im XDA ist das ja auch Thema, also da kommt sicher bald was.


Mankokoma, was war da genau bei dir für ein Problem, als du die alten Update-Zips genommen und die neuen Inhalte eingefügt hast? Das war doch auch das, wenn ich's richtig verstanden habe.
Allerdings auch in einer deiner Anleitungen gelesen, dass du den Kernel mit der Tar flashen musstest, weil das Zip nicht ging.
Wat war denn da alles? Vielleicht komm ich so drauf woran's bei mir liegen könnte...

 

[mankokoma]

Also bereits am Dienstag kam ein Update für den Busybox Installer:
Zwischendurch ging's mal bei mir, aber dann auch ganz schnell wieder nicht. Aber im XDA ist das ja auch Thema, also da kommt sicher bald was.

Weiß nicht so genau, was du meinst. Wegen der adb shell im CWM? Hat daaamit glaub ich nix zu tun... Busybox ist ja nur ein Programm, in dem die "üblichen" Unix/Linux Befehle implementiert und ver-symlinked sind.

Mankokoma, was war da genau bei dir für ein Problem, als du die alten Update-Zips genommen und die neuen Inhalte eingefügt hast? Das war doch auch das, wenn ich's richtig verstanden habe.
Allerdings auch in einer deiner Anleitungen gelesen, dass du den Kernel mit der Tar flashen musstest, weil das Zip nicht ging.
Wat war denn da alles? Vielleicht komm ich so drauf woran's bei mir liegen könnte...

Eigentlich gab es nie ein Problem mit den Kernel(?)update.zip's. Worauf Du Dich hier höchstens beziehen kannst, ist, dass als ich CM7 das erste Mal installiert habe, der Fugumod-Kernel dabei war. Da hat es nicht funktioniert mit dem Update.zip den G3MOD über den Fugumod zu bekommen. Da hat nur ODIN geholfen. Ansonsten kein Problem. Hillbeast hatte sich nur geweigert, seine Testkernel als update.zip's rauszugeben, damit nicht irgendwer irgendwo in der Botanik weit weg von einem PC sitzt, beim fläschen was schief läuft und er nicht mal mehr ein CWM hat, ums wieder richten zu können.

 

[Michael M.]

Ich hab leider keine Ahnung wie die Busy-Box da mit reinspielt, aber nach nem Update auf ne neuere Version ging's einmal....
Ach, ich bin jetzt eh voll durch von der Sucherei nach Lösungen... Das kann bis zu nem Update von was auch immer dann warten. Sind nur sekundäre Sachen, die ich da machen/ausprobieren wollte.
Aber Danke! Die Posts im Xda haben auch weitergeholfen beim Verständnis.

Z.B. kann die System-Partition nicht mehr geunmounted werden. Also hat sich jemand ein Script gebaut, der das System noch vor dem Start des CWM-Recovery unmounted und schon funktionierts...

 

[mankokoma]

Da ich gerne auf überflüssige umfangreiche Software (in diesem Falle SetCPU) verzichte, habe ich ein kleines Script geschrieben, das von /etc/init.d aus beim Booten gestartet wird und den Governor bei Ausschalten des Bildschirms von LAGFREE bei max. 800 MHz auf ONDEMAND bei max. 400 MHz umschaltet. Habe ich ein paar Tage lang getestet, für gut befunden und bei XDA hochgeladen:
xda-developers - View Single Post - [KERNEL][HYBRID]G3MOD v2.2.2

 

[paul28]

hallo
ich wollte gerade nach der anleitung von hillbeast ([GUIDE] How To Convert ODIN Tars to System.imgs for CWM - xda-developers) aus der ics-tar-datei eine system.img für multiboot machen.
Nach vielen Versuchen bin ich auch bis zum 6. Schritt gekommen. Was adb da rausgespuckt hat, habe ich nicht wirklich verstanden und habe einfach den befehl für den 7. Schritt reinkopiert.

1. Check for that loopback devices are available:
   Code:
   losetup -a
   If nothing shows up then you don't need to worry
2. Using the first available loopback device (ie if nothing showed up, loop0, or if the highest that showed up was 6 then use loop7), attach the factoryfs.rfs to the loopback device.
   Code:
   losetup /dev/loop0 ~/Desktop/factoryfs.rfs
   You may notice the file system show up in your file manager.

Da kam dann aber:

# losetup -a
losetup -a
losetup: invalid option -- a
BusyBox v1.19.3-Stericson (2011-11-01 20:22:18 CDT) multi-call binary.

Usage: losetup [-o OFS] LOOPDEV FILE - associate loop devices
        losetup -d LOOPDEV - disassociate
        losetup [-f] - show

        -o OFS  Start OFS bytes into FILE
        -f      Show first free loop device

# losetup /dev/loop0 ~/Desktop/factoryfs.rfs
losetup /dev/loop0 ~/Desktop/factoryfs.rfs
losetup: /dev/loop0: No such file or directory

in meiner unendlichen ignoranz habe ich einfach alle meldungen ignoriert und weiterkopiert aber da kam nichts raus.
Also nach dem, was ich daraus schließe, ist eine benötigte datei, \dev\loop0, nicht vorhanden. Was soll ich jetzt machen?

ich hoffe, die etwas erfahreneren von euch können mir helfen
schonmal danke im vorraus

paul

 

[mankokoma]

einfacher ist (als root auf linux-pc):

mkdir /pfad/zum/mountpoint 
mount -o loop /pfad/zur/factory.rfs /pfad/zum/mountpoint

Das Telefon bleibt außen vor. Das hat nix mit adb zu tun.

 

[paul28]

einfacher ist (als root auf linux-pc):

mkdir /pfad/zum/mountpoint 
mount -o loop /pfad/zur/factory.rfs /pfad/zum/mountpoint

Das Telefon bleibt außen vor. Das hat nix mit adb zu tun.

und bei windows?