Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a 16GB SD card that has a few partitions on it (it's actually the card for a Raspberry Pi). I have several other 4GB cards that I want to clone the primary card to. The 3 partitions on the primary card are:

  • Rasp boot partition, FAT, 60MB
  • Linux partition, ext2, 1GB
  • Additional "storage" partition, FAT, 1GB

If I use dd to create an image of the card via:

dd if=/dev/sdb of=~/sd-card.bin

then the resulting .bin is 16GB in size. Is there a way to use dd to copy just what's actually being used, i.e. < 4GB so that I can then dd this onto a new 4GB card? Or is there a better solution that I should be using?

share|improve this question

migrated from Mar 19 '13 at 10:14

This question came from our site for professional and enthusiast programmers.

I ended up creating the exact contents on a new 4GB card and cloning that with dd to a quantity of other cards. Still, would like to know if it's possible to solve the initial problem. – Charlie S Mar 18 '13 at 20:07
up vote 8 down vote accepted

I assume you are using a PC linux or mac computer to perform the copy, not the raspberry pi itself. You will probably need to add a block size. I have seen one and four megs used for Raspberry pi disks by specifying bs=1M or bs=4M. I think block size is more important when writing the disk as large transfers are quicker than smaller ones. This does not set tthe block size for the disk, it just effects the size of transfers dd uses. One reason for setting a large block size is the need to erase the flash before writing it. This is done automatically but faster for transfers that are larger than the minimal erase size. You can limit the total amount of data copied by dd using "count". "count" is in units of blocks. If the end of the last partition on the source disk is before the size of the destination you can do what you want. Something like "dd if=/dev/sdb of=~/sd-card.bin bs=1M count=4000" will create an image that is 4000MBs in size. See and for more information. Not sure how to find the end of the last partition or the cards total size. However if you have formatted the disks you will probably know how to do this.

share|improve this answer
Thanks for the info. I was not aware of the count option. I'll give that a try. – Charlie S Mar 19 '13 at 1:32
@charlie it'd be fascinating if you can try it with and without the count option and report back. be sure though to check how the size of the disk is being reported, and if you can add files to it and the size changes. 'cos when dd fails related to different sized disks, you get those kind of problems. Here is an example where I messed up with dd with two different sized drives. In the end I didn't use dd to do the clone. – barlop Mar 19 '13 at 12:23

Expanding upon William's answer, one could calculate the end of the last partition using fdisk and a calculator:

$ fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 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
Disklabel type: dos
Disk identifier: 0x00057540

Device         Boot  Start     End Sectors  Size Id Type
/dev/mmcblk0p1        2048  186367  184320   90M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      186368 3667967 3481600  1.7G  5 Extended
/dev/mmcblk0p5      188416 3667967 3479552  1.7G 83 Linux

Total used space in bytes = end sector of last partition X sector size (here that's 3667967 x 512).

Total used space in GB = total used space in bytes / 10243 (here that's 1.749023 GB).

Usually, it is not vital to create an image that is pared right down to the last useful bit of data so in the above example I would create an image of 2 GB using the method described by William in that same earlier answer:

dd if=/dev/mmcblk0 of=/path/to/pi_updated.img bs=1M count=2048

Included at the end of the image will be a small portion of the useless guff after your last useful data but that is no different in principle than the useless guff that will be overwritten when you write the image back out to your media.

This method has been working for me on a dozen or so clones. If there are any fatal flaws in this method, they haven't surfaced yet.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .