Difference between revisions of "Thread:Talk:BeagleBone Black Extracting eMMC contents/Thanks, Issues, and Suggestions"

From eLinux.org
Jump to: navigation, search
(New thread: Thanks, Issues, and Suggestions)
 
m
Line 1: Line 1:
 
First off, thank you; this is a perfect way to handle reading/writing images.
 
First off, thank you; this is a perfect way to handle reading/writing images.
  
However, it seems that the current boot image does not support writing files to FAT32 greater than 2GB, which makes it where a full image cannot be captured.  I tried multiple SD cards formatted various ways, all of which only returned an image file of 2GB.  By capturing the dd output to a log file I got:
+
However, it seems that the current boot image does not support writing files to FAT32 greater than 2GB, which makes it where a full image cannot be captured.  I tried multiple SD cards formatted various ways, all of which only returned an image file of 2GB.  By capturing the dd output to a log file I noticed:
  
dd: writing '/mnt/BeagleBoneBlack-eMMC-image-9466.img': File too large
+
dd: writing '/mnt/BeagleBoneBlack-eMMC-image-9466.img': File too large
206+0 records in
+
206+0 records in
204+1 records out
+
204+1 records out
  
 
At first I thought it was an issue with how the SD card was formatted, however by just booting the BBB to Debian and running a dd I was able to copy 4GB to the same SD card:
 
At first I thought it was an issue with how the SD card was formatted, however by just booting the BBB to Debian and running a dd I was able to copy 4GB to the same SD card:
  
dd if=/dev/zero of=/mnt/zero.img bs=10M
+
dd if=/dev/zero of=/mnt/zero.img bs=10M
410+0 records in
+
410+0 records in
409+0 records out
+
409+0 records out
4294967295 bytes (4.3 GB) copied, 421.259 s, 10.2 MB/s
+
4294967295 bytes (4.3 GB) copied, 421.259 s, 10.2 MB/s
  
 
So it would seem there is a big flaw in the current build.  Perhaps it is related to this issue: https://groups.google.com/forum/#!topic/android-porting/alF-avcQNfI, which mentions some older linux kernels had the same issue?
 
So it would seem there is a big flaw in the current build.  Perhaps it is related to this issue: https://groups.google.com/forum/#!topic/android-porting/alF-avcQNfI, which mentions some older linux kernels had the same issue?

Revision as of 12:54, 31 December 2014

First off, thank you; this is a perfect way to handle reading/writing images.

However, it seems that the current boot image does not support writing files to FAT32 greater than 2GB, which makes it where a full image cannot be captured. I tried multiple SD cards formatted various ways, all of which only returned an image file of 2GB. By capturing the dd output to a log file I noticed:

dd: writing '/mnt/BeagleBoneBlack-eMMC-image-9466.img': File too large
206+0 records in
204+1 records out

At first I thought it was an issue with how the SD card was formatted, however by just booting the BBB to Debian and running a dd I was able to copy 4GB to the same SD card:

dd if=/dev/zero of=/mnt/zero.img bs=10M
410+0 records in
409+0 records out
4294967295 bytes (4.3 GB) copied, 421.259 s, 10.2 MB/s

So it would seem there is a big flaw in the current build. Perhaps it is related to this issue: https://groups.google.com/forum/#!topic/android-porting/alF-avcQNfI, which mentions some older linux kernels had the same issue?


I also suggest:

* Changing the dd line in the save autorun.sh to "dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-`date +%s`.img bs=10M &> /mnt/autorun.log"
* Providing a warning that you should check that your img file is 4GB.
* Note that the SD partition has to be "active" (as SaintGimp already mentioned, I just had the same issue initiall).
* Note that (on at least some revisions) the beaglebone must be powered by the barrel jack for it to work (I'm on a rev c board).
* Note that you must let go of the S2 button after a couple seconds.