to write the raspiblitz image i was using etcher v1.5.71 on linux (5.3.18 kernel on manjaro) to write to samsung 16gb evo micro sd card. the write operation completed successfully, however any further operations on the card was impossible.
So i thought, well sh** happens. and picked a second card same model to write the same image, but this time on windows (win10 1909 - etcher installed w/ chocolately). the write operation completed successfully again, but any further operation on the was impossible again.
to be honest, i won’t try a third time to destroy another card. I tried to write the image w/ rufus, and the card still works…
i don’t know if it is ether, or the model of image and card combination but never had 2 working cards borked so close to each other - why can’t be just a hard coincidence.
maybe somebody else who has some spare cards, can try & confirm. in case you need additional info, please ask.
Etcher is unlikely to have killed the cards. These GNU/Linux images tend to have very peculiar partition tables (usually as hacks to make them boot on CD/DVDs and USB sticks on a large variety of hardware, see https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033495.html) which can confuse your host operating system (both Linux and Windows).
For example, Raspiblitz may mark its partition tables as read-only, and not allow you to do anything else on them. Tools like Rufus give you different results because they re-write and inject their own partition table removing some of the peculiarities along the way (while Etcher does a true byte-by-byte copy of the image).
Have you tried completely wiping out the partition tables with gparted? Do you get an error? If so, can you provide us with a screenshot?
Hi @jviotti, i thought the same, so i tried fdisk, gparted, wipe /dev/sdX, your solution to recover cards (writing the first 512kb), also on windows diskpart, GUI to manage disks, also also downloaded paragon partition manager. No luck w/ any of these tools.
all say, partition removed, but if i eject and reinsert the partition table is there.
in addition even etcher can not write successfully a second time to the same sd cards, neither rufus, nor any tools. the sdcards were working fine, and the first write operations w/ etcher were successful.
in case you have any other ideas, i’m all ears… thanks.
Hi @ffissore, the thing is that gparted shows a successful operation (dialog), however after clicking ok to close the dialog it reloads the devices, and the sdcard card show the same 2 partitions again. It is as the sdcard accepts the commands but ignores them.
Hi @garethtdavies, already running w/ sudo, and if not, it asks automatically - also visible in terminal output:
$ gparted
localuser:root being added to access control list
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
...
Could you please try to run sudo badblocks -nvs /dev/sdb, where /dev/sdb should be the sdcard deviceand provide the output? This might give us some idea on the sd card corruption.
Hi @afitzek, the result looks actually bad, basically each and every block is bad:
$ sudo badblocks -nvs /dev/sdb
Checking for bad blocks in non-destructive read-write mode
From block 0 to 15645695
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 0
...
Pass completed, 15645696 bad blocks found. (0/0/15645696 errors)
Hello, Thanks for the extra information. After discussion with engineers here, we think the most likely scenario is some kind of hardware issue (we’re quite confident that etcher is not capable of damaging the cards in this way). If you have access to other equipment, please could you try a different reader, USB socket, and perhaps a different computer altogether. I’d suggest that you try the read tests first, to see if the results are any different. You might want to then try the write again (though I can understand your reluctance to do so) - preferable with completely different hardware.
hi @srlowe, thank you for the feedback. I tried multiple card readers (~3 or so) and multiple systems (win & linux) to re-write again and 2 sdcards of same type. I really guess it is probably a combination of the image, the sd-card, and the etcher. since i don’t have a same sdcard type anymore, the test won’t be the same. i might try again at some point in time but need to purchase couple of cheap sdcards first - might take a while.
Hello, I’m sorry we weren’t able to get to the bottom of this. I hope you don’t have further problems. If you would like, it might be helpful if you would send us the make/model of the SD card reader (I think we have details of the image and sd card model in this thread). Though there are many possible factors involved, I can at least make a note of this and perhaps we could try to procure the same reader in the future.
I think that I experienced the same problem, but found the way to solve what I guess it’s what happened to all who use balena etcher. You must have Windows or some formatting OS. Download Partition Magic, I then bought the complete program (to be free of annoying problems). Balena etcher can install the bootloader for the FIRST TIME. If the SD card with Raspbian gets damaged or inoperative after you install with Balena, you cannot install the Raspbian OS installer again. Partition Magic found two partitions on every card (which later I repaired and used them again) and, back to NF windows partitions! Why? Why I don’t know. With Partition Magic go to format your cards again on FAT32 (I even formatted a 128Gigs SD card that I use for the Raspberry’s now. It is very difficult to delete the partitions that balena etcher formats and install the first time you prepare an SD card. I repaired many SD cards that I thought they were damaged forever. Please read carefully here. I am not an English Language born person.
Thank you for sharing your solution, although I think the issue above is a different one.
As for “why are there two partitions”: the partitions you find on the flashed target are exactly what the image you just flashed is composed of, since all that Etcher does is write byte-to-byte the chosen image