I am running Ubuntu 18.04.1 in a Virtual Machine (VMWare) on a Windows host. I am trying to zero out an entire SD card using dd. This is part of the process I use to release embedded Linux to the software group (SD card images compress much better when the empty FS data is all 0).

The command I am using is: sudo dd if=/dev/zero of=/dev/sdc bs=4M status=progress and it completes successfully; I get the printout of records transferred, and a message saying no space left on device. If I then do a sudo cat /dev/sdc | hexdump to look at the disk contents though, the disk is still full of data and isn't zeroes (and not just at the end).

Do I have to specify the number of bytes of the SD card for it to work consistently? I don't have this issue every time I zero out an SD card.

Complete console output:

gen-ccm-root@ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdc bs=4M status=progress
15929966592 bytes (16 GB, 15 GiB) copied, 1274 s, 12.5 MB/s
dd: error writing '/dev/sdc': No space left on device
3799+0 records in
3798+0 records out
15931539456 bytes (16 GB, 15 GiB) copied, 1274.19 s, 12.5 MB/s
gen-ccm-root@ubuntu:~$ sudo cat /dev/sdc | hexdump
[sudo] password for gen-ccm-root: 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0101000 2004 0000 6004 0000 0000 0000 0000 0000
0101010 0000 0000 0000 0000 0000 0000 0000 0000
0101400 2005 0000 6005 0000 0000 0000 0000 0000
  • 2
    Can you try the same with badblocks -t 0x0000 -sw /dev/sdc (dangerous, it will write zero data too) Mar 21, 2019 at 16:06
  • Your question makes sense until “I don't have this issue every time I zero out an SD card.” I then wonder if I miss-read the start. Do you mean “I don't have this problem every time”? Mar 21, 2019 at 17:02
  • 2
    I didn't actually know badblocks existed, which is a good thing to learn. Correct I don't have this issue every time. Today was the first time that it has been consistent. badblocks is slow, but if I am reading the output correctly (7234624 done, 39:10 elapsed. (0/0/2417408 errors)) it looks like my SD card might be toast (A different question implies the last number is corruptions), which is unfortunate since it was new less than a week ago. I guess I just got lucky since I have been burning new kernels on it for the past week and they all worked fine.
    – Eskimoalva
    Mar 21, 2019 at 17:09
  • 1
    Yes it is probably lost, but before saying this try with another sd card or in another machine. RAM errors can cause this too, because it will compare a value stored in RAM with a value found in the sdcard. It may run almost eternally depending on the damage you are experiencing the command dmesg will show important informations too. Mar 21, 2019 at 18:37
  • 1
    I jsut got another new SD card and it appears to be working fine.
    – Eskimoalva
    Mar 21, 2019 at 19:03

2 Answers 2


As said in the comments, the sdcard was with badblocks.

The solution I proposed was to run:

badblocks -t 0x0000 -sw /dev/sdc

CAUTION: this is data destructive like dd if=/dev/zero.

And the user received something like:

7234624 done, 39:10 elapsed. (0/0/2417408 errors)

Showing the sdcard was damaged.

The sdcard was replaced and the problem was solved.

  • @sourcejedi I did not understand what you say, my first language is Portuguese. What do you mean? Mar 21, 2019 at 20:54
  • 0/0/2417408 means no write errors, no read errors, but the data returned by 2417408 reads did not match the data that was written. But, that's what we already saw in the question :-).
    – sourcejedi
    Mar 22, 2019 at 0:17
  • 1
    By that logic we did not need to run badblocks. It was just another way to run the same test. But apart from that, the principle is good, I agree with the conclusion you reached.
    – sourcejedi
    Mar 22, 2019 at 0:23
  • @sourcejedi Thanks +1 for your comment. I still would use badblocks, it is a tool made for that dd stops when the first bad block was found, as I experienced a lot of times, but badblocks will run the entire disk, so, sometimes you will see only 1 badblock for a device (considering that you probably have more, as if it is impossible to reallocate). Mar 25, 2019 at 0:07


sudo fdsik -l

and see result for example:


it's maybe different in your output!

now you should use:

sudo dd bs=4M if=exmple.img of=**/dev/mmcblk0** conv=fsync status=progress
  • Why are you reading from what looks like a filesystem image? What difference does the conv setting do? Why do you think they're using the wrong device to write to?
    – Kusalananda
    Mar 21, 2019 at 19:20

You must log in to answer this question.

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