Base Lutea OFW 2.1 und Möglichkeiten

Hallo,

ich habe ein gerootetes Base Lutea mit OFW 2.1 und möchte den Root-Zugriff maximal ohne CFW ausnutzen. Dazu habe ich einmal ein paar Fragen.

1. Ich habe zwar Ahnung von Linux stehe aber bei Android manchmal etwas doof da, man muss schon wirklich umdenken. Link2SD funktioniert zufriedenstellend bei mir. Ich stehe aber nicht so auf Extra-Apps und mache mir gerade Gedanken wie man das besser und auf System-Ebene hinbekommt. Ich würde gerne selber symbolische Links erstellen (sind die bei Link2SD eigentlich hard oder soft?) und zwar würde ich gerne /data/apps generell auf meine ext2-Partition mounten. Wäre das mit der OFW möglich? Den internen Speicher würde ich dann erst einmal für den Dalvik-Cache und den /data/data Daten lassen.

2. Hat der Kernel der OFW den eigentlich die Möglichkeit eine SWAP-Partition zu mounten? Netfilter hat der OFW-Kernel ja zum Beispiel definitiv nicht. Falls der Kernel der OFW Swap-Partitionen ermöglicht, würde ich mich über eine Anleitung wie ich diese permanent einhänge, freuen. Laut mount ist sie nicht eingehängt.

3. Wie sieht es beim Recovery-Modus der OFW aus? Wie kommt man dahin und wie steuert man diesen Recovery-Modus? Per QuickReset war ich schon mal drin, konnte aber keinen Menüpunkt auswählen.

4. Ich würde gerne /system besser ausnutzen. Also momentan move ich gerade einige System-Tools dahin. Ich finde den ungenutzen Speicher nur schade und deshalb kommen da wirklich nur Tools rein die nicht unbedingt mit dem Market geupdatet werden müssen und nicht per Link2SD auf die SD kommen müssen.

5. Welche Apps(apks) oder Linux-Tools(bin) kann ich bei der OFW nachrüsten ohne auf eine CFW zu wechseln?

Also es geht hier wirklich nur um die OFW und nicht um CFWs und ich scheue mich euch nicht davor alles in einen Terminal-Emulator einzugeben. Ich möchte nur soweit wie möglich nur per root-zugriff Möglichkeiten nutzen und nicht auf CFWs switchen.

Ich werde mir bald eine 8 GB Class 6 oder Class 10 zulegen und würde vor dem partitionieren, wissen ob ich Swap-Partitions nutzen kann und /data/app generell auf die ext2-Partition linken kann.

Wie gesagt Alle FAQs und Posts drehen sich meistens um die CFWs und bei der OFW sind einige Systemprogrammen und Kernel-Funktionen nicht vorhanden und deshalb für mich so nicht praktikabel. Ich bin aber der Meinung das viel auch mit der OFW möglich ist und hoffe das dieser Post eine Anlaufstelle für gerootete OFWler wird.

Thx
CyberPunkBln

Hi Chris,

dank Dir für Deine Antworten. Inzwischen steige ich immer tiefer ins System ein und habe bereits erfolgreich eine native App2SD-Ext2 (Wie ich das mal nenne) Installation hinter mir. Ich habe einfach, da ich noch nicht so einhundertprozent (pushen und pullen per adb ist nicht so meine sache um shell-skripte komfortabel auf meinem Linux zu editieren) im System (Linux/Kernel) durchsehe einfach mal init-recovery.sh von Link2SD für eine mount-anweisung mißbraucht. Ich nehme mal einfach an, das klassischerweise alle mit init beginnenden Skripte als Startskripte durchlaufen werden. Und was bei Link2SD per symbolic link zeitktitisch okay ist, sollte dann auch für so eine Mount-Anweisung okay sein.

Ich sehe aber die Begrifflichkeiten bringen mich etwas durcheinander. Man muss schon arg umdenken bevor man selbst als Linux-Experte voll damit klar kommt, aber inzwischen geht es einigermaßen.

Recovery-Image ist mir inzwischen klar. Ist ein alternatives "Bios" um mehr Möglichkeiten zu haben beim booten und alle anderen Images sind halt die Partitionen von der internen SSD (naja so lahm wie die beim Base Lutea ist nehme ich mal an, das ist en normaler und preisgünstiger Flashspeicher).

