[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)

[fipsy]

Ich weiß nicht, ob dies ein spezielles CM7-Problem ist, aber ich poste es hier einfach mal. Vielleicht hat ja jemand Ahnung, wo das Problem liegt:

Beim Booten des Gerätes sichere ich immer einige Verzeichnisse auf die SD-Karte. Dazu habe ich in /etc/init.d eine Shellscript, das die SD-Karte mountet, die Daten kopiert und die Karte dann wieder unmountet. Das Ganze sieht etwa so aus:

mount -w -t auto /dev/block/mmcblk0p1 /mnt/sdcard
cp -dR -f -L /data/data/blabla /mnt/sdcard/backup/
date >> /mnt/sdcard/.reboot.log
umount /mnt/sdcard

Das Problem ist nun: Nur in etwa 50% der Fälle werden die Daten tatsächlich kopiert. In den anderen 50% passiert gar nichts. D.h. "gar nichts" ist der falsche Ausdruck. Es passiert schon was, hinterher liegen nämlich alle zu kopierenden Dateien als Fragmente im LOST.DIR

Und auch ein "Checkdisk" der FAT32-Partition ergibt eine Reihe verlorener Segmente. Daraus schließe ich, dass der Kopiervorgang noch gar nicht abgeschlossen ist, wenn das umount ausgeführt wird. Aber wie kann das sein??? Eigentlich sollte umount doch warten, bis alle Daten geschrieben und alle offenen Dateien geschlossen sind, bevor es das Device unmountet. Oder nicht?

Es ist eh blöd, dass bei der Ausführung der Scripte in /etc/init.d die SD-Karte noch nicht gemountet ist. Wann wird diese eigentlich gemountet und geschieht dies asynchron? Offenbar schon. Wie es aussieht, gibt es gar keine zuverlässige Methode, während des Bootvorgangs über init.d-Scripte auf die SD-Karte zuzugreifen, oder?

Außerdem kommt es hin und wieder vor, dass die SD-Karte read-only gemountet wird. Ich vermute, das hängt auch mit meinem Script zusammen. Hat jemand vielleicht ne Lösung? *heul*

 

[-FuFu-]

das wird ein generelles Problem sein...
und die sdcard ist dann nicht gemountet, da dies in 99% der fälle nicht nötig ist und es auch zu problemen kommen kann, wenn sie nicht unmountet wird, da dann unter umständen das Android System die Karte nicht richtig mounten kann....

aber dein Problem könntest du durch 2 weitere befehle vielleicht beheben, das ganze script sollte am ende dann so aussehen:

mount -w -t auto /dev/block/mmcblk0p1 /mnt/sdcard
cp -dR -f -L /data/data/blabla /mnt/sdcard/backup/
date >> /mnt/sdcard/.reboot.log
sleep 3
sync
sleep 3
umount /mnt/sdcard

die sleep commands kann man eventuell auch weg lass, es ist einfach nur ein zusätzlicher zeitbuffer, den ich auch gern mal verwende... der sync befehl ist hoffentlich klar und bekannt falls nicht, der dient dazu gecachte, noch nicht geschriebene Daten auf die Festplatte/sdcard zu schreiben...

und deinen mount befehl könntest du evenuel wie folgt abändern:

mount -t vfat -o rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,shortname=mixed,utf8 /dev/block/vold/179:1 /sdcard

den befehl nutz ich unteranderem im 98swapon script und da hatte ich damit soweit keine probleme, vielleicht hilft es dir ja

 

[ClubMenthol]

Ich weiß nicht, ob dies ein spezielles CM7-Problem ist, aber ich poste es hier einfach mal. Vielleicht hat ja jemand Ahnung, wo das Problem liegt:

Beim Booten des Gerätes sichere ich immer einige Verzeichnisse auf die SD-Karte. Dazu habe ich in /etc/init.d eine Shellscript, das die SD-Karte mountet, die Daten kopiert und die Karte dann wieder unmountet. Das Ganze sieht etwa so aus:

mount -w -t auto /dev/block/mmcblk0p1 /mnt/sdcard
cp -dR -f -L /data/data/blabla /mnt/sdcard/backup/
date >> /mnt/sdcard/.reboot.log
umount /mnt/sdcard

