Database Develop

[CM7] Boot loop issue - Noticed more people now seeing this issue

I noticed more people are having same issue as me and I wanted to create a thread to find the solution.
I was running CM7 RC4 / OC 40311 - It was running fine and one day system hung and so I rebooted and that was it.
Symptom :
System boots and pass the "Touch the future Reading" and displays "ANDROID _" on the bottom of the screen and after 10-15 sec it reboots and loop this process.
Things I tried so far :
CWR 3.0.0.5
- Repratition to stock nook.
- Getting error when I try to format system and data - I thought it was because CM7 was setting system to ext4.
- ADB and DD boot.img, System.img and copy Factory to mmcblk0p3
- Try to restore from back up I made
- Nothing works but goes back to boot loop
CWR 3.0.0.6 - One I got from CM7 install to emmc thread
- System format works
- Install latest nightly
- Restore from back up
- ADB can't find device - This is odd and couldn't find a way to fix it yet.
- Tried to install Stock zip but going back to CM7 boot loop
CWR 3.0.1.0
- Can't format data/system
- ADB to delete partitions and create them again but it doesn't help
- Tried all zip files to bring it back to stock - no go
- ADB to copy Factory.zip to emmc partition - umount and mount again then file I copied is gone.
- Deleted partitions and reboot but some how I got back to CM7 loop
If you are having same issue please post and share your experiences so we can find the solution!!!

tuxhacker said:
Symptom :
System boots and pass the "Touch the future Reading" and displays "ANDROID _" on the bottom of the screen and after 10-15 sec it reboots and loop this process.
Click to expand...
Click to collapse
This means the kernel is loading, and most likely the init.encore.rc is running as well. Have you tried grabbing a log from adb logcat? Or perhaps checking if the shell works?
tuxhacker said:
Things I tried so far :
CWR 3.0.0.5
- Repratition to stock nook.
Click to expand...
Click to collapse
How are you repartitioning?
tuxhacker said:
- Getting error when I try to format system and data - I thought it was because CM7 was setting system to ext4.
Click to expand...
Click to collapse
What is the error?
tuxhacker said:
CWR 3.0.1.0
- Can't format data/system
Click to expand...
Click to collapse
Again- if its getting an error, what is that error? Have you tried formatting manually?
tuxhacker said:
- ADB to delete partitions and create them again but it doesn't help
Click to expand...
Click to collapse
Errors? Logs?
You have to be more specific.

- I was flashing "repartition-boot-with-stock.zip" also tried to delete the partitions using fdisk - from adb shell
- And I was getting "Error formatting / system!" and "Error formatting /Data!" from CWR format system and format data
I also tried to format it manually using "mke2fs /dev/block/mmcblk0p1,2 and 3..."
And could you please tell me how to get the log?
Thank you.

have you tried booting off an cwr 3.0.1.0 bootable sd card and formatting reinstalling?

john10101 said:
have you tried booting off an cwr 3.0.1.0 bootable sd card and formatting reinstalling?
Click to expand...
Click to collapse
Yes I have. I tried several times. It seems like my nook is a read only device now. It won't take any changes.

tuxhacker said:
Yes I have. I tried several times. It seems like my nook is a read only device now. It won't take any changes.
Click to expand...
Click to collapse
unpossible!

chisleu said:
unpossible!
Click to expand...
Click to collapse
Here's one example. I did this from CWR 3.0.1.0.
- Mount mmcblk0p3 to emmc
- Copied factory.zip to emmc
- ls -l /emmc to check the new file
- umount /emmc
- Mount /emmc again
- ls -l as you can see old file date again.
Code:
~ # mount -w /dev/block/mmcblk0p3 /emmc
mount -w /dev/block/mmcblk0p3 /emmc
~ # mount
mount
/dev/block/mmcblk0p3 on /emmc type ext2 (rw,errors=continue)
~ # exit
C:\Program Files\Android\android-sdk\platform-tools>adb push factory.zip /emmc
3779 KB/s (168335604 bytes in 43.492s)
C:\Program Files\Android\android-sdk\platform-tools>adb shell
~ # ls -l /emmc
ls -l /emmc
-rw-rw-rw- 1 root root 168335604 Apr 17 04:06 factory.zip
drwx------ 2 root root 12288 Oct 23 05:27 lost+found
-rw-rw-rw- 1 root root 2567 Nov 17 22:27 rombackup.zip
~ # umount /emmc
umount /emmc
~ # mount /dev/block/mmcblk0p3 /emmc
mount /dev/block/mmcblk0p3 /emmc
~ # ls -l emmc
ls -l emmc
-rwxrwxrwx 1 root root 168332495 Nov 11 23:35 factory.zip
drwx------ 2 root root 12288 Oct 23 05:27 lost+found
-rw-rw-rw- 1 root root 2567 Nov 17 22:27 rombackup.zip
~ #

May I ask why you had to mess around with the partitions at all?

lechiffre said:
May I ask why you had to mess around with the partitions at all?
Click to expand...
Click to collapse
It was keep rebooting itself so I was trying to reflash CM7 but didn't work. Next I was going back to stock to start over and that didn't work. Found one thread about DD boot.img, system.img and factory.zip to mmcblk0p3 then 8 failed attempt to restore to stock. etc...
I'm sure that while I was trying to fix I made more mess.

I did adb logcat and got the permission denied error.
Code:
C:\Program Files\Android\android-sdk\platform-tools>adb logcat
- waiting for device -
- exec '/system/bin/sh' failed: Permission denied (13) -

Did you try going into clockwork recovery and using the fix permissions option?

