Related
This is a basic gui I wrote to unlock my encrypted partitions during boot.
I'm running my /data and /sdcard partitions encrypted, and the "luksunlock" binary is launched from init.rc to read the password and unlock the encrypted partitions.
I have included my somewhat modified init.rc for those interested.
For more information about LUKS on Android see this blogpost, written by shawn (Seems I'm not allowed to have urls in the post, but Google for 'android luks' , first hit)
This works good on Wildfire, altough it should work fine on other phones as well. Just remember that you need to set up your partitions as in the luksunlock.c (or change the defines).
Dont forget to backup before you start playing around!
Good luck!
Thanks! i'll give a try!
Hi,
I tried to use your cryptsetup binary from your blog, but I have some issues that you'll sure have an answer:
I run ./cryptsetup luksFormat -c aes-plain /dev/block/loop2 and after i put the luks password it says 'Command failed', no logs, no other output, even using the -v flag...
Any clue?
Thanks in advance!
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
tusabe said:
Hi,
I tried to use your cryptsetup binary from your blog, but I have some issues that you'll sure have an answer:
I run ./cryptsetup luksFormat -c aes-plain /dev/block/loop2 and after i put the luks password it says 'Command failed', no logs, no other output, even using the -v flag...
Any clue?
Thanks in advance!
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
Click to expand...
Click to collapse
CM6.1 for wildfire uses a 2.6.32 kernel (see HCDR.jacob's post about his custom kernel for more info)
tusabe said:
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
Click to expand...
Click to collapse
Yeah you really need dm-crypt support, either compiled into the kernel or as a module. You also need the AES ciphers support.
sigkill1337 said:
Yeah you really need dm-crypt support, either compiled into the kernel or as a module. You also need the AES ciphers support.
Click to expand...
Click to collapse
Hi! Yeah, that's what I was afraid of.... ok, but the problem is that i'm running CM6.1 with 2.6.35.9 which has no dm-crypt module neither compiled in kernel... where can i find some kernel with this modules included? Is for an HTC Desire (@Sympnotic )
Thanks in advance!
Great work and thanks for sharing @Sigkill. Working on building it here for my NexusOne with CM6.1.
BTW, I’m the lead on a project working on general secure Android distro – we’ve ported Tor, have an OTR IM app, and have supported other projects along those lines. Would love to talk more about supporting anyone working on this specific capability.
wow! awesome work!!! Very exciting news. Gonna give this a go on my MyTouch Slide
NathanFreitas said:
Great work and thanks for sharing @Sigkill. Working on building it here for my NexusOne with CM6.1.
BTW, I’m the lead on a project working on general secure Android distro – we’ve ported Tor, have an OTR IM app, and have supported other projects along those lines. Would love to talk more about supporting anyone working on this specific capability.
Click to expand...
Click to collapse
Seems really nice. I like the secure phone concept.
New Makefile and wiki info up
_hc from the @guardianproject has a new build process up for Crypsetup/LUKS which includes a Makefile compatible with Android NDK r5.
We have new instructions up on our wiki, as well.
I cannot post links under this account, but you can find the info on github if you search "LUKS" or just under our guardianproject account.
How did you create the encrypted partitions? Could you give some pointers for that. I am familiar with using dmcrypt/cryptsetup on desktop linux, I guess this works similar. What are the relevant device names? Did you run into any problems?
Calavera1 said:
How did you create the encrypted partitions? Could you give some pointers for that. I am familiar with using dmcrypt/cryptsetup on desktop linux, I guess this works similar. What are the relevant device names? Did you run into any problems?
Click to expand...
Click to collapse
Hi, sorry for the late answer,
/dev/block/mtdblock5 is the "userdata" partition. I formatted it and mount it to /encrypted-data during init:
mount yaffs2 [email protected] /encrypted-data nosuid nodev
The only file on this partition is "data.encrypted" file, which gets created in init.rc as a loopback device:
exec /system/bin/losetup /dev/block/loop0 /encrypted-data/data.encrypted
I created the "data.encrypted" file on my computer with cryptsetup and losetup, and copied all files from my old unencrypted userdata partition to it and then copied it back as a file to the formated userdata partition.
The sdcard "/dev/block/mmcblk0p2" partition is formated with "cryptsetup luksFormat", I did this also on my computer, saves some time. And then copy everything from the old unencrypted sdcard.
I did run in to one problem recently, my phone hung during boot, about 4 months after I started encrypting my phone.
Had to copy my data.encrypted file to my computer, mount it as a loopback device and do a fsck, and then copy it back to my phone.
I suspect this has to do with the filesystem not being umounted properly. (I have had this on my to do list for a while hehe)
Probably should make a script run during shutdown to cleanly "luksClose" the encrypted partition and then umount them. Not doing this is probably very crazy
I also want to fix it so my "/dev/block/mmcblk0p2" partition gets presented to my computer when i attach my usb cable (as it should do), so i can unlock it in ubuntu and copy images and files. Right now i have to take my memorycard out and put it into the computer.
I hope this post makes sense, it was written in haste =) Good luck!
sigkill1337 said:
Hi, sorry for the late answer,
/dev/block/mtdblock5 is the "userdata" partition. I formatted it and mount it to /encrypted-data during init:
mount yaffs2 [email protected] /encrypted-data nosuid nodev
The only file on this partition is "data.encrypted" file, which gets created in init.rc as a loopback device:
exec /system/bin/losetup /dev/block/loop0 /encrypted-data/data.encrypted
I created the "data.encrypted" file on my computer with cryptsetup and losetup, and copied all files from my old unencrypted userdata partition to it and then copied it back as a file to the formated userdata partition.
The sdcard "/dev/block/mmcblk0p2" partition is formated with "cryptsetup luksFormat", I did this also on my computer, saves some time. And then copy everything from the old unencrypted sdcard.
I did run in to one problem recently, my phone hung during boot, about 4 months after I started encrypting my phone.
Had to copy my data.encrypted file to my computer, mount it as a loopback device and do a fsck, and then copy it back to my phone.
I suspect this has to do with the filesystem not being umounted properly. (I have had this on my to do list for a while hehe)
Probably should make a script run during shutdown to cleanly "luksClose" the encrypted partition and then umount them. Not doing this is probably very crazy
I also want to fix it so my "/dev/block/mmcblk0p2" partition gets presented to my computer when i attach my usb cable (as it should do), so i can unlock it in ubuntu and copy images and files. Right now i have to take my memorycard out and put it into the computer.
I hope this post makes sense, it was written in haste =) Good luck!
Click to expand...
Click to collapse
I figured most of that out without your post and tried it on my desire (I created the luks partitions with adb on the phone though, worked anyway ). Then I couldn't figure out where my regular init.rc is stored (I could only find the one used by Clockwork Recovery), and then I figured I already spent enough time, tried a reboot (which of course didn't work). Then I couldn't even get into recovery (probably because its init.rc tries to mount /data which doesn't work? I didn't investigate any further). Flashed my backup with fastboot and was stuck again with my un-encrypted pre-experiment state
Oddly enough, it was no problem to unlock my encrypted SD-card from my computer (running ubuntu) while in recovery (clockword has an option to present the sd card to a computer connected via usb). Maybe the booted system handles this differently than recovery though? I didn't get a chance to try, as I couldn't boot after my encryption attempt.
I will try again after my algorithm and data structure exam this friday and report back
Is anybody using the UI on another device than the Wildfire? Does it work?
How much is the performance drain when using an encrypted /data partition?
Amazing work!
Did anyone manage to make sigkill1337's luksunlock build from source ?
I would like to change the path of the data/sdcard partitions to match my device but I tried many ways using the NDK and I can't get it to compile properly.
Is there any way to do this ?
I have been trying for days, I am getting literaly insane !
@sigkill1337 : could you give me some pointers ? I would appreciate a lot.
mount manpage said:
The bind mounts.
Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
or shortoption
mount -B olddir newdir
or fstab entry is:
/olddir /newdir none bind
After this call the same contents is accessible in two places. One can also remount a single file (on a single file).
This call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place using
mount --rbind olddir newdir
or shortoption
mount -R olddir newdir
Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command, for example:
mount --bind olddir newdir
mount -o remount,ro newdir
Click to expand...
Click to collapse
If nothing helps, you should always be able to bindmount it
I'd rather get sigkill1337's UI to compile...
Lots of nice security tweaks and settings could be done with a pre-boot GUI
Anyway, concerning encryption, I'll use the bind option for now, thanks for the tip.
But if anyone here could give me some pointers about compiling this stuff it would be great.
I managed to compile it by integrating luksunlock in Android source externals and main.mk but when I push it to my phone and modify init.rc to call it, it just does not work...
Other modifications are working (mount, mkdir, etc.) but the GUI won't show up
Sorry for the late reply.. But you could try running it from a shell when the phone is booted, just to verify that the binary starts (thats how I tested it without having to reboot my phone all the time)
My environment for building the source was setup using one of the tutorials online, nothing out of the ordinary
Im still running this on my phone, for almost 8 months now, I havent noticed that much in performance problems, the Wildfire was slow before i started using luks.
When i get a new phone (maybe SE Arc) i will be easier to see if performance is affected
There is an Issue for getting CM support for encrypted filesystems during boot:
Issue 2736: support encrypted filesystem from boot
If you want to get that feature, just "star" it, so it may get more attention.
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.
I WAS WONDERING IF WE COULD EDIT OUR PARTITIONS IN PHONE LIKE HERE ON GALAXY NOTE http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
THIS WOULD BE HELPFUL FOR ALOT OF PEOPLE THAT BRICK THEIR PHONE.IF G PARTED WOULD WORK ON OUR PHONES WE COULD EDIT SOME PARTITIONS THAT OUR PHONE WOULD BE FASTER....
EDIT:sorry for capslock.
yes u can... search in the forum there are flashable zips to use in cwm... try searching for costum partitions... i use it...
Our phone uses MS-DOS MBR boot record, so this tutorial will not work. MBR uses fdisk to modify partition table, but it's very easy to break something with that so better not go and wonder what any of the commands do.
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.