Database Info

Missing space with new Apps2SD method

I was trying to use the new Apps2SD method by Marcus and I seem to be running into a problem. When I try to remove the unionfs partition through either G-Parted or disk utility I cannot remove/format it.
As far as I'm aware unionfs is NOT supported in G-parted nor in Mac OS. I only have a 1GB FAT32 partition and the other 3GB seem to be lost. I searched the forums and Google but cannot find anything. Does anyone have any suggestions?

im not sure what are you trying to do, but you can repartition removing phone's sd card and plugin it into a computer. If you want to repartition / change partitions with you phone acting as sd card reader connected with usb, you will have to undo unionfs process before trying to repartition / make any changes to sdcard
that last can be acomplished removing /data/init.rc and /data/a2sd.sh and rebooting the phone.
if this doesnt help you, provide more info, like the output of "df" command.

What I'm trying to do is restart Marcus's unionfs Apps2SD by destroying the partitions so I can get a fresh start. I tried deleting the 2 files you told me about but that didn't work. Heres the output of df:
# busybox df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 49356 0 49356 0% /dev
tmpfs 4096 0 4096 0% /sqlite_stmt_journals
/dev/block/mtdblock3 92160 60244 31916 65% /system
/dev/block/loop0 492 492 0 100% /system/modules
/dev/block/loop1 3524 3524 0 100% /system/xbin
/dev/block/mtdblock5 91904 23756 68148 26% /data
/dev/block/mtdblock4 30720 1160 29560 4% /cache
/dev/block//vold/179:1
991664 0 991664 0% /sdcard
Thanks!

[MOD] Alternative to new fs for swap

EDIT: I cannot recommend placing the swapfile on /sdcard as I have done here. As discussed below, this will cause problems if you mount the SD card without first shutting down swap. Instead, use an existing ext2/ext3 filesystem (if you have one). If you don't, you have been warned.
Apologies if this was already discussed somewhere; I searched about and aside from a couple threads with too many hundred pages to sift through, I didn't see anything obviously relevant...
There is an alternative method to using an additional ext2/ext3 partition for setting up swap space on an SD card, but I'm not sure what the performance ramifications are (should be insignificant). I set this up on the vfat partition that's mounted as /sdcard (yes, I know the risks behind having swap mounted on the vfat slice -- if you care and have a large enough pre-existing ext2 or ext3 filesystem, go ahead and put the swapfile there instead ):
as root, via adb shell, to make a 24mb swapfile:
Code:
# dd if=/dev/zero of=/sdcard/swapfile.swp bs=1024 count=24576
# mkswap /sdcard/swapfile.swp
# swapon /sdcard/swapfile.swp
Afterwards, "free" should look something like this:
Code:
# free
free
total used free shared buffers
Mem: 98328 96412 1916 0 116
Swap: 24568 0 24568
Total: 122896 96412 26484
I haven't worked out automounting of the swapfile on reboot...I'm still debating if the performance gains are worth the effort to continue, but it looks like there's some potential. Certainly the lag and and "loading" time when going to TouchFlo from another app feel reduced - but I have no empirical evidence to back that up.
Cheers!

Thanks for posting, I will try it using Dude's 1.3rc2. I am also using the ext3 partition.

As far as I know, this is how the Swapper app in the Market works - it places a swap file at the path of your choice (/sdcard/ by default)

Hi There,
I just tried on JF1.51 ADP
I set the swap file on the ext3 partion of the sdcard. It actually seems to help a lot, specially with intensive applications (i.e. copilot live).
I'll test it for a while.
with app2sd it would be possible to modify the script to call the mkswap and swapon command on boot.
Cheers and thanks for the info

Sorry doulbe post

Saiboogu said:
As far as I know, this is how the Swapper app in the Market works - it places a swap file at the path of your choice (/sdcard/ by default)
Click to expand...
Click to collapse
Thanks for that! This does appear to be the case. I hadn't looked for apps in the market -- the various ROM threads are filthy with comments about manually creating a third partition to house swap and I wanted to cleanly illustrate an alternative that relies only on existing partitions.
Swapper looks to potentially be an even easier alternative.
rastacre said:
with app2sd it would be possible to modify the script to call the mkswap and swapon command on boot.
Click to expand...
Click to collapse
After the file is created (via dd) mkswap initializes it as swap space. So long as the file doesn't get deleted/recreated, you shouldn't actually need to re-mkswap it, just swapon it.
Also, it shouldn't be necessary to use Apps2SD to make it mount on boot. It certainly is one way to skin the proverbial cat, but I'm hoping for a more elegant solution...
Cheers!

Yes swapper does the same thing as this but there is an issue here.
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Only thing now is if someone can figure out how to run the swap script on boot, and everything would be golden

sxfx said:
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Click to expand...
Click to collapse
And there it is. Wow, that really does do something extremely bad...not sure what though.
After mounting the card in Windows, and then releasing it back to the handset, it did complain about an unreadable SD card. It also suggested that I would need to reformat.
Instead, I just run 'swapoff /sdcard/swapfile.swp ; sync' and then rebooted the phone. No reformatting necessary and subsequently executing 'swapon /sdcard/swapfile.swp' works as well.
Looks like using a swapfile on the vfat partition, anyway, is ... not recommended ... unless a way can be found to programmatically 'swapoff' the swapfile before unmounting the partition.
It appears that this is ONLY a problem if your swapfile exists on the "/sdcard" partition, but that you can still create the file on any other pre-existing ext2/ext3 filesystems (such as an Apps2SD partition, if applicable). I have been unable to recreate this problem with swap mounted on my "/system/sd" slice (/dev/block/mmcblk0p2)...

