Clone a dragonboard to other dragonboard units

Products Support DragonBoard410c
#1

Hi
I’m building a linux application on the dragonboard 410c that requires me to use a bunch of third party libraries. It takes about an hour to get all the dependencies from apt and then another hour or so to build my code.
I have a reference board setup for the final application. I’d like to clone it to 10 other devices.
I was thinking that I could just dd the mmcblk0p10 partition into an image file and then dd that image file into the other dragonboards. The problem is its not working. The cloned board doesn’t go beyond random block pool initialization while booting. I’m pretty sure its a result of dding into a mounted and running rootfs.

step 1: dd if=/dev/mmcblk0p10 of=/media/<thumb_drive>/clone.img
On different board
step 2: dd if=/media/<thumb_drive>/clone.img of=/dev/mmcblk0p10

I’d ideally like to clone a dragonboard into an SD card and then use the SD card to quickly setup all the other boards. Please help me figure this out and find a solution. It’ll save me a long arduous week.

Thanks

1 Like
Requesting help with two issues: cloning a custom image and installing a fresh image
How to generate sdcard installation image?
#2

hi,

without knowing to much the context of what you want to do with the ‘10 other devices’, i can already say that this isn’t a really good idea to dd the rootfs. while it might (seem to) work, it is very prone to errors.

there are many scripts that run at ‘first boot’ that wouldn’t run in your case, for example.

the right thing to do would be to make your own images and add your packages in that image (which implies that you also need to package your own app as a debian package).

if you can’t go that far, you can look into a few tips:

  • when you install deb files there are downloaded/copied in /var/cache/apt/archives/, so once you’ve installed on one board, you just need to copy these files over to the new board (and reinstall them there)
  • for your application, it should be safe to tar/untar it over.

this might not be perfect either, but still better than dd’ing the entire rootfs…

#3

Thanks for your help
Could you please point me to a resource that helps me create my own bootable installer SD card to flash my custom rootfs and custom boot image? Is it possible that I make my own rootfs.img and replace the one in the standard installer sdcard so that its my image that is flashed and not the standard one?

#4

hi, there is no ‘wiki’ that explains that, but here is the script that generates the images that we publish on 96boards.org website:

https://git.linaro.org/ci/job/configs.git/blob/HEAD:/lt-qcom-debian-images-arm64/installer-dragonboard-410c.sh

it is better than any documentation, it is the source code :wink:

Some folks on the forum have reported that they were able to make their own images, so if you have questions, hopefully someone will be able to help.

Also if you only want to create a bootable SD card (without the installer), e.g. if you want to boot from SD your own OS without flashing the eMMC, you can use this wiki: https://github.com/96boards/documentation/wiki/Dragonboard-410c-GPT#create-a-bootable-sd-card

And to answer your last question, yes you should be able to make your own rootfs.img and add it in the SD card. You can replace the one we have, or even better you can make your own folder and create your own release.

#5

Thanks for the script.
I’m cloning the kernel tree right now. I’ll try to build my own installer and ask you if i run into any problems. I already have a bootable sd card through which I can boot into the system. I wanted to ask your opinion on something I was working on and whether it would be a good solution to my problem.

install the standard image from the sd card.
install all the packages from deb and source that I need.
build and install my application on the dragonboard 410c.
boot from the bootable SD Card.
dd the rootfs from the emmc (mmcblk0p10) into a USB stick as custom_rootfs.img

replace the rootfs.img in the standard sd card installer with custom_rootfs.img
boot from the sd card installer and install
Boot from emmc
This should now have all my dependencies and my application installed

Please share your thoughts on this. Can you also point me to the scripts that run on first boot so that I can manually add them to the custom_rootfs.img so that they execute the first time I boot into custom rootfs?

You’ve been most helpful so far and I’m really grateful for the amount of pains you take to keep the forum going and also for your patience with us noobs.

#6

hi,

as i said earlier it is not a good idea to dd an already booted system. There is not one ‘script’ that runs on first boot, but potentially many. Each debian package can have one (or many) scripts that will do ‘something special’ on first boot.

One of our script for example will resize the rootfs so that it uses the entire partition. this is done on the first boot only. The image that we build are as small as possible , but then if you check after the first boot you will see that they use the entire space on the partition.

