11

I'm running into an issue where if I attempt to flash a microSD card with

sudo dd bs=4M if=some_pi_image.img of=/dev/sdb

It claims to have written the image at about 1.9 GB/s, with output:

1088+0 records in 1088+0 records out 4563402752 bytes (4.6 GB) copied, 2.59837 s, 1.8 GB/s But has definitely not written to the card.

Stranger still, when I run "sync" after the dd command it returns pretty much immediately. However it's verifiable that when I put the SD card in my pi and boot it up, it's running the old image, and essentially has flashed nothing to the card. I'm careful to umount all /dev/sdbX partitions before running the dd command.

Just for grins I took the microSD card out of the adapter and ran DD again, and got the exact same result, though I know "sdb" is the correct designation, as i can unplug the usb adapter and /dev/sdb will stop showing up when I run "ls /dev/".

I've tried this across 2 cards (one that came with the pi, raspberry symbol and all) and 3 adapters. Running Ubuntu.

Why would "sync" be returning immediately, and nothing be written to the actual SD card?

Improve this question
4
  • Welcome to Raspberry Pi. Please, what is your question?
    – MadMike
    Feb 22, 2017 at 20:05
  • Edited to explicitly ask the question :D
    – Alexander Lucas
    Feb 22, 2017 at 20:31
  • I'm using dd regularly and never encountered anything like it. Nothing seems to suggest that copying from some_pi_image.img to /dev/sdb produced an error, except that your SD-card doesn't show the data you expect. I don't use sync at all so I don't know how long it should take to finish after a big copy job. I'm unsure how one would reproduce your problem...
    – MadMike
    Feb 22, 2017 at 21:09
  • have a look at the output of dmesg or the log file /var/log/syslog, I would guess that your uSD card is locked or gone bad, or your adapter supplies multiple /dev/sd? entries, and you're not accessing the correct one. See output of sudo fdisk -l to find uSD card.
    – lornix
    Feb 22, 2017 at 21:23

5 Answers 5

Reset to default
6

I had this problem and it turned out to be a faulty sd card. I tried to delete partitions and reformat the sd card but it plain refused. Use another sd card and it was fine.

Improve this answer
1
  • I've also seen this happen once, though I forget the brand of the card. A new card worked fine.
    – Dave W. Smith
    Sep 2, 2018 at 20:47
9

Late to the party, but I had the same issue today:

$ sudo dd if=output/images/sdcard.img of=/dev/mmcblk0 bs=2M status=progress
66+1 records in
66+1 records out
138412544 bytes (138 MB, 132 MiB) copied, 0.0644025 s, 2.1 GB/s

As it turns out, sometimes the device file /dev/mmcblk0 does not get deleted when the SD card is removed, and when the device is plugged in, it is not updated as such and no other /dev/mmcblk file is created; I have not yet found the root cause for this. This meant that the dd command was simply firing data at a file not tied to a device.

I removed the card, deleted /dev/mmcblk0 by hand (rm /dev/mmcblk0), and re-inserted it. The card was now functioning. So I would caution anyone immediately jumping to the conclusion of a bad SD card. If this issue is occurring, /dev/mmcblk0 will persist after the card is unplugged.

Improve this answer
5
  • 3
    It's not a bug, it's a misunderstanding. That dev node is not hardwired to the physical slot on your computer. If it persists after you remove the card and you then re-insert it, the card will now be, e.g., mmcblk1 (vs. 0). A device is an abstract concept, so "firing data at a file not tied to a device" might be better phrased, "firing data at the wrong device", wrong meaning not the one you thought it was. "...deleted /dev/mmcblk0..." -> In future don't do that.
    – goldilocks ♦
    Dec 8, 2018 at 21:03
  • I checked for existence of other /dev/mmcblk files though and there were no others, the partition device files /dev/mmcblk0p1, /dev/mmcblk0p2 were always created in the same place as well, however they disappeared when the SD card was removed.
    – JMercer
    Dec 8, 2018 at 21:22
  • My dmesg output while this was occurring: [429752.591765] mmc0: card aaaa removed [429756.825526] mmc0: new high speed SDHC card at address aaaa [429756.826103] mmcblk0: mmc0:aaaa SL16G 14.8 GiB [429756.828492] mmcblk0: p1 p2
    – JMercer
    Dec 8, 2018 at 21:24
  • 2
    What does "I deleted /dev/mmcblk0 by hand" mean? Without a command or some type of hint, this answer is not useful to anyone who doesn't already know how to do everything you suggested.
    – Anthony
    Mar 13, 2019 at 22:30
  • You really think someone who's using dd doesn't know how to use rm? Updated the answer anyway.
    – JMercer
    Mar 22, 2019 at 20:19
5

Had the same problem with this:

dd bs=4M if=2018-04-18-raspbian-stretch.img of=/dev/sdX conv=fsync

But it worked by dropping the fsync

dd bs=4M if=2018-04-18-raspbian-stretch.img of=/dev/sdX
Improve this answer
3

I had the same problem. In addition, I found out that removing the old partitions on the SD card using fdisk did not do anything either, which is a quicker test than trying dd again. I was able to create a file using touch this_is_partX in the root of each mounted partition on the SD card, which is useful to check 1) if the SD card is still functional and writeable, and 2) if a subsequent reinstall of the pi image actually worked and overwrote these files.

The fix turned out to reboot the linux pc used for installing the image to the SD card. After the reboot, the dd command took about twice the time, and really wrote a fresh image on the SD card.

Improve this answer
0

One more option to consider, is that to make sure you have the device name correct. For example I discovered I was doing dd of=/dev/mmblk0 which was showing files data written to that location. However, I finally noticed that the device path was /dev/mmcblk0.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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