Das Problem ist nun: Nur in etwa 50% der Fälle werden die Daten tatsächlich kopiert. In den anderen 50% passiert gar nichts. D.h. "gar nichts" ist der falsche Ausdruck. Es passiert schon was, hinterher liegen nämlich alle zu kopierenden Dateien als Fragmente im LOST.DIR

Und auch ein "Checkdisk" der FAT32-Partition ergibt eine Reihe verlorener Segmente. Daraus schließe ich, dass der Kopiervorgang noch gar nicht abgeschlossen ist, wenn das umount ausgeführt wird. Aber wie kann das sein??? Eigentlich sollte umount doch warten, bis alle Daten geschrieben und alle offenen Dateien geschlossen sind, bevor es das Device unmountet. Oder nicht?

Es ist eh blöd, dass bei der Ausführung der Scripte in /etc/init.d die SD-Karte noch nicht gemountet ist. Wann wird diese eigentlich gemountet und geschieht dies asynchron? Offenbar schon. Wie es aussieht, gibt es gar keine zuverlässige Methode, während des Bootvorgangs über ini.d-Scripte auf die SD-Karte zuzugreifen, oder?

Außerdem kommt es hin und wieder vor, dass die SD-Karte read-only gemountet wird. Ich vermute, das hängt auch mit meinem Script zusammen. Hat jemand vielleicht ne Lösung? *heul*

Das kann schon sein, dass zu schnell ungemounted wird und noch nicht alles geschrieben ist. Versuche doch mal vor der unmount Zeile ein

sync

einzufügen, dann sollte eigentlich alles erst geschrieben werden. Siehe hier.
Durch das zu frühe unmounten kommt es dann vor das die Daten im Lost.dir landen, somit ist dann das Dateisystem beschädigt. Das sollte dann auch der Moment sein in dem die SDCard nur "read only" gemounted wird.
Ich bin jetzt nicht so der Scrip freak aber Du könntest Dir ja irgendwie eine Art SDCard Reperatur mit einbauen. Der Befehl dafür währe bei ungemounteter SDCard

fsck_msdos /dev/block/mmcblk0p1

.


Naja was solls, FuFu war wieder schneller.

 

[fipsy]

sync

Jaaaa! Nach genau sowas habe ich gesucht. Also nach sowas wie "fflush" in C.

und deinen mount befehl könntest du evenuel wie folgt abändern:

mount -t vfat -o rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,shortname=mixed,utf8 /dev/block/vold/179:1 /sdcard

Vielen Dank! Das werde ich sofort mal so einbauen

Das sollte dann auch der Moment sein in dem die SDCard nur "read only" gemounted wird.

Ah, alles klar! Das erklärt auch meine letzte Frage! Heißen Dank!

Ich bin jetzt nicht so der Scrip freak aber Du könntest Dir ja irgendwie eine Art SDCard Reperatur mit einbauen.

Auch dafür Danke! Aber ich denke, das Problem wird dann nicht mehr auftreten. Wenn was im LOST.DIR liegt, nehme ich die Karte eh immer raus, lege sie in den Kartenleser ein und checke sie unter Windows. Bin das so gewohnt und scheint mir auch zuverlässiger als das fsck_msdos.

 

[-FuFu-]

da sollte die lösung von ClubMenthol eventuell helfen ^^
einfach "fsck_msdos /dev/block/mmcblk0p1" nach dem umount befehl mit einbauen, so werden evenuelle dateisystemfehler bei jedem reboot automatisch behoben

 

[fipsy]

einfach "fsck_msdos /dev/block/mmcblk0p1" nach dem umount befehl mit einbauen, so werden evenuelle dateisystemfehler bei jedem reboot automatisch behoben

Ja, aber ich wage nicht zu raten, wie lang der Bootvorgang dann dauern wird ;-)

 

[-FuFu-]

wird sich nicht großartig verzögern
du kannst ja mal in meine MiniMod OR booten und dort im sd tools menu mal check fat machen, das ist genau der befehl und es dauert nicht wirklich lange ^^

 

[fipsy]

GEIIIIIILLLL !!!

Die Tips waren ja Gold wert! Es hat alles supi funktioniert. Auch ohne sleep. *knutsch*

Und kurioserweise ist der Bootvorgang jetzt plötzlich auch spürbar schneller und verzögerungsfreier. Offenbar hat das wilde Unmounten ohne sync das Android-System jedesmal heftig verunsichert. Ich denke mal, da wird beim Mounten eine Art Kurzprüfung des Datenträgers durchgeführt und da diese immer Fehler ergab, wurde dann vermutlich eine Prüfroutine angeschmissen, die die Fragmente ins LOST.DIR sortiert hat. Das hat scheinbar massig Zeit verbraucht. Ich kenne mich zwar mit den Interna von Android nicht so aus, aber so stelle ich es mir in meinem naiven Gemüt etwa vor .

Edit:
Frage: Wo schmeißt fsck_msdos eigentlich die verlorenen Segmente hin? Nur damit ich sie auch wiederfinden kann...
Muss fsck_msdos in dem Script nicht mit dem Parameter -y versehen werden, damit eventuelle Fragen nach Wiederherstellung etc. mit "Ja" beantwortet werden? Sonst bleibt das Script doch hängen, oder nicht?

 

[ClubMenthol]

Auch dafür Danke! Aber ich denke, das Problem wird dann nicht mehr auftreten. Wenn was im LOST.DIR liegt, nehme ich die Karte eh immer raus, lege sie in den Kartenleser ein und checke sie unter Windows. Bin das so gewohnt und scheint mir auch zuverlässiger als das fsck_msdos.

Zuverlässig ist das, wichtig bei dem Befehl ist halt nur das die SDCard nicht gemounted seien darf. Ich habe mir so schon öfter bei SDCard Problemen geholfen, habe halt nicht immer einen PC mit Cardreader dabei.

Edit:
Frage: Wo schmeißt fsck_msdos eigentlich die verlorenen Segmente hin? Nur damit ich sie auch wiederfinden kann...
Muss fsck_msdos in dem Script nicht mit dem Parameter -y versehen werden, damit eventuelle Fragen nach Wiederherstellung etc. mit "Ja" beantwortet werden? Sonst bleibt das Script doch hängen, oder nicht?

Das ist richtig, in einem Script das beim Booten ausgeführt wird können keine Rückfragen beantwortet werden, also sollte u.U. der Parameter -y mitgegeben werden.
Die verlorenen/wiederhergestellten Segmente sollten entweder direkt im rootverzeichnis der SDCard oder im lost.dir auftauchen.

Ja, aber ich wage nicht zu raten, wie lang der Bootvorgang dann dauern wird ;-)

Das sollte dann nur bei einem Fehler im Dateisystem etwas länger dauern, sonst sollte fsck eine art filesystem ist clean zurückgeben und beenden.

 

[fipsy]

