All I can say then is to turn on verification in Etcher and try to reimage (assuming the SHA matches in the first place). When mine died, I could format/image and it would say it would show success, but when I pulled the card out, reinserted, it still showed the data that was on the card prior to the last operation. I’ve had to trash 3-4 cards now due to that same issue over the past few years. Frustrating to say the least, almost like some internal fuse burned to read-only.
1 Like
Since using decent quality, large capacity cards, I haven’t had any problems whatsoever.
SanDisk High Endurance Video Monitoring Card Micro SDXC 64GB
There is some mechanism for card ‘locking’ that exists, but I’m not sure how it gets engaged on microsd cards. The larger format SD cards have/had lock switches on the side whereas microsd’s don’t. I can only assume some sort of power glitch may in fact flip an internal fuse somehow under the right (wrong) conditions. Information is tough to come by in this respect.
No idea if this works…
https://www.diskpart.com/articles/sd-card-write-protected-but-not-locked-1984.html
SD/SDHC/SDXC memory cards have a “Protected Area” on the card for the SD standard’s security function. Neither standard formatters nor the SD Association formatter will erase it. The SD Association suggests that devices or software which use the SD security function may format it.
Card password
MicroSD to SD adapter (left), microSD to miniSD adapter (middle), microSD card (right)
A host device can lock an SD card using a password of up to 16 bytes, typically supplied by the user. A locked card interacts normally with the host device except that it rejects commands to read and write data. A locked card can be unlocked only by providing the same password. The host device can, after supplying the old password, specify a new password or disable locking. Without the password (typically, in the case that the user forgets the password), the host device can command the card to erase all the data on the card for future re-use (except card data under DRM), but there is no way to gain access to the existing data.
Windows Phone 7 devices use SD cards designed for access only by the phone manufacturer or mobile provider. An SD card inserted into the phone underneath the battery compartment becomes locked “to the phone with an automatically generated key” so that “the SD card cannot be read by another phone, device, or PC”. Symbian devices, however, are some of the few that can perform the necessary low-level format operations on locked SD cards. It is therefore possible to use a device such as the Nokia N8 to reformat the card for subsequent use in other devices.
I have tried to directly copy iso files of various sizes to microSD card (No etcher or Win32DiskImager) . Found only files 3.8 GB or less can be copied. For iso files of higher size such as 4.5 GB or 6 GB, got following message, although the microSD card was showing “14.9 GB free of 14.9 GB”.
File size limit for Fat32 is 4GB.
1 Like
OK, tonight I will fire up Ubuntu 20, format microSD card as single 16 GB ext4 partition, and try to copy 13 GB fabian64.iso. If that fails, will try 6 GB Kali Linux .iso
EDIT:
Instead of trying in Ubuntu as above, I will again try to copy-paste in Windows, but this time not one, but several 3.8 GB files, one by one, and see how many I can copy-paste. This is easier.
I’m not following what you are trying to do? If trying to test the card, why not go back to H2Testw since it does just that, fills the card (if specified) and then verifies the written data - that’s what it was written for besides speed testing - it doesn’t lie.
I have already done H2Testw, and it showed all OK. Anyway, tonight or tomorrow morning I will repeat it.
Then I would venture to guess that either the image you burned onto the card is bad (did you match SHA-256?) or something went south during the write process. Be sure to double-check the SHA of the ISO against the source and enable write verify on Etcher and try again?
There is a reason most legit sources come with a SHA-256 checksum for instance:
If running Winblows, HashMyFiles is a decent app to have installed since you can enable it through cmdline when your right-click a file for quick verification:
If on Linux, simply use ‘sha256sum {filename}’
1 Like
Thanks for the advise. I will do SHA-256 checksum and verify after write.
The strange thing is that I have tried two images raspios-arm64 and raspios-armhf, and in both cases this microSD card failed to boot. May be card reader which I used for burning image has gone bad? I will try another card reader.
Not sure. Just trying to help you debug the issue from the top down. Step one is to make sure you’re working with a proper/verified image, then to make sure it gets written correctly and go from there.
It could be the card, but best to make sure the prerequisites are in order first.
I chased my own tail in the past for hours and it came down to a bad image that failed SHA. Had I made it a habit to check that first… Perhaps one person can learn from my mistakes. 
1 Like
Well most person like me learn the hard way… by falling in a ditch 
Wrote same image, using same card reader, plugged into same USB slot of Desktop, BUT a different microSD card. Worked perfectly well.
Tried another image on trouble giving card and another card. Other card will boot, trouble giving card wont boot.
This eliminates Image, card reader, and USB slot in Desktop from list of possible candidates, leaving only the troblemaking microSD card as the cause.
Made one more attempt by wiping MBR (MBR = /dev/hdX, and not /dev/sdX), then imaging again, wont boot. No use wasting more time,I will throw it into trash can.
Wipinging MBR of microSD card
abcd@kali2020:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 32G 0 disk
├─sda1 8:1 0 31G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 975M 0 part [SWAP]
sdb 8:16 1 15G 0 disk
└─sdb1 8:17 1 15G 0 part
sr0 11:0 1 1024M 0 rom
abcd@kali2020:~$ sudo dd if=/dev/zero of=/dev/hdb bs=446 count=1
1+0 records in
1+0 records out
446 bytes copied, 0.000204513 s, 2.2 MB/s
I disagree, how?
Sounds like a bad card, but still don’t see any SHA checks for the helluvit. Need to get in that habit and not work around it, takes 3 seconds to verify that your image is good and be done with it - never to guess again. I don’t think you have a bad image from what you described above, but good to check regardless. I’ve had to trash a few cards myself, it sucks.
Thanks for the advise. I have never done SHA checks. Will google to find out how to.
Browse up about 7 posts mate
Thanks @Nitr0. Have somehow missed it, now found it after you pointed to it.
Download HashMyFiles for 64-bit systems