tuxhacker said:
It was keep rebooting itself so I was trying to reflash CM7 but didn't work. Next I was going back to stock to start over and that didn't work. Found one thread about DD boot.img, system.img and factory.zip to mmcblk0p3 then 8 failed attempt to restore to stock. etc...
I'm sure that while I was trying to fix I made more mess.
Click to expand...
Click to collapse
I still don't get why you decided the partitions were faulty.
This might not help you now but might help others in you situation. IMO the process should be when you encounter bootlooping:
1. Reflash current OS using CWR 3.1.0 uSD.
2. If Step 1 fails, using CWR 3.1.0 uSD: format /system /data /cache. Attempt to install CM7. If CM7 install fails, attempt to install stock.
3. ***Requires a a working CWR backup which should contain your original boot partition***
If Step 2 fails, using CWR 3.1.0 uSD: format /system /data /cache and /boot. Restore stock /boot partition only via advanced restore. Attempt to install CM7 or stock.
4. ONLY if the previous steps fail should you even touch any partition tool. I've never had to use any, but I've never messed with the partitions in the first place (ie double booting off eMMC).

Just wanted to share that getting stuck on the boot screen may not have anything todo with what or how you've flashed.
On a fresh install/flash of CM7 I can reboot just fine as many times as I want. As soon as I restore all my apps and reboot I get stuck on the boot screen.
So SOMETHING amongst all the apps I have backed up gets me stuck on the boot screen. Really don't want to go through a reboot for each app one at a time though

FIXED - wipe battery status in CWM
This problem seems to occur when the battery runs out, Nook is plugged in and then it hangs at "the future..."
So to fix this problem, boot into CWM (using CWM for SD) and go to Advanced-Recovery and Wipe Battery Status. Remove the CWM SD and go back to the root menu and reboot.
Your CM7 would boot now just fine. I don;t know what the problem is yet, but that seems to fix it. It saved me from reinstall.
the Nook gets into this state only when the battery is completely drained.

TuxHacker, did you ever resolve your issue of what seems to be the internal memory being in a write-protected state? I'm in the exact same boat you are but instead of CM7 I got CWR 3.0.0.5 installed on my boot and brianf's custom froyo installed.
I agree it seems like the device is now write protected as I've mounted boot/system/media and deleted everything in there, ls'd to double check, but once I remount, all the old stuff is back there again.
I also tried using samuelhalff's NookUMC app to mount all the partitions in windows, deleted everything, and upon remount, all the files are back. The NookUMC app was the one I initially used to copy a bunch of mp3's and vids to the media partition in the first place and now this partition behaves as if it was write-protected as well.
lechiffre said:
I still don't get why you decided the partitions were faulty.
This might not help you now but might help others in you situation. IMO the process should be when you encounter bootlooping:
1. Reflash current OS using CWR 3.1.0 uSD.
2. If Step 1 fails, using CWR 3.1.0 uSD: format /system /data /cache. Attempt to install CM7. If CM7 install fails, attempt to install stock.
3. ***Requires a a working CWR backup which should contain your original boot partition***
If Step 2 fails, using CWR 3.1.0 uSD: format /system /data /cache and /boot. Restore stock /boot partition only via advanced restore. Attempt to install CM7 or stock.
4. ONLY if the previous steps fail should you even touch any partition tool. I've never had to use any, but I've never messed with the partitions in the first place (ie double booting off eMMC).
Click to expand...
Click to collapse
I can't speak for TuxHacker, but mucking around with the partitions seems to be a last ditch effort to at least *change* anything on the device. I've followed a few guides on here about showing the partition table and mine matches a stock partition table. I haven't gotten around to actually modifying any of the partitions yet though...
In all of your steps, the first sub-step is to format one or all of /system /data /cache /boot. This is precisely the step that fails for us with "Error Formatting /system!" or any of the others The only CWR that it doesn't fail on is CWR 3.0.0.6, but any flashes don't take, the NC just reverts back to what it was just before the system decided to go read-only.
I'm running off SD now but that is a pretty crappy experience... if anyone can fix the mess we got ourselves into I will def buy that guy a cold one!

drazil22 said:
In all of your steps, the first sub-step is to format one or all of /system /data /cache /boot. This is precisely the step that fails for us with "Error Formatting /system!" or any of the others The only CWR that it doesn't fail on is CWR 3.0.0.6, but any flashes don't take, the NC just reverts back to what it was just before the system decided to go read-only.
I'm running off SD now but that is a pretty crappy experience... if anyone can fix the mess we got ourselves into I will def buy that guy a cold one!
Click to expand...
Click to collapse
Yes. And on CWR 3.0.0.6 I can't connect via ADB so can't do much with it. On CWR 3.0.1.0 and CWR 3.0.0.5 I can connect via ADB but can't format. I tried all the ADB connect tips and tricks but no go.
I think it coubd be a permission issue since I get - exec '/system/bin/sh' failed: Permission denied (13) - when I tried ABD logcat while its rebooting.
I'm also running off SD now and it is really bad.

I'm in the same boat as you guys and I just wanted to add my two cents.
I've tried multiple times to use the partitioning tools that drazil22 is talking about, but every time I reboot, the partitions come back. What is weird is that while I'm still in adb, after I've written the partition table back to the device, is that it shows the new partition table when I tell it to print it out. I can exit all the way out of adb and, unless I've rebooted my nook, the partitions are back to the way they were. However, once I reboot my nook, the partitions come back...
I've gone as far as deleting every single partition and then rebooting just so that I could have a brick to take back to B&N, but the stupid partitions keep coming back...

lol that's what I was thinking too... brick the thing and get the store to reflash it, as someone else with a bricked nook did. I think the store must have another utility or device to reflash it back to stock.
The weird thing is any changes I make stay for the session until I unmount. I tried to copy the system.img and boot.img which is a little over 500MB to the /media partition (mmcblk0p8) but because I filled it with mp3's and videos, only about 200MB was free and of course the adb push errored out saying not enough space. I then navigated to the /media partition, deleted a bunch of videos and was able to adb push the two files over. I was also able to run the dd commands and got the expected results. Upon reboot, of course nothing got dd'd, the two .img files I copied to /media were gone, and the videos I deleted to free up space were back!
I was also hoping that with the new B&N update to 1.20, they might have released a flashing utility but I guess that was wishful thinking...
Edit: one other peculiar thing I noticed is that when I use adb when booted into CM7 (using the SD), it shows the serial number as 11223344556677. When I use adb booted up using the CWR on my boot partition, or with a bootable SD, it shows the actual serial number written on the sticker behind the sd cover.
getllamasfast said:
I'm in the same boat as you guys and I just wanted to add my two cents.
I've tried multiple times to use the partitioning tools that drazil22 is talking about, but every time I reboot, the partitions come back. What is weird is that while I'm still in adb, after I've written the partition table back to the device, is that it shows the new partition table when I tell it to print it out. I can exit all the way out of adb and, unless I've rebooted my nook, the partitions are back to the way they were. However, once I reboot my nook, the partitions come back...
I've gone as far as deleting every single partition and then rebooting just so that I could have a brick to take back to B&N, but the stupid partitions keep coming back...
Click to expand...
Click to collapse