ROM ist für mich immer noch ein Read Only Memory und kein Image von einer Partition auf einem Flashspeicher.

Schon ein stranges aber aufregendes Gesamtkonzept, was Google da zusammengepackt hat. Gefällt mir und regt an zum weiterforschen.

Ich denke mal alle meine weiteren Fragen zum Kernelreplacement oder andere Anpassungen gehen über das raus, was man hier im Root-Forum bringen sollte. Also am besten von mir noch eine Zusammenfassung was man Alles als Root auf einem Stock-ROM (von mir vor Tagen noch Orginal Firmware (OFW) genannt) machen kann und was man minimal brauch oder kann um sein System optimal zu handeln.

1. Recovery-Image (ClockWorkMod_Blade)
2. mciroSD Partitionieren mit ext2 und nutzen der Partitionen für sämtliche Verzeichniss auf dem Daten und Systemspeicher. Nützlich nur für /data/app, /data/data, /data/dalvik-cache (Class 2 sollte erst einmal ausreichen)
3. Keine Nutzung mit dem originalen Stock-Kernel des Swap-Speichers möglich. Mir ist keine Möglichkeit bekannt Swap per Kernel-Module nachzuladen.
4. Anpassung sämtlicher Stock-Inis des Linux-Kernels und des Android-Dalvik-Kerns
5. Keine Nutzung des Netfilter-Moduls für WiFi-Tehering
6. Im Prinzip Alles was man mit dem Stock-Kernel machen kann.

Fragen zu Custom Firmwares und mögliche Stock-Kerneländerungen stelle ich dann in einem anderen Forum.

Die Änderungen an der boot.img werde ich übrigens bald ausprobieren, das mounten per init-Recovery.sh ist mir bezogen darauf das die SD so partioniert Alle Installationen und Restores überleben soll zu unsicher. Nachdem ich das /dev/-Prinzip kapiert habe sollte es relativ schnell gehen.

Gruß
CyberPunkBln

PS: Wieso brauch dieses Forum JavaScript zum posten???

Hi,

kurz noch einmal ne Frage. Das Recovery-System bindet ja nicht die boot.img ein oder? Die /etc/fstab sieht so aus also ob es die Datei der Recovery.img wäre und nicht die Datei der boot.img? Im Recovery-Menü kann ich die Boot-Image ja nicht mounten?

Laut mount im Android-System stimmt diese Mount-Table nicht mit der von der Recovery-Shell überein. /etc/fstab gibt es auch im Android-System nicht. Komisch. Vielleicht der letzte Stein für mich im Gesamtpuzzle.

thx
CyberPunkBln

Hi Chris,

yoah die gute alte fstab wird nicht mehr benutzt, heul. Nein klingt logisch bei einem Plug and Play Smartphone-OS. Wie gesagt mich nervt push und pull und das man in der recovery keinen richtigen editor hat, muss ja kein nano sein, hätte mich seit Jahren wiedermal mit vi angefreundet oder auch urrgs mit ed. Nunja also war ich in der install-recovery.sh schon garnicht mal so falsch. Ein Skript als Device fürs mounten zu nutzen damit hatte ich noch nix zu tun, aber wie gesagt ist ja ein Smartphone-OS und da sollte vieles automatisch gehen. Hatte oft die Boot-Schleife als Fehler weil ich falsche Block-Devices gemountet hatte oder Android sagt mir "Alles Formatieren Du Idot hast wohl ne komsiche microSD drin",lach.

Tja ich will erst einmal zufrieden sein mit meinem Root-Access und meiner nativen App2Ext2 Lösung und den Stock-Kernel mal so in Ruhe lassen, ein Nadroid-Backup machen und dann mal schauen wie ich weitermache. Lach wollte eigentlich nur ein kostengünstiges Smartphone mit Android und nachdem ich den internen Speicher hab schrumpfen sehen mache ich anstatt Augemnted Reality und Mobile Internet nen Recovery-Restore,lach.

Kann meinen Post also abschließen mit: ClockWorkMod_Recovery-Image,Root und App2Ext2 und gut beim Stock-ROM.

Dank dir nochmal Chris, bist ja momentan der einzigste der mir auf meine Post antwortet.

Gruß
CyberPunkBln