[Tutorial] Ändern der Partitionsgrößen / des Speichers

  • 15 Antworten
  • Letztes Antwortdatum
S

sessions

Stamm-User
152
Ich habe mir schon sehr lange Gedanken über das Umpartitionieren des internen Speichers meines Xperia U gemacht, da das Gerät 2GB für Apps (/data) hat und nur 4GB für Userdaten (/sdcard) vorweist.

Nach langem probieren (siehe Link) habe ich dann einen Weg gefunden, wie man die Aufteilung der Partitionen ändern kann :victory:

In diesem Tutorial beschreibe ich den Ablauf um die Partitionsaufteilung zu ändern.

Achtung!
Das Ändern der Partitionierung eines Gerätes stellt einen massiven Eingriff in das System dar!
Ich und Android-Hilfe.de können keine Verantwortung für auftretende Schäden, verlorende Daten oder zerstörte Geräte übernehmen.
Es werden dabei ALLE Daten am Handy gelöscht, das Android- System (/system) sollte im Normalfall aber drauf bleiben!
Also bitte vorher alles sichern.
Führt dieses Tutorial nur aus, wenn ihr euch sicher seid, was ihr macht.


Ein Paar Worte vorweg:
Ich habe es nicht geschafft, die Größe von /system zu verändern. Der Hintergrund ist (vermutlich!), dass auch das Recovery auf /system zugreift, nämlich dann, wenn man über adb auf das Handy zugreifen will. Adb verwendet die Shell (/system/bin/sh), die halt auf /system liegt...
Diese Tutorial liest sich sehr umfangreich, da ich alle Informationen die ich habe hineinpacke. Dies dient der Orientierung und in manchen Fällen vielleicht zur Klarstellung. Der ganze Ablauf ist in Wirklichkeit in wenigen Minuten erledigt.
Bei meinen Versuchen ist es auch passiert, dass das Handy gar nicht mehr gestartet hat. CWM hat noch gestartet, hat aber keine Partition ansprechen können. adb Zugriff war auch weg. In diesem Fall habe ich mit Flashtool die "Partitions" aus der Stock ROM geflashed - also alles "exclude" angehakt, außer "Partitions". Dadurch wurde die Originalpartitionierung wiederhergestellt.
Ich gehe davon aus, das der vorliegende Ablauf auf allen Xperia Handys funktioniert, zumindest jedenfalls sinngemäß.
Dieses Tutorial hat nichts mit Flashmode, Fastboot, Bootloader unlock oder einer Custom Rom zu tun.

Benötigt
Handy mit Recovery (CWM oder TWRP) und natürlich root
adb shell
Gehrinhirn
evtl. Taschenrechner


Ablauf
Der hier abgebildete Ablauf entspricht allen Kommandozeileneingaben, die ich beim Umpartitionieren meines Xperia U hatte. Ich habe diesen Ablauf zwei mal durchgespielt, es hat jedes mal funktioniert. Die von mir eingegebenen Befehle werden in blau dargestellt.


Das Handy wird ins recovery gestartet, /data, /cache und /sdcard müssen unmounted werden. Im CWM/TWRP dazu auf mounts and storages -> unmount
Das Handy mit dem PC verbinden und in die adb shell einsteigen. Ich setze hier vorraus, das die nötigen Treiber installiert sind. Ich habe das über eine Ubuntu Live CD gemacht, da sind alle nötigen Treiber schon dabei, da ich es unter Windows einfach nicht geschafft habe die richtigen Treiber zu installieren.

Code:
root@ubuntu:/tmp# ./adb shell

Über adb arbeitet man jetzt also am Handy. Als erstes als Superuser anmelden. Über das Tool "fdisk" mit dem Befehl "p" kann man die Partitionsdaten anzeigen lassen.

Code:
root@ubuntu:/tmp# [color=blue] ./adb shell [/color]
shell@android:/ $ [color=blue]su [/color]
root@android:/ # [color=blue]fdisk /dev/block/mmcblk0 [/color]