This is odd, but I dont think this is limited to CM7 as I've seen it happen with different phones running AOSP. Over on the Evo there was numerous accounts of peoples devices suddenly rebooting and then getting stuck in a bootloop, all partitions seemed to be corrupted including the recovery partition and there was absolutely no way to write to the system anymore. Complete booting brick. No one was able to find the cause and no one was able to find a fix.

RileyGrant said:
This is odd, but I dont think this is limited to CM7 as I've seen it happen with different phones running AOSP. Over on the Evo there was numerous accounts of peoples devices suddenly rebooting and then getting stuck in a bootloop, all partitions seemed to be corrupted including the recovery partition and there was absolutely no way to write to the system anymore. Complete booting brick. No one was able to find the cause and no one was able to find a fix.
Click to expand...
Click to collapse
I really hope this isn't true...
On an unrelated note: Do you think that B&N would notice if I microwaved my nook for a few seconds?

[MOD] Get more usable space with smaller custom roms

Hello
scroll to the bottom of this post for an update
So, i've been searching now for a while for a guide on how to get more internal space and reduce the /system partition of my sgs3,
since many custom roms are much smaller in size compared to stock.
Since i haven't found any, i've figured i'll try doing it myself.
This requires some linux/unix shell knowledge, so unless you used linux shell and/or adb before, i don't recommend trying this.
Also, i have done this on GT-I9300, the international version. If yours is not the same, the partition layout will probably differ
Requirements:
* parted ( can't post links yet.. )
* adb ( android sdk, platform tools )
* CWM recovery installed
* Custom ROM zip on your PC to upload after the operation.
Alright, so here goes. ( since i already mentioned this is an advanced operation, i'll keep it pretty basic )
1. Reboot into CWM recovery
2. Unmount everything possible (either in CWM or 'adb shell', i used the latter - more reliable i would guess)
3. adb push X:\xx\xx\parted /
4. adb shell
5. chmod +x parted
Now the real fun begins.
6. /parted /dev/block/mmcblk0
This will launch parted. type 'p' and press 'enter', you'll see something like this:
Code:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
Now you need to calculate the partition sizes you actually need. Ignoring first partitions up to CACHE not to mess things up.
As far as i know, the CACHE partition is used for OTA, hence it's size - to fit ~ size of the rom. Personally i have no intention of using OTA, so i made the partition 100mb. I'm definitelly no expert in hacking android yet, but personally i haven't noticed myself using /cache more than that.
HIDDEN contains some preloaded apps - not valid in case of custom roms. I made it 1mb.
Not sure what OTA partition is used for, but again, i don't use OTA so i don't really care. 1mb.
As for SYSTEM, this depends how big is your custom rom. I currently use SlimBean which is ~100mb together with gapps, but just in case i've set the size to 300mb.
and the rest goes for USERDATA. I think you can already forsee a few more GBs for internal storage
So, just remove all the partitions that need to be resized and recreate them:
Code:
(in parted)
rm 8
rm 9
rm 10
rm 11
rm 12
then issue 'mkpart' 5 times to recreate the partitions.
When asked for a name, just press enter (we'll set the names later, since mkpart didn't change the names for me anyway)
When asked for type, you can either enter ext4 or simply press enter. We'll format partitions afterwards anyway.
When asked for start, enter the value from last partition's 'End'. For CACHE that would be the end of RADIO, so 92.3MB
For End enter the size you want. 10KB, 20MB, 1GB - annotations accepted.
After you create a partition, issue 'p' to check it's End for the next partition's start.
For USERDATA End just enter what you saw in the beggining, 15.8GB in my case.
exit parted, 'q'
7. format new partitions (except OTA)
Code:
mke2fs -T ext4 /dev/block/mmcblk0p8
mke2fs -T ext4 /dev/block/mmcblk0p9
mke2fs -T ext4 /dev/block/mmcblk0p10
mke2fs -T ext4 /dev/block/mmcblk0p12
For USERDATA i also used an option '-m 0.2' to get those extra 300mb from ext4 reserve.
8. mount /data/ ; mkdir /data/media
9. exit adb ; adb push X:\xx\customRom.zip /data/media
10. Flash new rom in CWM and reboot.
That's pretty much it. At least it was for me.
I may have missed something, but i'm now assured that this is possible.
For reference:
Code:
Before:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
After:
Code:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 192MB 99.7MB ext4 CACHE
9 192MB 500MB 308MB ext4 SYSTEM
10 500MB 501MB 1000kB ext2 HIDDEN
11 501MB 502MB 1000kB OTA
12 502MB 15.8GB 15.3GB ext4 USERDATA
So now i have 13.8Gb of usable space on my sgs3 and i'm pretty happy about it.. No need to convert user apps to system apps in titanium any more..
Since i'm not sure about the effects of this for the long term, please provide me feedback if it went ok for you or not.
And if you have any points to make why this is not good i would also appreciate that.
UPDATE:
First of all, parted seems to be included in CMW, at least the cwm-touch-6.0.1.2 version has it ( noticed only after a while )
So no need to look for parted binaries if you're using that.
Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8.
So that's all fine. In case you don't want to try .pit method, you could simply restore the partition table using parted. Basically resize the partitions using same method to the original sizes. haven't tried this myself, but i imagine it should work
One last note, since i was too eager to do this all, i didn't notice the 'unit' command in parted. basically you can use 'unit kib', 'unit mib' to get the 'computer' values for sizes, which actually make more sense looking at parted output. the OTA partition is for example exactly 8mb (mib).
To get the 1000s units, use 'unit kb', 'unit 'mb' or 'unit compact' which selects the unit automatically based on partition size.

Alright,you've got some balls dude.I got to give you that!Bravo,really nice work.I don't need it atm (32gb version rocks hard),but I may do it for the fun of it.

Love it!... but there will be someone posting here, crying their eyes out before long (no sympathy from me however).
So much for the 'xda-downloaders.com' mentality and moar powah to the developer!
I salute you.

Very useful man. Thanks!
Sent from my GT-I9300 using xda app-developers app

Nice mod man!
You've got balls of steel trying to do that,i really admire you...
Anyway,excuse me if i'm wrong but i think applications you get form market get downloaded in cache first?
If you shrink that partition won't you have issues with apps?

1024Kb is one MB not 1000. it is 2^10 for a full MB. Great guide though, and VERY nice detailed instructions. Thank you, and you might wanna put a "I am NOT responsible" banner at the top!!!

nfsmw_gr said:
Nice mod man!
You've got balls of steel trying to do that,i really admire you...
Anyway,excuse me if i'm wrong but i think applications you get form market get downloaded in cache first?
If you shrink that partition won't you have issues with apps?
Click to expand...
Click to collapse
You might have issues if you try to download apps that the apk is bigger than the cache partition. Otherwise i don't think there's an issue. And since i don't download anything above 100mb, that's why i made it so. and even then, you can just symlink some folder in /data to /cache and you'll have all the space in the world for you cache..
b-eock said:
1024Kb is one MB not 1000. it is 2^10 for a full MB. Great guide though, and VERY nice detailed instructions. Thank you, and you might wanna put a "I am NOT responsible" banner at the top!!!
Click to expand...
Click to collapse
That's how parted displays it.

Ok, so 1000KB in parted equals 1024KBs or 1MB? Just trying to get this right...
Sent from my GT-I9300 using xda premium

b-eock said:
Ok, so 1000KB in parted equals 1024KBs or 1MB? Just trying to get this right...
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
1MB. In the guide above i have put 501MB for start and 502MB for end for OTA partition for example. That's 1MB in size, but gets displayed as 1000Kb. And 1000MB would be 1GB there.
I guess parted calculates in 10s and actually all of the hard drives are calculated like that on label. So in reality there's 16000000000 of bytes in my SGS3. divide that by 1024 a couple of times and you get lower 'actual' size. then file system format reduces usable space even more, but that's another subject...

Does this not qualify as Original Development .
OP i would PM a mod to ask for inclusion in Original i have .
jje

Well yes i guess. Just didn't have permissions to post there
If a mod reads this, feel free to move the thread. Otherwise i'll pm someone when i get home
Sent from my GT-I9300 using xda app

Hardware uses the industry-standard 10^3=1000 (according to sni: KiB) while software tends to use 2^10=1024 (according to sni: KB)
Sent from my GT-I9300 using xda premium

i made similar changes to my I9000 before, no problems at all
edit forgot to mention that the only thing you have to take care of is how to install newer roms with the new layouts in the future, but i bet with your knowledge in linux it wont be a problem to you at all

Will these changes in parted be saved into PIT structure?
Otherwise ODIN may repartition this if u will flash anything through it. Probably it won't touch data outside flashed part, so in this case it's still possible to flash for example recovery partition (in case if it get corrupted). If ODIN write some marks in all partitions every time then you may corrupt data on later partitions.
Btw, to make this thread useful, here is parted i've found on http://forum.cyanogenmod.com/topic/6433-solved-messed-up-partitions-on-internal-storage/ :
http://www.sendspace.com/file/w6hi6x

sorg said:
Will these changes in parted be saved into PIT structure?
Otherwise ODIN may repartition this if u will flash anything through it. Probably it won't touch data outside flashed part, so in this case it's still possible to flash for example recovery partition (in case if it get corrupted). If ODIN write some marks in all partitions every time then you may corrupt data on later partitions.
Btw, to make this thread useful, here is parted i've found on http://forum.cyanogenmod.com/topic/6433-solved-messed-up-partitions-on-internal-storage/ :
http://www.sendspace.com/file/w6hi6x
Click to expand...
Click to collapse
As far as I know Odin only repartitions the device if you include the correct pit for the device and check repartition.
L

9Lukas5 said:
As far as I know Odin only repartitions the device if you include the correct pit for the device and check repartition.
Click to expand...
Click to collapse
ODIN always read PIT file from device if you don't provide such. You can check ODIN logs. I believe, ODIN does following things:
1) if PIT file not provided, then read it from device
2) check file names assigned to every partition and pick them from supplied TAR file
3) write files directly (after un-sparse img files if required) to flash addresses taken from PIT.
so, if PIT structure in I9300 is not the same as GPT partition table, then you may mess data if you will accidentally flash parts beyond CACHE partition through ODIN.

