Clone Ubuntu EMMC on BBB

[Brian Piccioni]

Hello and thank you in advance for the help.

I know that, in general, this topic has been addressed before. I looked through all the posts, followed whatever methods, etc., were suggested but I can't get it to work (it being cloning my eMMC on one BBB to another BBB).

I live in rural Canada and downloading costs me $10/gb so I am cautious about downloading stuff unless i have to, etc..

My 'source' system is Ubuntu 13.04 (GNU/Linux 3.8.13-bone21 armv7l). Initially my target was an 'out of the box' BBB.

I booted the 'source' system from an Anstrom 'bootable' microSD, mounted a USB drive, in the USB directory I executed

        dd if=/dev/mmcblk1 of=BeagleBoneBlack-eMMC-image-Jan52014.img bs=10M

The command completed with no errors and a reassuring amount of data copied (1.9gb)

Then I booted the 'destination' system from an Anstrom 'bootable' microSD, mounted my USB drive, and in the USB directory executed

        dd if=BeagleBoneBlack-eMMC-image-Jan52014.img of=/dev/mmcblk1 bs=10M

Again, the command completed with no errors and a reassuring amount of data copied (1.9gb)


Unfortunately, when I boot the destination machine, nothing much happens except a flashing LED. I can't SSH into the board and it doesn't even show up on my network.

Figuring there was something Ubuntu related I flashed the destination BBB with Ubuntu 12.4, which I had around. It worked fine, however, when I repeated the above procedure (including booting Angstrom off microSD) I got the same result.


