Related
Hi everyone, this is my first thread
I recently rooted my 16gb WiFi only nexus 7. After installing 3 different roms (touchwiz, cyanogenmod 10, and xenon HD) I didn't like touch wiz or cyanogenmod, and I'm currently running xenon HD. However, when I opened my storage today, of said I had 3.6gb remaining. I thought it may have been all the apps, so I factory reset it, reset the partition, and deleted all data via recovery mode. That gave me about 1 more gigabyte. I opened ES file explorer and deleted everything there. I still have only 4.6 gigabytes usable. Anyone else have this issue?
Thanks
Sent from my Nexus 7 using xda app-developers app
Well, I deleted some old backups and now I have 7.5 gb of storage, which should do for now. But I still have that 6 GB leftover, anyone know whats wrong?
Thanks
Sent from my Nexus 7 using xda app-developers app
OK. Now I mucked around in the mounting/unmounting stuff, and now it won't boot. It's stuck at the Google screen. Someone help please???
Sent from my Nexus 7 using xda app-developers app[/QUOTE]
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
nicetaco said:
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
Click to expand...
Click to collapse
Wait, is that for getting back the storage or actually letting it boot up? Because right now the storage is the least of my concerns.
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
bftb0 said:
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
Click to expand...
Click to collapse
Ughhh its still not turning on...
nicetaco said:
Ughhh its still not turning on...
Click to expand...
Click to collapse
Please re-read this quote from your 2nd thread in this fiasco.
Nico_60 said:
How do you want to know what's happening to your device if don't tell us which commands you have done exactly with fastboot and why ?
Click to expand...
Click to collapse
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
bftb0 said:
Please re-read this quote from your 2nd thread in this fiasco.
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
Click to expand...
Click to collapse
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
nicetaco said:
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
Click to expand...
Click to collapse
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
upichie said:
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
Click to expand...
Click to collapse
I wonder if I can I trade them in for some coupons or something
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
bftb0 said:
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
I wonder if I can I trade them in for some coupons or something
Click to expand...
Click to collapse
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
nicetaco said:
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
Click to expand...
Click to collapse
Thank you so much. That did it.
First problem fixed through XDA developers
Enjoy my thanks
Nico_60 said:
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
Click to expand...
Click to collapse
The ADB daemon - "adbd" is definitely sitting there running inside the custom recovery. Even if you can't communicate with it because of a lack of a driver, you should nevertheless be able to see it as an unknown device in the PC's device manager.
I have done the same hack - hand editing the .INF file - with both the Google SDK drivers and the Asus drivers, and in both cases it worked fine (one driver for everything: ADB in the OS, ADB in TWRP/CWM, and fastboot with the bootloader).
I have also used the Google SDK driver without modification plus the XDA Universal Naked driver. That means using the Google driver for fastboot and ADB when the OS is booted, and the XUN driver for custom recoveries only.
At the present time the ONLY driver I have installed is a hacked version of the Asus drivers.
Win 7 complains about signing when doing this (for the Asus drivers for sure, I can't remember if the Google driver is signed or not).
As I mentioned, Win 7 Pro x64. I suppose the whole "violated signing" might make life even more difficult with Win 8 though.
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
upichie said:
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
Click to expand...
Click to collapse
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
bftb0 said:
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
Click to expand...
Click to collapse
.
I'm a total command prompt beginner here, so could you explain where I'm doing the fastboot format command? In a terminal on the device? Using adb on my windows machine? I tried all that I could think of, but none of it worked. No form of wiping the device (yes, via "format data" in TWRP) seems to work. I'm still missing half of my storage.
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
upichie said:
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
Click to expand...
Click to collapse
Arrgh. Did you do the "fastboot erase userdata" first?
Here's what the fastboot format looked like on my device when I did this last (3/13):
Code:
$ fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 4.974s]
finished. total time: 4.979s
$ fastboot format userdata
erasing 'userdata'...
OKAY [ 4.454s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 30734811136
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7503616
Block groups: 229
Reserved block group size: 1024
Created filesystem with 11/1875968 inodes and 161774/7503616 blocks
sending 'userdata' (139197 KB)...
writing 'userdata'...
OKAY [ 33.733s]
finished. total time: 38.194s
As I said, I was unable to reproduce the problem even though I tried. But it almost seems like the creation of the new filesystem is inferring something from somewhere (but where?) about the userdata partition size which is incorrect. Almost like it happens because of something it sees in the prior filesystem (which is being destroyed). So it becomes irreproducible unless you can recreate the same starting condition.
There's other mysterious crap going on here too. See the output above? The part where it says "sending 'userdata' (139197 KB)" ? It will say this no matter where you run the command from, and there is no 139 MB "userdata.img" file in the folder it runs from!!! 139 MB? For a filesystem which is empty when you mount it?
I don't know. Here's one more thing to try, though. In addition to doing the "erase" & "format" commands, perhaps you could actually flash the userdata image from the stock ROM
Code:
fastboot erase userdata
fastboot format userdata
fastboot flash userdata userdata.img
and then when you boot to the custom recovery, perform a "factory reset" - or try doing the "Format Data" thing in TWRP after (or before?) the above steps.
If none of this works, I suppose you could try the equivalent sorts of things with CWM and see if you get a different result.
You don't need to permanently install CWM with a hard flash - you can just soft-boot it for a single session:
Code:
fastboot boot recovery-clockwork-touch-6.0.2.3-grouper.img
Sorry this is so vague, but you know how it goes - you stumble into a problem, start fooling around until it gets fixed - and because you weren't really expecting the problem in the first place, you haven't written down the exact conditions and steps. Like I said, I tried to re-create the problem a variety of ways - but failed at that effort.
good luck
Q&A for [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
Khaon said:
Hello,
many users complain that since lollipop their system partition size doesn't reflect the actual system of the block device. Therefore, they can not install some extra in this partition( busybox, big gapps packages,etc.).
This is due to the system image size specified when building the rom:
One of the parameter of your system partition(which has been hardcoded in some config file, I.e. BoardConfig) is its size, but if the block device(i.e. the part of your internal storage that will be mounted for the system partition)'s size that is mounted is larger than the system partition's size than you will loose some space.
Fortunately resize2fs executable allows to modify an ext2,ext3,ext4 partition size:
This package simply resizes your system size to match the size of your block device size.
It does not alter your partitions table just reclaim the unmounted space.
Instructions:
Boot on a twrp 2.8.x.y TWRP recovery
flash the package
Download :
https://drive.google.com/file/d/0B9kxrJw-dzUmNG12QkdaU3R4Ujg/view
Credits :
@m11kkaa from whom I took the idea
Click to expand...
Click to collapse
Hello,
It doesn't work on my fresh install of 5.1 (stock and on nexus 7 2012 wifi). TWRP says :
Code:
Error executing updater binary in zip '/sdcard/resize_manta.zip'
Error flashing zip '/sdcard/resize_manta.zip'
I've tried both with TWRP and with nexus root toolkit. I've redownload the zip. Still the same.
Any idea ?
carrion crow said:
Hello,
It doesn't work on my fresh install of 5.1 (stock and on nexus 7 2012 wifi). TWRP says :
Code:
Error executing updater binary in zip '/sdcard/resize_manta.zip'
Error flashing zip '/sdcard/resize_manta.zip'
I've tried both with TWRP and with nexus root toolkit. I've redownload the zip. Still the same.
Any idea ?
Click to expand...
Click to collapse
The binary is not static and it was built for nexus 10.
OK, thank you. I will search for another solutions.
Khaon said:
Can you confirm this is the path of your system partition's block device?
Code:
dev/block/platform/sdhci-tegra.3/by-name/APP
Click to expand...
Click to collapse
I have a Nexus 7 (2012) and can confirm that this is the path of the device:
Code:
[email protected]:/ # cat /proc/mounts
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,seclabel,relatime,user_xattr,acl,barrier=1 0 0
OK I won't be able to edit now but if you open the .sh fi!e you will be able to hardcode this path instead of the one I put!
0.0mb system on Nexus 7
So I found this post which have the solution to this problem here;
http://forum.xda-developers.com/nexus-10/development/mod-reclaim-free-space-partition-t3029605
This does not currently work for the Nexus 7. Since I'm a new member here I cannot answer the OP personally, but if he sees this or anyone care to relay the information;
I can confirm that this is the correct path
Code:
dev/block/platform/sdhci-tegra.3/by-name/APP
//MarK
Khaon said:
OK I won't be able to edit now but if you open the .sh fi!e you will be able to hardcode this path instead of the one I put!
Click to expand...
Click to collapse
Okay so I tried to hardcode this path. Maybe I'm just extremely stupid, but I couldn't get it to work.
Still get the Error executing updater binary. I'm on TWRP 2.8.7.0.
MarkPersson said:
Okay so I tried to hardcode this path. Maybe I'm just extremely stupid, but I couldn't get it to work.
Still get the Error executing updater binary. I'm on TWRP 2.8.7.0.
Click to expand...
Click to collapse
If you are on twrp 2.8.7.0 you dont need this anymore , yu can from the wipe screen resize a system partition
Khaon said:
If you are on twrp 2.8.7.0 you dont need this anymore , yu can from the wipe screen resize a system partition
Click to expand...
Click to collapse
Oh. I had no idea.
I don't know if the N7 has too low memory, but this didn't help at all unfortunately.
I get the following info:
Present: Yes
Size: 639MB
Free: 0MB
Used: 639MB
Backup Size: 639MB
Tried both to Resize and Repair but to no avail. :crying:
MarkPersson said:
Oh. I had no idea.
I don't know if the N7 has too low memory, but this didn't help at all unfortunately.
I get the following info:
Present: Yes
Size: 639MB
Free: 0MB
Used: 639MB
Backup Size: 639MB
Tried both to Resize and Repair but to no avail. :crying:
Click to expand...
Click to collapse
I'm probably, no ... surely ... completely out of my depth, but is there any chance this was done intentionally to keep Bad Things(tm) from being put onto the system partition? It seems like a horrible oversight so I'm wondering if it was intentional. Of course if a hack was in a position to write the the system partition, then it is just as likely in a position to delete something to make room, but that might then be noticed.
Just something that popped into my head after all day cooking for the in-laws and now trying to decompress with some Nexus hacking
Both the script and the TWRP functionality worked fine on my N10. But it still doesn't leave much space on /system when running a Marshmallow-based ROM. Meanwhile, I have 22GB free on my internal user storage (emulated SD card).
I'm curious if it would be possible to shrink that user partition size some and add that space to /system using this script or TWRP? Running fdisk -l /dev/block/mmcblk0 in adb shell shows only one partition, so I'm not totally sure how things are being sectioned off internally.
I used this for the main reason to fix the issue of insufficient space in system partition that wasn't letting me install gapps, I don't know why but after I did the mod, and flashed aicp is showing 700mb total on system partition in tibu, I thought it's supposed to be 800mb on it, no biggie since I fixed my main issue but I only have 13mb left in system.
Sent from my Nexus 10 using Tapatalk
PIT files
My nexus 10 has the boot loop problem and I think I have been left with the only option of Re-Partition but I need the PIT file. Can anybody help or provide this file?
I have tried everything else (fastboot, adb, temporary custom recoveries, Nexus Root Toolkit) with no success.
Every new lollipop update has shrunk the system partition and now with 5.1.1 for the first time the system partition has 0.0 mb free.
I've seen a pattern with every update but now they really made sure there is no free space at all. I remember when I had like 50 mb free.
I really wonder if they do this intentionally to make it a little more difficult to root. I know how to free up some system space so I can install busybox, I usually just delete google+, but this was never necessary up until 5.1. But even then there was about 0.3 mb free.
I wanted to make sure that it wasn't filled up because of leftovers from previous updates so I made a complete fastboot wipe, both erase and format every partition, and then installed 5.1.1 manually through ADB. But it made no difference.
I don't think that are shrinking it. It's just a problem on the nexus 7. I noticed the same on mine. The build is just bigger so they use exactly the amount of space they need. May be why some units get soft bricked during the update. I gave up on the nexus 7 though. Doesn't run how it used to and lollipop seems to be just too much for it. My samsung galaxy s6 still has 500mb free of it's system partition and is running lollipop. I got a free galaxy tab 4 10.1 when I got 2 new phones and I have not touched my nexus since.
Previously when installing Kali linux and the wifi "hacking" toolkit i resized my system partition. Now when i search google i cannot find the guide on how to resize the system partition on the nexus 7 without running the risk of bricking the device.
Does anyone have any memory of what im talking about? It was pretty simple as i recall.
Gizmoe said:
I don't think that are shrinking it. It's just a problem on the nexus 7. I noticed the same on mine. The build is just bigger so they use exactly the amount of space they need. May be why some units get soft bricked during the update. I gave up on the nexus 7 though. Doesn't run how it used to and lollipop seems to be just too much for it. My samsung galaxy s6 still has 500mb free of it's system partition and is running lollipop. I got a free galaxy tab 4 10.1 when I got 2 new phones and I have not touched my nexus since.
Click to expand...
Click to collapse
But they should be able to avoid filling the system partition to the brim, the images are still device specific and someone at Google must know that leaving 0 space left is bad. Now with the 5.1.1 update it even was as if there was negative free space because i removed Google Plus which should've freed up 35 mb but I only got 8. It was enough for busybox but still weird. I do think they are making these little problems to mess with us who root. With this and that you can't install otas anymore if your not 100% stock.
The system partition is not full and there is a fix
I had the same problem with my Nexus 10 but not my Nexus 4. I have also come against this after updating the Nexus 7 for my son.
This was fixed on my Nexus 10 by running a script from this link:- http://forum.xda-developers.com/nexus-10/help/qa-reclaim-free-space-partition-t3055387
As you will see, it is not that Google is filling the system partition but that there is a problem with the update which sets the partition size to the size of the system image rather than the full size of the partition hence a seemingly full partition.
The script comes in a zip file and when I ran it on my Nexus 10, as promised, I got the full system memory back reclaiming in the order of 150Mb.
As you will see in the thread, people have tried it for the Nexus 7, as did I, and it does not work but the developer says that this is to do with the 'system partition's block device' being different and that this can be corrected for the Nexus 7 by editing the 'sh' file and entering the correct path for the 'system partition's block device' which is also shown in the post.
I have not had the confidence to do this but hopefully this information will help people or at least point them in the correct direction. All the best.
mryorkshireman said:
I had the same problem with my Nexus 10 but not my Nexus 4. I have also come against this after updating the Nexus 7 for my son.
This was fixed on my Nexus 10 by running a script from this link:- http://forum.xda-developers.com/nexus-10/help/qa-reclaim-free-space-partition-t3055387
As you will see, it is not that Google is filling the system partition but that there is a problem with the update which sets the partition size to the size of the system image rather than the full size of the partition hence a seemingly full partition.
The script comes in a zip file and when I ran it on my Nexus 10, as promised, I got the full system memory back reclaiming in the order of 150Mb.
As you will see in the thread, people have tried it for the Nexus 7, as did I, and it does not work but the developer says that this is to do with the 'system partition's block device' being different and that this can be corrected for the Nexus 7 by editing the 'sh' file and entering the correct path for the 'system partition's block device' which is also shown in the post.
I have not had the confidence to do this but hopefully this information will help people or at least point them in the correct direction. All the best.
Click to expand...
Click to collapse
thx for the tip..
i tried many times and finally was able to flash a modified zip successfully, however, the system partition is still around 640MB (with just 448K free space left) same as before the flash.. is it because of the zip not working or because my N7 2012 8GB really just has this maximum size for the system partition?
i here attach the update zip that i used..
View attachment reclaim_system_partition_size_n7.zip
and the updater script included in the zip..
Code:
ui_print("");
ui_print("*********************************************");
ui_print("* Reclaim System Partition Size *");
ui_print("*********************************************");
ui_print("");
package_extract_file("resize2fs", "/tmp/resize2fs");
set_perm(0, 0, 0777, "/tmp/resize2fs");
run_program("/sbin/e2fsck", "-fy", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
run_program("/tmp/resize2fs", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
run_program("/sbin/e2fsck", "-fy", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
ui_print("");
ui_print("*********************************************");
ui_print("* Resizing Done! *");
ui_print("*********************************************");
ui_print("");
I ran into this too and couldn't install Busybox. I used ES File Explorer in root mode and moved the IMEKorean and Hindi fonts, maybe one or two other minor things, to the /sdcard partition. I got enough space back for busybox plus a custom font I wanted to use.
Script problems
iamelton said:
thx for the tip..
i tried many times and finally was able to flash a modified zip successfully, however, the system partition is still around 640MB (with just 448K free space left) same as before the flash.. is it because of the zip not working or because my N7 2012 8GB really just has this maximum size for the system partition?
i here attach the update zip that i used..
View attachment 3346439
and the updater script included in the zip..
Code:
ui_print("");
ui_print("*********************************************");
ui_print("* Reclaim System Partition Size *");
ui_print("*********************************************");
ui_print("");
package_extract_file("resize2fs", "/tmp/resize2fs");
set_perm(0, 0, 0777, "/tmp/resize2fs");
run_program("/sbin/e2fsck", "-fy", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
run_program("/tmp/resize2fs", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
run_program("/sbin/e2fsck", "-fy", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
ui_print("");
ui_print("*********************************************");
ui_print("* Resizing Done! *");
ui_print("*********************************************");
ui_print("");
Click to expand...
Click to collapse
Sorry I have been so long in replying I have been very busy. As I said I did not feel confident or indeed competent to amend the script myself I just wanted to point out that people would perhaps be better following this line that I had found in the Nexus 10 forum and worked rather than continuing to blame Google for filling the system partition.
I no longer have the Nexus 7 to test your script on as I said it was my sons and not mine. He was fed up of his Nexus 7 being so slow so I installed the Cyanogen Mod latest CM12 update for him.
I have however looked at your script and the only thing that I note is that it does not include the following two lines.
ui_print("");show_progress(1.34, 2);
ifelse(is_mounted("/system"), unmount("/system"));
I am aware that the first line is not necessary but the second line checks to see if the system partition is mounted or not and if it is, it unmounts it. If the partition is mounted then the script will not work.
Sorry that I am not much help, my expertises if I have any was with windows when I was working, which was a long time ago now.
Good luck with it anyway.
mryorkshireman said:
Sorry I have been so long in replying I have been very busy. As I said I did not feel confident or indeed competent to amend the script myself I just wanted to point out that people would perhaps be better following this line that I had found in the Nexus 10 forum and worked rather than continuing to blame Google for filling the system partition.
I no longer have the Nexus 7 to test your script on as I said it was my sons and not mine. He was fed up of his Nexus 7 being so slow so I installed the Cyanogen Mod latest CM12 update for him.
I have however looked at your script and the only thing that I note is that it does not include the following two lines.
ui_print("");show_progress(1.34, 2);
ifelse(is_mounted("/system"), unmount("/system"));
I am aware that the first line is not necessary but the second line checks to see if the system partition is mounted or not and if it is, it unmounts it. If the partition is mounted then the script will not work.
Sorry that I am not much help, my expertises if I have any was with windows when I was working, which was a long time ago now.
Good luck with it anyway.
Click to expand...
Click to collapse
thx for the reply..
im using twrp and system is not mounted by default, so i just removed that line..
i had errors in executing the original script from nexus 10, and had to experiment a lot to get it to run..
anyway before further information gathered, im done with this as my n7 is also a backup device at the moment..
EDIT: If you are coming here for the first time, this guide should still work, but @PorygonZRocks has created a flashable zip that should deal with a lot of these issues automatically. You can check out his post here:
https://forum.xda-developers.com/showpost.php?p=75787067&postcount=699
This method will indirectly allow you to root the LG Gpad v410 after it has been upgraded to Lollipop 5.1.1. Yes. Rooting LG v410 Lollipop. It's through a downgrade, but it works.
It took a while to get working, but here's how I did it. The process is straightforward, but the details matter greatly. You will brick your device if you mess up. Please read everything *first* before you do anything. Be sure you understand the process. I'll try to explain what's going on along the way.
An external SD card is extremely helpful for this process. You *could* adb push everything, but that will tedious.
First, you need some files.
The 4.4.2 KDZ which is a TEST OS, but it can be rooted and it downgrades to a Bump'able bootlaoder:
http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
The LG 2014 Flash Tool:
http://www.mediafire.com/download/fwrcd3pdj0svjtb/LG_Flash_Tool_2014.zip
Android LG Drivers:
https://www.androidfilehost.com/?fid=24052804347802528
Parted for Android. You can probably find it other places, but I found this file:https://dl.dropboxusercontent.com/u/84115590/LG%20G2%2016GB%20Solution/sdparted-recovery-all-files.zip
EDIT: There seems to be a lot of confusion here. My bad. All you need is the file named "parted" from this zip file - nothing else. Just put that one file in the root of your external SD card.
https://dl.dropboxusercontent.com/u/84115590/LG G2 16GB Solution/sdparted-recovery-all-files.zip linked from here: http://www.**********.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/
EDIT2: The dropbox link is down. I've attached the file directly.
The Candy5 ROM (This will potentially save you some manual steps. Somewhat optional, but highly recommended):
http://forum.xda-developers.com/g-pad-10/development/rom-candy5-g-pad-v410-lollipop-5-1-1-v2-t3111987
Flashify APK:
http://www.apkmirror.com/apk/christian-gollner/flashify/flashify-1-9-1-android-apk-download/
TWRP for the v410:
http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
LG One Click Root:
http://forum.xda-developers.com/lg-g3/general/guide-root-lg-firmwares-kitkat-lollipop-t3056951
(You may use Purple Drake or whatever else you want. They all use the same root script as this does and the GUI is helpful for novices.)
Android SDK (specifically adb.exe. After installing go to SDK Manager and ensure that Android SDK Platform Tools is checked):
http://developer.android.com/sdk/index.html
For clarification below, when I have commands in "quotes" they are Windows commands. When they are in `backticks` they are commands that you run inside of ADB which actually run on your device....as root. Root can screw things up. Please be extra cautious. If you blame me for messing up your device I will laugh at you. But that's not gonna happen, right? Good. Let's go.
Now that you have everything, put it all into a folder where you can access it easily.
Install the LG Drivers.
Install Android SDK (or otherwise get adb.exe).
Extract all of the archives.
Move the KDZ to the LG Flash Tool 2014 folder.
Put the tablet into Download Mode by powering it off, holding VolUp, and plugging in the USB cable. Press VolUP when instructed. You must be in Download mode before continuing.
Run LGFlashTool2014.exe. Select the KDZ file. Click "CSE Flash". Click "Start". Select "English" and click OK. Do not change anything else.
WAIT for the flash to continue. If you really want to brick your device, here's a good opportunity.
The device will reboot into Android 4.4.2. You will only have 4GB of internal storage at this point. DON'T PANIC! We are fixing it.
Enable USB debugging.
Connect the device.
Install and run LG One Click Root. Wait for the device to be rooted before proceeding.
Copy the Flashify apk, TWRP image, and Candy5 ROM to your external SD card.
Install Flashify and flash TWRP to the recovery partition.
Use the Flashify menu to reboot in to recovery.
DON'T PANIC! You will get white vertical lines on the boot screen from now on. They only show up during boot animations. A small price to pay. This may be fixed at a later date. for the time being! Thanks to marcsoup's first post ever, we have a fix! Details below. PLEASE click this link and thank him!
Things get tricky here. Copy parted to your external SD card and then run "adb shell" from Windows to get a shell in TWRP.
In TWRP, unmount /data by tapping Mount > uncheck Data.
`cp /sdcard/parted /sbin/` This copies the parted binary to /sbin so it can be executed in the path. I had trouble running `/sdcard/parted`, but YMMV.
`chmod +x /sbin/parted` Make it executable.
`parted /dev/block/mmcblk0` Run parted against the internal mmc
`p` Prints the partition table.
`rm 34` Deletes partition 34 labeled "grow". This is the root of our problem. The KDZ apparently only creates a 4GB partition, I assume so the test build has maximum compatibility with all sized devices.
`rm 33` Deletes partition 33 "userdata"
`p` Print to verify
`mkpartfs` Create a partition and put a filesystem on it. If we only expand the partition it won't help us because the filesystem is still only 4 GB.
a) name: userdata
b) type: ext2 (the tool only supports ext2. This is ok for now.)
c) start: 3439MB (the end of part 32. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the MB part otherwise the offset will overwrite another critical partition.
d) end: 15.8GB (where "grow" ended above. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the GB part otherwise the offset will overwrite another critical partition.
`p` Verify. For me it did not name the partition properly. Gotta fix that.
(if necessary) `name 33 userdata` This is critical for mount to find it in /dev/block/platform/msm.sdcc.1/by-name/ on some/all ROMS.
`p`. Verify one last time. Compare it to my partition table in the attachments. If you want to brick, delete some random partitions here.
Flash Candy5 with TWRP. It's only 239 MB, so it will flash quickly. I do this because Candy5 will reformat mmcblk0p33 from ext2 to ext4 for you. It does this as part of it's system boot, apparently. If you install a different ROM that does not do this, you can reformat it by running `make_ext4fs /dev/block/mmcblk0p33`. If your ROM does not have make_ext4, it likely has some differnt method to make an EXT4 filesystem. `/system/bin/mke2fs -t ext4 /dev/block/mmcblk0p33` may work better. Just flash Candy5 and be done with it.
Tap Wipe > Swipe to Factory Reset.
Tap Reboot > System.
WAIT!!! It will take a minute for the ROM to start the first time. You will have white lines and and possibly a white screen. WAIT. It's moving the DEX files to cache, formatting a partition, creating default folders on the internal storage, and several other things. WAIT! When the screen goes dim or turns off then it's ready.
Cycle the display or turn it on. You should be at the Candy5 lock screen.
USB debugging is on by default. Run "adb shell".
`mount | grep userdata` Make sure mmcblk0p33 is mounted.
`df` Make sure /data is 11.3 GB (or whatever size it is on non-16GB devices).
HELL YEAH, you downgraded, rooted, and fixed the partition problem. Enjoy your tablet!
Thanks to dopekid313 for finding the KDZ.
Thanks to timmytim for Candy5.
Thanks to the creators of the root script, flashify, TWRP, and XDA for being so awesome.
Thanks to marcsoup for fixing a fix to the white lines.
Thanks to navin56 for the partition dumps. PLEASE thank his post!
White lines fix.
What we are going to do is flash the aboot partition with the stock image provided by navin56. I've removed the extra files from the dump, so simply download aboot.img.7z below. Unzip it using 7zip.
These commands are to be run in TWRP. Reboot to TWRP recovery and connect with "adb shell". All of the following commands will be run in ADB under TWRP. If you cannot figure out how to get here, please post in the thread and someone will help you. Onward:
If you do everything correctly then you don't have to reflash your ROM and you won't lose data. This process can be done any time after flashing the KDZ, even before you follow the steps above to resize the userdata partition. It's a completely separate process.
Unzip aboot.img.7z so you have the file named aboot.img. You should also make sure that aboot.img's MD5 sum is e97431a14d1cee3e9edba513be8e2b52. Do not flash the 7z file. Please.
Copy aboot.img to your external SD card. It should live at /sdcard/aboot.img
Boot to TWRP and run "adb shell"
`ls -al /dev/block/platform/msm_sdcc.1/by-name/` Let's make sure we are flashing the right partition. On my device "aboot" is /dev/block/mmcblk0p6. You should verify this on your device or you WILL brick your tablet.
`dd if=/dev/block/mmcblk0p6 of=/sdcard/aboot-fukt.img` Let's back up our current aboot partition before we go flashing things just in case there are unintended consequences later. Be sure you have the same partition that "aboot" referred to in the 4th step or you have just backed up the wrong partition.
`dd if=/sdcard/aboot.img of=/dev/block/mmcblk0p6` Be sure the file exists, is the correct aboot.img, and you are flashing the right partition. You have been warned!!
Reboot TWRP and enjoy your boot animations again.
If I missed anything, please let me know. As far as I know this is the very first tutorial that details what is necessary to accomplish this. Please hit the Thanks button on every thread that you visit to download files!
FAQ:
Q: Why do I only have 11.3 GB of space when my device is 16GB?
A: The entire internal SD card (eMMC) is 16 GB. Gotta have someplace to install the bootloader, recovery, android, the modem OS, the secondary bootloader, the cache, the resource and power manager, and all of the other partitions necessary for the table to operate. Please look at the second screenshot in the OP. All of those 33 partitions take up room on the internal card. Fortunately ALL of those partitions ONLY take up about 4.4 GB. Hence the 'userdata' partition is ~11.3 GB.
If anyone wants to use my work to create a flashable zip to make it easier for novices, please do so. My problem is solved and I don't have the time to create the zip. Please post any questions and I'll gladly answer them! I'm so stoked that we have a usable downgrade method now!
Thank You, Worked Great
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
grandamle91 said:
Thank You, Worked Great
Click to expand...
Click to collapse
Glad to be of help!
dopekid313 said:
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
Click to expand...
Click to collapse
Of course! If you hadn't obtained the firmware then we'd all still be looking for a solution. It pisses me off to no end when people try to take credit for other people's work. We all just need to realize and acknowledge that we are simply standing on the shoulders of those who did the work necessary for each of us to do our work.
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
grandamle91 said:
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
Click to expand...
Click to collapse
Is this after you've rebooted into Candy5 and the partition is reformatted as ext4 (or you've done so manually)? TWRP may not be able to mount an ext2 partition.
EDIT: I just tested this. Following my instructions and flashing to Candy5, TWRP sees mmcblk0p33 (userdata) as the full size and mounts it at /emmc.
For clarification, after you run the parted commands, it will mess with the partition table and TWRP will most likely not be able to see it to remount it - at least not until after a reboot. This is why you need an external SD card from which to install ROMs.
/data not mounted
Edit: nevermind. The partition 33 was still ext2. I had to run make_ext4fs /dev/block/mmcblk0p33 and now I am able to mount /data. Thanks.
Thanks for taking the time to help us.
I followed the steps and till 33 I am good. But once I am in Candy5, I am not able to adb shell (adb not recognizing device eventhough usb debugging is on). I rebooted to recovery and adb works there. But my /data partition is not enabled in TWRP. I am not able to check it either under Mount in TWRP.
Code:
mount | grep userdata
is empty
Code:
df
does not show data
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
gridironbear said:
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
Click to expand...
Click to collapse
At what point did it bootloop? What was the last step that you took before rebooting?
Zip
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
drumm3rb0y said:
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
Click to expand...
Click to collapse
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
fatbas202 said:
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
Click to expand...
Click to collapse
The adb part is the part im having issue with. Everything else is flashed already. I was wondering if you could make a zip for the adb part so I can just flash it through twrp.
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
shahidmianoor said:
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
Click to expand...
Click to collapse
I have no solid evidence of this, but I suspect that the white lines are caused by a display driver issue where when the bootloader hands over control of the display to the kernel it doesn't get reinitialized properly. I have no ideas as to how to get rid of that at the moment but if I stumble across something I'll be sure to post here.
While I'm not an Android developer, I've been a Linux admin for 10+ years and have a lot of experience with Android devices. I'd be really hesitant to go flashing things ad hoc. While Download Mode may save you if you flash the wrong thing, I'm not entirely sure what the limitations that you may run in to with a locked bootloader are.
After having this device for months on 5.x and FINALLY being able to downgrade and run custom ROMs with root, not seeing a boot animation is a pittance to pay. But I'll keep looking.
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
iphone5sf said:
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Click to expand...
Click to collapse
You shouldn't need to remount or format data. The parted command nukes the filesystem and creates a new one formatted as ext2. At this point the running kernel has the old partition table loaded and won't know that the partition has been extended. Simply flash Candy5 and reboot at this point and it will reformat the userdata partition.
See above for the white lines during the boot animation. Known issue, no fix in sight, doesn't really matter.
nmnm4alll said:
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
Click to expand...
Click to collapse
You only need the sdparted-recover-all-files.zip from that site. "parted" is not a folder, but the binary (without a file extension) inside of that zip file. Copy that file to /sbin and you are in business.
zmali1 said:
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Click to expand...
Click to collapse
summonholmes said:
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
Click to expand...
Click to collapse
I'd recommend installing the SDK and pulling the drivers from that. Alternatively, you can try the drivers here: https://github.com/koush/UniversalAdbDriver.
Technically, when I ran the "parted" commands I was actually booted in to rooted 4.4.2 from the KDZ; I wasn't actually in TWRP. It's just not a very recommended way of going about it. I explained how to run all of this from TWRP, but there's no technical reason that you *can't* run this from Android. You just *shouldn't* because you can't cleanly unmount the filesystem and it theoretically could cause filesystem corruption. I just figured that I don't care about that partition getting corrupted since it's getting wiped out.
Update 10/26/20:
I didn't worked anymore on this (from january) since there doesn't seem to be much interest on it on Dior's official Telegram Group, but I'm seeing that some people tried to flash the test zip that I had on my bitbucket (altought it wasn 't officially released).
The script works on my device as you can see in the attatched pictures, but needs further testing to solve possible issues it might have with slightly different Dior versions (I don't wanna brick anyone's device).
All that said: I can write some Instructions to flash it if someone is willing to try (at his own risk).
This kind of modifications may potentially brick your device, although risk is reduced to minimum.
Original 1/9/20:
Hi guys,
I'm making a flashable zip for dior to repartition system and give us more space taking it from data partition (this will let us install open_gapps without error 70 on android oreo or pie roms) based on the work by CLAMOR, an Unlegacy Android dev (https://forum.xda-developers.com/nexus-4/orig-development/repartition-nexus-4-repartition-t3844383 ).
I'm gonna need someone with unmodified system partition (if you didn't manually repartitioned it like me, you can help me) and some basic skills: flash a zip in twrp that creates a log file in the root of internal memory (and don't modify anything of your phone), open that log and screenshot or send it to me.
I manually modified the partition table on my dior so mine is no good to check stock partition table.
With that log I can make the flashable zip able to repartition our phones back to stock partition table if anytime is needed.
Download:
- Here's the zip I need you to flash: https://forum.xda-developers.com/devdb/project/dl/?id=30446 (It will not modify or touch anything on your device, only creates a log)
You can see on the pictures that my system partition is bigger and has enough space to install almost any open_gapps package (400mb free after install mokee 9.0 experimental build)
The scripts are almost finished, with your help I will be able to finish it very soon!
Source Code: https://bitbucket.org/endlssprdx/dior-repartition-script/
Credits:
- Unlegacy Android Team
- Clamor (https://forum.xda-developers.com/member.php?u=5424240 )
Hi! Thanks for your work! Is the zip flasheable ready? I'm trying to upgrade the phone but system partition is too small. Any help would be great.
Thank you.
Enviado desde mi LG-H850 mediante Tapatalk
Log System Partition
Hello,
Here information that you requested, I need resize partition system, please you help me!!!
My phone is XIAOMI REDMI NOTE 4G SINGLE SIM DIOR (first generation)
Rom installed Mokee MK71.2-dior-190228-HISTORY.
Gapps: open_gapps-arm-7.1-pico-20200612
status: Works fine, I force installation of gapps but System is insufficient so system is to limited and after days the rom crashes or dropped with failures services play google.
Model: MMC 008GE0 (sd/mmc)
Disk /dev/block/mmcblk0: 7818182656B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17408B 2097151B 2079744B sbl1
2 2097152B 4176895B 2079744B sbl1bak
3 4176896B 5225471B 1048576B rpm
4 5225472B 6274047B 1048576B rpmbak
5 6274048B 7322623B 1048576B tz
6 7322624B 8371199B 1048576B tzbak
7 8371200B 8379391B 8192B ssd
8 8379392B 9427967B 1048576B sdi
9 9427968B 10476543B 1048576B DDR
10 10476544B 14670847B 4194304B aboot
11 14670848B 18865151B 4194304B abootbak
12 18865152B 24108031B 5242880B bk1
13 24108032B 28302335B 4194304B misc
14 28302336B 36690943B 8388608B logo
15 36690944B 67103743B 30412800B bk2
16 67103744B 68676607B 1572864B modemst1
17 68676608B 70249471B 1572864B modemst2
18 70249472B 70250495B 1024B fsc
19 70250496B 134212607B 63962112B bk3
20 134212608B 135785471B 1572864B fsg
21 135785472B 167767039B 31981568B bk4
22 167767040B 201321471B 33554432B bk5
23 201321472B 268430335B 67108864B fat16 modem
24 268430336B 285207551B 16777216B boot
25 285207552B 301984767B 16777216B recovery
26 301984768B 335539199B 33554432B ext4 persist
27 335539200B 1174399999B 838860800B ext4 system
28 1174400000B 1577053183B 402653184B ext4 cache
29 1610612736B 7818165759B 6207553024B ext4 userdata
after flashing your zip (https://bitbucket.org/endlssprdx/dior-repartition-script/downloads/) and writing "modify" in terminal as per instruction, twrp now fails to mount all partition except system and now I can't do anything
abhi21sept said:
after flashing your zip (https://bitbucket.org/endlssprdx/dior-repartition-script/downloads/) and writing "modify" in terminal as per instruction, twrp now fails to mount all partition except system and now I can't do anything
Click to expand...
Click to collapse
Hey, sorry for the delay.
Did you solved or do you still have problems? I didn't worked on this script since january (people didn't showed many interest on it on official Dior's Telegram Group).
The script itself needs a little bit of testing but works on my Dior (I didn't released officialy so that's why there isn't any instructions).
What you're facing it's normal:
After flashing it with the "modify" command, it's mandatory to format everything in your phone. (mount errors will not affect formatting)
- In TWRP: Wipe > Format data
- Type yes
- Once this completes go to: Wipe > Advanced Wipe
- Tick all the boxes and wipe. There should be no further mount errors.
After doing this and maybe rebooting TWRP you should be able to mount every partition and check your new System increased space:
TWRP > Wipe > Advanced Wipe > Tick System > Repair or change filesystem > And then you will be able to check it at "Size:".
If it shows the old size that's normal, do a "Repair File System" and "Resize File System". It should show the increased space now.
From now on, after installing a new rom (before flashing gapps or anything else), you probably need to do this too (repair and/or resize system partition filesystem).
This happens because our TWRP still believes that the system size is the stock one (we need a modified TWRP with increased system partition info to solve this, but I dunno how to do it).
If you want to go back to stock system size all you have to do is reflash the script, now it will promt you to type "stock" instead of "modify" on twrp terminal. (Also need to format everything as I said earlier when back to stock).
I hope you would be able to solve your problem
lusagad01 said:
Hi! Thanks for your work! Is the zip flasheable ready? I'm trying to upgrade the phone but system partition is too small. Any help would be great.
Thank you.
Enviado desde mi LG-H850 mediante Tapatalk
Click to expand...
Click to collapse
herreradimas said:
Hello,
Here information that you requested, I need resize partition system, please you help me!!!
My phone is XIAOMI REDMI NOTE 4G SINGLE SIM DIOR (first generation)
Rom installed Mokee MK71.2-dior-190228-HISTORY.
Gapps: open_gapps-arm-7.1-pico-20200612
status: Works fine, I force installation of gapps but System is insufficient so system is to limited and after days the rom crashes or dropped with failures services play google.
...
Click to expand...
Click to collapse
I didn't worked anymore on this since january, but works fine on my device (it need more testing to solve possible issues, didn't wanna brick anyone's device). There's a flashable zip available on my bitbucket if someone wants to test at his own risk. I can give you instructions on how to flash it and how to flash roms in the future with the extended system partition, but I didn't released it officially and will not make me responsible if something goes wrong. The script may potentially brick your device, although risk is reduced to minimum.
PS: Although I'm not working on this anymore, wanna thank you herreradimas, you are the second person since January that sent me the logs I needed to finish it hahhaha
endlssprdx said:
Hey, sorry for the delay.
Did you solved or do you still have problems? I didn't worked on this script since january (people didn't showed many interest on it on official Dior's Telegram Group).
The script itself needs a little bit of testing but works on my Dior (I didn't released officialy so that's why there isn't any instructions).
What you're facing it's normal:
After flashing it with the "modify" command, it's mandatory to format everything in your phone. (mount errors will not affect formatting)
- In TWRP: Wipe > Format data
- Type yes
- Once this completes go to: Wipe > Advanced Wipe
- Tick all the boxes and wipe. There should be no further mount errors.
After doing this and maybe rebooting TWRP you should be able to mount every partition and check your new System increased space:
TWRP > Wipe > Advanced Wipe > Tick System > Repair or change filesystem > And then you will be able to check it at "Size:".
If it shows the old size that's normal, do a "Repair File System" and "Resize File System". It should show the increased space now.
From now on, after installing a new rom (before flashing gapps or anything else), you probably need to do this too (repair and/or resize system partition filesystem).
This happens because our TWRP still believes that the system size is the stock one (we need a modified TWRP with increased system partition info to solve this, but I dunno how to do it).
If you want to go back to stock system size all you have to do is reflash the script, now it will promt you to type "stock" instead of "modify" on twrp terminal. (Also need to format everything as I said earlier when back to stock).
I hope you would be able to solve your problem
Click to expand...
Click to collapse
After flashing your script when everything became 0mb I formatted every partition but data and cache partitions still failed to mount so I reflashed your script and flashed stock fastboot rom