Database Users

Lost A LOT of storage after installing a new rom

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] [MOD][TWRP][RECOVERY] Reclaim the whole free space of your system partition

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.

Nexus 7 (2013) Razor MMB29K to MMB29O missing /storage/...

Hi.
First the symptom:
I installed the MMB29K to MMB29O OTA on my nexus 7 2013 and as per the thread title is lost done of the links on /storage/..
There's also a /storage/self that I've never seen before.
/storage/emulated/ is still there but doesn't go to sdcard (which still works and has all my data by the way).
The tablet reports space issues even though sdcard is available and has plenty of space
Now the background:
My only modification is chainfire rootless. I needed to delete the file level checksums and repack the zip to get OTA to install. The above approach worked fine on my nexus 5 but It did report a space issue while flashing on the nexus 7.
DF shows 4 meg free on /system
Before i flash the full factory image minus userdata img make it worse does anyone have any ideas? Has the new MMB29O grown too big?
Thank you
Chris

Update : Just flashed the full .img contents from Google-Factory images, minus the userdata folder and reapplied systemless root and all good. A little confused why I lost the mountpoints in /storage in the first place
I wonder if related to the modifications that systemless root makes to the boot image

System partition is too small

Hi,
After checking my Nexus, I have noticed that my system partition is quite small:
Filesystem Size Used Available Use% Mounted on
tmpfs 548.8M 52.0K 548.8M 0% /dev
tmpfs 548.8M 648.0K 548.2M 0% /tmp
/dev/block/mmcblk0p7 519.7M 8.7M 510.9M 2% /cache
/dev/block/mmcblk0p9 13.1G 441.0M 12.7G 3% /data
/dev/block/mmcblk0p9 13.1G 441.0M 12.7G 3% /sdcard
/dev/block/mmcblk0p8 787.4M 13.4M 774.0M 2% /system
Click to expand...
Click to collapse
This have two effects, as far as I know:
I can't install any Gapps greather than pico.
My apps seem to be installed in the system partition. Therefore, once it is full, the whole system gets broken.
I can't barely have apps without Trebuchet crashing in LineageOS or the app optimization failure in the stock ROM.
I have tried to increase the system partition manually by using parted and increasing the number of sectors:
System before: 1253376s to 2891775s
System after: 1253376s to 5963775s
But TWRP seems to detect the system partition always as 700MB, no matter the repartition that I have made.
I am wondering if you have ever been able to increase the system partition or if there is any room with a bigger one.
Thanks!

CodingFree said:
Hi,
After checking my Nexus, I have noticed that my system partition is quite small:
This have two effects, as far as I know:
I can't install any Gapps greather than pico.
My apps seem to be installed in the system partition. Therefore, once it is full, the whole system gets broken.
I can't barely have apps without Trebuchet crashing in LineageOS or the app optimization failure in the stock ROM.
I have tried to increase the system partition manually by using parted and increasing the number of sectors:
System before: 1253376s to 2891775s
System after: 1253376s to 5963775s
But TWRP seems to detect the system partition always as 700MB, no matter the repartition that I have made.
I am wondering if you have ever been able to increase the system partition or if there is any room with a bigger one.
Thanks!
Click to expand...
Click to collapse
You have to customize TWRP too as it is programmed for manta that has 700MB.

mr.natural said:
You have to customize TWRP too as it is programmed for manta that has 700MB.
Click to expand...
Click to collapse
Thanks, would you know if there is any specific procedure to customize it?

CodingFree said:
Thanks, would you know if there is any specific procedure to customize it?
Click to expand...
Click to collapse
You can start here: https://forum.xda-developers.com/showthread.php?t=1943625

Cannot boot recovery partition failed
Hi everyone,
I have an issue,
Yesterday I tried to install LineageOS 16 and GappsPico
Since my Manta Nexus 10 only have space for 700M, I couldnt install any type of Gapps.
So I do a partition changed.
After deleting and recreating partition, I mistakenly reboot the linux kernel. So it means my Nexus doesnt have any TWRP or anything
Right now, if I pressed power + volume up - hoping to get the recovery option - which I dont get, I only got start.
Is theres a way to fix this? or its just doom for me?
really appreciate it

Cannot boot recovery partition failed
Hi everyone,
I have an issue,
Yesterday I tried to install LineageOS 16 and GappsPico
Since my Manta Nexus 10 only have space for 700M, I couldnt install any type of Gapps.
So I do a partition changed.
After deleting and recreating partition, I mistakenly reboot the linux kernel. So it means my Nexus doesnt have any TWRP or anything
Right now, if I pressed power + volume up - hoping to get the recovery option - which I dont get, I only got start.
Is theres a way to fix this? or its just doom for me?
really appreciate it

@tongqabiz This may help you: https://forum.xda-developers.com/showpost.php?p=77992510&postcount=3

Yes it's possible. YMMV.
I was able to grab some space from the userdata partition using this guide: https://forum.xda-developers.com/nexus-4/general/guide-increase-nexus-4s-partition-space-t3800264
This guide is for Nexus 4s, but was taken from other guides built for other Nexus devices, so I took a chance with my Nexus 10 manta. The guide explains how to take the space from the cache partition which also works, but i repeated the process to set the cache back to its default size, and take the space from the userdata partition instead. Now I'm able to flash LineageOS 16 and open-gapps pico. I have some display issues with icons disappearing, and I don't seem to be ale to set any wallpaper, but I've not seen anything else causing any problem (yet). I've rooted it using addonsu (specifically for LineageOS I think?) https://mirrorbits.lineageos.org/su/20190709/addonsu-16.0-arm-signed.zip, and installed remote desktop and busybox in order to run kali.
I had to repeat some steps in the guide where i got some odd error messages about device busy and stuff e.g. when running mke2fs on newly created partitions. Naturally, don't expect to keep any data on your device if you follow this guide, and also expect to brick your device if you're careless with entering the commands.

CodingFree said:
Hi,
After checking my Nexus, I have noticed that my system partition is quite small:
This have two effects, as far as I know:
I can't install any Gapps greather than pico.
My apps seem to be installed in the system partition. Therefore, once it is full, the whole system gets broken.
I can't barely have apps without Trebuchet crashing in LineageOS or the app optimization failure in the stock ROM.
I have tried to increase the system partition manually by using parted and increasing the number of sectors:
System before: 1253376s to 2891775s
System after: 1253376s to 5963775s
But TWRP seems to detect the system partition always as 700MB, no matter the repartition that I have made.
I am wondering if you have ever been able to increase the system partition or if there is any room with a bigger one.
Thanks!
Click to expand...
Click to collapse
Hi,
I thought there was a TWRP Special image written for SELinux (TWRP-3.1.1-0-manta.img MD5: 4290afd6b1697d7f7b0d958131010676) written specifically for N10 to address this issue.
It is not the one from the TWRP site tough. Not sure where i got it from either. Check for the above checksum once you find it. I guess can't post any URL's or upload anything atm.
Cheers :fingers-crossed:

[TESTERS][WIP] Flashable zip to increase SYSTEM partition (Solving Gapps Error 70)

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