Meine Euphorie war leider unberechtigt. Es war ein einmaliger Zufall, dass das Kopieren im init.d-Script gestern mal funktioniert hat. Jetzt habe ich trotz sync und sleep wieder alle Dateien im LOST.DIR :-(((.

Auch das Mounten der SD nach deinem Beispiel, FuFu, hat leider nicht geklappt. Wenn ich so mounte, passiert gar nichts.

Das Allerschlimmste aber: Meine SD-Karte ist jetzt hinüber. Die Dateien im LOST.DIR lassen sich nicht mehr löschen. Android gibt nur eine Fehlermeldung aus. Und wenn ich sie im Kartenleser auf dem PC löschen will, führt er den Löschvorgang aus, aber die Dateien sind danach alle noch vorhanden. Nun ist die Kacke so richtig am dampfen! :-(((

 

[-FuFu-]

um zu sehen ob und wie gemounted ist, hau nach dem mount befehl noch folgendes mit ins script

mount >> /mnt/sdcard/.reboot.log

dann siehst ja wie die sdcard gemountet ist... und wenn er noch immer nicht korrekt kopiert weis ich so auch nicht weiter, ich mach sowas ja nicht beim booten
aber eventuell sync, sleep 5, sysnc einbauen, also nen doppelten sync vor dem umount...

 

[fipsy]

um zu sehen ob und wie gemounted ist, hau nach dem mount befehl noch folgendes mit ins script

mount >> /mnt/sdcard/.reboot.log

dann siehst ja wie die sdcard gemountet ist... und wenn er noch immer nicht korrekt kopiert weis ich so auch nicht weiter, ich mach sowas ja nicht beim booten

Nur wenn ich so mounte, wie du vorgeschlagen hast, ist die Karte gar nicht gemountet ;-). Dann kann ich ja auch nix in /mnt/sdcard/.reboot.log schreiben!

Du hast übrigens recht: Sync kehrt zurück, auch wenn die Daten noch gar nicht fertig geschrieben worden sind. Siehe hier:

On Linux, sync is only guaranteed to schedule the dirty blocks for writing; it can actually take a short time before all the blocks are finally written. The reboot(8) and halt(8) commands take this into account by sleeping for a few seconds after calling sync(2).

Wie es aussieht, gibt es keine zuverlässige Methode festzustellen, wann die Daten fertig geschrieben wurden. Irgendwie ist dieses Kommando nur sehr bedingt sinnvoll... Ich finde es eh schon hanebüchen, dass ein umount überhaupt ausgeführt wird, wenn noch nicht alle Daten geschrieben wurden und das System es im Bewusstsein dieser Problematik leichtfertig in Kauf nimmt, dass einfach Daten verloren gehen! Da kann ich echt nur den Kopf schütteln...

Wenn 6 Sekunden Wartezeit zum Schreiben nicht ausreichen, hat das Ganze nur noch wenig Sinn. So lange kann und will ich beim Booten nicht warten. Und leider gibt es - wie es scheint - keine Möglichkeit, automatisch Skipte ausführen zu lassen, wenn die Karte gemountet wurde. Oder gibts sowas wie "at"?

 

[-FuFu-]

umount gibt aber eigentlich ein fehler zurück, wenn die partition/das gerät noch in benutzung ist...

und bei meinem 98swapon script klappt das mounten mit meinem befehl ich mußte den da ja so reinmachen, weil es sonst probleme mit cm9 gab, aber da meine swap settings so übernommen werden wie sie in der conf stehen, scheint die sdcard bei mir immer gemountet zu werden ^^

 

[fipsy]

Ich würde dein mount-Kommando ja gerne mal im Terminal Emulator testen, aber da ist umount nicht funktionsfähig. Es kommt stets nur "Device or resource busy".

 

[-FuFu-]

joa, dann nutzt man einfach mal umount -f oder umount -l testen ^^

 

[fipsy]

Ich habe die SD-Karte im Terminal Emulator mit deinem Kommando einfach mal in ein anderes Verzeichnis gemounted. Das hat einwandfrei funktioniert. Dann lag es wohl auch an dem Gesamtproblem, dass da nix passiert ist und nicht an deinem Mount-Kommando.

Die SD-Karte konnte ich auf dem PC mit der Fehlerüberprüfung wieder sauber kriegen. Unter Android ging das auch mit fsck_msdos nicht mehr. Offenbar ist die Windows-Routine bei schwierigen Fehlern doch überlegen.

 

[-FuFu-]

sonst kopier die sachen doch erst auf die ext beim booten und später verschiebst du sie in android selbst auf die sdcard, ist war umständlicher, aber vielleicht auch ne lösung...

oder du schaust was dein script macht, wenn du den umount befehl einfach weg lässt, ob android sich dann beschwert ^^ aber dann auch fsck_msdos weg lassen ^^

 

[fipsy]

sonst kopier die sachen doch erst auf die ext beim booten und später verschiebst du sie in android selbst auf die sdcard, ist war umständlicher, aber vielleicht auch ne lösung...

Aber dann bräuchte ich wieder in Android ein Script, das nach dem Mounten der Karte automatisch ausgeführt wird. Manuell will ich das nicht immer verschieben müssen! Denn dann kann ich mir auch das init.d-Script sparen ;-).

oder du schaust was dein script macht, wenn du den umount befehl einfach weg lässt, ob android sich dann beschwert ^^ aber dann auch fsck_msdos weg lassen ^^

Habe ich probiert. Android sagt gar nix. Es läuft alles normal. Mountet Android denn die SD-Karte genauso, wie du es weiter oben beschrieben hast und in deiner 98swapon machst? Dann wäre es ja im Grunde egal, ob ich sie mounte oder Android.

 

[-FuFu-]

gute frage ^^ ka wie genau android die karte mounted...
und wenn er alles kopiert und android nicht meckert sollte das ja so passen

 

[fipsy]

Ja, das Kopieren scheint so zu funktionieren. Ich werde es jetzt erstmal so lassen und weiter genau beobachten. Grundsätzlich finde ich es aus unterschiedlichsten Gründen eine gute Sache, wenn man während der Ausführung der init.d-Scripte auch auf die SD-Karte zugreifen kann. Es sind sicher viele Dinge vorstellbar, die man auf diese Weise automatisiert erledigen könnte.