This method is useful for quickly deploying a fleet of devices for the same application. Ie you have a single device setup and working for the application, and want to quickly get dozens or hundreds more devices up and running doing the same thing. This is an alternative to building your own firmware.

Pros and Cons

This cloning process serves as a quicker alternative to creating your own firmware from scratch using the build system (https://github.com/OnionIoT/source), which is more work intensive
If a factory restore is triggered on a cloned device, it will revert to the original firmware. Meaning it will look and behave like an Omega device coming from the factory.

Overview of the Process

1. Create the clone image from the original device:
   • Set up device with all of the packages, files, and configuration that you'll need
   • Create a full filesystem image and copy it to external storage (usb drive, sd card, etc)
2. Clone to other devices
   • Flash other Omega devices using the image
   • Run a script on the cloned device to restore its unique identifiers

Step 1: Create the Clone Image from an Original

• Set up an Omega2 device that will act as the original device. Meaning install all required packages, add files, perform configuration, etc
  • Take note of the firmware version the original device is running
• When ready, plug in a USB drive (or other external storage)
• Navigate to the mounted USB drive
  cd /mnt/sda1
• Create the image
  dd if=/dev/mtd3 of=<IMAGE-NAME>.bin

We recommend using a version number or a date to easily differentiate the clone images, for example:
dd if=/dev/mtd3 of=/mnt/sda1/firmware-20200308.bin

Step 2: Clone other devices

• Boot a target device
• Make sure the target device is running the same firmware version as the original device
• Plug in the USB drive
• Navigate to the mounted USB drive
  cd /mnt/sda1
• Flash the image
  mtd -r write <IMAGE-NAME>.bin firmware
• When the device reboots, restore the device's unique identifiers by running
  updateHostname -f

Repeat Step 2 for all devices that you want to clone with the same setup as the original.

This is exactly what i was hoping for, thanks for that!
I guess this is just cloning and injecting the overlay into a "fresh" omega right?

Are there any concerns about using the same firmware version on both source and target?

I can imagine that you wouldn't want to clone that overlay (maybe containing older version packages) to a firmware thats newer than those packages? Or the other way around... Any thoughts on that?

I will keep on the safe side for now and will be checking for matching firmware versions using this method...

Cheers, Tony

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

I guess this is just cloning and injecting the overlay into a "fresh" omega right?

The target device can be not "fresh" since this will overwrite the overlay partition (on /dev/mtd3). But just to be safe try to make sure the target device is fresh.

For more info on openwrt flash layout, see this OpenWRT Docs article

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

Are there any concerns about using the same firmware version on both source and target?

You raise a good point! I would recommend making sure you're using the same firmware version on both source and target. I've edited the procedure above to mention this.

This process will only clone the overlay partition, that is, changes you've made to the device. This could potentially cause issues if the packages in the firmware of the target are a different version than on the source.

After having the auto-provisioning up and running I still have a small imperfection in play.

Whenever mtd -r write <IMAGE-NAME>.bin firmware finishes it does not do the -r because it complains about not being able to [e]rase a block. ...it exits with 1

Writing from 20211027-pan35-blusser-9-5.bin to firmware ...
[e]Failed to erase block

mtd verify doesn't end well either.

After a reboot the omega seems to be running my custom firmware happily, so I dont worry too much yet, but it keeps nagging

I have followed the instructions closely, also tried a couple of times more to make a new .bin file using the dd method.

This is how that runs:

root@Pandora3-74F3:/mnt/mmcblk0# dd if=/dev/mtd3 of=20211108-pan35-blusser-9-5.bin
64896+0 records in
64896+0 records out

Any idea where i should look?

Thanks, Tony

We have been working with OpenWRT 22.03 ever since you posted the good news "Beta OpenWRT 22.03 firmware available! Your feedback is needed"

I have had a hard time deciding where to post this question since you asked for feedback elsewhere, but this is where it all started for us.

The "dd if=/dev/mtd3 of=<IMAGE-NAME>.bin" trick has been great for a long time.We have cloned our product 100's of times with tthis method.

However it seems that the "new" OpenWRT is not so forgiving about this trick.

I've made a clone the same way as i did before, and all seemed well.

However during the write on a fresh Omega2S+ things get really nasty.

[  191.778153] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.848147] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.918210] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  191.988187] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  192.058167] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node
[  192.128210] jffs2: error: (483) jffs2_do_read_inode_internal: Argh. Special inode #16 with mode 0x2000 had more than one node

this does NOT stop....

after a very messy reboot a second firmware write with the same image makes everything good again

