I have a couple of Micro SD card here and it seems like only some of them can be flashed correctly. No errors during the flashing process, but only the boot partition turns out to be mountable on my Linux computer and so the RPi fails to boot it (Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)).
At first I assumed that the issue was just with a very old card that I had lying around (broken sectors or something like that).
But now I have bought a brand new 16GB MicroSD card (SanDisk 16GB 80MB/S), and I get the exact same result: Flashing seems to work, but only the boot partition becomes mountable.

I flashed using:

sudo dd bs=4M if=2017-08-16-raspbian-stretch.img of=/dev/mmcblk0 status=progress conv=fsync

4907335680 bytes (4.9 GB, 4.6 GiB) copied, 397.067 s, 12.4 MB/s
1170+1 records in
1170+1 records out
4907675648 bytes (4.9 GB, 4.6 GiB) copied, 452.665 s, 10.8 MB/s

and then I also I also tried:

sudo dd bs=1M if=2017-08-16-raspbian-stretch.img of=/dev/mmcblk0 status=progress conv=fsync

4906287104 bytes (4.9 GB, 4.6 GiB) copied, 399.06 s, 12.3 MB/s  
4680+1 records in
4680+1 records out
4907675648 bytes (4.9 GB, 4.6 GiB) copied, 451.091 s, 10.9 MB/s

Using the lite image instead didn't make a difference.

I also bought a new cheap Fujitsu card that only has 2GB and that card flashed just fine.

My Micro SD cards:

  • A very old Vertatim 2GB card (flashing etc works fine)
  • A very old SanDisk 8GB card (flashing etc doesn't work correctly)
  • A new Fujitsu 2GB card (flashing etc works fine)
  • A new SanDisk 16GB card (flashing etc doesn't work correctly)

It almost seems like there are issues with cards bigger than 2GB.

What am I doing wrong?

Edit: The output of sudo fdisk -l /dev/mmcblk0:

Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 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
Disklabel type: dos
Disk identifier: 0x242ad76d

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk0p1       8192   93814   85623 41.8M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      94208 9585303 9491096  4.5G 83 Linux

Edit 2:

Output of sudo cmp /dev/mmcblk0 2017-08-16-raspbian-stretch.img

/dev/mmcblk0 2017-08-16-raspbian-stretch.img differ: byte 4194370, line 1

Edit 3: I just bought another 8GB Micro SD card, this time from the brand 'Intenso'. - Same issue with that card.

Edit 4: Tried it with Etcher instead of dd. - Same results.

Edit 5: I tried it with dd on a different computer and it was able to correctly flash all my cards. But I still need this to work on my system...

  • Edit it the output of sudo fdisk -l /dev/mmcblk0.
    – goldilocks
    Sep 24, 2017 at 15:49
  • @goldilocks Added it to the question.
    – Forivin
    Sep 24, 2017 at 16:03
  • What software are you using to flash your cards ? I currently use Etcher on my Mac. Which model RPi ? What spec PSU ?
    – CoderMike
    Sep 24, 2017 at 16:18
  • The root filesystem on that card has been expanded to 4.5 GB. Just copying an image would not do that. This implies it booted once and raspi-config or some such expanded it automatically. You could run fsck on it and/or mount it to see what's there.
    – goldilocks
    Sep 24, 2017 at 17:31
  • 1
    How about trying Etcher for Linux to flash your new 16GB card.
    – CoderMike
    Sep 24, 2017 at 19:04

5 Answers 5


To be sure that all writes are done after a dd, be sure to use the command sync. Once sync command brings back the prompt, you can then eject the SD card, never before. Some SD may takes more time to write their buffer and ejecting before all writes are done just corrupt it.

If you properly sync your SD card and still endure issue, this may be related to the hardware, maybe a faulty SD card. You can check if the kernel doesn't provide I/O error with sudo dmesg.


If you are executing those commands on a running RPi, you are writing to the running system (of=/dev/mmcblk0) unless I'm missing something in your explanation. I'd expect your command line to look like:

sudo dd bs=1M if=2017-08-16-raspbian-stretch.img of=/dev/sda status=progress conv=fsync

Targeting a card mounted in a reader at /dev/sda as the target for writing.

  • You should read the question again. Did read the part where where I said that the command I'm using works for some cards?
    – Forivin
    Sep 29, 2017 at 9:24
  • I read it. I'm pointing out that you are not using what sounds like the normal procedure. It working sometimes but not others does not mean it's working properly. It might be worth trying what's suggested. Unless you want to keep trying the same thing to see if you get different results.
    – bobstro
    Sep 29, 2017 at 12:47

Check the image after writing it and see if it verifies.

Do your normal copy:

sudo dd bs=4M if=2017-08-16-raspbian-stretch.img of=/dev/mmcblk0 status=progress conv=fsync

4907335680 bytes (4.9 GB, 4.6 GiB) copied, 397.067 s, 12.4 MB/s
1170+1 records in
1170+1 records out
4907675648 bytes (4.9 GB, 4.6 GiB) copied, 452.665 s, 10.8 MB/s

Then see if the written image is the same as the download:

$ sudo cmp /dev/mmcblk0 2017-08-16-raspbian-stretch.img
cmp: EOF on 2017-08-16-raspbian-stretch.img

If you get the EOF message, then verification has succeeded and the image on the card seems to match the download. Normally I'd suggest verifying the image itself (checksum or such), but you are saying that writing the image to other cards works. So that seems to point to the image being okay.

If the card is having a problem, then you should get a message about the first location where there is a difference between the two.

  • I get a /dev/mmcblk0 2017-08-16-raspbian-stretch.img differ: byte 4194370, line 1. How can I fix that?
    – Forivin
    Sep 25, 2017 at 6:48
  • @Forivin, that failed right after the 4 MB mark. Have you tried using this card for anything else (like storing music or something), or is it "brand new"? I suspect it's either a bad card or possibly a fake. Maybe check askubuntu.com/questions/737473/… ??
    – BowlOfRed
    Sep 25, 2017 at 7:22
  • The card is brand new and directly from Amazon. I highly doubt they would send me a fake. The other card that didn't work has been used for storing other things, but that shouldn't really matter because my old 2GB card has also been used to store things like music and that card flashed just fine. I find it hard to believe that this brand new 16GB card and my old 8GB card have the exact same issue. That seems pretty unlikely.
    – Forivin
    Sep 25, 2017 at 15:26
  • All I can suggest is to test the card through some method other than the imaging process. Right now it's saying that the data being read from the card is not the same as the data that should have been written.
    – BowlOfRed
    Sep 25, 2017 at 19:04
  • I just bought another brand new 8GB card form a different brand. Same issue.
    – Forivin
    Sep 28, 2017 at 17:51

I came here having similar problems: One card flashing fine, one failing repeatedly. It finally worked when I did

dd if=... of=...

instead of

dd bs=4M if=... of=... conv=fsync

I just encountered the same problem and I finally succeed after using a microsd adapter to flash directly instead of using a sd to microsd adapter in between. Hope that helps!

Your Answer

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

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