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
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.
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.
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)