Related
I hated the 128MB partition that mounts with the internal 8GB and my sdcard, so I used gparted via ubuntu to remove it and expand the linux-swap partition to fill the 128MB of unallocated space. Now no ROMs I use can mount the internal or external storage, nor can I mount it via USB- unless I'm in recovery. From recovery I can read the sdcard and mount it to browse via USB. Anyone have a solultion for this? I've wiped data and system and tried other ROMs, but each one is affected with the same issue.
Try a hard reset
Sent from my ADR6300 using XDA App
jdkoreclipse said:
Try a hard reset
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
Meaning to remove root, nand unlock, etc and start fresh?
No...its the clear storage option in the bootloadwr
Sent from my ADR6300 using XDA App
jdkoreclipse said:
No...its the clear storage option in the bootloadwr
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
My mistake. I just did that, waiting for results now.
xvenom89 said:
My mistake. I just did that, waiting for results now.
Click to expand...
Click to collapse
Nope, that did not work. My sdcard and internal storage are not mounting. Anyone else have an idea?
try a method posted in the cm6 thread
Sent from my ADR6300 using XDA App
jdkoreclipse said:
try a method posted in the cm6 thread
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
This?
http://forum.xda-developers.com/showpost.php?p=7319333&postcount=753
I don't see that as a solution. I need it to detect my storage like it does out of the box, as it did before I deleted one of the partitions. There has to be a way to restore it to factory defaults; I don't mind having to start from scratch at this point.
My only idea that might work is to flash a PB31IMG.zip from the bootloader... Anyone else have an insight?
Just an update, this fixed it:
http://androidforums.com/all-things...ideo-howto-unroot-incredible-downgrading.html
Update2:
I can get my phone running the original 2.2 leaked ota, but trying to upgrade to skyraider 2.5.2 from there brings me back to square one...
I can only access them while booted using the original 2.1 ROM or the first 2.1 OTA. When I upgrade to ANY Froyo ROM, the internal storage and sdcard disappear. I wish someone here would help me out so I can move on with my life; it's been this way for 24 hours now and I can't take it anymore.
Have you tried to just remake the partitions as they were?
lamerto said:
Have you tried to just remake the partitions as they were?
Click to expand...
Click to collapse
I cannot figure out how. Clue me in? I've used clockworkmod recovery to format each partition manually, but that didn't help.
I restored completely to stock as described here, followed by using unrevoked to root. From the stock 2.1 OS, I can read from the SD Card and Internal storage just fine. I then upgrade the radio to 2.15.00.07.28, as described here; everything still works at this point. Then I choose any 2.2-based ROM (skyraider, pmf, stock, cyanogenmod, etc) to upgrade to and install it via clockworkmod recovery. At that point, the booted system no longer reads from the SD Card or Internal Storage (BOTH are declaired "Unavailable" under Menu -> Settings -> SD & Phone Storage). From recovery I can still mount the SD Card via USB.
Before this mess I was running Skyraider 2.2 almost flawlessly, then I was picky and chose to use gparted via Ubuntu to delete the smaller ~128MB partition that mounted along side the SD Card and Internal Storage because it annoyed me. After deleting it, I expanded the linux-swap partition to fill the unallocated space. I did all this while the system was booted (after applying unrevoked-forever, so it would actually take effect). I then downloaded and installed the Skyraider 2.5.2 upgrade and that is when I first discovered this problem.
I think it MIGHT be fixable if I could figure out how to manually edit configurations to mount both partitions at boot.
I hope what happened is now clear to you all, because I'm dying here without my Incredible. I can't use it properly without the SD Card mounted, so I'm using a Palm Pre Plus for the time being. I could use a 2.1 ROM, but I became too in love with Froyo to part so soon. Please, if anyone has suggestions I would love to hear them. Thanks..
Since it seems nobody else has a clue how to work with this, I'm trying more things. I don't know why I didn't think of it before, but I'm editing the phone's fstab.
What was included:
/dev/block/mtdblock5 /cache auto rw
/dev/block/mmcblk0p1 /data auto rw
/dev/block/mtdblock6 /datadata yaffs2 rw
/dev/block/mtdblock3 /system yaffs2 rw
/dev/block/mmcblk1 /sdcard vfat rw
/dev/block/mmcblk1p2 /sd-ext auto rw
I added "/dev/block/mmcblk0p3 /emmc auto rw" for the internal storage and it worked once after I rebooted, but the sd card issue hasn't changed at all. It's already defined in the fstab, so why isn't it mounting?
So now sometimes the internal storage mounts and sometimes it doesn't. Anyway, with the sd card, now I found another interesting detail: the phone recognizes a different 2GB micro sd card while booted, but not the 16GB one I've been using for ages, the one that mounts fine in clockworkmod recovery and in 2.1 ROMs. It used to mount fine in Froyo, now it is "Unavailable". Why is this?
Xvenom89,
Wished I could help. But being a noob.....
If nothing else, at least I've bumped the thread for you. (-:
Just in case it helps, if the file you're referring to is vold.fstabs, the only entries in mine are;
dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0 /devices/platform/msm_sdcc.2/mmc_host/mmc1
dev_mount emmc /mnt/emmc 3 /
devices/platform/msm_sdcc.3/mmc_host/mmc2
Maybe you could PM one of the more friendly devs and ask if they'd mind making a suggestion.
________________________________
Unrevoked forever
SkyRaider 2.5.2 Sense
Hrdra kernel ocuv_ov_v10 (#2)
I'm having the same issue with the OTA Froyo update. So I was wondering, did you figure out a way to fix this issue?
xvenom89 said:
I cannot figure out how. Clue me in? I've used clockworkmod recovery to format each partition manually, but that didn't help.
Click to expand...
Click to collapse
Uh, if you can't figure out how, how did you manage to delete one?
Methinks you should have at least written down the details from the removed partitions before you removed them
It just seems sane.
I'm sorry to sound harsh, but, what were you thinking? It's a few megabytes that you risked the usability of your phone for.
That said, I think only recreating them yourself would fix it properly - possibly given the partition map of another Incredible (heck, maybe just dumping the first 512 bytes of the emmc device, assuming it's MBR, from a working incredible and having you patch that in would fix it.).
Yea what were you thinking, you don't just delete partitions randomly >.
Are there any roms or other easy ways to increase the size of the partition /data/data on the Droid Incredible? To this day, all I really find are ways to save space in there. That's been covered - everything from Cachemate to not using certain apps. I want to know if there are any roms out there that use space from internal or other areas and reroute them so that /data/data shows more space. Any help would be appreciated.
+1
I've run into this a lot lately. Even my Eris never had this problem.
enigmatl said:
Are there any roms or other easy ways to increase the size of the partition /data/data on the Droid Incredible? To this day, all I really find are ways to save space in there. That's been covered - everything from Cachemate to not using certain apps. I want to know if there are any roms out there that use space from internal or other areas and reroute them so that /data/data shows more space. Any help would be appreciated.
Click to expand...
Click to collapse
No roms do it currently. But its probably doable.
Sent from my ADR6300 using Tapatalk
There is an app on the market called Notenoughspace. I have never used it, but it is supposed to take stuff out of your data/data, and insert it somewhere else. I here it is tricky, so be careful if you use it. I really don't know much about it. The first couple of times I ran into this problem it drove me crazy. Have you read all of the threads for what causes this? Stay away from Facebook. If you sync contacts in Facebook it can cause this. I am a crackflasher, so I rarely run into the problem. I don't think that a Rom can fix this, but I am a newb myself. Really just wanted TP help since I saw your disgruntled post in the developers section....good luck
Thanks for the reply. But here's the thing. Please let's not go into the likes of notenoughspace and cachemate and whiping out facebook. This is what people say in EVERY thread on this from the beginning of the droid incredible.
I'm not looking for a solution that at best can let an extra app or 2 get installed on the droid incredible. I'm looking for a way to INCREASE the size of the /data/data partition by way of taking some unused space from other areas like system or cache or better yet, from that pointless internal storage (for all the SD card users).
There is a lot of extra space on these phones. Thus it is nonsensical to have a measly 150mb to use in that area.
AS this phone is for a friend (and I generally do the upgrading or fixing), I do not experience this on my photon nor do I experience it on my Iconia tab. There was a limit for /data/data on my evo but it was about twice the Droid Incredible I believe.
So this most likely has to be a partition issue. Is there really no fix for it? Since it's not a hardware limit, I'm surprised as I've seen some out of this world ROMs for the device (like Skyraider's which I hoped would make it to the Evo when I had that).
enigmatl said:
Thanks for the reply. But here's the thing. Please let's not go into the likes of notenoughspace and cachemate and whiping out facebook. This is what people say in EVERY thread on this from the beginning of the droid incredible.
I'm not looking for a solution that at best can let an extra app or 2 get installed on the droid incredible. I'm looking for a way to INCREASE the size of the /data/data partition by way of taking some unused space from other areas like system or cache or better yet, from that pointless internal storage (for all the SD card users).
There is a lot of extra space on these phones. Thus it is nonsensical to have a measly 150mb to use in that area.
AS this phone is for a friend (and I generally do the upgrading or fixing), I do not experience this on my photon nor do I experience it on my Iconia tab. There was a limit for /data/data on my evo but it was about twice the Droid Incredible I believe.
So this most likely has to be a partition issue. Is there really no fix for it? Since it's not a hardware limit, I'm surprised as I've seen some out of this world ROMs for the device (like Skyraider's which I hoped would make it to the Evo when I had that).
Click to expand...
Click to collapse
I have had the same problem, and I haven't seen any roms that come close to solving it. And there is no quick and easy solution.
The best work around I could find was to mod the stock rom and add Dark Tremor's APP2SD, and use notenoughspace.
With dtapps2sd you have to partiton the SD card so that you have a ext3 partition on it that can be mounted and apps can be ran from it. It does this for /data/app and a couple of other folders.
Notenoughspace will let you move folders in /data/data to the sd partition that dtapps2sd has mounted, and that survive through a reboot. The extra partition option is what you would use, not the NES partition.
Using this work around I have about 300 apps on my phone, and about 70mb free in /data/data.
My Android version is GB 2.3.4 (build 4.06.605.3).
enigmatl said:
Are there any roms or other easy ways to increase the size of the partition /data/data on the Droid Incredible? To this day, all I really find are ways to save space in there. That's been covered - everything from Cachemate to not using certain apps. I want to know if there are any roms out there that use space from internal or other areas and reroute them so that /data/data shows more space. Any help would be appreciated.
Click to expand...
Click to collapse
Bootmanager will install the whole rom on /sdcard or emmc storage and as an added bonus, /data and /data/data are all in one image so you have shared space. By default you have 950 MB to share for apps and app data. As an added bonus you have the ability to boot multiple roms and have them all loaded at once. It's available on the market and the devs who made it are awesome. However it costs a few dollars.
If you don't want to go that route then it's possible to create an image on the sdcard or emmc and symlink it to /data/data and you could set the size of the file. Then the ramdisk would need to be modified and maybe a couple of things done on the rom. You asked for an easy way and this is one but not easy though. Bootmanager is pretty easy though and no coding changes need to be done to the roms and it will leave your original rom intact.
I've been wondering about this as well.
I've tried a couple different approaches, and ended up sticking with one: it takes some setup overhead for every ROM I install, but it helps a lot.
I ended up deleting the datadata mount from init.inc.rc in boot.img (get ROM, unpack, edit init.inc.rc, repack, flash), and booting in recovery mode to move the data from ([email protected])/ over to (mmcblk0p1)/data (which is now just a subdir on the 768MB /data partition.)
Initial tests repartitioning mmcblk0 (houses /data, /cache, and /emmc) to make /data larger for this purpose didn't work out well: the bootloader rewrites the MBR/partition table when it finds that they don't match metrics it likes. /emmc can not really be reformatted because the bootloader updates some bits that it expects to be FAT32 on boot time as well, corrupting other filesystems.
Why on earth HTC would ship a phone in this day and age with such a crippled storage layout is beyond me.
DHowett said:
I've been wondering about this as well.
I've tried a couple different approaches, and ended up sticking with one: it takes some setup overhead for every ROM I install, but it helps a lot.
I ended up deleting the datadata mount from init.inc.rc in boot.img (get ROM, unpack, edit init.inc.rc, repack, flash), and booting in recovery mode to move the data from ([email protected])/ over to (mmcblk0p1)/data (which is now just a subdir on the 768MB /data partition.)
Initial tests repartitioning mmcblk0 (houses /data, /cache, and /emmc) to make /data larger for this purpose didn't work out well: the bootloader rewrites the MBR/partition table when it finds that they don't match metrics it likes. /emmc can not really be reformatted because the bootloader updates some bits that it expects to be FAT32 on boot time as well, corrupting other filesystems.
Why on earth HTC would ship a phone in this day and age with such a crippled storage layout is beyond me.
Click to expand...
Click to collapse
That doesn't sound too difficult (i moved CM7 from emmc img to the actual phone partitions so that should be pretty simple). The only downside is you do lose space for apps (easily solved with apps2sd). I haven't seen you around since you posted your idea for multiboot. Been busy?
Well, the emmc method would be a loopback image which would not touch the fat32 filesystem.
Or if you're doing nightlies for instance once you mod the boot.img just add it to each new nightly.
Would Conap's dual boot work the same way? I am comfortable with this, and all the coding is intimidating for this newb. Would one of you smarter members put out a small guide as to exactly how to do this. I know it is time consuming, but it would really be worth it to us low lifes. Thanks
How can you do this?
DHowett said:
I've been wondering about this as well.
I've tried a couple different approaches, and ended up sticking with one: it takes some setup overhead for every ROM I install, but it helps a lot.
I ended up deleting the datadata mount from init.inc.rc in boot.img (get ROM, unpack, edit init.inc.rc, repack, flash), and booting in recovery mode to move the data from ([email protected])/ over to (mmcblk0p1)/data (which is now just a subdir on the 768MB /data partition.)
Initial tests repartitioning mmcblk0 (houses /data, /cache, and /emmc) to make /data larger for this purpose didn't work out well: the bootloader rewrites the MBR/partition table when it finds that they don't match metrics it likes. /emmc can not really be reformatted because the bootloader updates some bits that it expects to be FAT32 on boot time as well, corrupting other filesystems.
Why on earth HTC would ship a phone in this day and age with such a crippled storage layout is beyond me.
Click to expand...
Click to collapse
Wow, that sounds like a great idea. Like the above poster, can I also ask if someone who knows how would write up some instructions on how to to this? It certainly would be appreciated by many! With Gingerbread, there's not much Incredible users can do about the tiny /data size. Thanks!
I'm encountering this issue with 384MB of phone storage free and nearly 4GB of SD free. When I checked, I only had 14.5MB free in /data/data. 150MB for this is ridiculous! I would appreciate any fix, preferably one I can set and forget (don't want to have to constantly move or create symlinks for ever new app I install).
possible fix
You should check out jermaine151's Stock+ version 2.1. http://forum.xda-developers.com/show....php?t=1260994. I can't personally vouch for it as he just released it and it's a little late to start reinstalling everything, but it looks promising.
Apologies if this has been resolved before, but I've been seeing two download folders in my SD card "downloads" and "Downloads." I've tried deleting one but I get an error - this also confuses Recovery when I try to flash a file located in one of the directories it typically looks in the wrong one. Has anyone had this or resolved it?
pongalong said:
Apologies if this has been resolved before, but I've been seeing two download folders in my SD card "downloads" and "Downloads." I've tried deleting one but I get an error - this also confuses Recovery when I try to flash a file located in one of the directories it typically looks in the wrong one. Has anyone had this or resolved it?
Click to expand...
Click to collapse
I have the issue and have just learned to deal with it. I don't really know when it why it happened, sometime around when I first flashed jellybean I think. Idk. Just letting you know you're not alone. Btw the "download" folder appears first in recovery. I move all my roms and kernels there. The "Download" is the folder all the general downloads end up in for me... at least I think... it's confusing but a sms issue to me.
DARKSIDE
I made a folder called Aaroms. It goes alphabetical and capital letters first so that folder is always on the top of the list. I then sort my roms mods and kernels with sub folders.
If you keep your (D)download folder clean and sorted it should be easy to know which one has what
Sent from my Galaxy Nexus using xda premium
This is just speculation, but...
1. I think the virtual sdcard (sdcard0) and its links exists to make the real "sdcard" (/data/media) look like fat to apps instead of ext, which it really is (because it doesn't have a separate partition to itself). Most apps only know how to write to fat on the sdcard.
2. To programs that expect to be writing to fat, "download" and "Download" are the same directory, so they can be careless how they spell it when they access it or create it. But since the real filesystem is ext, they get created as two different directories. Maybe through some case-checking bug in the virtual sdcard or some program that writes directly to /data/media.
3. What I wound up doing was taking all my data out of both directories, deleting one, and making sure the remaining one was named "directory". Then I put all my data back in that one and everything has been good since then.
Well this is Linux after all. Downloads != downloads
Sent from my Galaxy Nexus using xda premium
Need help too
pongalong said:
Apologies if this has been resolved before, but I've been seeing two download folders in my SD card "downloads" and "Downloads." I've tried deleting one but I get an error - this also confuses Recovery when I try to flash a file located in one of the directories it typically looks in the wrong one. Has anyone had this or resolved it?
Click to expand...
Click to collapse
I have the same issue. I have two Download folders. The thing is that the one with the small "D" (download), it is empty, and when I try to delete it, it always reappear.
Help!
this was anwsered like 2 days ago.
sent from my i9250
bk201doesntexist said:
this was anwsered like 2 days ago.
sent from my i9250
Click to expand...
Click to collapse
I cant find the post telling the answer. Lol. The last post isbin october 2010.
strumcat said:
1. I think the virtual sdcard (sdcard0) and its links exists to make the real "sdcard" (/data/media) look like fat to apps instead of ext, which it really is (because it doesn't have a separate partition to itself). Most apps only know how to write to fat on the sdcard.
Click to expand...
Click to collapse
I think that the symlinks are there just for backwards compability issues with apps, that look under /sdcard/ mount point. it doesn't have anything to do with fs, android never used fat, or ntfs; known fs in android are yaffs2, ext4 and maybe a few proprietary ones like sammy's rfs.
bk201doesntexist said:
I think that the symlinks are there just for backwards compability issues with apps, that look under /sdcard/ mount point. it doesn't have anything to do with fs, android never used fat, or ntfs; known fs in android are yaffs2, ext4 and maybe a few proprietary ones like sammy's rfs.
Click to expand...
Click to collapse
The real sdcards were formatted as fat, and most apps that used them to store data only knew how to read/write a fat fs. I found this out by creating a mountable volume on a real sdcard on my old phone. It mounted as a directory on the sdcard. If I formatted the volume as fat, all my apps could use it normally. If I formatted it as ext(anything), a few apps could use it but most could not.
The symlinks are for backwards compatibility, but I believe the fuse filesystem virtual sdcard0 exists to make ext4 look like fat to all apps and to windows.
Note that if the gnex "sdcard" had its own partition, it could be formatted as fat and mounted as USB external storage like a real sdcard. I don't know, but it seems like Google went out of their way to prevent that.
The Google line is that the gnex sdcard shares an ext4 partition to maximize space, ie no unused wasted space on two partitions. But that is pretty farfetched, since the number of problems caused by this arrangement is huge in proportion to the "space saved" which is negligible.
Obviously, the real reason for this kludged-up mess is to discourage local storage/backup and encourage cloud storage, which can then be monetized.
strumcat said:
The real sdcards were formatted as fat, and most apps that wrote data to it only knew how to write it to a fat fs. I found this out by creating a mountable volume on a real sdcard on my old phone. It mounted as a directory on the sdcard. If I formatted the volume as fat, all my apps could use it normally. If I formatted it as ext(anything), a few apps could use it but most could not.
The symlinks are the for backwards compatibility, but I believe the fuse filesystem virtual sdcard0 exists to make ext4 look like fat to all apps and to windows.
Note that if the gnex "sdcard" had its own partition, it could be formatted as fat and mounted as USB external storage like a real sdcard. I don't know, but it seems like Google went out of their way to prevent that.
The Google line is that sdcard shares ext4 partition to maximize space, is no unused wasted space on two partitions. But that is pretty farfetched, since the number of problems caused by this arrangement is huge in proportion to the "space saved" which is negligible.
Obviously, the real reason for this kludged-up mess is to discourage local storage/backup and encourage cloud storage, which can then be monetized.
Click to expand...
Click to collapse
sure, i was talking about nand storage. still, if apps really depend on that to survive (said "fat compability"), it's unlogical to me coming from linux, where several fs can co-exist, as you may know.
if sdcard had its own partition like you say, and it could be formatted to fat, it would suck from a performance point of view, right? because its way slower than ext4 or yaffs2?
sent from my i9250
bk201doesntexist said:
sure, i was talking about nand storage. still, if apps really depend on that to survive (said "fat compability"), it's unlogical to me coming from linux, where several fs can co-exist, as you may know.
if sdcard had its own partition like you say, and it could be formatted to fat, it would suck from a performance point of view, right? because its way slower than ext4 or yaffs2?
sent from my i9250
Click to expand...
Click to collapse
Sure, Android knows how to read/write fat as well as ext. But I guess the app devs figured sdcards would be fat forever. so they only included fat I/O in their apps.
Yes, ext4 is better than fat. But fat+mass-storage is far better and faster than ext4+fuse+mtp. For example, an sdcard backup from fat mounted as mass storage to a pc is much faster and more reliable than an sdcard backup using mtp. MTP backups are painfully slow and often won't even complete due to errors.
strumcat said:
Sure, Android knows how to read/write fat as well as ext. But I guess the app devs figured sdcards would be fat forever. so they only included fat I/O in their apps.
Yes, ext4 is better than fat. But fat+mass-storage is far better and faster than ext4+fuse+mtp. For example, an sdcard backup from fat mounted as mass storage to a pc is much faster and more reliable than an sdcard backup using mtp. MTP backups are painfully slow and often won't even complete due to errors.
Click to expand...
Click to collapse
Well it still happens in 2017 running Android 7.1.2 lol
Sent from my SM-G930W8 using Tapatalk
Currently running MikG3.11 w/a2sd so have a EXT3 partition for data (I have my /cache pointing there also). I'm looking to move to a JB rom (probably Evervolv - http://forum.xda-developers.com/showthread.php?t=1961602).
How do I need to re-partition my 16G sd to make the most efficient use? It's been quite a while so a quick 'step1,2,3 howto would be great..including suggested sizes, ext3/ext4...)
Recovery is SmelkusMod..
Thanks Tons!
You may not *need* to do anything out of the ordinary.
If your ext3 partition is of a reasonable size, you might be able to just wipe everything (except 'SD card') in smelkus, flash the ROM, and proceed from there. Nandroid first of course.
'Reasonable' means about 512 to me, others may have different ideas.
How big is your ext partition?
The main reason to repartition is if you are having mystery SD card issues or you want to add or resize partitions. If these don't apply, just wipe, flash, and go.
6100 using xda app-developers app
NxNW said:
You may not *need* to do anything out of the ordinary.
If your ext3 partition is of a reasonable size, you might be able to just wipe everything (except 'SD card') in smelkus, flash the ROM, and proceed from there. Nandroid first of course.
'Reasonable' means about 512 to me, others may have different ideas.
How big is your ext partition?
The main reason to repartition is if you are having mystery SD card issues or you want to add or resize partitions. If these don't apply, just wipe, flash, and go.
6100 using xda app-developers app
Click to expand...
Click to collapse
I would. Repartition, 0/1024, ext3, then ext4....i actually do this before any flash. Think about what a2sd does, and you'll realize that if you don't format, your system has to run through more dead data to get to the info it needs
Sent from my EVO 4G using Tapatalk 2
jwitt418 said:
I would. Repartition, 0/1024, ext3, then ext4....i actually do this before any flash. Think about what a2sd does, and you'll realize that if you don't format, your system has to run through more dead data to get to the info it needs
Sent from my EVO 4G using Tapatalk 2
Click to expand...
Click to collapse
/system 318 used out of 350mb
/data 369/428mb
/cache 1.38mb/160mb
sdcard ext3 .97 used, 1.79GB total.
sdcard fat32 (rest of the 16G)
I had thought that going ext4 was typically recommended for JB. Are you saying first create a 1G ext3, then the rest as ext4? How does that work for transferring files back and forth via usb to a win7 box?
I intend on doing this fresh.. ie, install gbapps and individual app re-installs from there.
I have a lot of opinions on this but let me just try to answer your one specific question about ext4.
(going from memory here, I'm sure someone will correct me if I'm wrong..)
When creating partitions in recovery, you will be prompted to allocate space to three separate partitions, swap, sd-ext, and 'the rest'. You have to choose a specific size for the first two, the third partition gets whatever is left. If you choose a size of zero when prompted, it will skip creating that partition.
So if you follow jwitts advice above, you will answer zero for swap, then 1024 for the ext partition.
This will skip the creation of a swap partition and create a sd-ext partition with size 1024. Initially you want to format this as ext2.
The rest of the SD card will go in the main sdcard partition and will be formatted as FAT.
As a last step you convert your ext2 partition to ext3 (and if you think there would be a benefit, you can further convert it from ext3 to ext4 in a subsequent step.)
Honestly, I installed evervolv over the exact same partition scheme you have already and have seen no need to tamper with it. Obviously others do. I leave you to make whatever decision you feel most comfortable with.
Partitioning is destructive: you lose all the contents of the entire SD card in the process so you need to make a backup first, and I don't mean nandroid. To me it's a bit more inconvenience plus the risk of losing irreplaceable data (ie pictures, music, etc).
By contrast, wiping partitions is routine and doesn't touch the main FAT partition. If you use smelkus to wipe your sd-ext partition (as implied in the oft-repeated advice to "wipe everything except 'SD card'") you should be starting with a pretty clean slate.
Maybe I've had the wrong understanding all this time, but I have been working under the assumption that "wiping" has the effect of deleting all the files below certain mount point.
The contents of your sd-ext folder are just as gone as if you "formatted". There may be other benefits to additional formatting or partitioning, and when you are planning to start from scratch, that can be a good time to do this sort of "preventive maintenance", but I was just pointing out that under normal conditions it is not strictly necessary.
Hi there,
I'm thinking of encrypting my phone as some important files (like my private key) are stored on it. Getting the internal storage to be encrypted isn't the big deal. My problem is that I can't find an option to encrypt the external SD. Some googling showed me, that it is theoretically possible. But I can't find such a point on my phone.
I'm on CM11 M8 (4.4.4) without any special kernel.
I've read occasionally that encrypted phones will suffer from speed loss. I don't really think that is a problem for my S4 Mini. What do you think? Is it practically or even necessary?
Thanks a lot
hadage said:
My problem is that I can't find an option to encrypt the external SD. Some googling showed me, that it is theoretically possible. But I can't find such a point on my phone.
Click to expand...
Click to collapse
You could use the SD card itself as data partition: http://forum.xda-developers.com/showthread.php?t=2644540 That way you can encrypt the whole SD card using Android stock encryption.
Keep in mind though that currently there is no (publicly known) way to mount an Android encrypted partition on another OS, should you ever wish to use that card e.g. on your PC.
hadage said:
I've read occasionally that encrypted phones will suffer from speed loss. I don't really think that is a problem for my S4 Mini.
Click to expand...
Click to collapse
Flash memory is sooooo slow, I expect the CPU to encrypt faster than that.
Thanks
So am I right, that after doing that "workaround" I'll be having one big internal storage (divided into real internal and fake internal) but no external SD card?
Aguaz said:
For the sake of still having an "official" external sdcard I made two partitions
Click to expand...
Click to collapse
Is there any need to?
Aguaz said:
This partition however has to be manually specified in the ramdisks fstab which involves flashing the boot partition.
Click to expand...
Click to collapse
I'm not sure if I'm understanding it right, but that means that I have to delete my boot partition?
hadage said:
So am I right, that after doing that "workaround" I'll be having one big internal storage (divided into real internal and fake internal)...
Click to expand...
Click to collapse
yes, nothing really changes except that the data partition will then be on the sdcard. The size of it is only limited by the size of your card.
hadage said:
...but no external SD card? Is there any need to?
Click to expand...
Click to collapse
As mentioned in the other thread I still use a small partition on sdcard for the "external" sdcard. Android usually tries to automount the first partition on the sdcard as "external" sdcard. So I chose to have data on the 2nd partition.
I doubt that this really is necessary though. I assume vold will just give up trying to mount "external" sdcard after realizing the partition is already in use.
Generally, I don't think there is a need for an external sdcard.
hadage said:
I'm not sure if I'm understanding it right, but that means that I have to delete my boot partition?
Click to expand...
Click to collapse
You would need to flash a new boot.img onto it, because this image holds the fstab.qcom file, which needs to be edited to change the mount point of the data partition. Unfortunately it's triple packed:
cm-11-UNOFFICIAL-serranodsdd.zip
.....> boot.img
..........> initrd.img
...............> fstab.qcom
So it's not very straight forward, but the forum is full of info on how to do so. Keep in mind that your recovery.img has to be changed the same way in order for it to find the new data partition.
When formatting a data partition to be used for Android encryption, make sure the filesystem doesn't extend into the last 16 Kbytes of the partition where the crypto footer is kept. See https://community.freescale.com/docs/DOC-93753
hadage said:
Thanks
Click to expand...
Click to collapse
Don't say that. Hit the button
Alright, I'll have a look on that. I'm not absolutely sure if I'll be doing this, but thanks anyway. Helped me a lot
It's a bit of effort to set up, but in the long term it'll save you time not having to deal with additional tools. Plus you got ONE big storage instead of data fragmentation across several locations.
Good luck!
aguaz said:
It's a bit of effort to set up, but in the long term it'll save you time not having to deal with additional tools. Plus you got ONE big storage instead of data fragmentation across several locations.
Good luck!
Click to expand...
Click to collapse
@aguaz,
That's some very interesting stuff you are writing about.
Few questions, if you will:
1. You say the fstab.qcom is tripple-packed. But if I use a tool like Android Kitchen or AIK to unpack the boot.img, it appears there's only one layer of packing.
2. why not mount the external SD card just as the /data/media/0/ instead of /data? This way, app-data is still kept on the internal memory, and we get even more free space on SD + faster read/write speeds for app-data.
3. What /dev/ are you using to mount the external?
Can you shed some light on that?
EDIT:
Ad. 1
I guess this is kind of irrelevant as doing it with the tools I'm using seems to work flawlessly.
Ad. 2 and 3.
I did in fact manage to mount the sdcard just as a subfolder /data/media/0/ while leaving all the remaining /data on the internal storage, and from brief testing on an old SD card, it seemed to work fine
Code:
/dev/block/platform/msm_sdcc.3/mmcblk1p1 /data/media/0/ ext4 nosuid,nodev,noatime,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=footer,length=-16384
Now, the question is how to tune those mount options for a SD card, and how would they change if I was to use F2FS instead of ext4, which would be the ultimate solution.
1) I'm not familiar with the tools you mention, but boot.img consists of both kernel & ramdisk images. The ramdisk image itself contains fstab etc.
Alternatively you could also try an init.d script to change fstab. Those scripts get executed before data and sdcard are mounted.
2) Did you keep the vold entry regarding the external card? If so, does it still get (additionally) mounted as external card?
impactor said:
Now, the question is how to tune those mount options for a SD card, and how would they change if I was to use F2FS instead of ext4.
Click to expand...
Click to collapse
The mount options are usually file system depended. So if file system is the same, you can use the same options as for internal flash partitions. I'd probably only change "errors=panic" into "errors=remount-ro" and remove "length=-16384" (deprecated).
I can't help you with f2fs mount options.
As the original question was about encrypting the card, let me add that stock encryption only works on partitions mounted as /data. So in your case that would not work.
Thanks for the clarification.
I commented out the vold mount, so it does not get automounted. Moreover, I doubt it would mount anyway because AFAIK a device in linux can only be mounted once.
aguaz said:
As the original question was about encrypting the card, let me add that stock encryption only works on partitions mounted as /data. So in your case that would not work.
Click to expand...
Click to collapse
I do want to encrypt my phone, eventually.
Can you elaborate more on why a card mounted under /data/media/0/ would not get encrypted when /data is being encrypted?
Also, what happens to encrypted partition when I install a new ROM? Can it still be mounted (will the rom ask me for password), or is the data lost and device needs to be reencrypted each time new ROM is installed??
impactor said:
Moreover, I doubt it would mount anyway because AFAIK a device in linux can only be mounted once.
Click to expand...
Click to collapse
You can multi mount as long as you specify the same mount options. I imagine it's technically the same as bind mounts.
impactor said:
Can you elaborate more on why a card mounted under /data/media/0/ would not get encrypted when /data is being encrypted?
Click to expand...
Click to collapse
Actually it's not the /data directory tree which gets encrypted, but the whole file system of the underlying partition. Linked locations or external mount points are are not part of that file system, so they are not regarded.
impactor said:
Also, what happens to encrypted partition when I install a new ROM? Can it still be mounted (will the rom ask me for password)
Click to expand...
Click to collapse
Yes, Android checks the data partition for an encryption footer and if found will ask for a password. So as long as you don't wipe/format that partition even a freshly installed ROM is supposed to recognize it.
aguaz said:
Actually it's not the /data directory tree which gets encrypted, but the whole file system of the underlying partition (as referenced by fstab). Linked locations or external mount points are are not part of that file system, so they are not regarded.
Click to expand...
Click to collapse
I see. Are you aware whether it's possible to use cross-device virtual devices (like LVM vgroups or BTRFS raid options) on android?
aguaz said:
Yes, Android checks the data partition for an encryption footer and if found will ask for a password. So as long as you don't wipe/format that partition even a freshly installed ROM is supposed to recognize it.
Click to expand...
Click to collapse
Is it still the case (4.4 CM roms) that if encrypted, the password must be the same as screenlock AND you have to tape it every time you unlock the screen AND the screenlock cannot be pattern?
BTW, what SD card model/spec are you using on your device for mounting as /data?
---------- Post added at 10:13 AM ---------- Previous post was at 09:25 AM ----------
One more thing. The tool I have been using seems to have proglems with boot.img fot KitKat. Where can I find this abootimage, and what options/operators are you using while (de)compressing with gzip, cpio & abootimage?
impactor said:
I see. Are you aware whether it's possible to use cross-device virtual devices (like LVM vgroups or BTRFS raid options) on android?
Click to expand...
Click to collapse
I'm not sure. Android tends to make things complicated, but at the end it's still just Linux.
impactor said:
Is it still the case (4.4 CM roms) that if encrypted, the password must be the same as screenlock AND you have to tape it every time you unlock the screen AND the screenlock cannot be pattern?
Click to expand...
Click to collapse
This is all by memory, but I think I might not be too far off:
- screenlock initially has to be either pin or pwd
- encryption password will be set the same as the current screenlock and cannot be changed once encrypted.
- screenlock however can be changed anytime.
- screenlock can also be completely removed by e.g. removing lock offline or installing a fresh ROM.
You can then choose whatever lock, or skip lock completely doh.
impactor said:
BTW, what SD card model/spec are you using on your device for mounting as /data?
Click to expand...
Click to collapse
I believe I got a Transcend 64GB UHS. But the S4 Minis controller is probably hooked to a slow USB line anyway, so It does not achieve advertised sequencial speeds.
aguaz said:
I'm not sure. Android tends to make things complicated, but at the end it's still just Linux.
Click to expand...
Click to collapse
Tis true, but it is quite gutted to achieve smaller footprint (among other reasons). Which is why, for example, we have so very few filesystems in kernels. I doubt getting LVM support is doable, but BTRFS should be less outlandish, as it's just a filesystem.
The thing is, hardly anyone here talks about it, which is strange as it offers features that scream "AWESOME" for uses in mobile phones - for example with transparent data compression: on an old HDD with interface capped at 50MB/s, I am able to reach transfers of up to 600MB/s with BTRFS. Imagine how that'd change the performance of internal memory and SD card in the phone...
aguaz said:
This is all by memory, but I think I might not be too far off:
- screenlock initially has to be either pin or pwd
- encryption password will be set the same as the current screenlock and cannot be changed once encrypted.
- screenlock however can be changed anytime.
- screenlock can also be completely removed by e.g. removing lock offline or installing a fresh ROM.
You can then choose whatever lock, or skip lock completely doh.
Click to expand...
Click to collapse
Now, this is interesting, because that would mean there were some serious changes since JellyBean 4.1.
See this bug: https://code.google.com/p/android/issues/detail?id=29468
Its status is still "NEW" instead of "Closed", so I wonder if anything has been done about it. If I had to type in the pin every time I unlock the screen, that would make encryption unusable for me due to practicality.
aguaz said:
I believe I got a Transcend 64GB UHS. But the S4 Minis controller is probably hooked to a slow USB line anyway, so It does not achieve advertised sequencial speeds.
Click to expand...
Click to collapse
UHS speeds are not achievable for mobile phones, but there is a difference in speed between various UHS-1 cards when used in such devices.
Right now I have SanDisk Ultra, but I've been digging around and decided this would be the option, especially if I have to use it as /data mountpoint: http://www.amazon.com/Samsung-Electronics-Adapter-MB-MP64DA-AM/dp/B00IVPU7AO#customerReviews
By the way: The tool I have been using for operations on boot.img seems to have proglems with boot.img fot KitKat. Where can I find this abootimage, and what options/operators are you using while (de)compressing with gzip, cpio & abootimage?
impactor said:
Now, this is interesting, because that would mean there were some serious changes since JellyBean 4.1.
See this bug: https://code.google.com/p/android/issues/detail?id=29468
Its status is still "NEW" instead of "Closed", so I wonder if anything has been done about it. If I had to type in the pin every time I unlock the screen, that would make encryption unusable for me due to practicality.
Click to expand...
Click to collapse
As mentioned above Android (I'm speaking for kitkat) lets you change the screenlocks pwd / pin after encryption. So the lock eventually can become independent of the pwd you enter for encryption at boot. If you want to use another kind of screenlock or remove it alltogether you can e.g. replace it offline or make a fresh ROM installation.
impactor said:
By the way: The tool I have been using for operations on boot.img seems to have proglems with boot.img fot KitKat. Where can I find this abootimage, and what options/operators are you using while (de)compressing with gzip, cpio & abootimage?
Click to expand...
Click to collapse
It's called abootimg, I've corrected that. All those tools are generally included in your distribution, so you can easily install them with the package manager.
unpacking ramdisk
Code:
$ abootimg -x boot.img
$ mkdir ramdisk && cd ramdisk
$ cat ../initrd.img | gunzip | cpio -idv
repacking boot.img
Code:
$ find . | cpio -o -H newc | gzip > ../initrd.img
$ cd ..
$ abootimg --create boot.img -f bootimg.cfg -k zImage -r initrd.img
Thanks. I have another problem, though. Whatever changes I make to fstab, they are being ignored by KitKat. Here's the details: http://forum.xda-developers.com/android/help/wrong-fstab-qcom-kitkat-changes-effect-t2898184
Do you know what might be causing it?
aguaz said:
When formatting a data partition to be used for Android encryption, make sure the filesystem doesn't extend into the last 16 Kbytes of the partition where the crypto footer is kept. See https://community.freescale.com/docs/DOC-93753
Click to expand...
Click to collapse
Something occurred to me. Later on, you said to drop the "length=-16384" from mount options. Is it the same thing as the above? If so, then is it no longer necessary to leave the extra space?
I can't recall why the mount flag was removed from CM. I expect the footer to be still in use though.
Run logcat via adb then start encryption for error messages.
impactor said:
I doubt getting LVM support is doable, but BTRFS should be less outlandish...
Click to expand...
Click to collapse
No sign of lvm, but btrfs is in the official samsung kernel sources.
Technically it should even work with encryption since the file system is on top of dm-crypt. But then again, it's Androids implementation...
Interesting. But still, it needs kernel module for BTRFS, and judging from the rarity of F2FS kernels, I am extremely doubtful we will get BTRFS one anytime soon, unless we compile it ourselves.
On the subject of encryption - I think I found a way to encrypt the external SD card mounted on /data/media/0 independently on /data encryption:
http://www.guyrutenberg.com/2012/06...isk-encryption/comment-page-1/#comment-357674
Read the comment from January 14, 2013 at 05:28.
impactor said:
I am extremely doubtful we will get BTRFS one anytime soon, unless we compile it ourselves.
Click to expand...
Click to collapse
Obviousely someone has to do it. But if nobody would do stuff like that there was no xda and we all use stock ROMs
impactor said:
On the subject of encryption - I think I found a way to encrypt the external SD card mounted on /data/media/0 independently on /data encryption:
http://www.guyrutenberg.com/2012/06...isk-encryption/comment-page-1/#comment-357674
Read the comment from January 14, 2013 at 05:28.
Click to expand...
Click to collapse
Yes, but this approach uses luks, another variant of dm-crypt used in stock encryption. There is nothing wrong with luks, in fact it'd be desirable if stock used luks as it is the de facto standard.
But as it's not the standard in Android a few downsides come to mind:
- requires 3rd party app/tool
- luks is not supported by recovery
- is that a plain text password in the init.d script!? If true you might as well skip encryption altogether.
Another approach could be:
- temporarily use sdcard as data just to encrypt it
- change again to desired mount point via fstab with "wait,check,encryptable=footer" options
- find out whether Android is smart enough to ask for password and mount it (even if it's not used for /data anymore)
Keep in mind that by hanging the sdcard in /data/media/0 most stuff gets written on the card anyway, so internal /data would not be of great use.
There is other good stuff you can do with it.