I had a power outage that left my RPi behaving strangely - hanging after specific set of command and similar. I have removed the SD card, plugged it via SD card reader to my computer, mounted and tried copying the files from it. Most of the files get copied without problem, but some of them only get copied up to a point (always the same), after which I get I/O errors. This renders SD card unusable - any subsequent reading of the SD card results in I/O errors, even for other files. Remounting SD cards makes it readable again, but any attempt to read the broken files makes it unusable again. Reading other files seems to work reliably.

Copying the whole partition with dd has similar effects - I get I/O error after which system no longer finds /dev/sdd.

e2fsck finds nothing:

# e2fsck -f /dev/sdd2 
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 50998/916864 files (0.6% non-contiguous), 2383924/3769856 blocks

My questions are:

  • how can I save the broken files?
  • how can I "mark" the broken sectors so that system avoids them?
  • should I throw away the SD card, or is this just data error that can be fixed?

Thank you in advance.

P.S.: the data is not crucial (I do have backups, just not completely recent), but still... :)

EDIT: running e2fsck -c doesn't help much because the card disappears after first error:

# e2fsck -c /dev/sdd2 
e2fsck 1.42.13 (17-May-2015)
e2fsck: No such file or directory while trying to open /dev/sdd2
Possibly non-existent device?
root@A6:/opt/backup/rpi.crash/trade1# e2fsck -c /dev/sdd2 
e2fsck 1.42.13 (17-May-2015)
Checking for bad blocks (read-only test): done                                                 
rootfs: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Group 14's block bitmap (458752) is bad.  Relocate<y>? no
Group 15's block bitmap (458753) is bad.  Relocate<y>? no
Group 14's inode bitmap (458754) is bad.  Relocate<y>? no
Group 15's inode bitmap (458755) is bad.  Relocate<y>? no
Group 16's block bitmap (524288) is bad.  Relocate<y>? ^C
rootfs: e2fsck canceled.

rootfs: ***** FILE SYSTEM WAS MODIFIED *****

rootfs: ********** WARNING: Filesystem still has errors **********

# e2fsck -c /dev/sdd2 
e2fsck 1.42.13 (17-May-2015)
e2fsck: No such file or directory while trying to open /dev/sdd2
Possibly non-existent device?

EDIT2: my main problem is that I can't touch some of the sectors, because SD card disappears when I do (and I must plug SD card reader to another USB port so I can work with it again). Kingston 16 GB class 10 if it matters, 6 months old (10y warranty, no receipt).

  • 1
    ddrescue will skip unreadable sectors. It was designed for scenarios where dd will fail.
    – flakeshake
    Jun 17 '18 at 7:19
  • Thanks, didn't know that! I'll give it a shot...
    – johndodo
    Jun 17 '18 at 8:29


I strongly suggest using Linux for this. Install ddrescue (it's better than plain dd ) and make an complete image of your card. Save it somewhere and create a second copy. Open the image with kpartx. Use PhotoRec to rescue your files.

An SD card should never have bad blocks. Why ? Because there is a controller which does wear levelling and can address hidden backup blocks. Your symptoms look like there is not even enough over-capacity left to perform wear leveling on !

20 years ago i would have suggested using badblocks. Now i would fear that it would trigger the controller do do more and more wear leveling which will further damage your card.

You cannot trust your SD card anymore if even reading fails ! Marking bad blocks makes no sense if the real bad blocks will and can be hidden by the controller. I believe your SD card is simply done for. Sorry.

  • Well, yeah, I did make a backup... of what I could read. :( The irony is that the card is not even half full (not that SD card controller knows it, but still). Do you happen to know the answer to my questions?
    – johndodo
    Jun 17 '18 at 6:57
  • The damage of the files may have occurred after writing them and must not be necessary lack of "backup" sectors. Just copy the corrupted files (if it is possible) may fix everything. The controller can then mark the corrupted sectors copied from.
    – Ingo
    Jun 17 '18 at 7:01
  • @Ingo I'm not sure what you had in mind? My main problem is that SD card disappears as soon as I touch the broken sectors, so I have no idea how to solve this. Note that saving data is not the highest priority (though it would be nice), I am more concerned with the SD card itself and the reasons for this issue. I don't want to buy a new card every 6 months. I have clarified the question...
    – johndodo
    Jun 17 '18 at 7:12
  • 1
    @johndodo It is only a comment to the answer that it mustn't be a problem with lack of space for wear leveling. In that case there is no chance to "repair" the SD Card. For your problem loosing access to the SD Card on error occurrence: that seems to be a problem with the driver accessing the SD Card. Have you tried to use one of the rescue tools, e.g. ddrescue, or use another card reader / driver / operating system?
    – Ingo
    Jun 17 '18 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.