I recently got my hands on an older pi (Model 3B), that I had left at my mom's house some time ago. When I went to start it, it wouldn't boot. The red light came on but the screen remained black.

I tried swapping the SD card with another one with NOOBS pre-loaded and the Pi worked fine, so I know there's nothing wrong with the machine.

After some searching, it seems this is a common problem, where a raspberry pi could corrupt its SD card over some time.

Here's the thing, I remember leaving some rather important information on this SD Card, information that I would much rather not lose.

Could you provide me with some suggestions on how I could go about rectifying this issue? Any ideas at all are welcome and would be considered.


I forgot to mention: when I mount the SD Card on my linux computer, it shows up as boot and SETTINGS. And I am unable to eject SETTINGS without this warning:

Unable to eject SETTINGS
Error ejecting /dev/mmcblk0: Command-line `eject '/dev/-
mmcblk0" exited with non-zero exit status 1: eject: unable to eject

Trying to mount it elicits a error that's similar. I can enter into boot however.

  • If the only partitions on the pi are boot and settings, I presume the original SD card was NOOBS as well, and the fact that there's no other partitions would suggest it doesn't have any operating system installed
    – Bravo
    Commented Sep 18, 2021 at 1:58
  • There are several problems with your post. DO NOT try to "fix" - that is almost a guarantee that you will lose whatever you are looking for, although you should be able to recover your data. It is unlikely that the SD Card would be /dev/mmcblk0 on a Linux computer, it is more likely /dev/sd? you should check and post the output of sudo fdisk -l /dev/?
    – Milliways
    Commented Sep 18, 2021 at 2:35
  • Hi @Milliways, the output of sudo fdisk -l /dev/? is simply: fdisk: cannot open /dev/?: No such file or directory
    – dedles
    Commented Sep 23, 2021 at 22:26
  • I don't know what device it is on your computer. You need to substitute the actual name.
    – Milliways
    Commented Sep 23, 2021 at 22:39

1 Answer 1


Start by making an image of your SD card (e.g. dd if=/dev/mmcblk0 of=backup.img bs=4M). Trying to fix existing filesystem errors on a failing SD card will produce new errors in relocated sectors, and fixing those will produce more errors etc. You can skip this step if you're certain your SD card is OK, but if the data you're trying to recover is really important, I wouldn't take this risk.

Once you have your backup image, put it on a loopback device (losetup -P /dev/loop0 backup.img). The first step is to understand if the partition table is OK or not: on a typical NOOBS installation you should see the RECOVERY partition /dev/loop0p1, the SETTINGS partition /dev/loop0p3 and a couple of system partitions for each system you have installed, typically /dev/loop0p5 and /dev/loop0p6. gparted will be helpful here, as it can show you the labels of the partitions it detects. Note that if you decided to forego the backup copy and work with your SD card, you'll have the same partitions, only with /dev/mmcblk0 or /dev/sda (for USB card readers) instead of /dev/loop0, and you simply need to plug the SD card instead of using losetup.

If the information you need was stored in the home folder of the pi user, it will be on /dev/loop0p6. Otherwise, you have to remember where you actually stored it.

If you don't see the partition you need, you'll have to recover the partition table and/or partition superblocks. I recommend doing this with testdisk, but there are other tools you may be more familiar with (fidsk, parted, etc.). If you have no experience, find a tutorial online (here's one for testdisk) or ask someone knowledgeable to do it for you. Once you do the necessary changes, run losetup -d /dev/loop0 to unbind the loop device and losetup -P /dev/loop0 backup.img to rescan the partition table again. If you're working on an actual SD card, unplug it and replug it again.

Once you get the partition you need to show up, mount it read-only (mount -o ro,loop /dev/loop0p6 /mnt/recovery) and see if you can find the files you need there. If not, unmount the partition and try to fix it with fsck /dev/loop0p6. If fsck reports errors, fix them with fsck -y /dev/loop0p6, mount the partition again and see if it helped.

  • 1
    Thank you, I will experiment with this approach over the weekend.
    – dedles
    Commented Sep 24, 2021 at 20:27
  • Hi @Dmitry Grigoryev, been trying to follow your advice but keep getting stuck at the first step. Each time I try to run dd if=/dev/mmcblk0 of=backup.img bs=4M my computer freezes. Do you have any idea why that might be?
    – dedles
    Commented Sep 28, 2021 at 22:18
  • 1
    Possibly the card itself is physically defunct (which would account for the fs corruption). There are some conundrums that the OS cannot get out of when trying to read from damaged/defective storage, which is why just trying to copy the card would cause a problem. If this is the case, there is not really anything you can do to get your data back.
    – goldilocks
    Commented Sep 30, 2021 at 18:21
  • @dedles If your SD card is in such a bad shape that dd won't copy it, you should try ddrescue: it skips a few MB after each bad sector, quickly copying most of the disk, and then makes additional passes re-reading those skipped areas, possibly in reverse order. It takes the same amount of time as dd to make a full copy, but you typically won't wait that long and simply stop once you get 95-99% of the data. Commented Sep 30, 2021 at 19:10
  • @dedles Also check out this: raspberrypi.stackexchange.com/q/132410/33476 Commented Sep 30, 2021 at 19:17

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.