The number of cylinders for this disk is set to 238592.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): [color=blue]p[/color]

Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
4 heads, 16 sectors/track, 238592 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1               1          32        1023+  0 Empty
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2              37          52         512  f0 Linux/PA-RISC boot
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3              33          36         128  f0 Linux/PA-RISC boot
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4              53      238592     7633280   5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5              65         320        8192  4a Unknown
/dev/block/mmcblk0p6             321         416        3072  83 Linux
/dev/block/mmcblk0p7             417         576        5120  70 Unknown
/dev/block/mmcblk0p8             577         832        8192  83 Linux
/dev/block/mmcblk0p9             833        1344       16384  48 Unknown
/dev/block/mmcblk0p10           1857       34624     1048576  83 Linux
/dev/block/mmcblk0p11          42625      108160     [color=green]2097152[/color]  83 Linux
/dev/block/mmcblk0p12          34625       42624      [color=green]256000[/color]  83 Linux
/dev/block/mmcblk0p13           1345        1856       16384  48 Unknown
/dev/block/mmcblk0p14         108161      238592     [color=green]4173824[/color]   c Win95 FAT32 (LBA)

Partition table entries are not in disk order

Command (m for help):

Die Paratitionen sind beim Xperia U folgendermaßen verteilt:
/dev/block/mmcblk0p10 = /system (1,04GB)
/dev/block/mmcblk0p11 = /data (2,5G0B)
/dev/block/mmcblk0p12 = /cache (256MB)
/dev/block/mmcblk0p13 = ?????
/dev/block/mmcblk0p14 = /sdcard (4,17GB)

Achtung! Ich weiß nicht, was mmcblk0p13 ist! Diese Partition ist sehr klein, ist aber "am Anfang" des Speichers (Cylinder 1345 - 1856). Sie musste mitgelöscht werden, da ansonsten die Reihenfolge der Partitionen nicht mehr stimmt. Beim neuanlegen wird sie wieder genau gleich erstellt. Bei meinem Xperia U hatte das keine Auswirkungen.

Mit der Abfage oben ist zu sehen, wieviele Datenblöcke zu der jeweiligen Partition gehören.

In meinem Beispiel sind das z.B. 2097152 Blöcke bei mmcblk0p11 (=/data), was also 2,09GB entspricht.
Code:
 /dev/block/mmcblk0p11          42625      108160     [color=green]2097152[/color]  83 Linux

Diese Datenblöcke werden in der Partitionstabelle über die Start und End-Blöcke definiert.
Um also die Größe einer Partition zu verändern muss man den Start- und End Block neu festlegen. Das erreicht man, indem man alle Partitionen danach (also hier 11, 12, 13 und 14) löscht, und mit neuer Aufteilung neu anlegt.


Die Partitionen 11 bis 14 löschen:
Code:
Command (m for help): [color=blue]d[/color]

Partition number (1-14): [color=blue]14[/color]

Command (m for help): [color=blue]d[/color]
Partition number (1-13): [color=blue]13[/color]

Command (m for help): [color=blue]d[/color]
Partition number (1-12): [color=blue]12[/color]

Command (m for help): [color=blue]d[/color]
Partition number (1-11): [color=blue]11[/color]

Jetzt kann man daran gehen, die Partitionen der Reihe nach neu anzulegen. Man muss dabei unbedingt die Reihenfolge einhalten, da das System die Mountpoints ansonsten nicht korrekt setzen kann. Als Startcylinder muss man immer den Endcylinder der vorhergegangenen Partition "+1" vergeben. Mit "p" kann man sich immer die aktuelle Partitionierung anzeigen lassen.

Für den neuen Endcylinder muss man rechnen, da die Cylinder eine Größe von 32kB haben:
Größe der Partition = (Endcylinder - Startcylinder) x 32kB
Also in meinem Beispiel die neue Größe für /data: 62825 - 42625 = 20200 x 32kB = 646400kB = ~650MB

