No free space on SD card partition after writing 2016-06-05

[Wally Bkg]

bone-debian-8.5-lxqt-4gb-armhf-2016-06-05-4gb.img.xz leaves no free space on the partition it creates when written to an SD card. I've done it using both dd and Etcher, on two different brands of 8GB cards.

Its not a show-stopper since grow-partition.sh still works after the Beaglebone has booted, but after I make the card I've a few scripts I like to copy over to set up NAT apt-get install some things that aren't part of the standard image.

Its good to see that the Cloud9 fade.js analogWrite() example is working again. Haven't completed all my "newbie tests" yet, but so far the only issue is the Bonescript Interactive Guide web page only works for the first two "levels". The example using the on-board LEDs all seem to work, but the pages for the specific functions like analogWrite() and digitalRead() don't work because they don't render correctly. I've used the latest Chrome browser and Firefox

[Graham]

If you have access to a Linux desktop, you can take the card after you write it, then plug it in to the Linux desktop and use Gparted to expand the partition size to the limit of the card, before you ever insert it into the BBB.

That way, you have full card memory available on the initial boot.

--- Graham

==

[Wally Bkg]

I know that, that is why I said its not a show-stopper, and Windows users can still boot the card and run grow_partition.sh, but the previous testing lxqt images were apparently sized to match the 4GB eMMC.

If there is a reason for it, (new slightly smaller eMMC chip to save a few pennies on some board revisions?) that's fine, but if its an error that crept into the image making process, I thought RCN might want to know. I did verify that the 0 bytes free didn't interfere with the Beaglebone initial boot up.

I was pretty impressed by the Etcher application, at least on a current version of Linux, If it works as well on Windows it'll help a lot of people get started with newer images. Maybe its better now, but a few months ago my BBG shipped with a pretty useless image in the eMMC.

[Robert Nelson]

On Mon, Jun 20, 2016 at 6:05 PM, Wally Bkg <wb666...@gmail.com> wrote:
> I know that, that is why I said its not a show-stopper, and Windows users can still boot the card and run grow_partition.sh, but the previous testing lxqt images were apparently sized to match the 4GB eMMC.
>
> If there is a reason for it, (new slightly smaller eMMC chip to save a few pennies on some board revisions?) that's fine, but if its an error that crept into the image making process, I thought RCN might want to know. I did verify that the 0 bytes free didn't interfere with the Beaglebone initial boot up.

It's a little juggling game, the bb-node-red package got a little big
these last few weeks till i got the pre-build npm packages ironed out,
so those are smaller..

Otherwise, from trial and error we only partition 85% of eMMC stated size..

Here's the calculation logic with a few data-points..

#eMMC: (dd if=/dev/mmcblk1 of=/dev/null bs=1M #MB)
#Micron 3744MB (bbb): 3925868544 bytes -> 3925.86 Megabyte
#Kingston 3688MB (bbb): 3867148288 bytes -> 3867.15 Megabyte
#Kingston 3648MB (x15): 3825205248 bytes -> 3825.21 Megabyte (3648)
#
### seek=$((1024 * (700 + (gsize - 1) * 1000)))
## 1000 1GB = 700 #2GB = 1700 #4GB = 3700
## 990 1GB = 700 #2GB = 1690 #4GB = 3670
#
### seek=$((1024 * (gsize * 850)))
## x 850 (85%) #1GB = 850 #2GB = 1700 #4GB = 3400
#
dd if=/dev/zero of="${media}" bs=1024 count=0 seek=$((1024 * (gsize * 850)))

Regards,

--
Robert Nelson
https://rcn-ee.com/