6

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
$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
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 though. verify.log is empty. hashlog just has the sha and md5 sums.

9
  • 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. Oct 20, 2016 at 5:51
  • 1
    indeed a mismatch, but no hints to what went wrong Oct 20, 2016 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). Oct 21, 2016 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, 2016 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, 2016 at 22:36

6 Answers 6

5
+50

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

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

Ubuntu 16.04 excerpt from man dd

status=LEVEL
              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.

or

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)

1

This is a comment on how fragile SD/microSD chips can be.

I used the above comment about badblocks^^ to test 2 new 512GB microSD chips. Given their size, I went with a USB 3.0 card reader on a USB 3.0 port. The chips got hot, really hot. I then did a benchmark using Disks to confirm their speed, using my standard test of 1000 samples (rather than the standard 100), again on USB 3.0 reader/3.0 port. 1 passed, the other got to ~600 samples and the write speed dropped from ~90 MB/s to under 20 MB/s. That write speed didn't change back, so I think I "burned"^ the chip because of the power available on a USB 3.0 port.

Given that the badblocks is an intensive, full disk, write/read process that takes a long time I would suggest using a USB 2.0 card reader, or preferably a USB 3.0 card reader on a USB 2.0 port, to minimize the possibility of burning out a large (expensive) chip. It will take longer, but so what. I would then recommend using the standard Disks 100 samples to benchmark (USB 3.0 reader/USB 3.0 port).

I (unfortunately) used a number of smaller 128GB microSD chips to determine the above procedure. Most of which went back under RMA for having failed my testing. These chips just aren't as robust as even USB 3.0 thumb-drives, so caveat emptor.

^ By the way, if you are on a USB 3.0 card reader/USB 3.0 port and your chip is taking a lot longer than another chip of the same size, it may already be "burnt".

^^Taken from the comment I got the usage of badblocks from:

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.

0

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
  • 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. Oct 16, 2016 at 21:52
0

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.

4
  • 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). Oct 22, 2016 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 ? Oct 22, 2016 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 Oct 22, 2016 at 13:25
  • it is not a SDHC SDXC problem since the image created is already different than the SD-Card Oct 23, 2016 at 15:36
0

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.

1
  • I unmounted my partitions and tried imaging, same results. Oct 23, 2016 at 15:35
0

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.

You must log in to answer this question.

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