Jump to content
Melde dich an, um diesem Inhalt zu folgen  
hg42

ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht

Recommended Posts

hg42

EDIT: der aktuelle Kern-Beitrag ist #38, der eine Übersetzung meines xda-Threads zu diesem Zeitpunkt ist^H^H^Hwar.

Aktuell ist trotzdem immer mein xda Thread , ich habe leider nicht die Zeit, das immer wieder ins Deutsche zu übersetzen, dort gibt es auch noch andere PITs usw.)

Hallo,

Ich möchte hier mal meine Erfahrung mit (m)einem ICS-Brick berichten, erst Mal just for info:

Ich habe ein N7000 und habe es trotz besseren Wissens dann doch gebrickt.

Ich hatte vorher cm9 drauf (eben wegen der Brick Gefahr aber auch weil ich schon länger ein CM-Fan bin, zuvor htc desire mit cm7).

Ich habe dann das Stock-ICS via Mobile-Odin geflasht, weil mir USB-Host und HDMI doch zu sehr fehlten.

Da dann einige Dinge etwas merkwürdig funktionierten (IMHO typisch wenn man nicht wiped zwischen stock und cm und umgekehrt), habe ich (reflexartig weil ich es vorher immer so gemacht habe) einen data-wipe durchgeführt und wusste im selben Moment, dass das wohl nicht sooo gut war.

Ich hätte das definitiv vorher überlegen sollen und nicht mit dem LPY-Kernel wipen sollen, sondern schon vorher als noch der CM9-CWM drauf war.

Nach dem Brick hab ich erst mal aufgeatmet, da das Stock-ICS normal startete...

es blieb dann aber nach einiger Zeit immer wieder minutenweise stehen, mit jeweils anschliessendem Absturz des com.android.acore (oder .core?), danach noch Absturz von Google Play Store.

Ein Blick mit einem Root-File-manager zeigte, dass /data nicht da war.

Zwischenzeitlich hatte ich noch die LCD-Density geändert (per App), was sich beim nächsten Booten darin äusserte, dass die build.prop ganz weg war.

Es ist mir bis jetzt noch nicht klar, wie das geht. Die Strategie der App könnte sein, die build.prop in ein eigenes Verzeichnis zu verschieben oder zu kopieren und dann geändert wieder zurückzukopieren. Aber wieso ist sie dann weg? Wenn man sie verschieben kann, sollte sie auch zurückkopiert werden können. In beiden Fällen wird das Dateisystem bearbeitet.

Ich hab dann einen anderen GB-CWM-Kernel via Odin installiert um mit einem sicheren CWM eine restore zu machen. Das klappte aber nicht und blieb bei /data hängen. Irgendwann habe ich deswegen dann noch (dummerweise?) data und system formatiert, weil sie nicht mountbar waren und ich dachte, das Dateisystem hätte nen Schuß und könnte deswegen nicht gemountet werden. Leider fehlt dem System dadurch auch einiges in system, was ich dann doch noch brauchen sollte.

Aktueller Zustand:

Das geht noch:

- Download-Modus mit Tasten oder USB-JIG

- Recovery lässt sich starten

- Kernel/Recovery lässt sich via Odin austauschen

Das geht nicht mehr:

- das mounten von /system und /data und auch der internen sdcard (auf /sdcard) scheint fehlzuschlagen, obwohl ich in einem CWM jetzt den mount wieder ausführen kann. Schreiben kann ich aber nicht dort.

Die interne SD scheint auch nicht gemountet zu werden, sondern ich vermute es ist nur ein Verzeichnis in der root ohne gemountetes Dateisystem. Mit einem alten Stock-Kernel (KJ4) war ich in der per adb einen Abzug eines Backups zu machen (incl. efs) das ich mit einem Thor-Kernel erstellt hatte.

- flashen einer Firmware mit Odin bleibt beim ersten Strich des Factory_FS stehen