If you really , really want to clone a system, please check for more appropriate tools (at least read about them, such as https://wiki.archlinux.org/index.php/disk_cloning, https://wiki.debian.org/Backup/Clone).

If you want to make your own custom image , it is not that hard, and you can reuse all our scripts:

  1. generate the ‘generic’ rootfs
    https://git.linaro.org/ci/ubuntu-build-service.git/tree/HEAD:/jessie-arm64-alip
    Here you can customize the packages that go into the image

  2. generate the db410c rootfs.img and boot.img
    https://git.linaro.org/ci/job/configs.git/blob/HEAD:/lt-qcom-debian-images-arm64/builders.sh

  3. generate the SD installer, as per my previous messages.

There is a bit of learning curve, but that shouldn’t be too hard. And then you end up with fully reproducible instructions…

#7

Your links are broken.
We need a simple way to create an image file from the eMMC so we can clone dragonBoards
Thanks

#8

Infrastructure changes means the link in #1 above would now be spelled differently:
https://git.linaro.org/ci/ubuntu-build-service.git/tree/jessie-arm64-alip

Having said that, the link has nothing to do with cloning images: it is a link to scripts to generate filesystem images from scratch (and it generates images from last years release rather than the current one). As Nico said before, it is generally better practice to generate images than to clone one from a board. Cloning from a board implies you haven’t got adequate infrastructure to effectively deliver updates (including security updates).

#9

another issue with ‘cloning’ an image, is that there are files with UID or keys which are generated during the first boot, so you need to clone before the first boot , but I suppose that if you want to clone it is because you want to clone your own image modification, which you would typically do after the first boot.

This is a very common question that you are asking, we hear that often. Maybe you can explain a bit more why you want to clone image, and we can start a document/wiki with recommendations about how to deal with such use cases?

#10

@anon91830841, imagine that you buy a DragonBoard, and then you want to build something on it (let’s say OpenCV for example), which takes some time, and then you change the configuration, and then you add some swap file, etc, etc. After that you simply want to copy/duplicate the DB to another one… That simply means to copy the content of the eMMC. I guess that’s what being done during manufacturing…
When I install linaro according the instructions (https://www.96boards.org/documentation/ConsumerEdition/DragonBoard-410c/Installation/LinuxFastboot.md.html) I burn 3 images. I want to be able to create these images after I put my code into them… Simple.

#11

ok, this specific use case should be covered with this guide then:

https://www.96boards.org/documentation/ConsumerEdition/DragonBoard-410c/Installation/LinuxSDBoot.md.html

Search for “Creating an image of the internal eMMC”

It does slightly more than “just” one partition, since it copies the entire eMMC image. if you prefer you can limit to making a copy of the partition you care about only (e.g. copy from /dev/mmcblk0pXX instead of /dev/mmcblk0). If you copy a single partition, then you end with a partition image (EXT4 for example), and you can then use fastboot flash to transfer on another board.

they key information in the guide is to make a block device copy, not a filesystem copy (e.g. dd , not cp), and to make the copy while the eMMC is not mounted (or booted).

#12

Thanks. I’ll have a look!

#13

The docs were revamped recently and the redirects aren’t working properly. The guide Nico mentions above is now found at:

#14

Thank you so much @danielt. I had discovered those resources after hunting about a bit and was waiting to report on how it works out after trying it out today.

Will report back. Thanks again.

#16

Hey @ttsas,

Did you ever get around to trying this? We are in a similar situation and I’m curious as to what your results might have been.

#17

@eee Sorry for the late response.

Here’s what I did, created a bootable microsd card using dd and the image dragonboard410c_sdcard_developer_debian-xxx.img (where xxx = some version number).

Then, I booted up into a live session.
Then cloned the installed OS with customizations (on the board’s storage) to an img using dd.
I used an external USB drive, mounted it, and used it as the destination for storing this img.

From here on out, I use the same process, to write this image from the USB, to a new board.

Seems to be working great so far, but I don’t know how it will hold up between hardware changes.

Hope that helps.

#18

So to anyone reading this far, the key (and instructions according to @danielt’s link) seems to be to create a block image of the rootfs partition while this partition is not mounted. This essentially means booting a live OS (96boards provides one) and creating the image from there.

@danielt @anon91830841, I’m still very much interested in the more formal way to configure a custom rootfs for our application as at some point we might bring to (initially low-ish volume) production. This customized OS would result from a combination of your Linaro release (which we’ll likely internally freeze at some point), some additional deb packages from signed repos, and our compiled proprietary source. Are the instructions in @danielt’s last post sufficient, or do I need to turn the complexity nob up a few notches?

#19

I doubt it. They only tell how to burn a pre-built SD card and how to backup the eMMC.

Most of the options are laid out in a pair of posts from myself and @anon91830841 (you’ll see us happily disagree with each other… but this is only really about how much effort it is for distributors to setup their own obs server and run fai):

#20

After jumping around a few topics related to this one, I can see this question getting asked in different contexts and being answered with different solutions depending on the particular need. Can you give (or reference) a set of instructions for mounting and chrooting this image with QEMU? Hopefully what I’m asking for is not redundant, but I have a sneaking suspicion it is.

This method…

At the really simple end this can be a matter of taking our image, unpacking it, loopback mounting it and chroot’ing (with the help of qemu) to update things. Then you can repack and install it as normal.

…seems to be the “smarter” path for our use-case. In short, I need a method to make some filesystem changes (install some packages, disable Bluetooth on boot, create a new user, etc.), drop in our complied application, button it up and flash this as our rootfs. Since IMO this is an appliance-like device, I like the Yocto idea too.

The longer version:

We have a small number of units running Debian and our application inside their functional prototype systems. I need a method to package up our changes and ideally simply reflash the rootfs to implement them. Since the changes are primarily in our application or an updated dependency, the unpack-update-repack method looks it’ll work. I can compile our app + deps on a reference DB410c (or x-compile), take the bins, drop them in a “clean” unpacked Debian, then overwrite the rootfs on the target board. Our current method is to:

  1. SSH in while performing sacrifices to the DHCP gods
  2. Do a bunch of git pulls
  3. Rebuild everything
  4. Cry over our lost productivity

Now that I have more than 2 boards to update in a run I’m really itching for a better way.

BTW, I’ll be happy to make a new topic if this a bit hijackie.

#21

I think it’s pertinent to this topic, so continuing here wouldn’t be too bad. If you do make a topic, please do share a link here.

Either way, I am interested in seeing if this qemu method works well for you.