Custom Firmware von zx128 - unslaved

Temar schrieb:

Wenn man Apps2Sd mit deinem Rom verwendet, wird da beim booten in irgendeiner Form ein fsck ausgeführt?

Zum Vergrößern anklicken....

Hast du das aus Cyanogen-Mod?

Hab mich jetzt etwas informiert.
Der Standard-ROM macht das scheinbar nicht und da unslaved auf dem basiert - auch nicht.

Ich werde mir das bei cyanogen anschauen und wenn dafür keine Binaries neu kompiliert werden müssen - in unslaved aufnehmen.

zx128 schrieb:

Hast du das aus Cyanogen-Mod?

Zum Vergrößern anklicken....

Ne, nicht wirklich. Bei meinem Rechner stand beim Booten gerade mal wieder ein fsck an. Da ist mir das so in den Sinn gekommen.

Hab mich jetzt etwas informiert.
Der Standard-ROM macht das scheinbar nicht und da unslaved auf dem basiert - auch nicht.

Zum Vergrößern anklicken....

Das Standard-Rom sollte das auch nicht wirklich benötigen, da es das YAFFS filesystem benutzt, dieses ist (neben dem fokus auf flash-speicher) auf eine hohe daten-integrität optimiert.

Ich werde mir das bei cyanogen anschauen und wenn dafür keine Binaries neu kompiliert werden müssen - in unslaved aufnehmen.

Zum Vergrößern anklicken....

Ich fürchte, dass dafür extra binaries benötigt werden. Das einzige fsck das ich finden konnte gammelt unter /system/xbin/bb/ rum. Normalerweise ist fsck aber aufgeteilt in mehrere Binaries - für jeden FS-Typ eine eigene Version.

Temar schrieb:

Ne, nicht wirklich. Bei meinem Rechner stand beim Booten gerade mal wieder ein fsck an. Da ist mir das so in den Sinn gekommen.

Zum Vergrößern anklicken....

Verstehe. Habe eben danach gesucht und gefunden, dass cyanogenMod das macht.

Wollte schon cyanogen ausprobieren habe aber rechtzeitig entdeckt, dass da keine Paid-Apps gehen - will ich so nicht.

Temar schrieb:

Das Standard-Rom sollte das auch nicht wirklich benötigen, da es das YAFFS filesystem benutzt, dieses ist (neben dem fokus auf flash-speicher) auf eine hohe daten-integrität optimiert.

Zum Vergrößern anklicken....

Leuchtet ein.

Temar schrieb:

Ich fürchte, dass dafür extra binaries benötigt werden. Das einzige fsck das ich finden konnte gammelt unter /system/xbin/bb/ rum. Normalerweise ist fsck aber aufgeteilt in mehrere Binaries - für jeden FS-Typ eine eigene Version.

Zum Vergrößern anklicken....

Habe mich wahrscheinlich unglücklich ausgedruckt.

Neue Binaries aufzunehmen - damit habe ich kein Problem.

Was ich bei unslaved nicht machen will - in die "offiziellen" Komponenten eingreifen:
Kernel ersetzen, init neu erstellen etc.

Solange es nur darum geht neue Files zu integrieren und/oder Konfig (wie init.rc) zu verändern - bin ich immer dabei.

@all:

Ich denke viele verstehen nicht, warum ich mich so anstelle.

Hatte schon im Blog ein Flame erleben müssen, warum ich denn Apps2SD gemacht habe, aber das API-Framework nicht verändern will.

Das ist genau der Grund:
ich will Neu-Kompilierungen vermeiden, denn ich nicht weiß, was für Sourcec T-Mobile für ihre Builds nimmt und was die damit genau machen.

Und einfach so Sources von source.android.com ziehen und sagen: "Es wird schon passen, ist ja auch Android" - das will ich nicht.

Ist bei der unslaved Version das OTA-Update abgestellt? Denn wenn ein neues Update kommt, könnte man im Terminal ja schneller an die Datei bzw. den Google-Link kommen.

Phantom-Lord schrieb:

Ist bei der unslaved Version das OTA-Update abgestellt? Denn wenn ein neues Update kommt, könnte man im Terminal ja schneller an die Datei bzw. den Google-Link kommen.

Zum Vergrößern anklicken....

OTA ist nicht abgestellt. Es sollte so ablaufen, dass das Update-File downgeloadet wird, aber nicht aufgespielt werden kann.

Leider konnte ich bisher das nie ausprobieren, da die Verteilungspolitik von OTA so toll ist (vlt. auch nur bei mir)

Ich habe mal auf RC7 geflasht und extra 1,5 Wochen gewartet - nix da, kein OTA, gar nichts.

Ich habe mir jetzt noch das unslaved_recovery installiert.
diesen Schritt konnte ich durchführen:
diesen nicht:

EDIT:
Wenn ich mit POWER+HOME den recovery-Modus starte, wird mir die unslaved-Version angezeigt.

Phantom-Lord schrieb:

Ich habe mir jetzt noch das unslaved_recovery installiert.
diesen Schritt konnte ich durchführen:

Code:

[I]flash_image recovery /pfad/zu/unslaved/recovery/image[/I]

diesen nicht:

Code:

[I]cat /pfad/zu/unslaved/recovery/image > /system/recovery.img[/I]
write: No space left on device

EDIT:
Wenn ich mit POWER+HOME den recovery-Modus starte, wird mir die unslaved-Version angezeigt.

Zum Vergrößern anklicken....

Wo kein Platz ist - da ist halt kein Platz.

Ne mal im ernst: die Infos auf der Webseite sind veraltet, sehe ich gerade.
Wenn du unslaved aufspielst - landet recovery.img unter /data, daher muss es nicht nach /system kopiert werden.

zx128 schrieb:

Verstehe. Habe eben danach gesucht und gefunden, dass cyanogenMod das macht.

Zum Vergrößern anklicken....

Ja, habe mir das cyanogen jetzt auch mal durchgelesen und gesehen, dass die mittlerweile ext3 verwenden. Das ist aber nur bedingt eine gute Lösung. Ext3 bietet zwar mehr Datensicherheit da es Journaling verwendet, schreibt dementsprechend aber auch mehr auf die SD, was zu einer kürzeren Lebensdauer führt. Da man ja in der Regel nur /app und /app-private auslagert ist das ganze eigentlich unnötig. Die Daten in diesen Ordnern werden ja nun nicht sooo häufig geschrieben.

Meiner Ansicht nach ist die bessere Lösung weiterhin bei ext2 zu bleiben. Allerdings sollten einige kleinere Änderungen gemacht werden. Zum einen habe ich mir die mount Optionen von dir mal angeschaut: Du mountest die Partition mit den Standard-Optionen, was bei flash Speichern eine ganz schlechte Idee ist. Ich habe bei mir mal die init.user.sh folgendermassen geändert:


Die Option "noatime" sorgt dafür, dass die Last-Access-Time nicht aktualisiert wird. Im Gegensatz zu Windows, merkt sich Unix nämlich für jede Datei, wann sie zuletzt angefasst wurde. Das betrifft sowohl das Schreiben (das macht Windows auch) als auch das LESEN! Im Klartext heisst das, dass jedesmal wenn du ein Programm startest die Last-Access Zeit aktualisiert wird. Für jeden Programmstart erhältst du also einen Lese- und einen Schreibzugriff. Die Option "noatime" verhindert dies und sollte dementsprechend für ein wenig mehr Performance und eine längere Lebensdauer der Karte sorgen.

Die Option "dirsync" sorgt dafür, dass Änderungen an den Verzeichnis Inodes direkt geschrieben werden. Das habe ich hinzugefügt um die Datensicherheit ein wenig zu erhöhen. Das ganze ist ein Kompromiss zwischen Datensicherheit und Langlebigkeit. Es gibt noch die Mount-Option "sync", welche dafür sorgt, dass ALLE Daten direkt geschrieben werden. Dies ist aber extrem schlecht für die Karte, da das Filesystem Schreibzugriffe dann nicht optimieren kann und somit wesentlich mehr Zugriffe benötigt werden um eine Datei zu speichern. Also habe ich das ganze auf Verzeichnis-Einträge beschränkt, die eigentlich nur neu geschrieben werden, wenn man ein Programm installiert/deinstalliert.

Was jetzt unbedingt noch gemacht werden muss, ist die Partition beim herunterfahren zu unmounten. Ich denke das Google das mit der normalen SD-Karten-Partition eh schon macht. Ich habe mal auf meinem Rechner einen fsck auf die Apps2SD-Partition gemacht und wie zu erwarten war, wurden einige Fehler gefixt. Die Daten-Partition hingegen war sauber. Das deutet darauf hin, dass Google zumindest diese Partition beim runterfahren schnell unmountet - alles andere wäre eigentlich auch zu fahrlässig.

