Last week I flashed Raspbian Buster image to a very old SanDisk 8gb card (slow) using win32diskimager on windows 10, it worked just fine on my new RPI4B-1GB board - and its still functional ...

Steps followed : 1) format SD card on windows as a FAT32 volume 2) flash 2019-07-10-raspbian-buster.img via win32diskimager

This 8gb card boots just fine in the new RPI-4B and older RPI-3B+.

I am now following the same procedure with the exact same Buster image (week-old and downloaded fresh) on 3 Sandisk 16GB ultra SDHC 1 cards for more disk space and none of them boot either in the new RPI-4B nor the older RPI-3B+ boards.

On the old RPI-3B+ - just the red power led stays on - no activity on green led - no hdmi output. On the new RPI-4B - as the red power led stays on the green led starts flashing 4 times periodically - no hdmi output.

All the 4 cards had old RPI3 images ( they mounted 2 partitions - boot and root when connected to the usb ports on windows 10 laptop). While the first format+flashing of 8gb card was successful right away, the other 16gb have been FAT32-formatted and buster-image-flashed multiple times.

Also 1) The cards are not corrupt. 2) I can format all of them to NTFS and access their full capacity that way 3) they all had bootable ubuntu-mate RPI 3B+ images on them earlier.

while I strongly suspect its a boot-sector corruption/alignment issue, I am totally stumped on this inexplicable issue...

what could be causing the problem here ? what else can I try?


  • "the other 16gb have been FAT32-formatted" -> There's at best no point to doing that before flashing a Pi image to them. The image is a device image and replaces any formatting that's on the card. What's on the card before you burn the image to it is totally irrelevant, unless it is something that makes some tool you are using choke.
    – goldilocks
    Aug 11, 2019 at 15:03
  • 1
    My cure is the following: (1) SD Formatter 4.0 to over write format (not quick format, and it takes a very long time), (2) Win10 built in utility standard format (again not quick format, but overwrite format which takes a long time, (3) Then use Win32 Disk Manager. I always use SHA256 hashing, just in case.
    – tlfong01
    Aug 12, 2019 at 0:37
  • "no html output" - huh? you mean hdmi :p also 4 flashes: start.elf not launch-able (corrupt) - so, thats the problem, not sure what the solution is Aug 12, 2019 at 1:16
  • @goldilocks yep - I am aware of it but since I am on windows and not using dd, the drive is not recognized by win32diskimager if its not formatted once on windows.
    – sith
    Aug 12, 2019 at 6:30
  • @JaromandaX yep hdmi - thanks for catching it! I corrected it. well I guess thats the issue and the boot and root partitions dont mount on windows cleanly as the working 8gb does.
    – sith
    Aug 12, 2019 at 6:32

1 Answer 1


I found a new recommended imager Etcher recommended by @HawaiianPi in this SD Cards issues thread.

Etcher was able to image all the 3 cards without any hiccups and all 3 cards are booting in pi4 now.

Win32DiskImager still doesnt work for me on the Buster image on the 16gb cards.

Also etcher detected all the sd cards as having around 15.5 GB while both Windows format util and sdformatter4 always detected the capacity to be around 14.4 GB. [UPDATED: I guess this is not an issue as per goldilocks below]

This SD Cards issues thread also says

Etcher is the preferred copier now as the win one is OLD


Note: that Win32diskimager does NOT do any image or write validation. When you write a card with Win32diskimager you really don't know if the resulting card is good or bad (even if it boots, it could have problems elsewhere). For example, Win32diskimager will happily write images to fake cards with less capacity than the image file. The write will complete without error, but all files above the real capacity will be corrupt.

  • "15.5 GB [vs.] 14.4 GB" -> This is actually the difference between GB (1000 * 1000 * 1000 bytes) and GiB (1024 * 1024 * 1024 bytes); 15.5 of the former is 14.4 of the latter, but using GiB is mildly contentious and probably also purposely avoided on some consumer tools to prevent immediate confusion (and instead create some delayed confusion...). In any case the widespread practice of using GB for both units is well, still widespread.
    – goldilocks
    Aug 13, 2019 at 10:50

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.