- CWM Restore eines cm9 Backups schlägt fehl weil /system jetzt leider leer ist (vor allem build.prop fehlt) und deshalb der Test auf das korrekte device via einiger ro.* properties nicht geht.

-andere CWM-restores gehen auch nicht, sie bleiben alle bei /data stehen

- ich habe jetzt eine busybox auf /cache, kann sie aber nicht starten, da adb shell unbedingt /system/bin/sh starten will, /system ist aber schreibgeschützt, ich kann also keine sh dorthin pushen (vielleicht ist /system auch nur ein Verzeichnis ohne mount). adb root,adb remount gehen in dem Recovery scheinbar nicht (gibt es bessere? oder es liegt am leeren /system).

Im Moment suche ich nach einer Möglichkeit wie ich die üblichen Unix-Kommandos für Dateisysteme (sowas wie mount, fdisk, fsck), auf dem SGN ausführen kann, also z.B. die busybox über adb aufrufen, oder erst Mal die /system/bin/sh irgendwie aufs SGN bekommen.

Hat jemand so etwas in der Hinterhand? z.B: ein tar-File das mir am besten via Odin ein Grundsystem erzeugt? Oder Tips/Links, wie ich so ein Archiv erstellen kann?

Im Moment habe ich auch das Problem, dass ich mit dem KJ4-Kernel ein bischen adb machen (pull/push), aber kein restore ausführen kann.

Ausserdem komme ich mit dem Recovery bei "apply update from sdcard" nicht auf das cache-Verzeichnis, das im Moment das einzige ist, wo ich drauf pushen kann. Also in jeder Richtung fehlt immer ein kleines bischen.

Am Ende ist aber vielleicht alles eh umsonst, wenn nämlich das Flash durch den Wipe zu kaputt sein sollte.

so das war's erstmal...reicht ja auch :-)

bearbeitet von hg42
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
hg42

ich wollte mal rausfinden, was da alles noch so auf meinem SGN vorhanden ist. Ich hatte die Idee, einfach mal

adb pull /

einzugeben und prompt hat mir adb viele interessante Dateien auf mein backup-Verzeichnis geströmt:

Diese Verzeichnisse gibt es auf oberster Ebene:

cache

lib

mnt

proc

res

sbin

sys

in /proc und /sys findet man dann so einiges über den aktuellen Zustand im Stock-Recovery (vom KJ4 Kernel).

U.a. habe ich da /proc/partitions wo Linux die gefundenen Partitionen verzeichnet.

major minor #blocks name

179 0 15388672 mmcblk0

179 1 20480 mmcblk0p1

179 2 1280 mmcblk0p2

179 3 1280 mmcblk0p3

179 4 8192 mmcblk0p4

179 5 8192 mmcblk0p5

179 6 8192 mmcblk0p6

179 7 204800 mmcblk0p7

179 8 16384 mmcblk0p8

179 9 872448 mmcblk0p9

179 10 2097152 mmcblk0p10

179 11 11616256 mmcblk0p11

179 12 524288 mmcblk0p12

Die Partitionierung ist also noch da.

in /res/recovery.fstab sieht man was die recovery davon kennt:

[device]

# mount point fstype device format option mount option

/efs ext4 /dev/block/mmcblk0p1 default default

/cache ext4 /dev/block/mmcblk0p7 default default

/system ext4 /dev/block/mmcblk0p9 default default

/data ext4 /dev/block/mmcblk0p10 default default

/sdcard vfat /dev/block/mmcblk0p11 default default

/preload ext4 /dev/block/mmcblk0p12 default default

Leider fehlt die Datei /proc/mounts, dann könnte man direkt sehen, was gemountet ist.

/cache (mmcblk0p7) ist jedenfalls da und findet sich auch unter /sys/fs/ wieder und unter /mnt finde ich .lfs (?), wo ein Ordner images mit diversen Bildchen drin ist, z.B. die Batterie beim Lade-Bildschirm, die Fehlermeldung, dass ein Update schiefgelaufen ist, die Bootmeldung von Galaxy Note N7000, aber auch eine vom 9220 und vom SII, usw..

