One thing to be aware of is SSH. If you set up SSH on the master you will end up with cloned SSH certificates on all of the images, which isn't necessarily what you want. OTOH, if you are going to be using the Pis headless, you probably do want SSH installed...
– Darren WilkinsonJul 16 '12 at 17:06

@darrenjw That is an extremely good point. You've saved me some embarrassment and no mistake. Thank you.
– JivingsJul 16 '12 at 19:28

Depending on how you intend to use that mass of Pis you may want to check out Andrew Mulholland's Raspi-LTSP project. It's not just useful for classroom use - it's also very good for clusters.
– Dave JonesNov 13 '14 at 11:50

11 Answers
11

There are a couple of easy prep steps to do before writing a clone master to copies which will save you a lot of headaches.

Configure the clone master for DHCP

Delete everything in /etc/ssh/ssh_host* (these get recreated when you run SSHD)

if you have an /etc/udev/rules.d/70-network* file, you'll need to modify the eth0 entry to something else (I used eth9 for my clone masters) - and remember to update the associated ifconfig file - in centos that is /etc/sysconfig/network-scripts/ifcfg-eth0 (make it 9) and in debian (raspbian) it's /etc/network/interfaces

I had the same requirements as 1 and 2 to distribute a customized OS. After looking around I found many commands, but not a single tool to create a compact .zip file from an SD card, so I wrote mkimg.sh, which works like this:

sudo bash mkimg.sh /dev/sda sdcard.img.zip

This takes the unmounted device at /dev/sda, shrinks down the filesystem and partition, and writes out a compressed zip. In my use, this writes a ~1.5GB Raspbian system to create a <500MB .zip.

Along with sanity checks and size calculations, the script essentially does this:

Step 5: Now here's where it gets interesting, from your main computer use multixterm like so from the command line multixterm -xc "ssh %n" host1 host2 where host1 and host2 are the ip addresses of the Raspberry Pis.

Step 6: Inside of multixterm's stdin window you can use dd as you normally would to write images to the SD cards but now multixterm will send that dd command to both Raspberry Pis simultaneously.

Step 7: Repeat steps 3-6 until you have all of your cards written.

The more SD cards you image the more Raspberry Pis you can use to image new SD cards. Obviously this technique won't write all of your cards in one go, but it would cut back on the amount of time it takes to complete writing all of the cards. This technique would be largely experimental so your mileage would vary, but the theory of it sounds like an interesting experiment...

Very interesting - but also very expensive for mass scale =) hehe love it. Is there no way to hyper thread writing images in different consoles to different USB SD adapters maybe?
– ppumkinNov 1 '12 at 10:12

What you are looking for is a Gang Programmer device for SD cards, or SD Card Duplicator.

Yes, these systems do exist. Here is one that I found by Googling "sd card gang programmer". This specific device has a master slot, which it can copy up to 7, slave SD cards at once. Other programmers with 3 or 11 slave slots are also available.

There are also different types of programmers. Some can flash an image from your hard drive and is controlled by software installed on a PC. Other devices, like the one linked above, do not have to interface to a servers because they mirror the information off of a master chip.

It is worth mentioning that these devices are not cheap. They are typically used in a mass production environment and demand isn't excessively high. Be prepared to pay at least $1,000 for a good device with this functionality.

ProDuplicator.com appears to have quite a few more SD Card duplication options, as well.

I wonder why these cost so much, considering that you still need to baby-sit this thing to manually put the SD cards in and out.
– Dmitry GrigoryevJul 6 '17 at 9:32

@DmitryGrigoryev In the 5 yeas since my answer, the duplicator site now has one for under $600, which IMHO seems cheap. Keep in mind that quantity drives price. Not many people need these so they are expensive because they need to recover development and manufacturing costs. If there was one of these for every 10 PCs or laptops, it'd probably be a $100-150 device.
– RLHJul 6 '17 at 18:15

We had a similar requirement for a project where we needed to be able to write images to 10+ Raspberry Pi SD cards on a daily basis. We looked at the various Card Duplicator's available to buy but found most of them won't successfully make a bootable SD card, as most only copy files directly and not the bootable information, they are also ridiculously expensive!

So as a solution we wrote our own simple web-based software to run on a single Raspberry Pi connected to 2 x 7-port Belkin powered USB hubs (The Pi has a limitation of 2 hubs, and a maximum of 14 USB ports).

We've now released this as Open Source software to help others who have the same requirement. Currently just the source code is available but we will also be uploading an image file based on Arch Linux ARM running Nginx + php

Although How do I backup my Raspberry Pi? provides excellent instrictions on how to clone a single SD card, doing it one at a time for dozens of cards will get tedious.

Given that no-one seems to have produced a multi-card SD card reader (one that can hold multiple SD cards at once) and the fact that that you can buy a USB hub and a bunch of single SD card USB readers very cheaply, one way to speed up the process would be to make your own SD card duplicator.

You could even write a script to automatically write your chosen Raspberry Pi image onto any empty SD card slot inserted in a slot. Scripts could automatically detect that a card has been inserted and indicate when the copy completes.

As darrenjw mentioned in comments though, you will want to replace the ssh certificates in each of the cloned images the first time they are booted, so you may want to make sure that this first boot is done while connected to a private network segment before connecting it to an internet connected network.

Thanks @AlexChamberlain, I've still got a couple of weeks before my Pi is supposed to arrive (Grrr, if I'd known I was on an RS waiting list for a long lead time I would have just ordered from Farnell with a long lead time in the first place) so I haven't actually tried this yet.
– Mark BoothJul 17 '12 at 12:34

There are usually better tool to do this, then to copy a lot of RP images.

But it depends on what you really want to do.

You should have a look at cfengine3[1], fai[2], chef[3], fabric[4] or puppet[5]. They are automatic configuration tools, which would be usefull for doing stuff in your machine when started first time (and later).

To address only having a single SD card slot on your computer, the easy answer for burning multiple images efficiently is a powered USB hub and a number of inexpensive microSD-USB adapters. I've tested using a 13 port USB-3 hub and cheap (< $1) microSD-USB adapters.

So far as burning a lot of base images simultaneously, check out dcfldd. It is available in the raspbian jessie repositories. It's an enhanced version of GNU dd, with the ability to simultaneously write to multiple images. I did some casual testing, and was able to copy a microSD card image on a RPi 3B to a mix of 7 cards plugged into 3 types adapters on a USB hub. Prior tests to a 3 port USB 2.0 hub on an A+ also worked. It's pretty much fire-and-forget once you get the parameters set correctly. I was limited to 7 adapters, but there's no reason to think it wouldn't work with a larger number of cards, albeit speeds will be limited to that of the slowest destination card.

If you need to keep a large number of RPis up-to-date with configuration changes once they're running and on your network, I'd look into using ansible or fabric to allow updates over ssh and avoid needing to re-burn the cards to keep them current.

Finally, you could modify your master to change the hostname on each RPi using a unique identifier (e.g. based on network MAC address) to allow easy location via avahi without having to modify every RPi to avoid conflicts after it boots to avoid conflicts.