Repair a broken SD card “superblock” on a RaspberryPi

how-to-fix-damaged-sd-card-android

Introduction

This has happened to me a few times, and it’s not a nice problem to find yourself in. You computer won’t boot, all your filesystem checks tell you you’ve a bad superblock, but you cant seem to find how to fix it. Well, here goes 🙂

This guide is for ext4 , though I’ll explain how other filesystems can be cured along the way. The easiest way to carry all this out, seeing as your computer probably won’t boot at this stage, is to download and burn a copy of Parted Magic. Boot from that, and you’ll get access to a number of useful tools.

The procedure

First, figure out what partition we’re dealing with.

sudo fdisk -l

The above will list all the partitions on all the drives in your computer. To recover a lost partition, you’re going to need Testdisk. Testdisk is included in Parted Magic, and there’s a great guide on their site. For this though, we just need the partition number, such as /dev/sda3 or /dev/hdb1.

Now, make sure your superblock is the problem, by starting a filesystem check, replacing xxx with your partition name. Here, you can change ext4 to ext3, or ext2 to suit the filesystem.

sudo fsck.ext4 -v /dev/xxx

If your superblock is corrupt, the output will look like this

fsck /dev/sda5
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5
The superblock could not be read or does not describe a correct ext4
filesystem. If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Now lets find where your superblock backups are kept.

sudo mke2fs -n /dev/xxx

Down at the bottom of this output, should be a list of the backups:

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

You’re almost there. Finally, restore the superblock from the backup, again replacing the x’s with your partition name, and block_number with the first backup superblock.

sudo e2fsck -b block_number /dev/xxx

Now reboot, and your superblock should be fixed. If it’s not, repeat the steps, but restore a different backup superblock :)

Checking your file system as a precaution

If you want to check your Pi file system because you feel it might be having a problem, try the following:

First of all, shut down your Pi using the following which will make the Pi check it’s own file system on reboot:

sudo shutdown -F -r now

Once the Pi comes up again, check the results of the scan by looking at the following file:

/var/log/fsck/

26 comments for “Repair a broken SD card “superblock” on a RaspberryPi

  1. 11 May 2013 at 4:18 am

    All I get is:

    e2fsck: Invalid argument while trying to open /dev/sdx1

    • 11 May 2013 at 5:53 am

      At what point do you get the error?

      • 11 May 2013 at 11:51 am

        After I try to restore the superblock with sudo e2fsck -b block_number my sd card.

        • 11 May 2013 at 11:54 am

          Try a different superblock.

          • 11 May 2013 at 12:24 pm

            I tried them all.

          • 12 May 2013 at 7:08 am

            I don’t know what to suggest, then – it’s always worked for me and others 🙁

          • Rob Aldred
            22 April 2015 at 2:24 pm

            Same, I tried all the superblock backups. I get the same error. “Superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem”

          • recantha
            22 April 2015 at 2:28 pm

            In that case I would say your SD card is beyond repair. 🙁

  2. 2 February 2014 at 11:26 am

    Use Win Minitool Power Data Recovery i better.

  3. theAntiguan
    4 September 2014 at 10:52 am

    I followed your instructions to repairing a broken CD superblock on RASPi, it does not appear to be taking the command. Below is my output.

    $ sudo fsck.ext4 -v /dev/sdb1
    e2fsck 1.42.9 (4-Feb-2014)
    ext2fs_open2: Bad magic number in super-block
    fsck.ext4: Superblock invalid, trying backup blocks…
    fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

    The superblock could not be read or does not describe a valid ext2/ext3/ext4
    filesystem. If the device is valid and it really contains an ext2/ext3/ext4
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193
    or
    e2fsck -b 32768

    $ sudo mke2fs -n /dev/sdb1
    mke2fs 1.42.9 (4-Feb-2014)
    Filesystem label=
    OS type: Linux
    Block size=1024 (log=0)
    Fragment size=1024 (log=0)
    Stride=0 blocks, Stripe width=0 blocks
    14336 inodes, 57344 blocks
    2867 blocks (5.00%) reserved for the super user
    First data block=1
    Maximum filesystem blocks=58720256
    7 block groups
    8192 blocks per group, 8192 fragments per group
    2048 inodes per group
    Superblock backups stored on blocks:
    8193, 24577, 40961
    $ sudo e2fsck -b 8193 /dev/sdb1
    e2fsck 1.42.9 (4-Feb-2014)
    e2fsck: Invalid argument while trying to open /dev/sdb1

    The superblock could not be read or does not describe a valid ext2/ext3/ext4
    filesystem. If the device is valid and it really contains an ext2/ext3/ext4
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193
    or
    e2fsck -b 32768

    I did the same for all three backups of the supperblock with the same results.

    Interestly when I launch Gparted and look at the SD card is it showing for the boot partition is a Fat16. is there away to change or correct it without loosing my data.
    I was using my raspi as database server mainly and I did not have a backup before the corruption occurred.

    Please advise.

    Thanks in advanced.
    theAntiguan

    • recantha
      4 September 2014 at 1:34 pm

      I think probably the best thing to do is to post your question to the Raspberry Pi Forum – it sounds like you’re having a very specific problem and I’m afraid the level of my knowledge might set you on the wrong path.

    • jam75
      2 October 2015 at 3:58 pm

      I had exactly this problem on several new µSD.
      In fact the problem was related to a very beautiful Samsung adapter !
      When I came back to my usual adapter, everything was correct.
      Best regards

  4. elisavet
    13 October 2014 at 1:20 pm

    I have the same problem.
    “The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem, then the superblock is corrupt, and you might trey running e2fsck with an alternate superblock: e2fsck -b 8193 ”

    I use all the blocks but then again it shows the same problem.

    Do you have any idea how can i solve this?

    Thank you!!!
    Elisavet

    • recantha
      13 October 2014 at 1:58 pm

      No, sorry, I don’t – it normally works for me. Try posting to the Raspberry Pi Forums – there’s more people to possibly help you on there 🙂

  5. Dave R
    17 November 2014 at 9:38 pm

    Hi Michael, just wanted to say thanks for the excellent post here. I had issues when power was lost to a Pi acting as a wallboard monitor for one of our company’s websites. The Pi refused to boot and all the code behind the monitoring was (foolishly on my side…) on the Pi only and not backed up anywhere.

  6. Román P.C.
    13 February 2015 at 4:42 am

    Thank you very much! Seems like this solution worked for me.
    Now I’m looking for the best solution to prevent this to happen again.

    Maybe a job in the boot process with the command:

    sudo fsck.ext4 -v /dev/xxx

    Regards.

  7. Vince
    9 August 2015 at 10:26 am

    I was able to recover several days of work by repairing mi pi’s SD card following your instructions.

    Thank you!

    • recantha
      10 August 2015 at 10:56 am

      You’re very welcome indeed 🙂

  8. me
    14 October 2015 at 12:41 pm

    Thank you very much for your fantastic howto!! You saved me a lot of work. Thanks again, have a great day (-:

    • Michael Horne
      14 October 2015 at 12:44 pm

      You’re welcome. Glad it helped 🙂

  9. Jr
    14 October 2015 at 2:35 pm

    Thank you for your help. My question is, do you have any idea what can be the origin of this problem? First I thought in power failures, but I could not find any crash with last command.

    • Michael Horne
      14 October 2015 at 2:45 pm

      I’ve generally seen it happen when you pull the power out of the Pi without shutting it down properly.

      • Jr
        14 October 2015 at 3:05 pm

        Yes, that was my first idea, but I could not detect none. I use “last” command, which prints “crash” whenever a power failure happens (as far as I understood, searching for how could I detect power failures from the logs), but none occurred. Do you know other way to detect if a power failure actually happened?

        • Michael Horne
          14 October 2015 at 3:28 pm

          As far as I know, you don’t get any logging when a power failure happens because the computer is ‘off’ before it can log anything. I don’t know of any other method… except the SD card normally corrupts (even if it’s in a small way).
          If you need to track power outages, the only thing I can suggest is a cron job that logs something every minute with a timestamp and then you can check for gaps.

Leave a Reply

Your email address will not be published. Required fields are marked *