FWIW, this is running on an Arch Linux ARM installation booting off a SATA, where I plugged in the SD card from the RPi. The original 16GB card was imaged from Windows using a Debian image. I had used an SD card that I happened to have on hand, but I don't want to keep that specific SD card in the RPi anymore:

Disk /dev/mmcblk0: 16.1 GB, 16134438912 bytes
4 heads, 32 sectors/track, 246192 cylinders, total 31512576 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: 0x000ee283

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            2048      155647       76800    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          157696     3414015     1628160   83  Linux
/dev/mmcblk0p3         3416064     3807231      195584   82  Linux swap / Solaris

So then I took a disk image

$ dd if=/dev/mmcblk0 of=/backup/rpiboot.bin bs=1M
15387+0 records in
15387+0 records out
16134438912 bytes (16 GB) copied, 1745.67 s, 9.2 MB/s

I swapped in the 8GB SD card, here's the fdisk of a stock 8GB SD card before dd:

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
81 heads, 10 sectors/track, 19165 cylinders, total 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
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192    15523839     7757824    b  W95 FAT32

I wrote the image to the 8GB drive (note the "no space left on device" message)

$ dd of=/dev/mmcblk0 if=/backup/rpiboot.bin bs=1M
dd: writing ‘/dev/mmcblk0’: No space left on device
7581+0 records in
7580+0 records out
7948206080 bytes (7.9 GB) copied, 1802.52 s, 4.4 MB/s

fdisk after dd:

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 32 sectors/track, 121280 cylinders, total 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
Disk identifier: 0x000ee283

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            2048      155647       76800    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          157696     3414015     1628160   83  Linux
/dev/mmcblk0p3         3416064     3807231      195584   82  Linux swap / Solaris

The partitions are all the same.

The RPi boots and everything seems fine.

So I surmise that because the stock image is just a 2GB image, and I never resized it to use up the full 16GB, it was able to copy it and then write the first 8GB to the new drive.

So am I likely to see any problems with this new SD card due to the way I cloned it? Is there a better way to handle this?

  • I would not suggest this method but you should be fine. This method works because you didn't resize the disk and because the existing partitions were placed at the beginning of the card. – Steve Robillard Jul 14 '12 at 3:57
up vote 7 down vote accepted

Yes this is fine because as you guessed, only the first 2GB has actual data. The rest of the space (either the original 14GB or the now 6GB) is unused, so it doesn't matter what's there or not.

If you're going to the trouble of moving it though, you could enlarge the main partition with fdisk, format it and use cp -a to copy the files from the old (1.6GB) partition to the new, larger one. Unlike other operating systems, Linux doesn't particularly care how files are arranged in the filesystem, so as long as you preserve the file attributes (which cp -a does) then that's all you need to move a Linux install from one partition/device to another.

Alternatively, you could create an extra partition in the unused space and mount it in /home, allowing you to store plenty of data in your home directory without affecting the space used by the core operating system.

  • Nice answer that offers good improvements. +1 – Jivings Jul 14 '12 at 8:34

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.