sxfx said:
Yes swapper does the same thing as this but there is an issue here.
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Only thing now is if someone can figure out how to run the swap script on boot, and everything would be golden
Click to expand...
Click to collapse
That's exactly what I was looking for.
What's the command I should use in terminal to push the swap file to my swap partition?

mholger said:
And there it is. Wow, that really does do something extremely bad...not sure what though.
After mounting the card in Windows, and then releasing it back to the handset, it did complain about an unreadable SD card. It also suggested that I would need to reformat.
Instead, I just run 'swapoff /sdcard/swapfile.swp ; sync' and then rebooted the phone. No reformatting necessary and subsequently executing 'swapon /sdcard/swapfile.swp' works as well.
Looks like using a swapfile on the vfat partition, anyway, is ... not recommended ... unless a way can be found to programmatically 'swapoff' the swapfile before unmounting the partition.
It appears that this is ONLY a problem if your swapfile exists on the "/sdcard" partition, but that you can still create the file on any other pre-existing ext2/ext3 filesystems (such as an Apps2SD partition, if applicable). I have been unable to recreate this problem with swap mounted on my "/system/sd" slice (/dev/block/mmcblk0p2)...
Click to expand...
Click to collapse
Yes, best bet is to not put it on the vfat partition. Since the mmcblk0p2 does not become mounted/unmounted, it is better to put it on there. I've corrupted my card twice putting it on the vfat. Even better is to create a swap partition, on mmcblk0p3

andonnguyen said:
Yes, best bet is to not put it on the vfat partition. Since the mmcblk0p2 does not become mounted/unmounted, it is better to put it on there. I've corrupted my card twice putting it on the vfat. Even better is to create a swap partition, on mmcblk0p3
Click to expand...
Click to collapse
Agreed.
Original post has been ... amended.

So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?

a class 6 sdcard is faster than the internal flash.
mholger said:
So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?
Click to expand...
Click to collapse

mholger said:
So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?
Click to expand...
Click to collapse
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard and:
mkswap /dev/block/mmcblk0p3
swapon /dev/block/mmcblk0p3
echo 30 > /proc/sys/vm/swappiness

andonnguyen said:
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard
Click to expand...
Click to collapse
I'm nominally inclined to disagree with this. Swapfiles shouldn't pose any risk in terms of fs or disk corruption on a non-removable filesystem -- it's been around in linux long enough that someone would have had to critically break Android to cause this to be a problem. On the other hand, corruption issues are rampant on the SD cards primarily as a result of dirty dismounts -- which can lead to other system problems as well. Combined with the theoretical** increase in read/write cycles on the flash, if performance were equal it would seem sensible to place as much swap internally as possible. As it turns out, things aren't exactly equal, however..
**I'm quite frequently wrong, as we'll see below, and this is a particularly salient point to disprove me on if you're so inclined.
dwang said:
a class 6 sdcard is faster than the internal flash.
Click to expand...
Click to collapse
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
Code:
# time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
real 0m 1.61s
user 0m 0.05s
sys 0m 0.70s
# time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 9.162 secs (1831173 bytes/sec)
real 0m 10.48s
user 0m 0.05s
sys 0m 2.90s
# time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 0.504 secs (16644063 bytes/sec)
real 0m 0.56s
user 0m 0.05s
sys 0m 0.47s
# time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 4.096 secs (2048000 bytes/sec)
real 0m 5.40s
user 0m 0.05s
sys 0m 1.13s
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!

andonnguyen said:
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard and:
mkswap /dev/block/mmcblk0p3
swapon /dev/block/mmcblk0p3
echo 30 > /proc/sys/vm/swappiness
Click to expand...
Click to collapse
any idea on writing this into a script so it executes every time your phone reboots?

Nice... I knew it was faster, but I didn't know how fast. Now we have some actual numbers. I wonder what the read performance is like.
here's the results writing to RAM /dev (I believe tmpfs is RAM).
How did you get this line printed out?
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
EDIT: Ok you used toolbox dd and I used busybox dd
Code:
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.35s
user 0m 0.02s
sys 0m 0.20s
# time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.32s
user 0m 0.04s
sys 0m 0.28s
# time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.27s
user 0m 0.02s
sys 0m 0.26s
#
mholger said:
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!
Click to expand...
Click to collapse

Another good idea I saw in another thread is to use swapper and set the location to system/sd/swapfilename
This way you wont have to go through the hassle of creating a swap partition, and swapper runs on boot ..

mholger said:
I'm nominally inclined to disagree with this. Swapfiles shouldn't pose any risk in terms of fs or disk corruption on a non-removable filesystem -- it's been around in linux long enough that someone would have had to critically break Android to cause this to be a problem. On the other hand, corruption issues are rampant on the SD cards primarily as a result of dirty dismounts -- which can lead to other system problems as well. Combined with the theoretical** increase in read/write cycles on the flash, if performance were equal it would seem sensible to place as much swap internally as possible. As it turns out, things aren't exactly equal, however..
**I'm quite frequently wrong, as we'll see below, and this is a particularly salient point to disprove me on if you're so inclined.
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
Code:
# time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
real 0m 1.61s
user 0m 0.05s
sys 0m 0.70s
# time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 9.162 secs (1831173 bytes/sec)
real 0m 10.48s
user 0m 0.05s
sys 0m 2.90s
# time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 0.504 secs (16644063 bytes/sec)
real 0m 0.56s
user 0m 0.05s
sys 0m 0.47s
# time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 4.096 secs (2048000 bytes/sec)
real 0m 5.40s
user 0m 0.05s
sys 0m 1.13s
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!
Click to expand...
Click to collapse
very nice sir

mholger said:
EDIT: I cannot recommend placing the swapfile on /sdcard as I have done here. As discussed below, this will cause problems if you mount the SD card without first shutting down swap. Instead, use an existing ext2/ext3 filesystem (if you have one). If you don't, you have been warned.
Apologies if this was already discussed somewhere; I searched about and aside from a couple threads with too many hundred pages to sift through, I didn't see anything obviously relevant...
There is an alternative method to using an additional ext2/ext3 partition for setting up swap space on an SD card, but I'm not sure what the performance ramifications are (should be insignificant). I set this up on the vfat partition that's mounted as /sdcard (yes, I know the risks behind having swap mounted on the vfat slice -- if you care and have a large enough pre-existing ext2 or ext3 filesystem, go ahead and put the swapfile there instead ):
as root, via adb shell, to make a 24mb swapfile:
Code:
# dd if=/dev/zero of=/sdcard/swapfile.swp bs=1024 count=24576
# mkswap /sdcard/swapfile.swp
# swapon /sdcard/swapfile.swp
Afterwards, "free" should look something like this:
Code:
# free
free
total used free shared buffers
Mem: 98328 96412 1916 0 116
Swap: 24568 0 24568
Total: 122896 96412 26484
I haven't worked out automounting of the swapfile on reboot...I'm still debating if the performance gains are worth the effort to continue, but it looks like there's some potential. Certainly the lag and and "loading" time when going to TouchFlo from another app feel reduced - but I have no empirical evidence to back that up.
Cheers!
Click to expand...
Click to collapse
jacHEROski does this automatically using a linux-swap partition - that way your sdcard never gets corrupted on mount. It's also more reliable.
jacHEROski_Experimental also does it.
check out my a2sd.sh in /system/bin/ for more info on how to do it.

[Q] Low Space Warning

Has anyone else run into a situation where your tablet has received a low space warning on your Transformer but you haven't installed/used a lot of space?
When I look at my storage break down I use about 400mb of media and 12GB+ of application. When I view by application there is no way that it's 12GB. So I installed DiskUsage and the "system data" is using 11GB on it's own. I am suspecting it some how related to system crashes but have not confirmed this. Anyone else?

I am having the same problem just different amount of space shown

I've been digging around in adb tonight trying to get to the bottom of this:
Code:
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell df
Filesystem Size Used Free Blksize
/dev 364M 32K 364M 4096
/mnt/asec 364M 0K 364M 4096
/mnt/obb 364M 0K 364M 4096
/system 503M 340M 163M 4096
/data 13G 11G 1G 4096
/cache 521M 8M 512M 4096
/mnt/sdcard 13G 11G 1G 4096
I've been trying to get a good look into /data, but it's a system owned directory and you need root access to view some of the contents.
When I try to run:
adb shell ls /data
It responds:
opendir failed, Permission denied
Looks like I will have to root to continue the hunt, because I want to find the cause. The unfortunate thing is I need to revert my version back to 8.3.2.9 to be able to perform the root successfully. About to begin work on that now.

Is it when you are updating apps in the market and the app installation fails with a low space warning?
My Nexus S does that (with over 6gb available), then re-try the install and it works. Not sure where the issue is.

@tekkitan my big concern is:
Code:
/data 13G 11G 1G 4096
/mnt/sdcard 13G 11G 1G 4096
Because I've only used about 500MB's of space.
But you are correct I get the error trying to install from the market, and sometime if I delete some apps I can make enough room to install a new one.
There is a difference between 2.x and 3.x of android and how it allot's space for apps. In 2.x there is a partition that is limited size where you can install apps no matter the size of the onboard memory, unless you root and work around it. In 3.x they changed that and all free space can be used for apps.

So I can't perform the root tonight, I don't have a microSD card I can use to downgrade to 8.2.3.9. Will have to wait until tomorrow now.

wildbohr said:
@tekkitan my big concern is:
Code:
/data 13G 11G 1G 4096
/mnt/sdcard 13G 11G 1G 4096
Because I've only used about 500MB's of space.
But you are correct I get the error trying to install from the market, and sometime if I delete some apps I can make enough room to install a new one.
There is a difference between 2.x and 3.x of android and how it allot's space for apps. In 2.x there is a partition that is limited size where you can install apps no matter the size of the onboard memory, unless you root and work around it. In 3.x they changed that and all free space can be used for apps.
Click to expand...
Click to collapse
The Nexus S only has internal storage so it is similar.
Did you try just re-trying the download instead of removing apps? Like I said, if I just simply retry the isntallation/update, it works just fine.

I can't get imagine how apps could significantly impact the internal memory on a 16 or 32gb TF.
I've been loading apps on my Droid X internal 8gb memory with wild abandon for almost a year, and have only used up about 3gb. Tablet scaled apps might be somwhat larger, of course, but not that big.
Sent from my DROIDX using Tapatalk

Again I don't think it is a space issue. Just a bug with the Android Market.

[Q] CyanogenMod 6.3.0 link2sd

Anyone get link2sd working with the latest CyanogenMod 6.3.0 from Moize yet?
Tried reformatting, keep running into the Mount script error.
"Mount script cannot be created.
mount: mounting/dev/block/vold/179:2 on /data/sdext2 failed: No such device"
For quick reference, it was working on Khalpower's EpicSteelBlue rom. I can't seem to get SU to run in adb shell either...
Any workarounds would be appreciated!
(I don't have enough posts to post in the main development thread yet.)

Can you run these commands (either in adb shell or terminal):
Code:
su
fdisk -l /dev/block/mmcblk0 > /sdcard/fdisk.txt
and then post the contents of /sdcard/fdisk.txt ?

I will try as soon as I get back home.
Restored my backup since I need to be heading out for now.

Back. Here are the contents of fdisk.txt.
Code:
Disk /dev/block/mmcblk0: 16.5 GB, 16574840832 bytes
255 heads, 63 sectors/track, 2015 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1689 13566861 b Win95 FAT32
/dev/block/mmcblk0p2 1690 1885 1574370 83 Linux
/dev/block/mmcblk0p3 1886 2015 1044225 82 Linux swap
The native app2ext works, but I can't enable link2sd for some reason.

Raydonn said:
Back. Here are the contents of fdisk.txt.
Code:
Disk /dev/block/mmcblk0: 16.5 GB, 16574840832 bytes
255 heads, 63 sectors/track, 2015 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1689 13566861 b Win95 FAT32
/dev/block/mmcblk0p2 1690 1885 1574370 83 Linux
/dev/block/mmcblk0p3 1886 2015 1044225 82 Linux swap
The native app2ext works, but I can't enable link2sd for some reason.
Click to expand...
Click to collapse
Can you try making an empty /sd-ext/link2sd directory and reboot? Or have you done that already?

Mioze7Ae said:
Can you try making an empty /sd-ext/link2sd directory and reboot? Or have you done that already?
Click to expand...
Click to collapse
I've tried that.
Link2sd won't recognize it for some reason on this rom.

I found some bugs in the link2sd init.d script. A hotfix can be found here:
http://forum.xda-developers.com/showpost.php?p=16757523&postcount=408

Thanks, link2sd is working now.
But there seems to be another problem I'm running into. I can't seem to get the system to mount anything but ext2.
So ext2? Link2sd and root explorer sees the sd-ext fine and reports the size, etc.
ext3 and ext 4? Unable to mount.
Perhaps there's something I'm overlooking, but I've reformatted the SD card several times now to no avail.

Try to manualy mount like:
mount /dev/block/mmcblk0p2 /sd-ext -t ext4(3) and reboot.

fjfalcon said:
Try to manualy mount like:
mount /dev/block/mmcblk0p2 /sd-ext -t ext4(3) and reboot.
Click to expand...
Click to collapse
Hmm, tried that.
Getting the error message
"mounting /dev/block/mmcblk0p2 on /sd-ext failed: No such device" for ext3.
"mounting /dev/block/mmcblk0p2 on /sd-ext failed: Invalid argument" for ext4.

ls /system/lib | grep ext
show input...

fjfalcon said:
ls /system/lib | grep ext
show input...
Click to expand...
Click to collapse
Code:
libext2_blkid.so
libext2_com_err.so
libext2_e2p.so
libext2_profile.so
libext2_uuid.so
libext2fs.so

Are you sure that u usyng cm 6.3.0?
Cause it has already build-in modules for ext4.
http://www.multiupload.com/VHPFIMOJTR
apply that update again, you don't need to make any wipes.(or just wipe cache...)

Hmm, tried updating/installing again.
Still no luck. Same results.
Does it matter that I skipped 6.1.2 and went straight to 6.3.0? Although that doesn't make much sense since you said 6.3.0 included the modules for ext4.
I also see ext2.ko, ext3.ko, ext4.ko in system/lib/modules so I assume it's all there.

Small update.
I don't know why, but link2sd is working now and apparently with ext4.
Maybe it's because I installed cm6.1.2 and then applied cm6.3.0 overtop it? I didn't factory wipe though, but it still works.
Or maybe it's because I used the new OR to update my ext2 to ext4 instead of fresh formatting it to ext4?
Or maybe the latest version of link2sd fixed ext4 support? I don't know.
But anyhow, thanks for all the help and the great ROM.

Raydonn said:
Or maybe it's because I used the new OR to update my ext2 to ext4 instead of fresh formatting it to ext4?
Click to expand...
Click to collapse
Probably this one. The ext4 update in the OR uses known-working ext4 options. I think there are some features that desktops turn on by default when formatting ext4 that don't work with our kernel. My guess is it's largefile support, but I haven't tested tested that hunch.

[Q] Insufficient Storage Available

ASUS Transformer -- Latest version of Revolver, using v22a of supercurios kernal, and the ice cream sandwich theme, v2.
I've searched and searched, bu haven't found a case similar to mine.
When trying to download and install or update apps, I always get a notification saying that there was "insufficient storage available".
I have over 3 gigs free on the Internal memory, and nearly 6 on my microsd card.
I've read about people wiping or deleting items in the dalvik cache, and I've read about clearing market data.
My problem is, some say that wiping the dalvik cache on custom roms can break them, requiring a new flash.
I also have another problem. Nearly 100% of the time, downloads fail in the stock browser. I'm not sure if they fail in other browsers, but frankly I don't care-- I haven't come across a single browser in the market that I actually like. Most aren't even worth the megabytes they eat up.
And I also can't get over the fact that one of androids nucest features of all times, the move apps to SD card function, is unavailable to me. This makes my 80 dollar high-speed microsd card that I bought specifically for fast application use useless.
What can I do about either issue? The app update and install and the storage issue is a priority for me.

I would be interested in what the output of 'df -hPa' is on your system (in the terminal).
Sent from my Transformer TF101 using Tapatalk

yup, i get that as well at times, it really is annoying however, a reboot normally always fixes it and a wiping of any and all caches (from recovery) will keep that problem from coming back for a long time. I always make backups (once a week) so that if I wipe the cache wrong or something, I can restore from the recovery backup I made. I havent had to reflash a rom yet (crosses fingers)

Spidey01 said:
I would be interested in what the output of 'df -hPa' is on your system (in the terminal).
Sent from my Transformer TF101 using Tapatalk
Click to expand...
Click to collapse
Spidey.. got this today driving me mad..
here is my output in terminal..
'df -hPa' = Filesystem 1k-blocks Used Available Use% Mounted on df: hPa: can't find mount point.
ok.. whats this telling me?
I have wiped cache's
un-installed a couple of big programs/games..
TB is reporting that I have the following..
System rom: 528MB(127MB Free)
Internal 13.3GB(8.51GB Free)
SD card 13.3GB(8.51GB Free)
settings/storage is showing..
12.43GB with 7.93GB free..
I undocked it, rebooted it..
pulled out the SDcard and tried to install..
but no joy..
looks like maybe a reinstall of the Rom, then slowly load things back in..
edits: looks like a mounting problem.. as the dock is not mounting usb1 for the external now..
will flash Blades kernel and see if it sets things right..
as the only difference in my set-up has been to flash Roachs kernel during the week..
a Kernel flash didn't fix it so am doing a full reset...
K..after a full Factory/data reset..
TB give me this now.. (Market loaded a few in.. but I stopped it.. )
System rom: 528MB(108MB Free)
Internal 13.3GB(9.08GB Free)
SD card 13.3GB(9.08GB Free)
settings/storage is showing..
12.43GB with 8.46GB free..
Will load TB backup back in and see if the problem starts again..
But If I have had this problem.. I am sure others will come across it..
as it seems I got a corrupted file somewhere in there,
will keep an eye on it and see if it happens again..
but for sure, there was a corrupt system file..
Anyone know which are the actual system files are called for the mounting operation?

**** happened again today..
after a clean install.. ran well yesterday..
this morning plugged in the USB Drive into the right USB and had a USB mouse in the left USB..
wonder if this is doing something to mount files?
Anyone know which are the actual system files are called for the mounting operation?
I might run with just the sdcard for the rest of the week shifting things on to it..
and see if I am getting a spike, hooking up with the usbdrive that is corrupting mounting files..
as this would seem like the problem.. its a western digital 500g portable that I am plugin and unpluggin

I modded the flash.cfg file in nvflash and increased my system partition from 512mb to 768mb. It works great. If anyone is interested in increasing their system partition size, I can post what I did to do it. You would need to backup your stuff as it wipes everything when you flash the new partitions.

romified said:
I modded the flash.cfg file in nvflash and increased my system partition from 512mb to 768mb. It works great. If anyone is interested in increasing their system partition size, I can post what I did to do it. You would need to backup your stuff as it wipes everything when you flash the new partitions.
Click to expand...
Click to collapse
I wouldn't mind knowing how.. incase I need to do it..
mine has settled this week as not been plugging/unplugging in the USB hard-drive..
so I have narrowed it down to this spike corrupting some files..
I have backed up the system/lib files incase I have to dump them back over top of corrupted ones.. as it will save a new Rom Flash..
as still not had time to narrow down the actual file or files needed for Mounting USB's in the Rom
If you could post here or PM.. would be grateful..

Basically you just use nvflash to flash a ROM, I flashed Prime since there was a nvflash version available.
All you have to do is edit the flash.cfg file in nvflash, and make the following change, and your system partition will go from 512mb to 768mb. I was trying to port a large ROM and kept running out of space, I made this change and never had a space issue since.
REMEMBER: nvflash will wipe all of your files and data, recovery and kernel as well. So make sure whatever you flash with nvflash is what you want in place. You can of course always reflash through regular CWM to any rom as well after using nvflash. You just need to flash something with nvflash to make the partition changes. And remember if you use nvflash in the future, if you do not edit the flash.cfg file per below, nvflash will partiton system back to 512mb when you use it.
It is only one line, so this is VERY easy. I have only tested this on a TF101-A1. I am not sure what the 32 GB (B1) models partition layout is like.
Open the flash.cfg file, and look for this (it started on line 93 of the flash.cfg I have):
Code:
[partition]
name=APP
id=9
type=data
allocation_policy=sequential
filesystem_type=basic
size=536870912
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=system.img
Change the "size=536870912" to "size=805306368" and save the file. The above section should now look like this :
Code:
[partition]
name=APP
id=9
type=data
allocation_policy=sequential
filesystem_type=basic
size=805306368
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=system.img
Now use nvflash as normal and your system partition will be 768mb.
I am not sure what the limit is on size or what else can be changed, so if you test, do so at your own risk, I have only changed system to 768mb. I think partition 16 is elastic and sizes based on space left over from other partitions (so this is where the extra space for system comes from), but I am not 100% sure on this yet. But do let us know if you do experiment as to what you learn
By the way, the "805306368" number is a number calculated based on bytes & cylinders (or something along those lines) :
1024 x 1024 (1048576) x size in mb = size used in above example
ie: 1048576 x 768 = 805306368

dgcruzing said:
'df -hPa' = Filesystem 1k-blocks Used Available Use% Mounted on df: hPa: can't find mount point.
Click to expand...
Click to collapse
Maybe a typo or damaged mount point? /system, /data, and /cache are what matters.
Code:
Thank you for using Better Terminal Emulator Pro
/ $ df --help
BusyBox v1.16.2androidbtep (2011-08-11 14:16:08 PDT) multi-call binary.
Usage: df [-Pkmhai] [-B SIZE] [FILESYSTEM]...
Print filesystem usage statistics
Options:
-P POSIX output format
-k 1024-byte blocks (default)
-m 1M-byte blocks
-h Human readable (e.g. 1K 243M 2G)
-a Show all filesystems
-i Inodes
-B SIZE Blocksize
/ $ df -Pha
Filesystem Size Used Available Capacity Mounted on
tmpfs 364.2M 32.0K 364.2M 0% /dev
devpts 0 0 0 0% /dev/pts
proc 0 0 0 0% /proc
sysfs 0 0 0 0% /sys
debugfs 0 0 0 0% /sys/kernel/debug
none 0 0 0 0% /acct
tmpfs 364.2M 0 364.2M 0% /mnt/asec
tmpfs 364.2M 0 364.2M 0% /mnt/obb
none 0 0 0 0% /dev/cpuctl
/dev/block/mmcblk0p1 503.9M 403.5M 100.5M 80% /system
/dev/block/mmcblk0p7 27.3G 4.1G 23.3G 15% /data
/dev/block/mmcblk0p2 512.8M 16.0M 496.8M 3% /cache
tmpfs 364.2M 0 364.2M 0% /Removable
/dev/fuse 27.3G 4.1G 23.3G 15% /mnt/sdcard
tmpfs 364.2M 32.0K 364.2M 0% /data/local/mnt/Linux/dev
devpts 0 0 0 0% /data/local/mnt/Linux/dev/pts
proc 0 0 0 0% /data/local/mnt/Linux/proc
sysfs 0 0 0 0% /data/local/mnt/Linux/sys
debugfs 0 0 0 0% /data/local/mnt/Linux/sys/kernel/debug
none 0 0 0 0% /data/local/mnt/Linux/acct
tmpfs 364.2M 0 364.2M 0% /data/local/mnt/Linux/mnt/asec
tmpfs 364.2M 0 364.2M 0% /data/local/mnt/Linux/mnt/obb
none 0 0 0 0% /data/local/mnt/Linux/dev/cpuctl
/dev/block/mmcblk0p1 503.9M 403.5M 100.5M 80% /data/local/mnt/Linux/system
/dev/block/mmcblk0p7 27.3G 4.1G 23.3G 15% /data/local/mnt/Linux/data
/dev/block/mmcblk0p2 512.8M 16.0M 496.8M 3% /data/local/mnt/Linux/cache
tmpfs 364.2M 0 364.2M 0% /data/local/mnt/Linux/Removable
/dev/fuse 27.3G 4.1G 23.3G 15% /data/local/mnt/Linux/mnt/sdcard
/ $
The other stuff you posted makes sense to me, as long as you have a 16GB TF and not a 32GB like mine.
The /data/local/mnt/Linux stuff is because of my Debian chroot, and the sdcard is really a cool hack they do for mounting /data/media correctly for Android. The mmcblk devices are the partitions on the internal memory, as far as I know at least.
Applications go in /data. Your /system partition can be touched by some things but you are not generally going to be stuffing apps in there when you go to the market. You can make an app a system app with some program I think but I wouldn't reccomend it for most apps without good reason.
As root, you can see for yourself with ls what is in the file system and see how Android does stuff, it's mostly self explanitory with some poking but not as obvious as people like me (or smarter people on the subject) might think.
Idk how the file system performance would be impacted here with regards to free space, I know FreeBSD with classic UFS2 / UFS2+SU on PCs will suffer heavy performance issues if the file system is tooooo full but now I'm talking Apples and Oranges. But I would be curious how increasing the /system partition would work for performance with the TF's specifics.
Sent from my Transformer TF101 using Tapatalk

Re: Transformer 16g system partition hack
Well after having it happen again to me today, I decided to bite the bullet and spend the night doing Romified's hack..(Thanks)
I nvflashed Prime 1.7 with the adjusted flash.cfg
As a note: using Notepad++ mine was on line 99
Will load it backup and see how we go..
Fingers crossed this will settle it down..
As said before.. once the problem starts.. even wiping programs off doesn't seem to store updates or allow installs of new programs, so it seems that only a good nflash is the way to go..
Will update as the week goes on..
Getting back to the hack..
it is interesting to get in to the Linux partition reading..
As the layout here seems to give us a bit of scope to play with..
I played safe and didn't push it this time..
but.. that's not to say that there couldn't be some decent discussion on
the actual need for so many partitions and their sizes..
This was the Terminal dump before the hack and with a flash of Prime 2.1/Blades latest Kernel.(As tried everything else before going ahead with the Nvflash hack)
Code:
/ # df -Pha
df -Pha
Filesystem Size Used Available Capacity Mounted on
tmpfs 364.2M 32.0K 364.2M 0% /dev
devpts 0 0 0 0% /dev/pts
proc 0 0 0 0% /proc
sysfs 0 0 0 0% /sys
debugfs 0 0 0 0% /sys/kernel/debug
none 0 0 0 0% /acct
tmpfs 364.2M 0 364.2M 0% /mnt/asec
tmpfs 364.2M 0 364.2M 0% /mnt/obb
none 0 0 0 0% /dev/cpuctl
/dev/block/mmcblk0p1 503.9M 403.5M 100.5M 80% /system
/dev/block/mmcblk0p7 12.4G 3.2G 9.2G 26% /data
/dev/block/mmcblk0p2 521.2M 9.1M 512.1M 2% /cache
tmpfs 364.2M 0 364.2M 0% /Removable
/dev/fuse 12.4G 3.2G 9.2G 26% /mnt/sdcard
/dev/block/vold/179:9
14.7G 3.9G 10.8G 27% /Removable/MicroSD
Will post back the new dump once got things loaded and settled..

romified said:
I modded the flash.cfg file in nvflash and increased my system partition from 512mb to 768mb. It works great. If anyone is interested in increasing their system partition size, I can post what I did to do it. You would need to backup your stuff as it wipes everything when you flash the new partitions.
Click to expand...
Click to collapse
This is pointless, /System is a ReadOnly filesystem.

well its back to the drawing board for me as it came back tonight..
after loading a small-iss program of 2meg from the market..
honest this is giving me the ****s..
as internal is showing 2.2g
system is 408mb of 504mb
this is the output on terminal with "df"
Code:
/ $ export PATH=/data/local/bin:$PATH
/ $ df -Pha
Filesystem Size Used Free Blksize
-Pha: No such file or directory
/ $ df
Filesystem Size Used Free Blksize
/dev 364M 32K 364M 4096
/mnt/asec 364M 0K 364M 4096
/mnt/obb 364M 0K 364M 4096
[COLOR="Red"]/system 503M 407M 96M 4096[/COLOR]
/data 12G 2G 9G 2048
/cache 521M 8M 512M 4096
/Removable 364M 0K 364M 4096
/mnt/sdcard 12G 2G 9G 2048
/R......./MicroSD 14G 4G 10G 8192
/ $
What is painful is I am clearing cache, going in and wiping programs
not only from market and also internally.. like in private data.. also apps out of system/apps
also wiped Market cache & Data..
but it doesnt seem to free up enough memory to allow even a 160k widget to download then download
an install from market..
Edit: Just did a test.. maybe its nothing to do with the actual Rom build..or Partitions but Market itself..
as I uninstalled a program downloaded from Market using another apps manager..
had a backup of it..
then re: installed it..via Root explorer.. installed no problems.. and is a 12meg program..
K.. will do a few more tests.. maybe its an unstall of market.. or a roll back..

dgcruzing said:
well its back to the drawing board for me as it came back tonight..
after loading a small-iss program of 2meg from the market..
honest this is giving me the ****s..
as internal is showing 2.2g
system is 408mb of 504mb
this is the output on terminal with "df"
/ $ export PATH=/data/local/bin:$PATH
/ $ df -Pha
Filesystem Size Used Free Blksize
-Pha: No such file or directory
/ $ df
Filesystem Size Used Free Blksize
/dev 364M 32K 364M 4096
/mnt/asec 364M 0K 364M 4096
/mnt/obb 364M 0K 364M 4096
/system 503M 407M 96M 4096
/data 12G 2G 9G 2048
/cache 521M 8M 512M 4096
/Removable 364M 0K 364M 4096
/mnt/sdcard 12G 2G 9G 2048
/R......./MicroSD 14G 4G 10G 8192
/ $
What is painful is I am clearing cache, going in and wiping programs
not only from market and also internally.. like in private data.. also apps out of system/apps
also wiped Market cache & Data..
but it doesnt seem to free up enough memory to allow even a 160k widget to download then download
an install from market..
Edit: Just did a test.. maybe its nothing to do with the actual Rom build..or Partitions but Market itself..
as I uninstalled a program downloaded from Market using another apps manager..
had a backup of it..
then re: installed it..via Root explorer.. installed no problems.. and is a 12meg program..
K.. will do a few more tests.. maybe its an unstall of market.. or a roll back..
Click to expand...
Click to collapse
try clearing the dalvik cache that may help you

Hi Stevie,
Yes..one of the first things I did..
But to no avail..
I see by your threads that you have a fair knowledge of how the partitions work and file structures work..
Would you know what are all the files associated with market and where all the directries are associated with it..?
I have found market.apk
Market update.apk
But where is market dropping the files you buy?
And market database filed?
At the moment, I am still leaning towards market doing something screwy to me..
As the test with
1:uninstall with root explorer
2:then a reinstall with TB
Proves that I can write to the partition.
But a..
1: uninstall 2 programs- with market
(Which in theory should free space)
2: reinstall 1 program- with market
Gives me the error again..
sent from yet another MikG HTC Evo

Just wondering how much room there is on the TF for apps? Just got one over the weekend...plus I use an N1 that has >200 MB...so from what I've read in this thread so far...seems that you can load up a butt load of apps on this tablet.

dgcruzing said:
Hi Stevie,
Yes..one of the first things I did..
But to no avail..
I see by your threads that you have a fair knowledge of how the partitions work and file structures work..
Would you know what are all the files associated with market and where all the directries are associated with it..?
I have got found market.apk
Market update.apk
But where is market dropping the files you buy?
And market database filed?
At the moment, I am still leaning towards market doing something screwy to me..
As the test with
1:uninstall with root explorer
2:then a reinstall with TB
Proves that I can write to the partition.
But a..
1: uninstall 2 programs- with market
(Which in theory should free space)
2: reinstall 1 program- with market
Gives me the error again..
sent from yet another MikG HTC Evo
Click to expand...
Click to collapse
It should download it to /cache then install it to /data nothing else
---------- Post added at 12:59 PM ---------- Previous post was at 12:58 PM ----------
SiNJiN76 said:
Just wondering how much room there is on the TF for apps? Just got one over the weekend...plus I use an N1 that has >200 MB...so from what I've read in this thread so far...seems that you can load up a butt load of apps on this tablet.
Click to expand...
Click to collapse
because /data and the emmc share the same partition, it is as much as you can store on your tablet, so 14ish GB on a 16GB device and 28ish GB on a 32GB device, unless of course you are running ubuntu in dual boot which shrinks the size of /data

lilstevie said:
It should download it to /cache then install it to /data nothing else
---------- Post added at 12:59 PM ---------- Previous post was at 12:58 PM ----------
because /data and the emmc share the same partition, it is as much as you can store on your tablet, so 14ish GB on a 16GB device and 28ish GB on a 32GB device, unless of course you are running ubuntu in dual boot which shrinks the size of /data
Click to expand...
Click to collapse
Yes, this is what I was figuring too.. that's why its frustrating me to be getting this error and leading me to believe that its a market problem..
I have already ruled out a space problem..
as time permits, I am going to wipe market off and try to install another version and see what happens..
This is why I am in the need of ALL files that point to and are called by market to wipe off it.. so that there are no rouge orphan files around..
Then of course going to have to hunt down a another copy to load in..
which I should be able to pull from one of the Roms..
as I dont want to use the one in Roach's Rom.. as this is the one that is maybe causing problems..(Via some unexplained help from Market update)
Note of course.. that I am not saying that it is anything to do with Roach's Rom and or files in it.. as I am still in the investigation stage of why I am getting the error..

dgcruzing said:
Yes, this is what I was figuring too.. that's why its frustrating me to be getting this error and leading me to believe that its a market problem..
I have already ruled out a space problem..
as time permits, I am going to wipe market off and try to install another version and see what happens..
This is why I am in the need of ALL files that point to and are called by market to wipe off it.. so that there are no rouge orphan files around..
Then of course going to have to hunt down a another copy to load in..
which I should be able to pull from one of the Roms..
as I dont want to use the one in Roach's Rom.. as this is the one that is maybe causing problems..(Via some unexplained help from Market update)
Note of course.. that I am not saying that it is anything to do with Roach's Rom and or files in it.. as I am still in the investigation stage of why I am getting the error..
Click to expand...
Click to collapse
is this on one rom? or has it happened to you on a few, and what rom are you running

lilstevie said:
is this on one rom? or has it happened to you on a few, and what rom are you running
Click to expand...
Click to collapse
Been on Roach's with C& B Kernel.. first time it happened swopped out to Blades Kernel..
Maybe its a Rom swop for a while to see if it settles..
might save the time spent on hunting down the problem..
Got a trip for a few weeks so don't want to be stressed with this on the road..
so got to get it settled in the next few days..
edit: going to run out of time.. as said on the road from Sunday..so decided to go a new Rom flash..
This is how it is looking like at the moment..
Code:
export PATH=/data/local/bin:$PATH:.
/ # export PATH=/data/local/bin:$PATH:.
/ # df
Filesystem Size Used Free Blksize
/dev 364M 32K 364M 4096
/mnt/asec 364M 0K 364M 4096
/mnt/obb 364M 0K 364M 4096
[COLOR="Red"]/system 755M 296M 459M 4096[/COLOR]
/data 12G 1G 10G 4096
/cache 521M 8M 512M 4096
/Removable 364M 0K 364M 4096
/mnt/sdcard 12G 1G 10G 4096
/Removable/MicroSD 14G 4G 9G 8192
/ #
interesting comparing it to the last one posted last night..
I have now got the full 755m in system as per nvflash..
as last one is only showing 503m with most of the same apps loaded back in..
I have done :
Mike1986 super wipe..
Then loaded in KRAKD rom..
Blue theme
Blades CptAwesome 12-07
let see how it goes..