I am new to the EeePad and have a question...
I am working on developing and customizing some ROMs and I need a larger /system partition. How can I go about accomplishing this on my Transformer (TF101-A1)? If this is covered somewhere, a link to it will do me just fine.
Thanks for the help !
romified said:
I am new to the EeePad and have a question...
I am working on developing and customizing some ROMs and I need a larger /system partition. How can I go about accomplishing this on my Transformer (TF101-A1)? If this is covered somewhere, a link to it will do me just fine.
Thanks for the help !
Click to expand...
Click to collapse
I'm not an expert, but you might be able to resize the partitions with nvflash and modding the flash.cfg file. Of course, this will only work if you have access to nvflash (b70-ish or lower serial number).
There might be some possibilities with flashing blobs via the staging partition, but I don't know if the partition table can be written that way and if that will effect the bootloader (blob.EBT). There is also a high, almost certain, brick risk if you fool around with this without access to nvflash.
You might want to check out the nvidia developers site.
Sn starts with b60 so maybe nvflash is a good possibility then.
I was successful in doing this with nvflash. Increased system from 512 mb to 768 mb.
Related
After copying a lot of files to the main memory of Acer Iconia Tab A501 (Android 3.2 stock) I can't boot anymore, I think it's because there is no free space (boot progress stops at Android logo). I need a way to copy my files or delete some of them to add free space, but I don't want to reset the device!
Do you know how to do it?
sksoft said:
After copying a lot of files to the main memory of Acer Iconia Tab A501 (Android 3.2 stock) I can't boot anymore, I think it's because there is no free space (boot progress stops at Android logo). I need a way to copy my files or delete some of them to add free space, but I don't want to reset the device!
Do you know how to do it?
Click to expand...
Click to collapse
I would be more concerned that you copied some corrupted files into the memory. This is probably the reason. And to locate the corrupted files would be almost impossible. Also possible you may have overwritten something the OS needs.
You might possibly get an adb connection, but I doubt it. Especially if you didn't turn USB Debugging on. And I believe the tab has to boot into the os before it can work.
Reset seems in order.
How to backup?
I need to backup several unique files from the device, reset with erasing them is not an option. Any ideas?
Please, help!
Mate, there is no way to get them if the tab won't boot...
ultramag69 said:
Mate, there is no way to get them if the tab won't boot...
Click to expand...
Click to collapse
Correction: nvflash can download a complete live partition dump assuming the OP has their SBK. I assume you can then mount the image as its ext4
Sent from my Iconia A500 using Tapatalk 2
How to mount the image?
blackthund3r said:
Correction: nvflash can download a complete live partition dump assuming the OP has their SBK. I assume you can then mount the image as its ext4
Click to expand...
Click to collapse
Sorry, what is OP and SBK? Could you please tell what should I do to use your scenario?
sksoft said:
Sorry, what is OP and SBK? Could you please tell what should I do to use your scenario?
Click to expand...
Click to collapse
OP = original post / original poster
SBK = secure boot key and is calculated based on your UID from Vache's SBK site
Sent from my Iconia A500 using Tapatalk 2
Hiya.
I got used to SDMaid on my old Xperia Ray and I also use it on my N7 for cleaning cache of apps etc.
I recently noticed that there are some unused `partitions` on my device (see attachment)
Is it possible to shrink the size of those directories to make more space usable for the user, or do something like re-routing the .thumbnail directory to /dev or /cache ?
Don't think repartitioning (layouts - SYSTEM size/DATA size, to put it simply) can be done without nvFlash in APX mode... and nobody has figured a way of doing that yet... but it's a theoretical possibility.
----
I have an Advent Vega (shuttle based), and when devs. release a new ROM, more often than not, it's a CWM .zip flashable.... BUT if a developer needs to ENLARGE the SYSTEM partition (for example, such that the ROM will 'fit'), the ROM has to be nvFlashed.
Rgrds,
Ged.
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
What exactly lies in the mmcblk0p7 partition?
MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.
@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.
@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.
@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.
I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet
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.
Hey guys/gals. I'm doing some new development on the Nexus 10, and I need to enable Verity for the /system partition. This poses a problem. The partition is already the full length, and I need to truncate it, so that I can store the hash table, metadata, etc.
As you probably know, the /system partition is an ext4 partition, and parted doesn't support that. So, being as I have complete control over the device, I can do almost anything to solve this problem.
So, here are some questions that I have:
Where are the partitions initialized for a blank device?
Is there a tool that would allow me to modify the sizes of ext4 partitions?
I'm really hoping someone here knows the answers to either of those. Lots of googling has turned up nothing.
If this isn't the right forum to ask this question, please point me to the correct one! I just want an answer, it doesn't have to be specific to the Nexus 10.
FrankRizzo890 said:
If this isn't the right forum to ask this question, please point me to the correct one! I just want an answer, it doesn't have to be specific to the Nexus 10.
Click to expand...
Click to collapse
The answer is that I misunderstood what I needed to do. It's NOT the partition that needs to be adjusted for Verity, it's the FILESYSTEM. And, only if the filesystem fills up the partition.