In /proc/diskstats sind u.a. folgende Zeilen:

179 0 mmcblk0 514 1028 78125 1650 79 307 3096 655 0 2035 2305

179 1 mmcblk0p1 39 158 1546 30 20 1 168 70 0 100 100

179 2 mmcblk0p2 0 0 0 0 0 0 0 0 0 0 0

179 3 mmcblk0p3 0 0 0 0 0 0 0 0 0 0 0

179 4 mmcblk0p4 88 304 3136 90 0 0 0 0 0 90 90

179 5 mmcblk0p5 0 0 0 0 0 0 0 0 0 0 0

179 6 mmcblk0p6 0 0 0 0 0 0 0 0 0 0 0

179 7 mmcblk0p7 20 95 908 15 49 306 2848 555 0 300 570

179 8 mmcblk0p8 0 0 0 0 0 0 0 0 0 0 0

179 9 mmcblk0p9 1 0 2 0 0 0 0 0 0 0 0

179 10 mmcblk0p10 21 128 1168 25 8 0 64 20 0 45 45

179 11 mmcblk0p11 329 311 70987 1480 0 0 0 0 0 1480 1480

179 12 mmcblk0p12 6 32 298 5 2 0 16 10 0 15 15

dazu habe ich folgende Felder gefunden:

Field 1 -- # of reads issued

Field 2 -- # of reads merged, field 6 -- # of writes merged

Field 3 -- # of sectors read

Field 4 -- # of milliseconds spent reading

Field 5 -- # of writes completed

Field 7 -- # of sectors written

Field 8 -- # of milliseconds spent writing

Field 9 -- # of I/Os currently in progress

Field 10 -- # of milliseconds spent doing I/Os

Field 11 -- weighted # of milliseconds spent doing I/Os

d.h. dann wohl, dass z.B. auf /system = mmcblk0p9 nur einmal zugegriffen wurde und insgesamt nur 2 Sektoren gelesen wurden, /data wurde schon 21 mal gelesen und /sdcard 329 mal mit immerhin 70000 Sektoren, also wahrscheinlich 35 MB?

Jetzt fragt sich nur, ob das Lesen denn fehlerhaft war? Gemountet wurden die drei jedenfalls nicht, da sie nicht in /mnt oder / zu finden sind. Kann aber sein, dass die recovery nur kurz reinschaut.

Im Moment frage ich mich, ob es nicht auch eine bessere Recovery gibt, mit der man die Partitionen mounten kann und mit der trotzdem auch adb (d.h. /sbin/adbd) läuft. Dann könnte ich sehen, was da alles noch drauf ist. Im Moment sieht es ja so aus, als sei doch noch nicht so viel hardwaremässig kaputt, nur die /system macht mir etwas Sorgen, wobei die ja komplett leergeputzt ist, eventuell reicht da dann ja ein Zugriff um das festzustellen.

Diesen Beitrag teilen


Link zum Beitrag
hg42

dass diese Fehlermeldung kommt liegt vermutlich auch daran, dass mein /system komplett leer ist. Irgendwo muss ja nachgesehen werden ob USB-Debugging eingeschaltet ist (davon hängt es ab, nehme ich an).

Also beißt sich die Katze wieder in den Schwanz.

ich müsswte etwas auf /system schreiben darf es aber erst, wenn ich dort was bestimmtes liegen habe...

Diesen Beitrag teilen


Link zum Beitrag
Guest herbertzzz

Wenn du in den Downloadmodus kommst. Warum flasht du dann nicht mit Odin eine FW? Dauert 5 Minuten und hättest schon den ganzen Tag Freude damit.

Diesen Beitrag teilen


Link zum Beitrag
andreas02

Wenn du in den Downloadmodus kommst. Warum flasht du dann nicht mit Odin eine FW? Dauert 5 Minuten und hättest schon den ganzen Tag Freude damit.

Hallo Herbert...steht im ersten Post....hängt beim ersten Strich...:madman:

LG

Andreas