I wonder if there is something wrong with my eMMC partion table on the source BBB (even though it works fine). When I execute fdisk -l I get the following (note the doesn't contain a valid partition table reports)

Disk /dev/mmcblk1: 1920 MB, 1920991232 bytes
255 heads, 63 sectors/track, 233 cylinders, total 3751936 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/mmcblk1p1   *          63      144584       72261    c  W95 FAT32 (LBA)
/dev/mmcblk1p2          144585     3743144     1799280   83  Linux

Disk /dev/mmcblk1boot1: 1 MB, 1048576 bytes
4 heads, 16 sectors/track, 32 cylinders, total 2048 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

Disk /dev/mmcblk1boot1 doesn't contain a valid partition table

Disk /dev/mmcblk1boot0: 1 MB, 1048576 bytes
4 heads, 16 sectors/track, 32 cylinders, total 2048 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

Disk /dev/mmcblk1boot0 doesn't contain a valid partition table


I would be very grateful if somebody could tell me what I am doing wrong.

Thank you

[Robert Nelson]

On Sun, Jan 5, 2014 at 4:33 PM, Brian Piccioni <nair...@gmail.com> wrote:
> Hello and thank you in advance for the help.
>
> I know that, in general, this topic has been addressed before. I looked
> through all the posts, followed whatever methods, etc., were suggested but I
> can't get it to work (it being cloning my eMMC on one BBB to another BBB).
>
> I live in rural Canada and downloading costs me $10/gb so I am cautious
> about downloading stuff unless i have to, etc..
>
> My 'source' system is Ubuntu 13.04 (GNU/Linux 3.8.13-bone21 armv7l).
> Initially my target was an 'out of the box' BBB.
>
> I booted the 'source' system from an Anstrom 'bootable' microSD, mounted a
> USB drive, in the USB directory I executed
>
> dd if=/dev/mmcblk1 of=BeagleBoneBlack-eMMC-image-Jan52014.img bs=10M
>
> The command completed with no errors and a reassuring amount of data copied
> (1.9gb)
>
> Then I booted the 'destination' system from an Anstrom 'bootable' microSD,
> mounted my USB drive, and in the USB directory executed
>
> dd if=BeagleBoneBlack-eMMC-image-Jan52014.img of=/dev/mmcblk1 bs=10M
>
> Again, the command completed with no errors and a reassuring amount of data
> copied (1.9gb)
>
>
> Unfortunately, when I boot the destination machine, nothing much happens
> except a flashing LED. I can't SSH into the board and it doesn't even show
> up on my network.

well get a usb-serial adapter and it'll tell you why it can't boot...

ignore the "/dev/mmcblk1bootX" they are not used in this system..

> I would be very grateful if somebody could tell me what I am doing wrong.

your debugging blind, grab a usb-serial adapter and you can easily see
what's wrong..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Brian Piccioni]

Robert

Thank you so much for the reply. I was unaware that I could pull diagnostic information from the BBB during boot from the serial port.

Indeed - I never noticed the serial port before either!

I believe I have a serial to USB adapter, so I'll try it when I get home.

One correction: my flashed BBB is not running Ubuntu 12.4, but 13.04. Not that it makes a difference, but I figure for historical reasons I'd correct it.

Thanks again for your help. I am sure dealing with newbies all the time must be frustrating. I do know a lot of stuff, but am relatively new to Linux, ARM, etc..

Brian

[Robert Nelson]

On Mon, Jan 6, 2014 at 10:26 AM, Brian Piccioni <nair...@gmail.com> wrote:
> Robert
>
> Thank you so much for the reply. I was unaware that I could pull diagnostic
> information from the BBB during boot from the serial port.

I wouldn't say it'll give you an 100% answer, but it'll at-least give
you a clue for the next direction to go..

>
> Indeed - I never noticed the serial port before either!
>
> I believe I have a serial to USB adapter, so I'll try it when I get home.
>
> One correction: my flashed BBB is not running Ubuntu 12.4, but 13.04. Not
> that it makes a difference, but I figure for historical reasons I'd correct
> it.

In most cases the version of ubuntu actually dosen't matter.. It's
more about when it was packaged and how it was setup on your device.

[William Hermans]

Just make sure your serial adapter is 3v3 TTL. 

Also you need to make certain adjustments to the uEnv.txt, and /etc/inittab or /etc/init/serial.conf files if you have not done so already. If you followed Roberts instructions thus far, then you're probably golden.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Piccioni]

Thanks for the suggestions.

I have found this information regarding serial.conf
     sudo nano /media/rootfs/etc/init/serial.conf
     With this content:
            /etc/init/serial.conf
            start on stopped rc RUNLEVEL=[2345]
            stop on runlevel [!2345]
 
            respawn
            exec /sbin/getty 115200 ttyO0

Are these the ones you mean?


I don't know which adjustments to the uEnv.txt I need - the ones I have seen appear to be about mounting the microSD under Angstrom (I think). Are there others? Also, I have not followed Robert's instructions (yet) are there instructions for cloning eMMC I should be following?


Also, thanks for the tip regarding a 3v3 FDTI, however, according to this

http://dave.cheney.net/2013/09/22/two-point-five-ways-to-access-the-serial-console-on-your-beaglebone-black

The Vcc line on the BBB is not connected - of course I will verify.

Thanks!

[Robert Nelson]

On Mon, Jan 6, 2014 at 7:51 PM, Brian Piccioni <nair...@gmail.com> wrote:
> Thanks for the suggestions.
>
> I have found this information regarding serial.conf
> sudo nano /media/rootfs/etc/init/serial.conf
> With this content:
> /etc/init/serial.conf
> start on stopped rc RUNLEVEL=[2345]
> stop on runlevel [!2345]
>
> respawn
> exec /sbin/getty 115200 ttyO0
>
> Are these the ones you mean?

That just sets up getty on ttyO0 so you login over the serial port too..

> I don't know which adjustments to the uEnv.txt I need - the ones I have seen
> appear to be about mounting the microSD under Angstrom (I think). Are there
> others? Also, I have not followed Robert's instructions (yet) are there
> instructions for cloning eMMC I should be following?

I actually use rsync/sfdisk to create a new microSD of the eMMC then
just using dd.. It's also way faster 5-10 minutes..

For example this will copy the eMMC to microSD:
https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-copy-eMMC-to-microSD.sh

however it'll only work on the images i host on rcn-ee.net due to some
assumptions made in my images.

[Brian Piccioni]

Got it, thanks.

So I'll basically plug in the FTDI, open a terminal emulator and try to boot off my cloned image and see what she says.

Unfortunately, I have to go through my eMMC copying routine first, and I have to remove 6" of snow first ...

I wasn't expecting any trouble using dd to clone the eMMC. I had done pretty much exactly the same thing converting my Windows and Linux systems to SSDs and it worked like a charm. I would have figured that, unless something like the MAC address (which is unique to each platform) matters to the OS it would work on the BBB as well.

By the way - I know you are very active in supporting the platform. Thanks on behalf of all BBB users.

I think it is great piece of kit.

Brian

[Robert Nelson]

On Mon, Jan 6, 2014 at 8:04 PM, Brian Piccioni <nair...@gmail.com> wrote:
> Got it, thanks.
>
> So I'll basically plug in the FTDI, open a terminal emulator and try to boot
> off my cloned image and see what she says.
>
> Unfortunately, I have to go through my eMMC copying routine first, and I
> have to remove 6" of snow first ...
>
> I wasn't expecting any trouble using dd to clone the eMMC. I had done pretty
> much exactly the same thing converting my Windows and Linux systems to SSDs
> and it worked like a charm. I would have figured that, unless something like
> the MAC address (which is unique to each platform) matters to the OS it
> would work on the BBB as well.

dd is facing two issues.. hotplug (so eMMC/microSD can easily swap
kernel names /dev/mmcblk0 / /dev/mmcblk1 ) and to support hotplug, we
are using UUID's to access the eMMC.. (such that you can easily boot
with the microSD plugged in or not..)

