I am trying to make a copy of my SD-Card so I can move it to my 64GB SD-Card. I have done this with the SD-Card of a raspberry pi, no problems there.

The SD-Card consists of two partitions: BOOT(fat32) and linux(ext4)

I have tried to make an image of the whole SD-Card using:

sudo dd of=Images/orangepi.img if=/dev/sdd bs=1M status=progress

And putting it back on a SD-Card:

sudo dd if=Images/orangepi.img of=/dev/sdd bs=1M status=progress

I could not mount the image since it consisted of 2 partitions. So I imaged BOOT and linux separately using:

sudo dd of=linux.img if=/dev/sdd2 bs=1M status=progress 
sudo dd of=BOOT.img if=/dev/sdd1 bs=1M status=progress

As you can see in the screenshot I added, the image created(on the right) from the SD-Card does not match the SD-Card(on the left).

My question is: why does this happen and how do I make a proper image of my SD-Card.

on the left the linux partition on the SD-Card, on the right the mounted image

My SD-Card's home folder has a folder called "Music" containing folders with mp3 files.

My image has a x-font.ttf with the name "Music". Folders seem to change into random files when imaged.

The SD-Card is a working ubuntu disk for my orangepi pc and is working at this moment.

**sudo apt install dcfldd
sda      8:0    0 465.8G  0 disk 
└─sda2   8:2    0 465.8G  0 part /media/Shared
sdb      8:16   0 238.5G  0 disk 
├─sdb1   8:17   0   500M  0 part 
├─sdb2   8:18   0 116.8G  0 part 
├─sdb3   8:19   0 117.3G  0 part /
├─sdb4   8:20   0     1K  0 part 
└─sdb5   8:21   0   3.9G  0 part [SWAP]
sdc      8:32   1   7.5G  0 disk 
├─sdc1   8:33   1    64M  0 part /media/fhfs/BOOT
└─sdc2   8:34   1   7.4G  0 part /media/fhfs/linux
sdg      8:96   0 465.8G  0 disk 
└─sdg1   8:97   0 465.8G  0 part /media/fhfs/0c91eeb6-7199-47b6-a603-04432a091fdc
sr0     11:0    1  1024M  0 rom  
**ls -lha /dev | grep sd**
brw-rw----   1 root disk        8,   0 Oct 18 14:54 sda
brw-rw----   1 root disk        8,   2 Oct 18 14:54 sda2
brw-rw----   1 root disk        8,  16 Oct 18 14:54 sdb
brw-rw----   1 root disk        8,  17 Oct 18 14:54 sdb1
brw-rw----   1 root disk        8,  18 Oct 18 14:54 sdb2
brw-rw----   1 root disk        8,  19 Oct 18 14:54 sdb3
brw-rw----   1 root disk        8,  20 Oct 18 14:54 sdb4
brw-rw----   1 root disk        8,  21 Oct 18 14:54 sdb5
brw-rw----   1 root disk        8,  32 Oct 20 18:11 sdc
brw-rw----   1 root disk        8,  33 Oct 20 18:11 sdc1
brw-rw----   1 root disk        8,  34 Oct 20 18:11 sdc2
brw-rw----   1 root disk        8,  48 Oct 18 14:54 sdd
brw-rw----   1 root disk        8,  64 Oct 18 14:54 sde
brw-rw----   1 root disk        8,  80 Oct 18 14:54 sdf
brw-rw----   1 root disk        8,  96 Oct 18 14:54 sdg
brw-rw----   1 root disk        8,  97 Oct 18 14:54 sdg1

**sudo dcfldd if=/dev/sdc2 of=linuxdcfl.img hash=md5,sha1 hashlog=hashlog.txt**
242944 blocks (7592Mb) written.
243056+1 records in
243056+1 records out
**sudo dcfldd if=/dev/sdc2 vf=linuxdcfl.img verifylog=verify.log**
0 - 0: Mismatch
Total: Mismatch

I tried dcfldd and got a mismatch, no error log tough. verify.log is empty. hashlog just has the sha and md5 sums.

  • maybe try dcfldd instead of dd, it has verification that a target drive is a bit-for-bit match of the specified input file or pattern. – DJCrashdummy Oct 20 '16 at 5:51
  • indeed a mismatch, but no hints to what went wrong – Frank Schrijver Oct 20 '16 at 21:28
  • 1
    i can only guess the partition-table and/or the file-system got some errors or maybe the storage suffered a physical damage (but i doubt this). - have you already checked your partition-table/file-system? if you got read-errors have a look at ddrescue (package gddrescue). – DJCrashdummy Oct 21 '16 at 9:17
  • 1
    Your question does not indicate where sdd was mounted at the time you attempted to image it, but as per your comments, it apparently was. I second the answer which says to umount and make sure it stays unmounted for the duration of the imaging. – tripleee Oct 24 '16 at 4:48
  • 1
    @pbhj It's entirely possible to boot from a system with a corrupted file-system provided the area(s) of corruption aren't required for booting. – Elder Geek Oct 28 '16 at 22:36