Diesen Beitrag teilen


Link zum Beitrag
Guest herbertzzz

Ich bin einfach davon ausgegangen

Das geht noch:

- Download-Modus mit Tasten oder USB-JIG

- Recovery lässt sich starten

- Kernel/Recovery lässt sich via Odin austauschen

- flashen einer Firmware mit Odin bleibt beim ersten Strich des Factory_FS stehen

das müsste er mehrmals versuchen. Odin hängt manchmal.

Wenn das nichts hilft, dann hat er sich den bootloader zerschossen - da würde er jedoch imho gar nicht ins Gerät kommen.

Diesen Beitrag teilen


Link zum Beitrag
andreas02

Ich bin einfach davon ausgegangen

das müsste er mehrmals versuchen. Odin hängt manchmal.

Die Erfahrung habe ich auch schon gemacht, aber so wie er schreibt, kennt er sich damit aus....und hat es schon mehrmals probiert :icon_redf

Ansonsten hätte ich nur den Tip....ab zu Samsung:thankyou:

LG

Andreas

Diesen Beitrag teilen


Link zum Beitrag
Guest herbertzzz

Ansonsten hätte ich nur den Tip....ab zu Samsung:thankyou:

Auch das war mein erster Gedanke. Aber er wäre der Erste der in den Downloadmodus kann sich aber mit Odin nicht flashen lässt. - Daher sollte er es noch ein paar Mal probieren

Ein screenshot von Odin mit den bereits verlinkten Datein wäre vielleicht auch hilfreich, hg42 ;)

Diesen Beitrag teilen


Link zum Beitrag
hg42

@stefan z: Ich kann in Odin flashen, aber der bleibt wie auch CWM irgendwann stehen

Inzwischen bin ich eine Ecke weiter gekommen.

Es liegt an bad sectors, bzw. IO Error beim Schreiben.

Ich bin gerade dabei mit e2fsck diese Blöcke erst Mal auszusortieren:

~ # e2fsck -c /dev/block/mmcblk0p9

e2fsck -c /dev/block/mmcblk0p9

e2fsck 1.41.11 (14-Mar-2010)

Error reading block 196608 (Attempt to read block from filesystem resulted in short read) while reading inode and block bitmaps. Ignore error<y>?

yes

Force rewrite<y>?

yes

Error reading block 196609 (Attempt to read block from filesystem resulted in short read) while reading inode and block bitmaps. Ignore error<y>?

...weiter ist er noch nicht gekommen...später mehr...

Diesen Beitrag teilen


Link zum Beitrag
hg42

Übrigens suche ich hier weniger Hilfe (wobei ein paar kompetente Tips nicht schaden können), sondern ich will nur mal berichten. Ich habe nämlich wenig tiefergehende Berichte über das Phänomen gelesen, und ich denke, dass man da immer noch weiter kommt, wenn man hartnäckig genug ist, was ich ja auch schon größtenteils geschafft habe.

Mit dem Thor-Kernel bin ich in adb auch in das Gerät gekommen (was aus unerfindlichen Gründen vorher nicht geklappt hatte).

Edit: es sieht so aus, als wenn das mit dem Thor Kernel nur klappt, wenn adbd in /system/... verfügbar ist, was am Anfang nicht der Fall war. Da ich daran gerade arbeite (z.B. mit dd if=/devZero of=... löschen usw.), klappt es jetzt im Moment leider wieder nicht mehr mit adb. Der KJ4-Stock-Kernel hatte den adbd in /sbin.

Manchmal gibt es keinen adb connect (mit "adb shell") obwohl "adb devices" ein Gerät anzeigt. Mit "adb root" kommt dann eine Fehlermeldung:

-> adb root

error: protocol fault (no status)

-> adb root

adbd is already running as root

danach klappt dann aber auch "adb shell".

Den Thor-Kernel muss man übrigens erst Mal finden, da er nicht direkt im Galaxy Note Bereich angesiedelt ist:

bei TegraOwners

Erwähnung bei android-hilfe [link entfernt, da nicht erlaubt: stefan z]

Da die recovery des Thor-Kernels netterweise ein ziemlich vollständiges /sbin Verzeichnis hat, kann man damit schon ne Menge aus der Situation herausholen. Den Kernel sollte man also immer zum Flashen auf der SD liegen haben, und wenn man ihn nur zum Reparieren oder Analysieren temporär flashed.

bearbeitet von herbertzzz
link zu dt Forum entfernt

Diesen Beitrag teilen


Link zum Beitrag
hg42

hmm, ich schrieb oben immer KJ4-Stock-Kernel, das war wahrscheinlich falsch.

Jedenfalls habe ich gerade eben mit dem KJ4 überhaupt kein adb-device zu sehen bekommen. Aber das (irgendwie inoffizielle?) 6-teilige(!) KL8-Paket namens N7000_XXKL8.zip enthält folgende Dateien:

KERNEL_N7000XXKL8_CL840182_REV02_eng_mid_noship.tar.md5

MODEM_N7000XXKL8_REV_05_CL1089796.tar.md5

UMS_N7000XXKL8_CL840182_REV02_user_low_ship_16GB.tar.md5

CODE_N7000XXKL8_CL840182_REV02_user_low_ship.tar.md5

EFS_N7000XXKL8_CL840182_REV02_user_low_ship.tar.md5

GT-N7000-MULTI-CSC-OXAKL8.tar.md5

Davon konnte ich dann via Odin den Kernel flashen (ich denke "eng" heisst soviel wie engeneering?) und jetzt habe ich im recovery wieder einen adb, der zwar jetzt im root Modus ist (warum?), aber wegen der fehlenden /system/bin/sh nicht für viel taugt. adb push klappt auch nicht.

Diesen Kernel hatte ich auch vorher schon mal drauf, der war es also wahrscheinlich. Das recovery sieht genauso aus, wei das vom KJ4, deswegen habe ich das wohl verwechselt.

Übrigens sollte man höchstwahrscheinlich davon absehen, die EFS-Datei zu flashen, da damit u.a. die IME usw. verlorengehen wird, also lieber die Finger davon lassen. Die UMS-Datei ist harmlos und legt nur auf /sdcard/Samsung ein paar leere Ordner an (Images usw.).

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
hg42

Ich habe nun versucht, die kaputten Blöcke in eine Blacklist auszusortieren, so dass sie nicht benutzt werden:

e2fsck -c /dev/block/mmcblk0p9

das klappt aber nicht. Es ist offensichtlich noch mehr kaputt als nur ein paar Blöcke. Vor allem ändern sich auch die Block-Nummern, die e2fsck als kaputt meldet.

Dann habe ich dasselbe noch auf /data anwenden wollen, aber da tut sich dann gar nichts mehr. /data scheint also noch mehr geschrottet.

Ich denke das war's dann mit dem Rettungsversuch bzw. der Analyse...

Diesen Beitrag teilen


Link zum Beitrag
Guest herbertzzz

Wenn du in den Downloadmodus gelangen kannst, würde ich mal versuchen mit Odin nur den Bootloader (ca 6MB) unter PDA zu flashen. - viel schlimmer kann es ja nicht werden.

Ich nehme an, du hast das aktuelle Treiberpaket auf deinem Rechner, bzw gehe ich davon aus.

Diesen Beitrag teilen


Link zum Beitrag
hg42

Wenn du in den Downloadmodus gelangen kannst, würde ich mal versuchen mit Odin nur den Bootloader (ca 6MB) unter PDA zu flashen. - viel schlimmer kann es ja nicht werden.

habe ich inzwischen auch schon 2x gemacht, weil ich das Warn-Dreieck beseitigen wollte, also einmal der "alte" Bootloader und einmal der "neue".

Ich nehme an, du hast das aktuelle Treiberpaket auf deinem Rechner, bzw gehe ich davon aus.