Probably it's all very obvious but i don't know how to do it the right way.
Using "mtd -r write <IMAGE-NAME>.bin firmware" definitely seems not to be the way anymore.

I noticed that with an openwrt.bin you advise using sysupgrade -F -n -v <SELECTED-FIRMWARE-IMAGE>.bin (in your technical doc )

I am not sure if i can use sysupgrade to write our clone, but my guess is no. (NOOOH!)

I hope you can give us some advice, since i now need to provision 200+ fresh Omega2s+ devices with our nice and perfectly running OpenWRT 22.03 image...

Thanks for the help... if you can offer any...

Cheers, Tony

PS,
i'm also looking at how the openwrt-imagebuilder-wrapper works, maybe thats a better path... but it will take me a long while to migrate everything we have in that direction i'm afraid.
Do you think that's the way to go in this case?

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

However during the write on a fresh Omega2S+ things get really nasty.

It's a strange error message, I haven't encountered it before.
Was this the first time you tried cloning to a fresh device? Were you able to get it to work before this?

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

after a very messy reboot a second firmware write with the same image makes everything good again

To make it good again did you reflash the beta firmware or write the cloned partition again?

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

I noticed that with an openwrt.bin you advise using sysupgrade -F -n -v <SELECTED-FIRMWARE-IMAGE>.bin (in your technical doc )
I am not sure if i can use sysupgrade to write our clone, but my guess is no. (NOOOH!)

Your guess is correct, sysupgrade can only be used with full firmware images, it doesn't work with clone partition images

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

i'm also looking at how the openwrt-imagebuilder-wrapper works, maybe thats a better path... but it will take me a long while to migrate everything we have in that direction i'm afraid.
Do you think that's the way to go in this case?

Yes, we made the openwrt-imagebuilder-wrapper for exactly this purpose
It's very simple to set up and incredibly quick to run - it takes minutes to build a firmware image. We use it to build our beta firmware and we plan on using this to move forward.

So I definitely recommend moving in this direction.

The only wrinkle is that you'll need to have your customizations wrapped up as packages.
As a stop-gap, you can add individual files to the firmware build (see this section in the wrapper readme) but in the long-term we recommend having your custom programs, configs, etc in packages.

If you have questions about the imagebuilder wrapper, feel free to post in the Omega2 Talk category and I'll get back to you!

i'll try to elaborate on the nasty cloning problem first.

I never got this to work "in one go" with "my own" cloned custom openwrt 22.03 on any occasion. I can reproduce the problem every time i "flash" a fresh omega this way (mtd write).

I have a hunch it might break because the image is too big, filesize is 33226752, it seems like it does not finish the write completely and the os gets corrupted because of it. I even saw "broken pipe" at one point.
After a reboot into the cripple new os (with a lot of console complaining) i "mtd write" exactly the same custom image again and then it works out completely fine. (so the second writing is started from the first-flashed 22.03 "cripple" os)

The woraround i found now is to first
sysupgrade -F -n -v onion_omega2p-22.03.5-20240122.bin a fresh omega
let that reboot and then
mtd -r write pan230_v4.1-96_20240222.bin firmware

This works, taking a LOT of precious extra time, but no nastyness.

Needles to say it would be great to write in one go because of the time loss (times 200)

This "not completely finishing the write" used to happen to the first clones we spoke about two years ago too, with the original onion os, they gave the error "[e]Failed to erase block" after writing, but they ended up running completely fine so i stopped thinking about it.

i'm still curious why the old mtd write method does not work for me anymore, but i think its more useful to point my energy towards the new and improved method...

I hope i still can bother you now and then, because i'm absolutely convinced i will find plenty of obstacles to be conquered

On that note, would it be better to report in the git issues or to discuss in the community?

thanks, tony

The woraround i found now is to first
sysupgrade -F -n -v onion_omega2p-22.03.5-20240122.bin a fresh omega
let that reboot and then
mtd -r write pan230_v4.1-96_20240222.bin firmware
This works, taking a LOT of precious extra time, but no nastyness.

The target device needs to be running the same firmware version as the original device. (This is mentioned in Step 2 in the original post)

The reason being the cloning only overwrites the firmware partition. If the rest of the partitions don't match, that opens to door to the nastiness you've been experiencing.

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

thanks for that little push toward the image builder.

Glad you're finding it useful!!

@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:

I hope i still can bother you now and then, because i'm absolutely convinced i will find plenty of obstacles to be conquered
On that note, would it be better to report in the git issues or to discuss in the community?

Definitely! Always open to suggestions!

I think the community is good for general discussion, if there's something specific then open a github issue