Code:
Command (m for help): [color=blue]n[/color]
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
[color=blue]l[/color]
First cylinder (53-238592, default 53): [color=blue]42625[/color]
Last cylinder or +size or +sizeM or +sizeK (42625-238592, default 238592): [color=blue]62825[/color]
[i][color=Orange]Die neue Größe für /data ist ~640MB[/color][/i]
Command (m for help): [color=blue]n[/color]
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
[color=blue]l[/color]
First cylinder (53-238592, default 53): [color=blue]62826[/color]
Last cylinder or +size or +sizeM or +sizeK (62826-238592, default 238592): [color=blue]67825[/color]
[i][color=Orange]Die neue Größe für /cache ist ~160MB[/color][/i]

Command (m for help): [color=blue]n[/color]
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
[color=blue]l[/color]
First cylinder (53-238592, default 53): [color=blue]1345[/color]
Last cylinder or +size or +sizeM or +sizeK (1345-1856, default 1856): [color=blue]1856[/color]
[i][color=Orange]Diesen Bereich habe ich genau gleich wieder angelegt, wie er schon zuvor war[/color][/i]
Command (m for help): [color=blue]n[/color]
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
[color=blue]l[/color]
First cylinder (53-238592, default 53): [color=blue]67826[/color]
Last cylinder or +size or +sizeM or +sizeK (67826-238592, default 238592): [color=blue]238592[/color]
[i][color=Orange]Die neue Größe für /data ist ~5,464GB[/color][/i]

Übere den Befehl "p" kann man die neu erstellte Partitionstabelle nun kontrollieren:

Code:
Command (m for help): [color=blue]p[/color]

Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
4 heads, 16 sectors/track, 238592 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1               1          32        1023+  0 Empty
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2              37          52         512  f0 Linux/PA-RISC boot
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3              33          36         128  f0 Linux/PA-RISC boot
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4              53      238592     7633280   5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5              65         320        8192  4a Unknown
/dev/block/mmcblk0p6             321         416        3072  83 Linux
/dev/block/mmcblk0p7             417         576        5120  70 Unknown
/dev/block/mmcblk0p8             577         832        8192  83 Linux
/dev/block/mmcblk0p9             833        1344       16384  48 Unknown
/dev/block/mmcblk0p10           1857       34624     1048576  83 Linux
/dev/block/mmcblk0p11          42625       62825      646432  83 Linux
/dev/block/mmcblk0p12          62826       67825      159992  83 Linux
/dev/block/mmcblk0p13           1345        1856       16376  83 Linux
/dev/block/mmcblk0p14          67826      238592     5464536  83 Linux

Partition table entries are not in disk order

Wenn nun alles passt, die Partitionsgrößen und die Start und End- Zylinder in Ordnung sind, kann man mit "w" Speichern und Beenden

Code:
Command (m for help): [color=blue]w[/color]
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

Die Partitionen sind jetzt also neu erstellt, aber noch nicht formatiert!
Alle Partitionen müssen nun einzeln formatiert werden:

Wichtig:
Die mir unbekannte Partition #13 wird nicht angegriffen.
Ich habe es nicht geschafft, /data mit FAT32 bzw vfat zu formatieren. Es wurden nur Fehler ausgegeben. Stattdessen wird ext2 verwendet. Keine Sorge - Beim ersten Systemstart wird die Partition dann durch das Android System erkannt und richtig neu formatiert ;)

Code:
[i][color=Orange]Hier wird /data formatiert:[/color][/i]
127|root@android:/ # [color=blue]mke2fs /dev/block/mmcblk0p11[/color]
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
40480 inodes, 161608 blocks
8080 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=167772160
5 block groups
32768 blocks per group, 32768 fragments per group
8096 inodes per group
Superblock backups stored on blocks: 
	32768, 98304

Writing inode tables: done        and filesystem accounting information: done

This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

[i][color=Orange]Hier wird /cache formatiert:[/color][/i]
root@android:/ # [color=blue]mke2fs /dev/block/mmcblk0p12[/color]                               
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
40000 inodes, 159992 blocks
7999 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
20 block groups
8192 blocks per group, 8192 fragments per group
2000 inodes per group
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

[i][color=Orange]Hier wird /sdcard formatiert:[/color][/i]
root@android:/ # [color=blue]mke2fs /dev/block/mmcblk0p14[/color]
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
261120 inodes, 1043456 blocks
52172 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1069547520
32 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


Zusammengefasst:

Es wurden die einzelnen Partitionen gelöscht und mit geänderten Größen neu erstellt. Danach wurden sie formatiert.
Ob das alles funktioniert hat, kann man im Recovery testen, indem man unter "Mounts" alle Bereiche mounted. Wenn das funktioniert, dann sieht das schon sehr gut aus. Wenn hier Probleme auftreten muss man die Partitionierung (fdisk) und die Formatierung nochmals überprüfen.

Wenn das nun alles funktioniert, kann man die adb shell verlassen und das Handy neu starten.
Code:
root@android:/ # [color=blue]reboot[/color]

Der erste Neustart wird länger dauern, da das Handy einen kompletten Werksreset erlebt hat.
Der interne Speicher (/sdcard) wird dann erkannnt, man wird gefragt ob man ihn formatieren will. Natürlich mit JA beantworten.
Das System läuft nun wieder, mit den geänderten Dateisystemgrößen.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: iSchneiderle und snoopy-1
Die Frage ist, was bei sowenig Speicher eine Aufteilung bringen soll. 2/4 GB scheint mir schon brauchbar. Wenn man für Apps (/data) noch weniger bereitstellt, kann man eh kaum was installieren, was eine Vergrößerung von /sdcard obsolet macht.

Besser währe es, wenn man den internen Speicher ganz für Apps bereitstellt und eine externe SD-Card (/sdcard1) aus sdcard0 mounted.

Man kann auch nicht genug betonen: Wenn ihr euch vertippt oder einfach den o.g. Partitionsnamen (mmcblk...) nehmt für ein anderes Handymodell brickt ihr euer Handy - mit viel Pech ohne Möglichkeit es ohne Einschicken wiederherzustellen. Ich würde mich an sowas nicht rantrauen, das Risiko wäre mir zu hoch im Vergleich zum Gewinn. Und ich hab schon 4 Jahre Android auf dem Buckel...
 
Ich bin voll und ganz bei dir!
Die Sinnhaftigkeit ergibt sich dann, wenn man so wie beim Xperia U keine externe Speicherkarte hat.
Bei so ziemlich allen neueren Geräten dürfte das sowieso kein Thema sein, da eigentlich immer genug Speicher verbaut wird.
Bei mir waren jedenfalls die 2GB für /data immer viel zu viel, und die 4GB /sdcard zu wenig ;)


Auf jeden Fall ist nochmals zu betonen, dass man dabei sein Handy massiv bricken kann. Das man es dann mit Flashtool wiederherstellen kann kann sein, muss es aber nicht - bei meinem Xperia U hat es jedenfalls funktioniert.
 
  • Danke
Reaktionen: TimeTurn
Achso, das das U keinen microSD-Card Slot hat, is mir neu :) Nunja dann ist das ne Überlegung wert. Meine 64 GB Karte ist ja schon mehr als zur Hälfte gefüllt :flapper:
 
Woher kriege ich denn eine brauchbare ADB shell für WIn XP?
 
So... nachdem ich mir diesen (von dir empfohlenen) Thread bereits vor einem halben Jahr angesehen habe, bin ich nun erneut hier.
Die Partitionen werden gelöscht und neu angelegt, soweit kenne ich das im Prinzip auch schon vom PC. Da ist es logisch, dass die neuen Partitionen anschließend blitzeblank sind.
Meine Frage ist nun: Kriege ich sämtliche Daten wieder drauf, ohne dass mein Android etwas davon mitbekommt? Ich meine, es geht ja nicht nur um Fotos oder Musik, sondern auch um wichtige Systemdateien. In /data sind zum Beispiel die ganzen Apps gespeichert.
Wenn ich nun also ein laufendes Betriebssystem habe, komplett eingerichtet mit allen möglichen Apps, Spielständen usw - wenn ich deine Anleitung ausführe und die zuvor gesicherten Dateien wieder auf die neuen Partitionen draufkopiere, verhält sich mein Handy dann exakt so wie vorher? Oder muss ich Apps neuinstallieren oder ähnliches?
 