Weisst du zufällig ob es ein shutdown-user.sh Script gibt in das man seine eigenen Änderungen reinschreiben kann? Falls nicht werde ich dein Rom mal entpacken und ein bisschen greppen. Unter Umständen muss man aber ein System-Shell-Skript editieren und dafür sorgen, dass die Partition sauber ausgeklinkt wird.

Der dritte Punkt wäre dann noch das fsck. Das werde ich demnächst bei mir auch mal reinbasteln.

Wollte schon cyanogen ausprobieren habe aber rechtzeitig entdeckt, dass da keine Paid-Apps gehen - will ich so nicht.

Zum Vergrößern anklicken....

Sehe ich genauso.

Habe mich wahrscheinlich unglücklich ausgedruckt.

Neue Binaries aufzunehmen - damit habe ich kein Problem.

Was ich bei unslaved nicht machen will - in die "offiziellen" Komponenten eingreifen:
Kernel ersetzen, init neu erstellen etc.

Zum Vergrößern anklicken....

Um Apps2SD wirklich *sauber* verwenden zu können, muss vermutlich ein shutdown skript angepasst werden. Das wäre dann aber nur eine Zeile und das betrifft ja auch nicht den Startvorgang. Leute könnten dann immernoch den Akku ziehen falls das G1 nichtmehr runterfährt.

So wie das mit dem Apps2SD im Moment gehandhabt wird ist das aber eine Gratwanderung. Ohne ein sauberes umount ist es ein reines Glücksspiel ob die Partition beim nächsten Booten noch gelesen werden kann. In den meisten Fällen geht das gut, da Schreibzugriffe ja nur sehr kurz sind. Schaltet man aber im falschen Moment aus, war's das mit Apps2SD.

ich will Neu-Kompilierungen vermeiden, denn ich nicht weiß, was für Sourcec T-Mobile für ihre Builds nimmt und was die damit genau machen.

Und einfach so Sources von source.android.com ziehen und sagen: "Es wird schon passen, ist ja auch Android" - das will ich nicht.

Zum Vergrößern anklicken....

Bin da absolut auf deiner Seite. Stabilität geht vor! Das Ding ist primär immernoch ein Telefon und das muss sauber funktionieren. Die meisten Community-Roms schiessen weit über's Ziel hinaus. Wenn ich schon lese, dass Paid-Apps nicht mehr funktionieren - wiedermal ein Fall von totgepatcht.

Paid-Apps gehen schon, aber Protected apps funktionieren nicht. Ist aber dasselbe wie bei der ADP Version.

Moin,

kann mir einer von euch die boot.img und die recovery.img nach dem neusten update (crc1) von unslaved uppen ??

MfG Kanty2ka

@Temar

Danke für die Infos, ich werde ein Teil davon nutzen.

Was umount beim shutdown/reboot angeht:

auf Anhieb fand ich keine Stelle, wo das System die FAT-Partition umountet,
daher kann ich mich mt der EXT2 da nicht einklinken.

Seit 1.5 verwenden die übrigens vold anstatt von mountd um die FAT zu mounten.

Google schweigt sich zum Thema "android shutdown" auch aus.

Ich werde wohl nicht umhin kommen, den gesamten Shutdown-Prozess im Android-Source durchzugehen.

Werde ich aber machen müssen, da umount wirklich kritisch ist.

zx128 schrieb:

Was umount beim shutdown/reboot angeht:

auf Anhieb fand ich keine Stelle, wo das System die FAT-Partition umountet, daher kann ich mich mt der EXT2 da nicht einklinken.

Zum Vergrößern anklicken....

Tatsächlich - hab mir auch grad mal die Android Sourcen gezogen und ein wenig gegreppt. Ist auf jedenfall nicht so straight forward wie ich mir das gedacht habe. Ich würde mal beim init-Prozess mit der Suche anfangen. Der ist zumindest unter normalen Linux-Systemen auch für den Shutdown zuständig. Bin leider ab morgen früh im Urlaub, sonst würde ich dir helfen.

Seit 1.5 verwenden die übrigens vold anstatt von mountd um die FAT zu mounten.

Zum Vergrößern anklicken....

Falls der vold für den umount zuständig ist, kann man die Apps2SD Partition vielleicht einfach mit in das vold Config-File reinschreiben und ihm auch das mounten überlassen. Allerdings muss man dafür sorgen, dass der vold die Partition dann nicht unmounted, wenn das G1 am PC bereit gestellt wird.

Ich werde wohl nicht umhin kommen, den gesamten Shutdown-Prozess im Android-Source durchzugehen.

Zum Vergrößern anklicken....

Das kann eigentlich nicht so wild sein. Die data Partition wird bestimmt auch ausgeklinkt, da zwar die hohe Datenintegrität von Yaffs2 schön und gut ist, das aber noch lange nicht garantiert, dass nicht noch ungeschriebene Daten im Cache sind. Ob ich jetzt ein sync mache oder die Partition sauber unmounte gibt sich nix. Daher gehe ich mal davon aus, dass Google alle Partitionen, die rw-gemounted sind auch unmounted.

Damit der unmount klappt muss man aber erstmal dafür sorgen, dass keine Datei-Handles mehr offen sind, d.h. alles beenden was irgendwie auf die rw-Partitionen zugreifen könnte. Das ist vor allem mal die Dalvik-VM. Somit bleiben nur noch der init-Prozess und einige Basis-Services die das unmounten erledigen können. Sollte also nicht allzuschwer zu finden sein.

Werde ich aber machen müssen, da umount wirklich kritisch ist.

Zum Vergrößern anklicken....

Jo, stimm ich dir zu. Nur ärgerlich, dass man für sowas simples scheinbar den Compiler anwerfen muss. Btw, kannst du dann gleich die e2fsprogs mitkompilieren? Die sind in den Android-Sourcen unter: external/e2fsprogs zu finden. Dann könnte man vor dem mounten nochmal nen fsck machen. Kann man ja so einstellen, dass fsck nur gemacht wird, falls die Partition beim runterfahren (durch Absturz oder Force-Reboot) nicht sauber ge-unmounted wurde. Dann bremst es den Bootvorgang nicht unnötig aus.

Hallo

Zunächst einmal ein echtes Lob - als Linuxfreund ist unslaved genau das was man braucht (toll - sogar mit einer busybox).

Vielleicht noch ein kleiner Optimierungsvorschlag für die Beginner:
Die Datei boot.img wird auf der Downloadsite angeboten; vielleicht könnte man auch noch (in der Installationsanweisung) einen Hinweis dazu geben, wo diese verwendet und wie sie eingebunden wird.

Mir ist klar - "unslaved" ist für die erfahreren User, aber es ist so gut, dass es sich auch für Beginner lohnen sollte.


Besten Dank

Kommt hier noch ein Update?

mit Donut.

für CRC 37 - nicht

Hallo

Ich habe eine kleine Nachfrage.

Es kommt immer wieder der Hinweis, dass eine neue Systemsoftware vorhanden ist.

Kann man das irgendwie abschalten?

(Nur bis zum nächsten update von unslaved)



Besten Dank

unter /system/etc ... gibt es eine Datei ota...
die muss gelöscht werden (nach einem adb remount)

den genauen Namen weiß ich jetzt nicht, es gibt da aber nicht so viele die mit "ota" anfangen.

Dann ist Ruhe mit der Benachrichtigung

Hallo und vielen Dank

Ich habe nun die Datei ausfindig gemacht sie steht in

/system/etc/security/otacerts.zip

Ich habe nun - wenn ich es recht verstanden habe - gelesen, dass nach dem löschen - jedenfalls bei früheren Versionen - das System ständig versucht das Update erneut herunterzuladen und zu verifizieren?

Ist das bei dieser Version nicht mehr der Fall?


Besten Dank

@ zx128

bist du schon dran, eine neue version zu machen??? donut ist doch schon draussen....oder hab ich da was falsch verstanden....cyanogen hat doch auch schon in seinem neuen experimental donut drinnen oder net...

CMcRae schrieb:

@ zx128

bist du schon dran, eine neue version zu machen??? donut ist doch schon draussen....oder hab ich da was falsch verstanden....cyanogen hat doch auch schon in seinem neuen experimental donut drinnen oder net...

Zum Vergrößern anklicken....

Der momentane Stand des Donut-Quellcode wird schon seit einiger Zeit immer mal wieder veröffentlicht. Teile davon hat Cyanogen auch schon eine ganze Weile verbaut. Jetzt ist nur soviel veröffentlicht worden, dass nicht mehr Teile von Donut den anderen Code verbessern, sondern dass Teile des anderen Codes Donut lauffähig machen. Und richtig gut läufts noch nicht wirklich.
Bis Donut dann auch wirklich für die normalen Kunden kommt dauert das schon noch ein Weilchen. Schließlich ist Bleeding-Edge-Experimentalstand auch nur eine Version ohne Camcorder und Videos, in der der Market spinnt.