I think we may have been talking about different things.
Yes, I agree. I understand the issue brought up by Basil. I just wanted to add that the reason we observed this issue was because installing heavy benchmarks like glbenchmark (~400 MB) made the system show ‘low storage space’ notifications and made the benchmark crash, which made us look into the partition sizes.
However, the extra disk space get's allocated to the last 'sdcard' partition and doesn't change the sizes of the other partitions. Those are hardcoded in l-a-m-c I believe
Ah right, I see.
I believe that to be correct too. And further to that, I believe the sdcard partition isn't mounted, so no matter what size it is, the user would have to mount it manually to be able to use it.
And how would one go about doing that? Is it simply a mount /dev/* from the terminal? What’s the best way to find out the device name for the sdcard in this case?
Thanks,
Varun
From: Ryan Harkin [mailto:ryan.harkin@linaro.org] Sent: 11 August 2014 09:04 To: Jon Medhurst (Tixy) Cc: Varun Sarwal; Basil Eljuse; Linaro Validation; Manik Bajpai; Dean Arnold Subject: Re: Observed diff between how dd'ing juno.img and using linaro-android-media-create...
On 8 August 2014 16:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Fri, 2014-08-08 at 16:08 +0100, Varun Sarwal wrote:
Hi all,
But basically, if you want bigger partitions, I would just say use linaro-android-media-create (l-a-m-c), and if you specifically want a raw disk image to test, use l-a-m-c to create one (using the --image-file --image-size options instead of '--mmc /dev/sdX').
So I used this command to create bigger partitions:
linaro-android-media-create --image-file /dev/sdb --image-size 6G --dev vexpress --boot boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2 (see attached image)
However, the USB flash drive continues to have partitions as observed before (attached image) , and Android can see only 488 MB of internal memory.
I think we may have been talking about different things.
I guess by 'internal memory' means free space on the 'userdata' partition.
Basil was saying that the prebuilt image gave him 14GB unallocated space, and using l-a-m-c with the three tarballs used all the disk which is what he wanted, and asked for the prebuilt images to be the same.
However, the extra disk space get's allocated to the last 'sdcard' partition and doesn't change the sizes of the other partitions. Those are hardcoded in l-a-m-c I believe.
I believe that to be correct too. And further to that, I believe the sdcard partition isn't mounted, so no matter what size it is, the user would have to mount it manually to be able to use it.
-- Tixy