(Attempting to) fix a corrupted microSD card

Get Help Guides
1

From time to time I've been gathering bad microSD cards. I tend to just push them into a particular drawer and replace them with a new one.

Okay, so now how do you resurrect it?

  1. Try to reformat it as the first course of action. Usually this works out great.
  2. Try to use Etcher, for example, to burn a new image to it. Again, this often works.

Unfortunately, there are times when I've lost power to a Raspi which was doing a timelapse and it's just really not happy after that. The microSD is so trashed it won't boot. Furthermore, I've got at least one that won't come up in Disk Utility on the Mac which is usually a bad sign.

  • Insert the microSD into an SD adapter and into the MacBook in this case
  • ls /Volumes shows me that there's a /Volumes/boot which corresponds to the first partition of the microSD so at least it shows up
  • diskutil verifyVolume boot
Started file system verification on disk2s1 boot
Verifying file system
Volume is already unmounted
Performing fsck_msdos -n /dev/rdisk2s1
** /dev/rdisk2s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
** Phase 3 - Checking for Orphan Clusters
Free space in FSInfo block (42580) not correct (42581)
Fix? no
165 files, 21290 KiB free (42581 clusters)
File system check exit code is 0
Restoring the original state found as unmounted
Finished file system verification on disk2s1 boot

Okay, so upon inserting the SD, it didn't auto-mount since there is an error. It didn't auto-correct the error since I just told it to verify.

  • diskutil repairvolume boot
Started file system repair on disk2s1 boot
Repairing file system
Volume is already unmounted
Performing fsck_msdos -y /dev/rdisk2s1
** /dev/rdisk2s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
** Phase 3 - Checking for Orphan Clusters
Free space in FSInfo block (42580) not correct (42581)
Fix? yes
165 files, 21290 KiB free (42581 clusters)
File system check exit code is 0
Restoring the original state found as unmounted
Finished file system repair on disk2s1 boot

It appears as though it fixed it. I note that it's not mounted. I remove/re-insert, the condition seems the same (bad) and the verify reports the same FSInfo error as before.

  • diskutil list /dev/disk2
/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.9 GB     disk2
   1:             Windows_FAT_32 boot                    45.2 MB    disk2s1
   2:                      Linux                         7.9 GB     disk2s2
  • diskutil eraseDisk FAT32 ERASED /dev/disk2 in a brute-force method of formatting the entire disk, noting that I'm using the disk2 disk name rather than the volume name of disk2s1, for example.
Started erase on disk2
Unmounting disk
Creating the partition map
[ \ 0%..10%..20%..30%..40%..50%.......................... ] 50.0% 
diskutil: interrupted

After watching this grind away for some time as stuck on 50%, I realize that the Mac really doesn't have an out-of-the-box driver for that EXT4 partition so it's a little unprepared for this.

Version 2 with Ubuntu and gparted

Alright, so that was frustrating. But I move this over to an Ubuntu laptop which has gparted installed on it. I fire up gparted and verify the drive(s) I have before inserting the microSD: just /dev/sda.

I insert the microSD and refresh devices, noting that I now have a /dev/sdb with two paritions. This time, I see that /dev/sdb2 has a red-circled exclamation point next to it. Right-mouse clicking and selection Information, I see the details of the warning:

5.65 GiB of unallocated space within the partition...

This may not be the cause of the previous problem but it's alerting me that the volume was never expanded in sudo raspi-config. I note that I inherited this microSD from the printer manufacturer.

Ignoring, I carefully delete both partitions and click the checkmark icon at the top to apply. I then receive a Libparted error: Input/output error during write on /dev/sdb.

At this point, I chalk this one up to the known-bad set of microSD cards that the 3D printer manufacturer was sourcing which have some sort of underlying fault. I don't believe that there is any means of resurrecting this particular one. I at least have more confidence in the process I'm using.

Next microSD

The next microSD to test doesn't show up on either the Mac or in Ubuntu at all. I try different ports for the USB adapter version of this—still nothing.

At a command line in Ubuntu it does show up as /dev/sdb when it's plugged in; this is gone when it's removed. An lsblk does not show the device. A sudo parted /dev/sdb returns "Error: Error opening /dev/sdb: No medium found".

Conclusions

There are times when I have successfully reformatted a problematic microSD. Today wasn't one of those times; these two cards probably want to be tossed. I'll hold onto one of them since I'm stubborn. If I come up with something clever, I'll share it here.

2

I have a suggestion that you might try on the first SD you worked on...

It's a bit of a truly brute force method that I've previously used successfully in the opposite of what I'm about to suggest

What I've done to recover data from a failed disk is to to a linux dd command and write everything from the failed disk to a good one. The success rate varies depending on the damage

What I would try is just the opposite. Image a known good SD card of the same size with raspbian, or Octopi or something, then mount the bad one, and dd the image onto the bad one

It might work, it might not. You're copying data bit for bit this way, so, it might just jump over bad spots. or not

You've got nothing to lose by trying at this point

3

I considered that and I'm comfortable with dd.

Also, another good one is to pop it into a camera like my Nikon. They don't write very sophisticated error-checking routines in those, typically. Determining that it can't read from the card it then offers you an opportunity to reformat.

Unfortunately that failed on both cards as well.

4

Another factor you probably should take in account is the card reader.
Recently I had some cards which were not recognized on my desktop-pc (via usb card reader) but works without problems with the build-in card reader on my notebook (both machines with Linux Mint).

5

And it goes without saying that occasionally the little write-protect tab gets partially slid on the SD adapter, preventing updates.

In this case, I tried two different adapters/types.

6

When I get an adapter with a loose write protect slider, I just put a dab of superglue on the slider to keep it in the write-enabled position.

1 Like