2gb image for 4gb BBB?

I’m looking at updates for the BBB, and the eMMC flasher versions all say 2gb. Why is this when it’s supposed to be a 4gb eMMC?

I also tried downloading https://rcn-ee.net/rootfs/bb.org/testing/2014-12-19/lxde-4gb/BBB-eMMC-flasher-debian-7.7-lxde-4gb-armhf-2014-12-19-4gb.img.xz
from here http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBB_Rev_C_.284GB_eMMC.29_2 and after writing the extracted image to SD and booting to it, the 4 lights on the BBB just flashed in sequence back and forth…

Am I missing something here? Can’t put a 4gb image on a 4gb BBB??

So the way my file naming works:

BBB-eMMC-flasher-debian-7.7-lxde-4gb-armhf-2014-12-19-4gb.img.xz

lxde-4gb: lxde deskop for the 4gb eMMC BBB's..

4gb.img: needs a minimal of a 4GB microSD to transfer the data to the bbb..

Regards,

Not to Mention that the RevC is probably in the minority of the total boards sold to the public. RevA / RevB both had 2GB eMMCs on board . .

I’m using a 128gb card so I meet the minimum size, but this image won’t go onto the BBB for some reason. Since it’s your image, can you tell me how to get it onto the BBB?

Thanks

Really? A "128gb" card...

You do realilze it's only been advertised as "mircroSD SDHC" thus 32gb
is the limit. Although in this forum, we've discovered that 64GB
"microSD SDXC" devices from SanDisk do work.. Just not using any of
the faster "SDCX" transfer modes..

So.. Which brand/model "128gb" do you have?

I would say use any other microSD that you have (SDHC) and retry..

Regards,

Yea is was the only spare I had laying around… It’s installed the 5-14 image several times so it should be fine… I have a couple 8 gig’rs on the way so maybe I’ll try again when they get here…

Wonders how long before someone gets / tries a 256GB card

Ok, so as a note to all those out there . . . to resize one of the 2G images to any sdcard size, The below “guide” will work. However, this is only tested on a single partition image, and if using a 2 partition image, you need to use the appropriate partition. USE AT YOUR OWN RISK One single typo can render your file system and / or the boot loader inoperable . . .

These steps were taken on an i386 Debian install ( PC ) with the sdcard listed at /dev/sdc:

william@eee-pc:~$ sudo fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 3963 MB, 3963617280 bytes
184 heads, 31 sectors/track, 1357 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 * 2048 3481599 1739776 83 Linux

Command (m for help): d
Selected partition 1
Command (m for help): p

Disk /dev/sdc: 3963 MB, 3963617280 bytes
184 heads, 31 sectors/track, 1357 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended

Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7741439, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-7741439, default 7741439):
Using default value 7741439

Command (m for help): p

Disk /dev/sdc: 3963 MB, 3963617280 bytes
36 heads, 27 sectors/track, 7964 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 2048 7741439 3869696 83 Linux

Command (m for help): a
Partition number (1-4): 1

Command (m for help): p

Disk /dev/sdc: 3963 MB, 3963617280 bytes
36 heads, 27 sectors/track, 7964 cylinders, total 7741440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 * 2048 7741439 3869696 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
william@eee-pc:~$

william@eee-pc:~$ sudo e2fsck -f /dev/sdc1
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 14430/108864 files (0.1% non-contiguous), 74875/434944 blocks

william@eee-pc:~$ sudo resize2fs /dev/sdc1
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/sdc1 to 967424 (4k) blocks.
The filesystem on /dev/sdc1 is now 967424 blocks long.

Then on the Beagelbone Black once booted . . .

root@beaglebone:~# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 3.7G 235M 3.2G 7% /

root@beaglebone:~# uname -a
Linux beaglebone 3.14.26-ti-r39 #1 SMP PREEMPT Mon Dec 8 04:56:09 UTC 2014 armv7 l GNU/Linux

root@beaglebone:~# cat /ID.txt
BeagleBoard.org BeagleBone Debian Image 2014-11-19

For those who may be wondering. This image was pulled off the recommended links for “official” testing images. The initial partition size is 2G ( minimal command line image ). This is an “all-in-one” partition where the boot loader files are in a “1M hole” at the beginning of the sdcard. Initial kernel was 3.8.13-bone67 then upgraded to the latest 3.14.x TI kernel using APT.

root@beaglebone:~# ls /boot/
SOC.sh config-3.8.13-bone67 uEnv.txt
System.map-3.14.26-ti-r39 dtbs uboot
System.map-3.8.13-bone67 initrd.img-3.14.26-ti-r39 vmlinuz-3.14.26-ti-r39
config-3.14.26-ti-r39 initrd.img-3.8.13-bone67 vmlinuz-3.8.13-bone67

I actually made a mistake, by forgetting to check / update the partition to active ( * boot ) by using “a” while in fdisk. I then inserted the sdcard into the Beaglebone black. Only to be greeted by 3 solidly lit USR LEDs. After which, I put the sdcard back into my PC, started fdisk again, and marked the partition appropriately. Of course then the board booted up fine.

Or you could just boot the uSD card with the 2G uSD image and run:

  sudo /opt/scripts/tools/grow_partition.sh

...then worst-case you only mess up your BeagleBone and not your x86 PC.

Or you could just boot the uSD card with the 2G uSD image and run:

sudo /opt/scripts/tools/grow_

partition.sh

…then worst-case you only mess up your BeagleBone and not your x86 PC.

The steps can also be done LIVE on the Beagelbone black, but can only resize the partition larger. . . .

Anyway, I think it is commendable that people like Robert, take their time to build these images for us, and write scripts to make things such as resizing a partition bigger. You too Charles for the work you’ve done. Truly.

However, running script(s) to do these things for us, teaches us nothing. Personally, I see a huge distinction between something like say universal io, and a really simple set of instructions to do basic Linux stuff. We’re using Linux here people, you need to learn how to use it.

The above “guide” I pulled directly off the official ubuntu forums, and made a few tweaks( some information was left out ). So knowing it could be done, but not 100% how, I was able to google the answer, rewrite my own instructions ,and apply it in under 10 minutes . . .