0

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...

Improve this question
10
  • Edit it the output of sudo fdisk -l /dev/mmcblk0. Commented Sep 24, 2017 at 15:49
  • @goldilocks Added it to the question. Commented 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 ? Commented 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. Commented Sep 24, 2017 at 17:31
  • 1
    How about trying Etcher for Linux to flash your new 16GB card. Commented Sep 24, 2017 at 19:04

6 Answers 6

Reset to default
1

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.

Improve this answer
1

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.

Improve this answer
2
  • You should read the question again. Did read the part where where I said that the command I'm using works for some cards? Commented 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. Commented Sep 29, 2017 at 12:47
1

It either your ejecting the card before the buffer is written or it's something with the hardware since they all work in another system. I agree with other previous posts; try adding the sync command to make certain the buffer is writes are completed.

Improve this answer
0

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.

Improve this answer
8
  • I get a /dev/mmcblk0 2017-08-16-raspbian-stretch.img differ: byte 4194370, line 1. How can I fix that? Commented 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/… ?? Commented 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. Commented 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. Commented Sep 25, 2017 at 19:04
  • I just bought another brand new 8GB card form a different brand. Same issue. Commented Sep 28, 2017 at 17:51
0

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

dd if=... of=... sync

instead of

dd bs=4M if=... of=... conv=fsync
Improve this answer
0

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!

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.