Ich habe es bei meinem LG am Schluß gelassen. Ich hatte 23 Partitionen und es war einfach nicht festzustellen, was in welcher gespeichert war. Ich habe dann eine SD-Karte eingesteckt und einige APPs dorthin ausgelagert.
 
@Romplayer
Das ist das gleiche wie wenn du eine Custom ROM aufspielst. Da wird ja auch /system und /data gewiped. Da gibt es unzälige Backup/Restore Strategien, mit denen das geht.
Ich nutze dazu - so wie die meisten - Titanium Backup. Das legt die Sicherungen auf die /sdcard ab, die können dann auch wiederhergestellt werden.
 
Also mit Titanium Backup eine komplette Sicherung von /data machen.
Anschließend /data und /sdcard auf den PC kopieren.
Partitionen formatieren und neu einrichten.
Dann hat man zunächst ein komplett neues System.
Darauf erneut Titanium Backup installieren und die /data Sicherung wiedereinspielen.

Soweit richtig?
Und nochmal: Danach ist alles exakt so wie zuvor? Oder muss man trotzdem noch bei einigen Apps spezielle (wenn auch unkomplizierte) Sachen durchführen, damit wieder alles wie zuvor ist (so wie man z.B. bei Windows-PCs Office neu aktivieren muss)?

Und was ist eigentlich mit den anderen Partitionen? Das Handy hat ja noch mehr als nur /data und /sdcard. Findet das System das nicht seltsam, wenn es mit gewipter /data das erste Mal bootet, aber in den anderen Ordnern im Root-Verzeichnis noch was drin ist?
 
Die Sache funktioniert da ein bisschen anders:
Titanium Backup speichert dir die Apps (also die .apk Datei) + die Hintergrunddaten der App, die auf /data liegen. Es können damit also nur einzelne Apps - es ist ja alles eine App - gesichert werden, so auch Kontakte, SMS, WLAN Hotspots, udgl.

Apps werden bei Android in /system/app (=SystemApps) und /data/app (=UserApps)in Form der .apk Datei installiert. Nur UserApps können ohne root verändert werden.
Das Verzeichnis "/", also das Root Verzeichnis, gibt es quasi nicht, das wird bei jedem Systemstart durch das Android System in einer Ramdisk generiert, und die einzelnen realen Partitionen dorthin eingebunden. Die anderen Unterverzeichnisse wie /etc, /dev, /sys, usw. werden beim Bootvorgang aus dem System heraus generiert.

Wenn du nun bei einem eingespielten System die /data partition formatierst (=wipe data) dann ist das so, als ob du die Firmware neu aufspielen würdest. Es sind alle Daten + Apps weg und das System muss neu eingerichtet werden. Die System Apps (wie der Launcher, Statusleiste, Google Apps,...) sind ja noch immer unangetastet auf /system/app geblieben.

Für den Vorhaben müsstest du also als erstes mit Titanium Backup eine Sicherung deiner Apps + Anwendungsdaten (Kontakte, WLAN Hotspots,...) machen.
Danach den gesamten Inhalt von /sdcard auf einem PC sichern.
Dann umpartitionieren
Daten wieder zurück auf /sdcard (mit der geänderten Größe)
Danach Titanium neu installieren und die Apps wiederherstellen.

Bis auf das zwischendurch auf den PC stellen ist das übrigens auch das Vorgehen, was man i.d.R. beim Flashen einer Custom Rom macht.
Ich möchte dich aber darauf hinweisen, dass auch der Umgang mit Titanium ein bisschen Erfahrung benötigt. Man kann nämlich nicht plump einfach alle Apps raussichern und dann wieder zurückspielen. In manchen Fällen spielt da das System dann nämlich verrückt :razz:.
 
Hmm. Also wieviel Zeit müsste man da insgesamt für die ganzen Schritte einrichten, bis das System anschließend wieder genauso aussieht wie vorher (bis auf neue Partitionengrößen)?
Würde das mit der neuen Partitionseinteilung nämlich schon ganz gerne durchziehen, aber auf ein komplett neues Einrichten vom Handy inklusive allen Apps, Einstellungen etc hätte ich zum Beispiel keinen Bock. Ich würde also gerne möglichst viel automatisiert haben, je mehr ein Tool wie Titanium Backup da also übernimmt, desto besser.
Spricht was gegen Backup und Wiederherstellung mit CWM? Oder ist das gegenüber Titanium Backup unterlegen bzw funktioniert nicht wenn man bspw Partitionsgrößen ändern würde?
 
