If you have access to a remote Linux / Mac system, you could use an SSH pipe to dump the contents of the MMC. I don’t have a board handy to verify this, but it should work.
(From the BBB)
$ sync ; dd if=/dev/mmcblk0 bs=1M | ssh user@local_ip ‘dd of=/path/to/image/myBBB.img bs=1M’
(Should ask for you for SSH password here, just enter it and press enter)
Be warned! This is kind of a hack. Try not to use the board while you’re dumping the image as it’ll increase the risk of corrupted log files. Ideally, you should really be running those commands after booting from the SDCard so you know processes aren’t trying to access the MMC while you’re trying to dump it.
I think it would be good to ship BBB with an SD card backup of the eMMC
out of the box. Preferably on an 'industrial' type SD card (these so far seem
to work way better than the consumer electronics ones).
bad idea. the beauty of the sale of the BBB is that there is *one*
product, and for your money, you get that one product. it's a single
box, and everybody gets the same thing. the instant you start adding
options, someone has to read the order carefully, add extra doodads,
possibly requiring a larger box and so on, maybe increasing the
value, which could affect customs or duty ... etc etc etc.
regardless of how complete you try to be, some people are going to
have problems for no apparent reason. i can't see a good defence for
complicating the purchase process for the occasional glitch. just
leave it the way it is, and allow people to get everything they need
via downloads.
The frustrating experience that led me to want this was:
opkg update; opkg upgrade
restart
OMG, my BBB is dead.
It wasn’t obvious to me (a new user) what version “shipped” with the BBB. It was relatively hard to get it back to a working state. Sucked the joy out of it for sure
These have eliminated all the awful problems caused by the cheap SD cards my
BBW came with. From all the flash problems people have had with BBB I bet
it would have been worth it for them too.
Those on Robert’s Debian image might want to try flashybrid. Basically a bunch of scripts that mount the filesystems ro and mount on top of them a ramfs with the corresponding commands to sync the ramfs overlay on the flash/sd. I use it to make my SD/eMMC last longer.
Anyway I haven’t find the datasheet of the eMMC used on the BBB to have a ballpark on it’s life
The beauty of the sysboot pins is that even if you break your eMMC you always can boot from uSD; please note that the factory shipped uBoot has some environment variables to always try uSD first in case it is plugged (importing uEnv.txt from it) but those variables can be changed; that would solve the problem people that want to use the uSD as storage and have to put the VFAT partition on it to boot.
Out of three different 4G SD cards (two then came with bones, one
cheap one that I bought), 2/3 died. One eventually became completely
unbootable, the other would frequently cause the terminal to freeze
for 10 or 20 seconds at a time after a command, and occasionally
caused errors in fread() etc. My app does quite a lot of small
writes, and uses the watchdog so there were a lot of inadvertent power
cycles involved in some stages of development.
Incidentally, my smartphone SD card also died after first becoming
gradually less and less reliable and eating/munging data. And the one
in my camera silently ate a bunch of photos.
Your average SD card is *really* unreliable. The APacer SD cards I
replaced them with have so far entirely obviated these problems
(through quite a lot more development work).
Of course I originally thought SD cards were reliable, since they are
so common and tended to blame the bone. I would try to avoid
blemishing your lovely creation with them if possible (eMMC is great,
but many people are still likely to try to use SD cards for one reason
or another and have bad experiences).
I would like put more expensive cards in the box, but that would raise the price of the product, significantly, and I am sure everyone will complain about that. Plus sooner or later they will buy more cards, all of them cheap, and end up at the same point anyway.
This was the reason for going to eMMC, which a lot of people do not seem to like because they prefer the uSD cards.
So, there is no winning solution for this other than to keep telling people SD card are not reliable as they are made out of Flash that nobody wants and they count on the controller identifying those bad blacks and not use them. But then the more bad clocks go bad and you get stuck.
So, if you need a more reliable solution, you need to buy the expensive solution form the SD card providers.
I’m trying to do the same thing, but end up with the data transfer stalling and eventually displaying an error message about a broken pipe. I can confirm that no additional data is being transferred by running “ls -l *.img” on my Mac and checking the size of the file in bytes. The size grows with repeated calls, but eventually stops. If I try executing anything in the BeagleBone terminal, the “dd” command returns with the broken pipe error.
I have made sure that my Mac is set up for Remote Login from System Preferences → Sharing → Remote Login, and confirmed that I can “ssh” into the Mac from the BeagleBone.
I am executing the following command from the BeagleBone:
Is it possible that the transfer was completed correctly? I end up with a final byte size of 1,919,287,296 for BBB_Angstrom_Backup.img, but I am not sure what size the file should actually be. I tried to compare md5sums of the BBB_Angstrom_Backup.img and /dev/mmcblk0 but they do not match – should they?
md5sum for the raw device won’t be the same as for the running system…the only way you’d have a shot at having the md5’s match is if you boot off of an SD card. Which actually is probably a better idea since a running system is going to modify the data you’re trying to backup.
You might want to make sure that your BBB & Mac are on a wired network, the broken pipe sounds like you’re maybe seeing network drops?
I’d also make sure that for each attempt that you’re trying a new filename (more precisely a file that doesn’t exist at the start of the dd).
As a last resort, you can start trying to look at whether packets are streaming across correctly with wireshark/tcpdump.
-Dale
ps. this process worked ok for me going to a Debian laptop.
Just wondering, has anyone tried to restore an image using the reverse of this process? I can’t seem to restore my “bricked” BBB. I would like to restore to my most recent backup so that I can get on with my thesis, but I’m struggling to get this working. I’ve tried the reversing the command, while booting the BBB from the microSD with an Ubuntu image, but /dev/mmcblk0p2 won’t unmount.