[Brian Piccioni]

I probably only understand a tiny part of what you wrote. I will post the result of the experiment tomorrow.

Thanks again for the help and your patients

Brian

[William Hermans]

https://lh4.googleusercontent.com/-3oca40vrH-g/Ubd5TjD-0_I/AAAAAAAAALU/-GibZBaTvKk/s1024/beaglebone-black-serial.jpg

thats what you have. vcc has nothing to do with it. RXD/TXD do . . . 

Yes on the serial.conf file and uEnv.txt should have a ...

console=ttyO0,115200n8

Line in it. Which i bet it does already.

--

[Brian Piccioni]

Thanks for the heads up  - fortunately, the board I have is 'switchable'. One interesting note, however, is that the board pinout is 180 degrees relative to the BBB and it won't fit the 'right way' Again, fortunately, I had some stackable headers from an Arduino protoboard so I could make it work.

I am now going to post the results ...

[Brian Piccioni]

Under Angstrom I did this
root@beaglebone:/usb1# dd if=/usb1/BeagleBoneBlack-eMMC-image-Jan52014.img of=/dev/mmcblk1 bs=10M
183+1 records in
183+1 records out
1920991232 bytes (1.9 GB) copied, 303.132 s, 6.3 MB/s

Which appear to be correct (as expected)


So here are the results of the 'serial dump' from the BBB as suggested

I cut out what I thought was non-diagnostic stuff at the beginning for brevity.

I suspect the problem is in ALERT!  /dev/mmcblk1p2 does not exist.  Dropping to a shell!

I am pretty sure the eMMC is mounted as /mmcblk1 on the 'Source' System when off it as Ubuntu