A little update:
First of all, parted seems to be included in CMW, at least the cwm-touch-6.0.1.2 version has it ( noticed only after a while )
So no need to look for parted binaries if you're using that.
Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8.
So that's all fine. In case you don't want to try .pit method, you could simply restore the partition table using parted. Basically resize the partitions using same method to the original sizes. haven't tried this myself, but i imagine it should work
One last note, since i was too eager to do this all, i didn't notice the 'unit' command in parted. basically you can use 'unit kib', 'unit mib' to get the 'computer' values for sizes, which actually make more sense looking at parted output. the OTA partition is for example exactly 8mb (mib).
To get the 1000s units, use 'unit kb', 'unit 'mb' or 'unit compact' which selects the unit automatically based on partition size.

where can i get this "GT-I9300_mx_20120329.pit" if something went wrong ?

fuflo said:
[...] Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8. [...]
Click to expand...
Click to collapse
Do you mean that after repartitioning that way, you weren't able to flash e.g. a modem with Odin? Because I tried it just now, and for me it's working fine.
From my understanding about the .pit file, the pit gives informtion about the start and end point for the partitions. After we have repartitioned the device partially, for the changed partitoins the information in the pit file doesn't match anymore, but as kernel, modem, recovery, etc. are stored on the partitons 1-7 and we haven't changed them, Odin pulls the pit from our device and flash to modem e.g. to the place the information in the pit file says. So all flashing actions which only go to the partitions 1-7 shouldn't be problematic, only if you want to flash a whole samsung firmware with Odin you have to tick repartitioning and select the correct pit file in Odin.
And then I have a question regarding doing the same on the S4. The S4 has a protected bootloader as you maybe has heard of. Do you think this method is also usable on the S4 without the danger of a hard-brick? From the recovery all the partitions I want to change ( cache, system, data, ...) are also flashable, only those before are protected, so could/should it work? Invisiblek has written it would brick my phone :
invisiblek said:
DO NOT DO THIS
that link is for an exynos sgs3
our pit is signed. This will brick your device.
Click to expand...
Click to collapse
L

You are most likely correct with the first part of your post. I haven't tried flashing separate parts of a rom at that time, but it would most likely work.
Regarding S4, to be honest i have no knowledge of it. Even more so about signed stuff. From general knowledge, if the signature isn't connected the things you want to modify, it would probably work, but don't take my word for it. You'd better off discussing this in the S4 forums
Regarding GT-I9300_mx_20120329.pit, i later read that it's for 64gb version of i9300. Although it worked fine for me. As for where to get it, just google it.. there are zips all around the net with various versions, including this one.

Workaround for "read-only mode" - install to SD card

Here's a rough guide to how I got the official T-Mobile Froyo release running from the external SD card. Booting is done via fastboot tethered to a PC, but after that you can disconnect and keep running off the SD (provided you don't reboot.) If there's interest I can provide more info/files.
My tablet is stuck with stock recovery, and Android bootloops when I try to boot normally. I can "fastboot boot" CWM 3.0.2.0 (no success with anything else really -- still not sure why), so I've got root adb.
Get the official T-Mobile Froyo release, decrypt it with the matching recovery (also fastbooted), unzip it. Recompile both the recovery kernel and the Froyo OS kernel, hacking the SD devices to be swapped (external SD card becomes mmcblk3 and internal MMC memory is mmcblk2.) This is so you won't have to fiddle with references to device IDs in config files, installation scripts, etc.
Partition and format the SD card roughly according to the MMC partition layout for the partitions that show up in Linux, using GPT. Here're the commands I used from the recovery (shell, parted commands, shell):
Code:
umount /cache
umount /system
umount /data
umount /sdcard
parted /dev/block/mmcblk3
mklabel gpt
unit s
mkpart logical 34 35
mkpart logical 36 37
mkpart logical ext3 38 688166
mkpart logical ext3 688167 917543
mkpart logical ext3 917544 950312
mkpart logical ext2 950313 954409
mkpart logical ext3 954410 3051562
mkpart logical 3051563 3084331
mkpart logical 3084332 3117100
mkpart logical 3117101 3149869
mkpart logical 3149870 3182638
mkpart logical 3182639 3215407
mkpart logical ext3 3215408 3248176
mkpart logical fat32 3248177 7798552
mkpart logical 7798553 7831321
mkpart logical 7831322 7864090
name 1 SOS
name 2 LNX
name 3 APP
name 4 CAC
name 5 MSC
name 6 FDR
name 7 UDA
name 8 OLG
name 9 LGF
name 10 RES
name 11 RGN
name 12 VAR
name 13 USP
name 14 SDC
name 15 WP1
name 16 WP2
mke2fs /dev/block/mmcblk3p3; tune2fs -j /dev/block/mmcblk3p3
mke2fs /dev/block/mmcblk3p4; tune2fs -j /dev/block/mmcblk3p4
mke2fs /dev/block/mmcblk3p5; tune2fs -j /dev/block/mmcblk3p5
mke2fs /dev/block/mmcblk3p6
mke2fs /dev/block/mmcblk3p7; tune2fs -j /dev/block/mmcblk3p7
mke2fs /dev/block/mmcblk3p13; tune2fs -j /dev/block/mmcblk3p13
dd if=/dev/block/mmcblk2p15 of=/dev/block/mmcblk3p15 bs=1M
dd if=/dev/block/mmcblk2p16 of=/dev/block/mmcblk3p16 bs=1M
Note the dd for p15 and p16 -- these contain data like your device IDs and MAC addresses. I'm not sure if they are actually needed in Android (the bootloader can read the "real" read-only ones and passes them on the kernel command line), but to be safe we'll copy them.
The partition table then looks like this:
Code:
Model: SD SD04G (sd/mmc)
Disk /dev/block/mmcblk3: 4027MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 18.4kB 1024B SOS
2 18.4kB 19.5kB 1024B LNX
3 19.5kB 352MB 352MB ext4 APP
4 352MB 470MB 117MB ext3 CAC
5 470MB 487MB 16.8MB ext3 MSC
6 487MB 489MB 2098kB ext2 FDR
7 489MB 1562MB 1074MB ext3 UDA
8 1562MB 1579MB 16.8MB OLG
9 1579MB 1596MB 16.8MB LGF
10 1596MB 1613MB 16.8MB RES
11 1613MB 1630MB 16.8MB RGN
12 1630MB 1646MB 16.8MB VAR
13 1646MB 1663MB 16.8MB ext3 USP
14 1663MB 3993MB 2330MB fat32 SDC msftres
15 3993MB 4010MB 16.8MB WP1
16 4010MB 4026MB 16.8MB WP2
I shrunk data partitions down to fit my small SD card, and some are tiny because they aren't needed for anything but preserving the numbering.
Remove references to blob and boot.img from the update.pkg scripts (since they won't need to be flashed), rezip it, adb push it to the device, and install it using the CWM menu item.
Replace the kernel in boot.img (for SD device ID swap I mentioned above), and "fastboot boot" it. Mine looks like it's hung during the T-Mobile boot animation, but eventually gets through. Android should come up as normal, and you can disconnect from the PC and use it until you reboot. Mine's a little laggy on this first boot -- not sure if it's a slow SD card to blame, or if it's just how the first boot goes on this tablet. My 4G modem is not working right now, but everything else seems to work.
Superuser.zip can be installed with the same hacked CWM recovery.
I'm working on Honeycomb, but seem to be having early boot problems, and I'm wondering if "fastboot boot" is different enough from a regular flash boot that some kernels can't handle it.
P.S. If you're happy with what you're stuck with on /system etc, you could potentially use that from the built-in memory, and put only your read/write stuff on SD. You'd probably have to patch more initscripts etc to do that though.

There is no gingerbread reelase.

giveen said:
There is no gingerbread reelase.
Click to expand...
Click to collapse
Oops, meant froyo. My point was that the vold service in pre-HC releases might be easier to work with. I've booted my GB-based phone off of an SD card via fastboot before.

joeyhewitt said:
Oops, meant froyo. My point was that the vold service in pre-HC releases might be easier to work with. I've booted my GB-based phone off of an SD card via fastboot before.
Click to expand...
Click to collapse
have you seen the method used in general involving the holding of all buttons for 2min then performing a wipe of dalvik cache?

Nocturnal_50 said:
have you seen the method used in general involving the holding of all buttons for 2min then performing a wipe of dalvik cache?
Click to expand...
Click to collapse
Tried (minus removing capacitive cover -- maybe if I get more desperate I'll try) and it didn't work for me. Although I tried wiping the cache first, since that's what you said here. I guess I'll try the other order. I've already verified that formatting /cache has no effect (contents are still there), so unless it has unexplained side-effects I'm not very optimistic.
P.S. Wait, 2 minutes?! You said 15 seconds before. Edit: saw your new instructions, I'll try that.

joeyhewitt said:
Tried (minus removing capacitive cover -- maybe if I get more desperate I'll try) and it didn't work for me. Although I tried wiping the cache first, since that's what you said here. I guess I'll try the other order. I've already verified that formatting /cache has no effect (contents are still there), so unless it has unexplained side-effects I'm not very optimistic.
P.S. Wait, 2 minutes?! You said 15 seconds before. Edit: saw your new instructions, I'll try that.
Click to expand...
Click to collapse
to be honest I was drinking the night I got it resolved on mine so 2min would have seemed extremely short, so stick with the 2min for now... if it some how happens to fix it then I will be looking into alternative measures to get this thing back to RW (it will probably involve acquiring a RO streak)

I think my problems booting the kernels in newer ROMs and recoveries are because I'm stuck using the old bootloader. Can anyone confirm that there are in fact incompatibilities? Since I can't just flash the new one, anyone know how to boot an nvflash-pushed bootloader image into fastboot mode, so I can then hopefully push a kernel image and boot that? Or perhaps can I patch the new kernel to work with the old bootloader?
Thanks.

joeyhewitt said:
I think my problems booting the kernels in newer ROMs and recoveries are because I'm stuck using the old bootloader. Can anyone confirm that there are in fact incompatibilities? Since I can't just flash the new one, anyone know how to boot an nvflash-pushed bootloader image into fastboot mode, so I can then hopefully push a kernel image and boot that? Or perhaps can I patch the new kernel to work with the old bootloader?
Thanks.
Click to expand...
Click to collapse
any change to the bootloader is included in the kernel, unless you mean recovery then you are just running in circles making everyone wonder what you are going on about

Nocturnal_50 said:
any change to the bootloader is included in the kernel, unless you mean recovery then you are just running in circles making everyone wonder what you are going on about
Click to expand...
Click to collapse
Sorry, I'm talking about the Tegra low-level bootloader, "bootloader.bin", which is flashed to the EBT partition (and it or possibly a variant is used for nvflash; I'm not sure if they are interchangeable.) I see the official Froyo release has one with a date March 2011 (shown on-screen when in fastboot mode), and looking at the one from the HC release in a hex editor (buried in the "blob" file from the update pkg), it says December 2011. This doesn't necessarily prove there are changes, but given the usual requirements to flash the official HC release before the third-party ROMs or recoveries, I think this is what's going on -- the HC release flashes in the new boot loader that the ROM/recovery needs.
Edit: The NVC partition may also be involved, don't know much about this yet. On all of this, anyone feel free to correct me if you know more; I'm just explaining it as far as I've been able to cobble together from scraps of information and hex dumps.

Spent 4 hrs IMEI still not restored. DO NOT use Boeffla Restore for I9305!! EFS=Death

Ok guys I have posted solutions in the Boeffla thread. I am having issues with my EFS restoring.
Phone does not boot because it has no EFS. So cannot restore via EFS professional because it cannot detect the device.
1). Heimdall restore - Action completes, device reboots but no EFS partition created. DOES NOT WORK
2). ADB restore - dd if=/sdcard/efs.img of=/dev/block/mmcblk0p3 bs=4096. no EFS partition created DOES NOT WORK
3). I've created a CWM script using my backup EFS.img - YES TO TRY?
4). Move all data from Ext-SD to PC. From Aroma File Manager via Philz Touch Move all Int-SD data to Ext-SD, eject Ext-SD. Format and reflash stock via Odin. Re-root. Reflash Boeffla Kernel. Copy Nandroid backup to Int-SD from Windows. Restore EFS via RootBrowser/RootExplorer. - ALMOST FINISHED BACKING UP
5). Restore via PARAM.bin LiquidPerfection Odin Flash <- I think this is going to be my best bet? I WILL TRY THIS NOW
Any other options anyone want to suggest?

Yes.
Flash via Odin with a PIT file. I believe this will force Odin to re-create the partitions. I used a PIT on a n7000 to increase /data in the past, but YMMV.

daedric said:
Yes.
Flash via Odin with a PIT file. I believe this will force Odin to re-create the partitions. I used a PIT on a n7000 to increase /data in the past, but YMMV.
Click to expand...
Click to collapse
Yup. You are spot on mate I did this before now just noticing you had replied. Flashing back to stock ICS first flashing PIT (Oh and backing up my SDcard) did force it to recreate the partitions. None of the above solutions worked. After Flashing stock ICS, I flashed root, flashed recovery, flashed Philz Touch and restored my nandroid backup with no loss of EFS/IMEI?
So in short none of those solutions worked. And strange that repartitioning revived my old EFS. I didn't need to restore my IMEI to an empty EFS partition like I had hoped and was expecting? So yeah all good. Back on the road again

the eMMC is just a big block of data. Somewhere near the start should be stored the Partition Table. When you lost your EFS partition, you probably got a Partition Table corrupted, but the Partition itself was still there. When you reflashed a PIT, all the system had to do was to start using the EFS again.
To be honest, your EFS partition was probably kept safe by having the PartTable corrupted. Since you couldn't mount it, you couldn't damage it

daedric said:
the eMMC is just a big block of data. Somewhere near the start should be stored the Partition Table. When you lost your EFS partition, you probably got a Partition Table corrupted, but the Partition itself was still there. When you reflashed a PIT, all the system had to do was to start using the EFS again.
To be honest, your EFS partition was probably kept safe by having the PartTable corrupted. Since you couldn't mount it, you couldn't damage it
Click to expand...
Click to collapse
Man you are soooo SPOT ON again!! :good: I have no doubt this is exactly what has happened. The more I thought about it the more this idea makes sense. I come on here now and read your post and it is exactly what is going through my mind.
For other members sake that might come hear by searching I will just give a bit more of a break down. Again this is only my interpretation based on PIT information that is known, please feel free to correct me where needed or elaborate :good:
Theoretical/virtual MMC Blocks
Bootloader ?? -> /dev/block/mmcblk???? <- could be the address? This has a PIT ID80 AKA sboot.bin
KNOX ?? -> /dev/block/mmcblk???? <- could be the address? This has a PIT ID81 AKA tz.img
PIT ?? -> /dev/block/mmcblk???? <- could be the address? This has a PIT ID70 - This is likely the part that could have got damaged?
MD5 ?? -> /dev/block/mmcblk???? <- could be the address? This has a PIT ID71 AKA MD5.img
Known physical Addressing MMC Blocks
BOTA0 -> /dev/block/mmcblk0p1
BOTA1 -> /dev/block/mmcblk0p2
EFS -> /dev/block/mmcblk0p3
Note if any of these blocks get damaged they too can wipe device IMEI
m9kefs1 -> /dev/block/mmcblk0p4
m9kefs2 -> /dev/block/mmcblk0p5
m9kefs3 -> /dev/block/mmcblk0p6
PARAM -> /dev/block/mmcblk0p7
BOOT -> /dev/block/mmcblk0p8
RECOVERY -> /dev/block/mmcblk0p9
RADIO -> /dev/block/mmcblk0p10
TOMBSTONES -> /dev/block/mmcblk0p11
CACHE -> /dev/block/mmcblk0p12
SYSTEM -> /dev/block/mmcblk0p13
HIDDEN -> /dev/block/mmcblk0p14
OTA -> /dev/block/mmcblk0p15
USERDATA -> /dev/block/mmcblk0p16
Click to expand...
Click to collapse

[Q] Fix missing space (23.03GB vs. 64GB), but keep data

I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model.
I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP.
Would that work? And would it even fix the problem of the missing space.
For reference, the issue has previously been discussed here:
http://forum.xda-developers.com/nexus-6/help/nexus-6-64gb-23gb-free-space-t2953636

stokholm said:
I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model.
I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP.
Would that work? And would it even fix the problem of the missing space.
For reference, the issue has previously been discussed here:
http://forum.xda-developers.com/nexus-6/help/nexus-6-64gb-23gb-free-space-t2953636
Click to expand...
Click to collapse
Just so its clear the fastboot format does the trick. (I also did fastboot and vol scrolled to recovery and did a full wipe before the format)(that was prob overkill)
fastboot format userdata
fastboot format cache
fastboot reboot
I've never done that with twrp. I usually just dump my whole SD card to a hard drive then start fresh. Its a reasonable pain to ensure there are no problems.
Also wouldn't you have been totally wiped anyway if you were going back to stock? Have you been using it with 23gb for a while?

No, haven't been using it for long like that. Only a few days actually.
It's not that I have a lot of files, but I do have a lot of settings and app settings. I know I could probably use Titanium Backup to back that stuff up, but I don't trust that method do get everything and not mess something up.
One more question though. Why format cache too? I saw that suggested in the thread I referenced. But isn't it enough to format data? I guess it makes no difference really, but I'm trying to learn in the process too.

stokholm said:
I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model.
I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP.
Would that work? And would it even fix the problem of the missing space.
Click to expand...
Click to collapse
Yes and no.
Let me explain;
The first problem, which may or may not actually *be* a problem, is whether or not recovery will PERMIT a backup to an OTG. Assuming that it does, it unfortunately will only backup everything on the data partition BESIDES the "media" directory (where the "internal SD card" can be found).
To work around this, perform your backup TO the internal storage, then reboot back to Android, copy *everything" from the "internal storage" path to your computer (which will include the "backup" directory, whatever it happens to be called with the recovery you prefer). Then perform the fastboot format on the data partition, boot into Android skipping all the signin junk, copy everything BACK to the internal storage, reboot into recovery again, and restore it.
ALTERNATIVELY, and probably much easier (definitely much faster, since it should complete within a few seconds)...
I *believe* that most recoveries should include the resize2fs command (though I've never had an actual need for this, so haven't actually tested it), so via ADB into your recovery.....
Code:
umount /data
resize2fs /dev/block/platform/msm_sdcc.1/by-name/userdata
should do the trick.
NOTE HOWEVER, it is generally recommended to backup any partition where you are resizing a filesystem PRIOR to resizing it.
HAVING SAID THAT, I've run resize2fs hundreds of times on hundreds of systems, and never had an issue with a grow operation.
Running resize2fs without a "size" parameter will grow the filesystem to the size of the partition. The partition table still holds the correct size, which is why "fastboot format" fixes the issue.

That was a great explanation, @doitright. Thank you for that. I will try resize2fs at some point.

stokholm said:
No, haven't been using it for long like that. Only a few days actually.
It's not that I have a lot of files, but I do have a lot of settings and app settings. I know I could probably use Titanium Backup to back that stuff up, but I don't trust that method do get everything and not mess something up.
One more question though. Why format cache too? I saw that suggested in the thread I referenced. But isn't it enough to format data? I guess it makes no difference really, but I'm trying to learn in the process too.
Click to expand...
Click to collapse
Resizef2s sounds relatively painless, but does again, as doitright says, require caution by backing up before.
About the cache thing. I think to do a full format, data and cache are on different blocks, so that might be why. But then again the SD card is mounted in /data/media so maybe only format data is needed and the cache is to help with something else or just to be cautious, I don't know.
Now I wonder (and this can be searched here in xda) if TWRP back up data is /data/data or /data minus /data/media? Because fastboot format data I think is all of data i.e. /data. This is worth knowing for the future. Especially since we are flashinging things to our phones and whatever else.

MunkinDrunky said:
Now I wonder (and this can be searched here in xda) if TWRP back up data is /data/data or /data minus /data/media? Because fastboot format data I think is all of data i.e. /data. This is worth knowing for the future. Especially since we are flashinging things to our phones and whatever else.
Click to expand...
Click to collapse
ALL recovery backups are /data/* EXCEPT /data/media, being "backed up" to /data/media/something.
It simply cannot be implemented any other way for devices without separate storage devices, otherwise the backup would back up previous backups, which would be just plain wasteful.
The /cache partition is practically irrelevant. There is quite literally NO REASON to ever worry about it. No reason to wipe it, no reason for format it unless it somehow becomes corrupt.

It doesn't seem like resize2fs is included in TWRP.

stokholm said:
It doesn't seem like resize2fs is included in TWRP.
Click to expand...
Click to collapse
The resolution really is as simple as you originally thought. Its a common issue I've seen a hundred times on the nexus 5.
Take a full TWRP backup and then copy your entire sdcard to PC.
Format data
Boot into android and do initial set up.
Copy sdcard backup back to device whilst booted into android
Restore TWRP backup

You can use the file manager in TWRP to copy your entire sdcard to USB-OTG and copy it back. Personally, I find this easier than copying to PC.

adrman said:
You can use the file manager in TWRP to copy your entire sdcard to USB-OTG and copy it back. Personally, I find this easier than copying to PC.
Click to expand...
Click to collapse
The reason I said to copy it to PC via android was that using MTP or adb in recovery will break the sdcard permissions, when it is copied back. If you're confident OTG in TWRP works differently to adb and MTP in TWRP, cool. I just haven't tested it myself so won't suggest it.

rootSU said:
The reason I said to copy it to PC via android was that using MTP or adb in recovery will break the sdcard permissions, when it is copied back. If you're confident OTG in TWRP works differently to adb and MTP in TWRP, cool. I just haven't tested it myself so won't suggest it.
Click to expand...
Click to collapse
I used OTG via TWRP's file manager, when I wiped to decrypt and everything came back properly. I would assume that would be the case here as well.

adrman said:
I used OTG via TWRP's file manager, when I wiped to decrypt and everything came back properly. I would assume that would be the case here as well.
Click to expand...
Click to collapse
Excellent

rootSU said:
Excellent
Click to expand...
Click to collapse
Channeling Mr. Burns? [emoji1]

adrman said:
Channeling Mr. Burns? [emoji1]
Click to expand...
Click to collapse
Always, aren't you?

From within TWRP there is an easy way to do this even after you have your phone all setup. This issue always happens on my Nexus 5 and Nexus 6.
I did this without doing a backup and after my phone has been used on marshmallow for a week or so.
Steps from within TWRP:
1. Wipe > Advanced Wipe
2. Select the Data partition.
3. Select Repair or Change File System
(Notice the Partition Size)
4. Select Resize
(Wait and shortly after see the partition size be up to full size.)

This doesn't appear to work on 6.0.1 custom Rom with systemless SU 2.61... gave me a bad partition error.
Guess I will have to wipe.
maamdroid said:
From within TWRP there is an easy way to do this even after you have your phone all setup. This issue always happens on my Nexus 5 and Nexus 6.
I did this without doing a backup and after my phone has been used on marshmallow for a week or so.
Steps from within TWRP:
1. Wipe > Advanced Wipe
2. Select the Data partition.
3. Select Repair or Change File System
(Notice the Partition Size)
4. Select Resize
(Wait and shortly after see the partition size be up to full size.)
Click to expand...
Click to collapse

I have come across this thread. Here is what worked for me. (in case somebody needs it in the future)
1. Boot into twrp, type
Code:
adb shell
2. list the mounted partitions
Code:
df
You should see
Code:
df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1507020 24 1506996 0% /dev
tmpfs 1507020 24 1506996 0% /tmp
/dev/block/mmcblk0p38
253920 264 248416 0% /cache
/dev/block/mmcblk0p42
24143612 23590364 536864 98% /sdcard
/dev/block/mmcblk0p42
24143612 23590364 536864 98% /data
/dev/block/mmcblk0p41
2015408 1965276 33748 98% /system
3. unmount /data and /sdcard
Code:
umount /dev/block/mmcblk0p42
umount /dev/block/mmcblk0p41
4. run
Code:
e2fsck -f /dev/block/platform/msm_sdcc.1/by-name/userdata
resize2fs /dev/block/platform/msm_sdcc.1/by-name/userdata
now you should see:
Code:
df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1507020 24 1506996 0% /dev
tmpfs 1507020 24 1506996 0% /tmp
/dev/block/mmcblk0p38
253920 264 248416 0% /cache
/dev/block/mmcblk0p42
57306748 23598452 33691912 41% /data
/dev/block/mmcblk0p42
57306748 23598452 33691912 41% /sdcard
5. reboot, you are done