ja, d.h. das was Kies sich holt, wenn man dort die Verbindung reparieren lässt (war glaube ich Version 1.5.4.0, und Kies habe ich danach wieder deinstalliert).

Aber das bewirkt alles wenig, da ja einerseits der Boot-Vorgang soweit ordentlich läuft und es auch kein Übertragungsfehler ist auch wenn es so aussieht.

Ich ja nach etwas Installations-Aufwand mit "adb shell" genau sehen kann, was eigentlich wirklich los ist, stütze mich also nicht mehr auf Vermutungen, wie es ja bei dem üblichen Blindflug ja nicht anders geht.

Viele Probleme, die untereinander gleich oder ähnlich aussehen sind ja in Wirklichkeit gar nicht so dramatisch, wenn man sehen würde was da passiert.

Deswegen starte ich ja z.B. ein Windows mit /SOS in boot.ini, damit man sieht, wer wann wie hängen bleibt, wenn was hakt.

Wie gesagt sind bei der /system-Partition einige Blöcke und bei der /data schon die wichtigsten ersten Blöcke nicht mehr beschreibbar und nach dem was man liest ist das beim ICS-Hard-Brick wohl auch nicht mehr reparabel, u.a. auch nicht mit JTAG usw., so dass die Hauptplatine ausgetauscht werden muss (>250EUR). Obwohl ja eigentlich nur der betroffene Flash-Chip ausgetauscht werden müsste, aber das macht ja heute keiner mehr.

Ich habe inzwischen ein neues SGN bestellt (weil ich es eigentlich wirklich brauche), das wohl morgen schon da sein wird.

Wobei ich mir dann überlegen werde, wie ich dann bzgl. flashen usw. damit umgehe. Ich denke ich ich werde erst Mal kein ICS draufmachen und wenn dann käme nur CyanogenMod in Frage.

Das alte werde ich vermutlich in der Art wiederbeleben, dass ich alle Partitionen bis auf Bootloader und die Wurzel des Dateisystems wo die anderen Partitionen eingehängt werden auf die SD-Karte verlege und von dort mounte, das sollte mit ein paar Zeilen Änderung möglich sein.

Dann geht natürlich kein einfaches Update mehr (mit Odin oder CWM).

Man muss dann rein dateibasiert updaten, was aber auch nicht soo schwierig ist.

Diesen Beitrag teilen


Link zum Beitrag
Guest herbertzzz

Wenn du Kies deinstallierst, deinstallierst du da nicht auch die Treiber?

Ist schon länger her (Galaxy S i9000) aber ich schaffte nach der Deinstallation von Kies keine ordentliche Verbindung mehr zum PC.

Wenn dem so wäre, dann würde das deine Probleme erklären.

Diesen Beitrag teilen


Link zum Beitrag
MoYo

Leute, die bei Google arbeiten wissen von der Sache. (Quelle)

Auch eine Lösung hat "Ken Sumrall" dafür.

Leider konnte er die Lösung nicht vorstellen,

da er zuvor die Erlaubnis von Google bzw. Samsung bekommen muss.

Diesen Beitrag teilen


Link zum Beitrag
hg42

Wenn du Kies deinstallierst, deinstallierst du da nicht auch die Treiber?

:-) sagen wir mal so, ich achte halt drauf, dass sie drin bleiben.

Wahrscheinlich kommt es auch drauf an, wie man es genau installiert hat.

Wenn ich wirklich die aktuellsten Samsung USB Drivers haben will, gehe ich so vor:

Ich installiere Kies.

Dann lasse ich Kies die Verbindung "reparieren" (auch wenn es vorher funktionierte).

Dann holt Kies anscheinend neue Treiber aus den Weiten des Internets.

Danach habe ich jedenfalls in MyUninstaller (in etwa dasselbe wie Systemsteuerung / Software) zwei Einträge

1. "Samsung Kies" und

2. "Samsung USB Drivers"

Kies deinstalliere ich dann meistens wieder, da ich es nicht brauche.