Zuletzt bearbeitet:
Mit dem CWM Restore (Data only) müsste es eigentlich auch funktionieren, da du ja /system unverändert lässt. Du musst aber trotzdem immer damit rechnen, dass es nicht funktioniert, dann solltest du halt das Titanium Backup parat haben! :cool:
 
Zuletzt bearbeitet:
Alles klar. Also sicherheitshalber doppeltes Backup von /data machen, /sdcard hingegen muss nicht manuell gebackuped werden sondern kann einfach aufn PC gezogen werden.
Wenn ich über CWM ein Restore mache und das noch bevor dem ersten Booten vom Handy, kriegt Android ja noch nicht einmal mit, dass es gewiped wurde, oder?
Habe gelesen, dass man bei Titanium Backup die Android-Systemeinstellungen lieber nicht sichern sollte, weil es da öfter mal Probleme gibt, aber das dürfte dann ja bei einer Sicherung über CWM nicht der Fall sein, oder?
So wie ich mir das also vorstelle, müsste dann beim ersten Mal Booten wieder alles so sein wie vorher, inklusive allen Einstellungen, sowohl von Android wie auch den Apps.
Ein Befüllen von /sdcard nach den Anpassungen dürfte bereits möglich sein, bevor man Android einmal gestartet hat, richtig? Weil man beim Partitionieren ja ebenfalls schon auf den Handyspeicher Zugriff hat ohne dass Android läuft, dann müsste das Kopieren von Daten ebenfalls funktionieren.
 
Romplayer schrieb:
Wenn ich über CWM ein Restore mache und das noch bevor dem ersten Booten vom Handy, kriegt Android ja noch nicht einmal mit, dass es gewiped wurde, oder?

Wird nicht funktionieren, da /sdcard durch das System formatiert wird. Zumindest bei mir hab ich das über adb direkt nach dem partitionieren nicht zusammen gebracht.

Du solltest also so vorgehen:
-CWM Backup
-Titanium Sichern
-Alles von der SDKarte auf den PC
-Umpartitionieren
-Booten (/sdcard wird formatiert), alles zurück auf die SDKarte kopieren
-CWM Restore Data (mit Wipe Cache und Wipe Dalvik Cache natürlich)
-Neustart -> Alles sollte wieder normal laufen, so wie vorher, ggf. sind ein paar Playstore Updates von System Apps nötig.



Wenn es schief geht (Bootloop, Softbrick) über das Flashtool die gesamte Firmware neu flashen, neu rooten, CWM drauf, CWM Restore /system und /data...
 
sessions schrieb:
...Achtung! Ich weiß nicht, was mmcblk0p13 ist!...

...das ist die swap-Partition (siehe: [Tutorial]Partitionsgrößen ändern)

Du solltest in Deinem Tutorial auch erwähnen, dass man nach dem Anlegen der swap-Partition, diese mit

"mkswap L SW1 /dev/block/mmcblk0p13"

wieder als solche bereitstellen sollte (ansonsten kann euer System eben nichts swappen) und außerdem, dass nach jedem Neustart

"su c swapon /dev/block/mmcblk0p13"

manuell eingegeben werden muss. Ich bin mir allerdings nicht sicher, ob man das auch direkt, wir unter "Standard-Linux" in der /etc/fstab eintragen kann.

Alles in allem 'ne nette Anleitung :thumbup:
 
  • Danke
Reaktionen: sessions

Ähnliche Themen

L
Antworten
0
Aufrufe
845
Ladyontour
L
meetdaleet
Antworten
200
Aufrufe
93.717
visagesauvage
V
Steinlaus
Antworten
0
Aufrufe
2.195
Steinlaus
Steinlaus
Zurück
Oben Unten