Here is the edited trace

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.545762] omap2_mbox_probe: platform not supported
[    0.822614] tps65217-bl tps65217-bl: no platform data provided
[    0.897877] bone-capemgr bone_capemgr.9: slot #0: No cape found
[    0.934981] bone-capemgr bone_capemgr.9: slot #1: No cape found
[    0.972089] bone-capemgr bone_capemgr.9: slot #2: No cape found
[    1.009201] bone-capemgr bone_capemgr.9: slot #3: No cape found
[    1.030362] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8                                          .45 (#5:BB-BONELT-HDMI)
[    1.040031] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[    1.046814] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BON                                          ELT-HDMIN:00A0 (prio 2)
[    1.067415] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed
[    1.132843] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by                                           44e10800.pinmux; cannot claim for gpio-leds.8
[    1.144604] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    1.151921] pinctrl-single 44e10800.pinmux: could not request pin 21 on devic                                          e pinctrl-single
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk1p2 does not exist.  Dropping to a shell!

[Robert Nelson]

On Tue, Jan 7, 2014 at 8:13 PM, Brian Piccioni <nair...@gmail.com> wrote:
> Under Angstrom I did this
> root@beaglebone:/usb1# dd if=/usb1/BeagleBoneBlack-eMMC-image-Jan52014.img
> of=/dev/mmcblk1 bs=10M
> 183+1 records in
> 183+1 records out
> 1920991232 bytes (1.9 GB) copied, 303.132 s, 6.3 MB/s
>
> Which appear to be correct (as expected)
>
>
> So here are the results of the 'serial dump' from the BBB as suggested
>
> I cut out what I thought was non-diagnostic stuff at the beginning for
> brevity.
>
> I suspect the problem is in ALERT! /dev/mmcblk1p2 does not exist. Dropping
> to a shell!
>
> I am pretty sure the eMMC is mounted as /mmcblk1 on the 'Source' System when
> off it as Ubuntu

Unless your running a later then 3.8 kernel, as mid summer we enabled
mmc hotplug..

So if no microSD is installed, eMMC is now /dev/mmcblk0 instead of /dev/mmcblk1

[Brian Piccioni]

Please bear with me.

When I log into the source system it says
Welcome to Ubuntu 13.04 (GNU/Linux 3.8.13-bone21 armv7l), which is a 3.8.13 Kernel (?).

When I made the copy I had burned this image to a microSD
                        Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.08.21

Based on your comment, I inserted a spare microSD into the destination BBB it works (apparently) perfectly. (!!!!)

THANK YOU!

Now, if I update the Kernel on the source BBB, then recreate the source and copy it to the destination should it behave properly even without a microSD?

This is not absolutely critical because my application will pretty much always have a microSD card installed, however, if the microSD were defective or not installed properly, etc., the original BBB could at least tell me while the copies would not.

Thanks again.

Brian

[Robert Nelson]

On Tue, Jan 7, 2014 at 8:41 PM, Brian Piccioni <nair...@gmail.com> wrote:
> Please bear with me.
>
> When I log into the source system it says
> Welcome to Ubuntu 13.04 (GNU/Linux 3.8.13-bone21 armv7l), which is a 3.8.13
> Kernel (?).

Oh, that was 7 months ago... let's just call it "old" and therefor "broken"..

>
> When I made the copy I had burned this image to a microSD
>
> Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.08.21
>
> Based on your comment, I inserted a spare microSD into the destination BBB
> it works (apparently) perfectly. (!!!!)
>
> THANK YOU!
>
> Now, if I update the Kernel on the source BBB, then recreate the source and
> copy it to the destination should it behave properly even without a microSD?
>
> This is not absolutely critical because my application will pretty much
> always have a microSD card installed, however, if the microSD were defective
> or not installed properly, etc., the original BBB could at least tell me
> while the copies would not.

Use an UUID instead of a raw /dev/mmcblk name in your bootloader
(uEnv.txt) and /etc/fstab then you won't have to worry about that..

[Brian Piccioni]

Thank you for your help. I was unaware of UUID(s) and the first thing I find is that you should use UUIDs instead of /dev/...

I will do a bit more work on UUIDs and try figure out the machinations of uEnv.txt and /etc/fstab and try figure out the final details myself. I will post for posterity whatever I discover works so the next noob won't waste so much of your valuable time.

Thanks again.

Brian

[Brian Piccioni]