Alternativ hole ich mir ein Treiber-Paket direkt irgendwo aus dem Internet, dabei habe ich aber manchmal Probleme beim Installieren (z.B. dass gar nichts passiert).

Ich konnte zumindest bei meinen Paketen ab 1.5.x keine wesentlichen Unterschiede feststellen, die verhalten sich bei mir alle gleich.

Und wie gesagt, wenn Odin bei dem factory_fs hängen bleibt, liegt es an den kaputten Blöcken im Flash und nicht an der Übertragung.

Ich kann in Odin auch grosse Sachen (z.B. ein cache.img) flashen solange nicht auf /system oder /data zugegriffen wird.

CWM meldet bei /system irgendwo in der Mitte nen Fehler und bleibt bei /data ganz hängen, und das ist ja komplett ohne PC.

Diesen Beitrag teilen


Link zum Beitrag
zipfelmuetze

Habe soeben erfolgreich das Note eines bekannten dank der Anleitung wieder zurück ins Leben geholt :)

:danke:

Diesen Beitrag teilen


Link zum Beitrag
hg42

Auf der xda-developers-Seite soll es wohl eine Lösung für die gebrickten Notes geben

Danke für diesen Anstupser!

Ich hatte zwar auch schon mit parted experimentiert, aber durch Deinen Hinweis auf den xda thread hab ich noch mal neu über meine Strategie nachgedacht und tatsächlich einen Weg gefunden, mein SGN wiederzubeleben :-)

parted war bei meinen letzten Versuchen auch immer bei Zugriffen auf die kaputten Blöcke hängengeblieben. So bin ich dann nicht weiter gekommen.

Wenn man das weiterdenkt, ist es natürlich schon mal logisch, dass man Zugriffe auf die kaputten Blöcke vermeiden muss.

Es geht ja letztlich für eine Wiederbelebung darum die kaputten Blöcke auszusondern, wie ich es mit e2fsck schon versucht hatte, das aber ebenfalls scheitert, weil es beim Lesen eines Blocks (um zu testen, ob ein Block kaputt ist) wieder an den kaputten hängen bleibt. So kann es also keine Bad-Block-Liste zusammenstellen.

Eben ist mir dann die Erleuchtung gekommen:

Man muss nur die Partitionen so legen, dass der betroffene Bereich unbenutzt bleibt. Da man eigentlich genug Platz hat, kann man dabei grosszügig einfach die Bereiche /system (893MB) und /data (2147MB) komplett aussparen.

Und wenn man dies mit Löschen anfängt, dann wird auch nicht auf die bad blocks zugegriffen.

Also habe ich die folgende Schritte durchgeführt...

zuerst parted auf dem flash device starten:

~ # parted /dev/block/mmcblk0

parted /dev/block/mmcblk0

GNU Parted 1.8.8.1.179-aef3

Using /dev/block/mmcblk0

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) print

print

print

hier kommen dann komischerweise ein paar Meldungen über Fehler in der Partitionstabelle, deren Reparatur ich erlaubt habe (vielleicht sollte man sie aber lieber so lassen?):

Error: The backup GPT table is not at the end of the disk, as it should be.

This might mean that another operating system believes the disk is smaller.

Fix, by moving the backup to the end (and removing the old backup)?

Fix/Ignore/Cancel? f

f

f

Warning: Not all of the space available to /dev/block/mmcblk0 appears to be

used, you can fix the GPT to use all of the space (an extra 2048 blocks) or

continue with the current setting?

Fix/Ignore? f

f

f

und so sieht die Partitionstabelle vor der Änderung aus:

Model: MMC VYL00M (sd/mmc)

Disk /dev/block/mmcblk0: 15.8GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Number Start End Size File system Name Flags

1 4194kB 25.2MB 21.0MB ext4 EFS

2 25.2MB 26.5MB 1311kB SBL1

3 27.3MB 28.6MB 1311kB SBL2

4 29.4MB 37.7MB 8389kB PARAM

5 37.7MB 46.1MB 8389kB KERNEL

6 46.1MB 54.5MB 8389kB RECOVERY