ddhas a long history of creating exact bit for bit duplicates. diff can be used to prove this quite handily

Note: you don't mention what version of Ubuntu you are running. The only reason that makes a difference is that the status switch usage has changed.

Ubuntu 14.04 Excerpt from man dd

              WHICH info to suppress outputting to stderr; 'noxfer' suppresses
              transfer stats, 'none' suppresses all

Ubuntu 16.04 excerpt from man dd

              The  LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer' suppresses
              the final transfer statistics, 'progress' shows periodic transfer statistics

All that aside, the only things I can think of that would result in your image file having a different bit pattern than your source is either:

User Error:

A) An attempt to image a mounted partition (an exceedingly bad idea)

B) Failure to sync leaving data behind in the kernel buffer.


Hardware failure:

C) A failing area on the disk where you stored the image. This implies impending failure of the drive (I hope you have backups, if not, hop to it!)

D) A dodgy connection providing poor connectivity to either the source or target media device

You would be wise to check the smart status of the drive you stored the image on.

The fact that dcfldd also resulted in a mismatch leads me to believe that you have either a failing cable or a failing storage media (whether on the input media or the output media)


Yes, you can mount partitions inside an image using kpartx

sudo apt install kpartx
cd Images 
sudo kpartx -a orangepi.img

It will create devices under /dev/mapper and the devices should be detected by nautilus to allow their respective partitions to be mounted.

To remove the device under /dev/mapper, after unmounting the partition,

cd Images
sudo kpartx -d orangepi.img

As to why the partition differ in your case, I have no idea, of what you have done to end up with that result. It should have been the same.

  • 1
    i just avoided looking for a way to mount a image with multiple partitions. There is a solution to anything in ubuntu/linux that is not my problem. My problem is figuring out what I am doing wrong. – Frank Schrijver Oct 16 '16 at 21:52

I always avoid doing dd on individual partitions. Except for exactly the same storage medium, same size, model number...

Looks like you created a bigger partition on the new card and messed something with the inodes in the process.

You said you couldn't mount the image, but does it work as intended on the destination sd card ? It should...

I'll take a guess, you're trying to move to a bigger card. My preferred way is dd the whole card. Then boot on a live or plug in other computer, load Gparted, shrink the partition of a couple MB, then back to full size. It will reclaim the new free space and takes only 2-3 min.

  • I did try imaging the whole SD-Card to my new SD-Card, with my first two lines of "sudo dd". It ends up exactly like my screenshot. My screenshot is the mounted image(not the target SD-Card, but the same nonetheless). – Frank Schrijver Oct 22 '16 at 12:11
  • So it could be caused by the switch from SDHC to SDXC, or some wear protection happening in the old card. If you ls -i on both, it should give you different outputs. Is only the home folder affected or the whole partition ? – boutch55555 Oct 22 '16 at 13:11
  • Also, did you make sure nothing was mounted when you created or wrote the image ? sudo umount /dev/sdc1 && sudo umount /dev/sdc2 – boutch55555 Oct 22 '16 at 13:25
  • it is not a SDHC SDXC problem since the image created is already different than the SD-Card – Frank Schrijver Oct 23 '16 at 15:36

The .xsession-errors file dates and sizes are completely different between the two file listings in your picture. There is no way 'dd' will be able to do that without scrambling the entire file system beyond recognition.

You should not use dd on mounted file systems. This is kind of difficult to avoid when most systems auto-mount as soon as you plug an SD card in.

Use 'df' and 'dmesg' to find the /dev/sd_# of your SD card. Warning: There may be more than one for that SD card if you have multiple partitions on it.

sudo umount /dev/sd_#

to unmount the SD card, but it will still be connected and not ejected.

Run 'df' again to verify it has been unmounted.

You may now 'dd' to read or write to the SD card as a whole (original poster's first pair of 'dd').

Tell the system to eject the SD card. [In Ubuntu 16.04, right click on the SD card and select "Eject parent drive". They really should add "mount" and "unmount" options] If you cannot find an Eject option, run 'sync' and wait for the prompt to return to flush the write buffers before you remove the SD card.

  • I unmounted my partitions and tried imaging, same results. – Frank Schrijver Oct 23 '16 at 15:35

The SD card may have bad blocks.

'sudo badblocks -s -w /dev/sd#' on the destination SD card to run a write-mode pattern test. Be very careful about the /dev/sd#. 'badblocks -w' is DESTRUCTIVE! You might want to verify /dev/sd# against 'ls -l /dev/disk/by-id/' to be sure you have the correct block device.

I run this on all my new storage devices and any suspected bad ones. A 1 TB SATA HDD takes about 24 hours to complete one pass of -w's four patterns. An SD card will be significantly faster. I have found bad USB flash drives, SD cards, hard drives, and even a few bad USB micro-SD card readers this way.

If any bad block numbers show up, you can try to RMA the device if it's still under warranty.

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.