Thanks to the help of Robert and William I have successfully cloned a Ubuntu BBB. For posterity (i.e. the next Noob who struggle with this, I have written up the procedure I used.

Thanks again for the help.
Brian

Start up the source BBB, booting Ubuntu off eMMC.

 

In order for this to work, uEnv.txt and /etc/fstab must use UUIDs for the root file system. My fstab was automatically generated and used UUIDs, however, uEnv.txt did not which meant the copy process did not function properly.

 

So you have to make sure uEnv.txt uses UUIDs. So, to the Find out what your UUIDs are

brian@arm:/boot/uboot$ sudo blkid

/dev/mmcblk0p1: LABEL="storage" UUID="5bdb27fd-1cb8-4a08-b2c2-51062e8b2fa7" TYPE="ext4"

/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="boot" UUID="AEA7-4FDD" TYPE="vfat"

/dev/mmcblk1p2: LABEL="rootfs" UUID="d933e4fe-59f6-4344-9935-8f86c04b7481" TYPE="ext4"

 

Edit uEnv.txt to use UUID for rootfs

sudo nano /boot/uboot/uEnv.txt

 

Replace the line

mmcroot=/dev/mmcblk1p2 ro

 

With the UUID of the root (i.e :UUID=d933e4fe-59f6-4344-9935-8f86c04b7481) and add mmcrootfstype as appropriate

mmcroot=UUID=d933e4fe-59f6-4344-9935-8f86c04b7481

mmcrootfstype=ext4 rootwait fixrtc

 

Save the file, double check to make sure you've saved it, made the right changes, etc..

 

 

Now to make a copy image (you do this once). On the Source BBB Remove Powe

Insert bootable microSD ( I used Angstrom, marked ‘O’)

Insert thumb drive

Push ‘Boot’ button (near microSD card) and insert power AT LEAST until all 4 LEDs light

Log in (as root, no password)

 

df - to see where the Thumb drive is mounted (/media/Lexar)

cd /media/Lexar

fdisk –l to list drives (eMMC will probably be /dev/mmcblk1)

 

Copy mcblk1 to a backup image

dd if=/dev/mmcblk1 of=BeagleBoneBlack-eMMC-image-Jan82014.img bs=10M

(This takes about 5 minutes and you should get a result like this:

183+1 records in

183+1 records out

1920991232 bytes (1.9 GB) copied, 336.935 s, 5.7 MB/s

 

 

On the second (destination) BBB Remove Power

Insert bootable microSD ( I used Angstrom, marked ‘O’)

Insert thumb drive

Push ‘Boot’ button (near microSD card) and insert power AT LEAST until all 4 LEDs light

 

df - to see where the Thumb drive is mounted (/media/Lexar)

cd to the thumb drive /media/Lexar

fdisk –l to list drives (eMMC will probably be /dev/mmcblk1)

 

Copy backup image to mcblk1

dd if=BeagleBoneBlack-eMMC-image-Jan82014.img of=/dev/mmcblk1 bs=10M

 

And get this result

183+1 records in

183+1 records out

1920991232 bytes (1.9 GB) copied, 303.132 s, 6.3 MB/s

 

Remove the uSD and USB Stick, reboot, log in and, find out what your UUIDs are (they should be the same as the source BBB)

brian@arm:/boot/uboot$ sudo blkid

/dev/mmcblk0p1: LABEL="storage" UUID="5bdb27fd-1cb8-4a08-b2c2-51062e8b2fa7" TYPE="ext4"

/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="boot" UUID="AEA7-4FDD" TYPE="vfat"

/dev/mmcblk1p2: LABEL="rootfs" UUID="d933e4fe-59f6-4344-9935-8f86c04b7481" TYPE="ext4"

 

[Cristian Astorino]

is it possible to use initrd with angstrom? I would like to boot from emmc with uuid. Actually when microsd is inserted the system boot from microsd and I would like to avoid that.

Regards