7 54.5MB 264MB 210MB ext4 CACHE

8 264MB 281MB 16.8MB MODEM

9 281MB 1174MB 893MB FACTORYFS

10 1174MB 3322MB 2147MB ext4 DATAFS

11 3322MB 15.2GB 11.9GB fat32 UMS

12 15.2GB 15.8GB 537MB ext4 HIDDEN

ich lösche also jetzt die Partitionen 9=FACTORYFS=/system 10=DATAFS=/data und 11=UMS=/sdcard(intern) und erzeuge sie neu ungefähr ab der Stelle wo im Moment die UMS beginnt, so dass also der Bereich von /system und /data am Ende frei bleibt:

(parted) rm 11

(parted) rm 10

(parted) rm 9

(parted) mkpartfs primary ext2 3500 4400

(parted) mkpartfs primary ext2 4400 7000

(parted) mkpartfs primary fat32 7000 15.2G

(parted) name 9 FACTORYFS

(parted) name 10 DATAFS

(parted) name 11 UMS

hier werden noch die ext2-Partitionen in ext4 umgewandelt:

~ # tune2fs -j /dev/block/mmcblk0p9

tune2fs -j /dev/block/mmcblk0p9

tune2fs 1.41.11 (14-Mar-2010)

Creating journal inode: done

This filesystem will be automatically checked every 30 mounts or

0 days, whichever comes first. Use tune2fs -c or -i to override.

~ # tune2fs -j /dev/block/mmcblk0p10

tune2fs -j /dev/block/mmcblk0p10

tune2fs 1.41.11 (14-Mar-2010)

Creating journal inode: done

This filesystem will be automatically checked every 30 mounts or

0 days, whichever comes first. Use tune2fs -c or -i to override.

~ # e2fsck -fDp /dev/block/mmcblk0p9

e2fsck -fDp /dev/block/mmcblk0p9

/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks

~ # e2fsck -fDp /dev/block/mmcblk0p10

e2fsck -fDp /dev/block/mmcblk0p10

/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks

und so sieht es nachher aus:

~ # parted /dev/block/mmcblk0 print

parted /dev/block/mmcblk0 print

Model: MMC VYL00M (sd/mmc)

Disk /dev/block/mmcblk0: 15.8GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Number Start End Size File system Name Flags

1 4194kB 25.2MB 21.0MB ext4 EFS

2 25.2MB 26.5MB 1311kB SBL1

3 27.3MB 28.6MB 1311kB SBL2

4 29.4MB 37.7MB 8389kB PARAM

5 37.7MB 46.1MB 8389kB KERNEL

6 46.1MB 54.5MB 8389kB RECOVERY

7 54.5MB 264MB 210MB ext4 CACHE

8 264MB 281MB 16.8MB MODEM

9 3500MB 4400MB 900MB ext3 FACTORYFS

10 4400MB 7000MB 2600MB ext3 DATAFS

11 7000MB 15.2GB 8217MB fat32 UMS msftres

12 15.2GB 15.8GB 537MB ext4 HIDDEN

danach habe ich jetzt inzwischen schon ein älteres CWM-Backup fehlerfrei zurückgespielt (das letzte vor den ICS-Leaks, vom letzten Stand hatte ich leider nur backups auf der internen SD, die bei den Aktionen irgendwann leider weg waren).

Danach habe ich cm9 wieder installiert und bin gerade dabei, meine Titanium-backups wieder einzuspielen.

Dumm nur, dass ein neues SGN schon unterwegs ist...

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag

Please sign in to comment

You will be able to leave a comment after signing in



Jetzt anmelden
Melde dich an, um diesem Inhalt zu folgen  

×
×
  • Neu erstellen...

Wichtige Information

Bitte beachten Sie folgende Informationen: Nutzungsbedingungen und Impressum & Datenschutzerklärung. Wir haben Cookies auf deinem Gerät platziert, um die Bedienung dieser Website zu verbessern. Du kannst deine Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist.