Is it possible to resize the webtop partition? (increase the size of /webtop and reduce the size of /sdcard)
I love flashing roms with bootmenu.
I usually keep my main rom on the webtop partition and run test roms in the 1st (normal) system, mostly to avoid the 2nd system file editing but also to keep my main system safe if I have to sbf flash.
But I quickly run out of space on the 2nd system. 1.3 GB sadly isn't enough for all my android goodies.
Related
I love flashing roms with bootmenu, but I quickly run out of room on the 2nd system 1.3 GB just isn't enough
So now I'm switching between bootstrap and safestrap, but it is time consuming to change between the unsafe/safe system
so i wonder
Is it possible to resize the webtop partition (increase size of /webtop and reduce size of /sdcard) or does the locked bootloader or anything else **** this up?
Didn't want to experiment with the partitions without knowing, i have no time for bricks.
Welcome to nookie cloner. This app makes a fully bootable sdcard copy of your on device ROM in a single click. For example, you may still be using CyanogenMod 7 as your nook colors default ROM and would like to test out the latest kit kat/ CyanogenMod 11 nightly. With this app you could make a fully bootable sdcard backup of CyanogenMod 7 with all of your data and apps and then install CyanogenMod 11. You would then effectively have a dual boot of cm 11 along with your old cm 7 install including all data and apps. It also works in reverse so the contents of a bootable sdcard can be flashed back as your main ROM. As far as I have tested this app should work for all nook color ROMs, even stock. Bellow information on the way this app formats sdcards can be found. I'm in the process of making changes specified by Steven676. In the meantime this app is still completely functional. If you find it useful or appreciate my work then please give the thanks button a press
Download Nookie Cloner alpha 1: https://dl.dropboxusercontent.com/u/46535328/Nookiecloner-A1.apk
Info:
Partition layout:
mmcblk1p1 - boot / fat32 size: 100 MB
mmcblk1p2 - system / ext4 size: 500 MB
mmcblk1p3 - data / ext4 size: 1000 MB
mmcblk1p4 - extended partition
mmcblk1p5 - cache / ext4 size: 400 MB
mmcblk1p6 - sdcard storage / fat32 size: whatever is leftover
Current bugs that I'm working to fix:
When the stock ROM is booted from an sdcard it doesn't mount the right fat partition so you only get 100 mb of external storage
Thanks:
Fattire - for the original idea.
racks11479 - For some essential ARM tools used in the process.
Disclaimer: I can not be held responsible for any "bad" things that happen to your nook, data, etc... because you choose to use this app on your device. To your comfort though, I have used this app for a while and have not experienced any serious implosions or explosions as of yet
rootfan said:
Welcome to nookie cloner. This app makes the creation of bootable sdcards possible right on your nook with a single click. It also works in reverse by cloning the contents of a bootable sdcard onto your devices internal storage.
Click to expand...
Click to collapse
Cool, thanks for picking up this idea and running with it!
Is source available somewhere?
Partition layout:
mmcblk1p1 - boot / fat32 size: 100 MB
mmcblk1p2 - system / ext4 size: 500 MB
mmcblk1p3 - data / ext4 size: 1000 MB
mmcblk1p4 - extended partition
mmcblk1p5 - cache / ext4 size: 400 MB
mmcblk1p6 - sdcard storage / fat32 size: whatever is leftover
Click to expand...
Click to collapse
This isn't a good partition layout, though -- both /system and /data are too small for future-proofing. I'd suggest at least 640 MB for /system (for the pending eMMC repartitioning, we're kicking around 768 MB) and 2 GB for /data. For performance reasons, you also want all the partitions (except for /boot, which is fixed in place because of first-stage bootloader limitations) to start on a 4MB boundary, though you may need to fiddle a bit with your tools to achieve this.
See the discussion on eMMC repartitioning in the dev thread beginning here for more information, particularly the bits on units and extended partition packing.
Also, you do not need a cache partition on SD card -- the ROMs and recoveries will not use it.
rootfan said:
Current bugs that I'm working to fix:
Stock ROM does not mount the sdcard partition properly. If it asks you to format the card on boot don't do it as it formats the bootable card in its entirety.
I think 4.3 doesn't mount the card properly but it should be an easy fix.
Click to expand...
Click to collapse
Honestly, the original idea was to only do this with install-location-agnostic builds (like CM11 builds from May 16 or later) -- with these, the ROM automatically figures out where everything is and you don't need to fiddle with the initramfs. If you are going to support modifying earlier builds to change the install location, please detect install-location-agnostic builds and leave them untouched.
steven676 said:
Cool, thanks for picking up this idea and running with it!
Is source available somewhere?
This isn't a good partition layout, though -- both /system and /data are too small for future-proofing. I'd suggest at least 640 MB for /system (for the pending eMMC repartitioning, we're kicking around 768 MB) and 2 GB for /data. For performance reasons, you also want all the partitions (except for /boot, which is fixed in place because of first-stage bootloader limitations) to start on a 4MB boundary, though you may need to fiddle a bit with your tools to achieve this.
See the discussion on eMMC repartitioning in the dev thread beginning here for more information, particularly the bits on units and extended partition packing.
Also, you do not need a cache partition on SD card -- the ROMs and recoveries will not use it.
Honestly, the original idea was to only do this with install-location-agnostic builds (like CM11 builds from May 16 or later) -- with these, the ROM automatically figures out where everything is and you don't need to fiddle with the initramfs. If you are going to support modifying earlier builds to change the install location, please detect install-location-agnostic builds and leave them untouched.
Click to expand...
Click to collapse
Thanks for the advice Steven. I'll try to get your suggestions implemented soon as possible. The way the app currently functions allows for the creation of bootable sdcards as far back as the stock froyo ROM. My noted bug is simply that the fat partition at mmcblk1p6 is not mounted properly. The sdcard is eaither not mounted at all (my fault) or the boot partition is mounted as the external sdcard. Perhaps it would simply be better to expand the boot partition for use as sd storage. I'll still modify it though so the new partition agnostic ROMS are not changed.
rootfan said:
My noted bug is simply that the fat partition at mmcblk1p6 is not mounted properly. The sdcard is eaither not mounted at all (my fault) or the boot partition is mounted as the external sdcard.
Click to expand...
Click to collapse
Look at /system/etc/vold.fstab (releases older than 4.3) or fstab.encore in the initramfs (4.3+); you can specify which partition of the SD card to use there.
So I got tired of my weird configuration of running the apps in a mounts2sd with a second ext4 partition on my sdcard and technically nothing should prevent us from running safestrap on the sdcard. So I looked around and it took me a while but I found Hashcode's source code and spent some time studying all the voodoo he does, and most of it is fairly straight forward. Small breakdown:
* Extend TWRP with ifdef statement to add new buttons
* sh scripts get called to perform the functionality for those button
* Swap out some links in /dev/block when you switch between slots and stock
* The entire boot partition including scripts, TWRP, etc are stored in boot image
* The boot image is stored in the stock system under /etc/safestrap
Like I said before, most of the functionality is done in borne shell scripts, but there is some hardcoding in TWRP like creating the .img file to /ss. I really don't want to try to recompile TWRP at this time. As such, I want to limit my changes to the borne shell and configuration INI files only. The simplest answer is to remap /ss from internal storage to the sdcard storage. Another option is to have "system" and "cache" in the internal storage and moving "data" to the sdcard. The difficulty here is since TWRP is hardcoded to create the .img file under /ss, I need to move it during the format stage which happens in the script. The danger with the first option I don't know if the phone will boot if the sdcard is removed. safestrap looks for that directory to figure out the mappings in /dev/block. I think if the directory is missing then it will attempt to create it. After that, things might go bad.
Anyway, what are your thoughts?
i wish and hope your still working on this..my phone is so low in internal storage..i cant even use a rom slot other than stock,,ive been useing stock slot ,flashing custom rom in stock slot....anyways hope you continue to figure this out..i know lots of people would appreciate it..thanks
So I've tried multiple ways and have had to step away, think about it some more, and come back to it. Essentially I was not able to get system to boot off of the sdcard. However, the good news is today I was able to have system and cache on internal storage and data on sdcard. So here are the keys to the kingdom that I have found....
The CM11 (and I assume other) ROMs there is a /system/etc/kexec/ramdisk.img file. This file is extracted (gunzip < ramdisk.img | cpio -iu) into the root directory "/" (rootfs). There is a shell script "/sbin/fixboot.sh" that gets executed by /init at the start of the android (on fs). That script essentially mounts /ss to /emstorage and does all the loop storage links to the system.img, cache.img, and data.img files. I was able to mount another /ss2 to my sdcard and point the userdata to /ss2/safestrap/rom-slot?/userdata.img. The limitation is that vfat limits all files to 4 GB max, so the userdata.img cannot be more than 4 GB of storage.
So an option is I can create an updated ramdisk.img file. You would just drop this into your /system/etc/kexec directory on the slot-rom you want to use it. The only file changed in ramdisk.img is /sbin/fixboot.sh. ramdisk.img is part of the CM11 distribution so you would need to replace it each time you perform an update on that rom slot. Other than that, safestrap would by default create userdata.img to be in internal storage.
The next part I'm going to look at is to create a f2fs partition on my sdcard and have my userdata use that f2fs partition. I figure I should good considerable more I/O as f2fs is suppose to be a good amount faster than ext3/4 and we wouldn't be going through a loop device from ext3 to vfat for all I/O. In addition, my data partition would no longer be limited to 4GB due to the file limitation size of vfat.
Thoughts...
So Spyder doesn't have f2fs on it so I've been running ext4. The kernel would need to be setup to be compiled with it. I have a second 6Gb partition formatted with ext 4 with writeback journaling but per my timing tests I don't think it has made a difference. Now I have more than enough space left in both the data and internal partitions. I don't know if it is just a placebo effect but my apps do seem to start slightly faster.
There doesn't seem much interest in this but it was a fun exercise for me. This will be good enough for me as I'll probably upgrade my phone sometime in the future.
Sent from my XT912 using XDA Free mobile app
TWRP, Pitchblack, OrangeFox, whatever recovery I try, I always end up with this Super partition. And I can't see how much size it is. It's just sitting 8192MB by default.
Aren't there any recoveries that show partitions normally like system, vendor separately, with actual sizes filled ?
MPK99 said:
TWRP, Pitchblack, OrangeFox, whatever recovery I try, I always end up with this Super partition. And I can't see how much size it is. It's just sitting 8192MB by default.
Aren't there any recoveries that show partitions normally like system, vendor separately, with actual sizes filled ?
Click to expand...
Click to collapse
That's because there are no dedicated partitions for system, vendor, and product. They are all located inside one partition called "super". Think of it as one big partition that houses other smaller partitions. The size of the individual partitions is variable hence you'll only be able to see the size of the super partition.
The size of the super partition is fixed and cannot be resized after a rom is installed. The super partition was created to eliminate the need for vendors to allocate specific sizes for sub partitions. Before the super partition, each partition had to be allocated a specific size and any free memory left after writing data to it could not be used when other partitions required more space. This free space was therefore wasted.
In the super partition, the sub partitions can be the exact size of the files contained within them. Any free space is left inside the super partition and can therefore be used by other sub partitions if they need it.
Unfortunately, the biggest setback for developers is that they cannot modify the contents of sub partitions once they're made read only (usually on the first boot after installing a new rom). People who try to modify these partitions often get into boot loops forcing them to reinstall the stock rom.
twistyplain said:
That's because there are no dedicated partitions for system, vendor, and product. They are all located inside one partition called "super". Think of it as one big partition that houses other smaller partitions. The size of the individual partitions is variable hence you'll only be able to see the size of the super partition.
The size of the super partition is fixed and cannot be resized after a rom is installed. The super partition was created to eliminate the need for vendors to allocate specific sizes for sub partitions. Before the super partition, each partition had to be allocated a specific size and any free memory left after writing data to it could not be used when other partitions required more space. This free space was therefore wasted.
In the super partition, the sub partitions can be the exact size of the files contained within them. Any free space is left inside the super partition and can therefore be used by other sub partitions if they need it.
Unfortunately, the biggest setback for developers is that they cannot modify the contents of sub partitions once they're made read only (usually on the first boot after installing a new rom). People who try to modify these partitions often get into boot loops forcing them to reinstall the stock rom.
Click to expand...
Click to collapse
Understood. But can we access /system & /vendor folders & modify files in it through root explorer.
So you're saying there's no way to remove system bloatware & unwanted apps ?
twistyplain said:
That's because there are no dedicated partitions for system, vendor, and product. They are all located inside one partition called "super". Think of it as one big partition that houses other smaller partitions. The size of the individual partitions is variable hence you'll only be able to see the size of the super partition.
The size of the super partition is fixed and cannot be resized after a rom is installed. The super partition was created to eliminate the need for vendors to allocate specific sizes for sub partitions. Before the super partition, each partition had to be allocated a specific size and any free memory left after writing data to it could not be used when other partitions required more space. This free space was therefore wasted.
In the super partition, the sub partitions can be the exact size of the files contained within them. Any free space is left inside the super partition and can therefore be used by other sub partitions if they need it.
Unfortunately, the biggest setback for developers is that they cannot modify the contents of sub partitions once they're made read only (usually on the first boot after installing a new rom). People who try to modify these partitions often get into boot loops forcing them to reinstall the stock rom.
Click to expand...
Click to collapse
Thx for explanation bro. Currently I have this issue. Can you take a look into this thread below & answer there ?
Unable to decrypt FBE device
Plz anybody help this out... I unlocked bootloader, then immediately flashed Pitchblack recovery, then booted into recovery. Initially console shows decrypted FBE device with default password. But Encryption status : Encryped So I went into wipe...
forum.xda-developers.com
MPK99 said:
Understood. But can we access /system & /vendor folders & modify files in it through root explorer.
So you're saying there's no way to remove system bloatware & unwanted apps ?
Click to expand...
Click to collapse
In some custom miui roms like miui eu it is possible without causing a bootloop. Sometimes a bootloop will occur because of the root explorer you use. However, of you're still on stock rom you'll very likely end up in a bootloop. AOSP roms don't have this weaknesses but they're not as stable as miui.
I recommend installing a debloated rom like MiuiMix or miui eu. Then get help from the support forums to find out how to get into system without killing the rom.
Everytime I tried to flash a ROM without wiping system (bc I can't) I got error 7. So I had to do a format data and I lost all of my stuff. Is there any way of wiping system so I don't have to do a format data?
Piusak said:
Everytime I tried to flash a ROM without wiping system (bc I can't) I got error 7. So I had to do a format data and I lost all of my stuff. Is there any way of wiping system so I don't have to do a format data?
Click to expand...
Click to collapse
Once after booting up any rom, check whether the device is encrypted or not. (Security > Encryption)
If it is, then offcourse, in recovery you had to wipe everything if you wanna flash a new rom. This device has dynamic partition update, that merges all OS partitions (system, vendor, product) & encrypts data partition if it's decrypted.
Ofcourse you also can't able to modify partitions while encrypted, caz you'll end up into errors.
I've been trying to follow the tutorials on resizing the partition but it seems like even after I do advance wipe and resize, the amount of free space on the system partition does not change. I take it that there is no free space to give and some other portion of the partition (like the data partition) should be shrunk before system partition can get the extra space.
I have no idea how Samsung managed to fit their OS AND all the google apps in the 560mb. Deleting any apps from the stock installed android only removes it from the data partition. System stays the same.
How can I resize the system partition properly to add more space?