2

So I'm coming back to my Raspberry Pi 3 after it was unwired for a week. Although I correctly shut it down and all, it doesn't boot. The power LED is steady red, but the ACT LED doesn't do anything. So I read it might be that the SD is corrupted (why if I shut down normally?). And I insert the card into my laptop (running Debian Jessie).

Now here is the funny thing. The card which is a 16 GB Intenso micro-SD with adapter to SD for the laptop, doesn't automatically mount or anything. In the Gnome 'Disks' utility, it shows as a '127 MB Unknown' volume:

enter image description here

If I try to write the Raspbian image again, I only get the message that the image is larger than the target device:

enter image description here

What's wrong here? It appears the micro-SD is not registered at all (neither by the RaspPi nor by the laptop), although it worked flawlessly before.

  • 1
    The card has failed. No one knows why this happens (infrequently). I had a similar card which was replaced on warranty. This is unrelated to any shutdown issue which may cause card corruption. – Milliways Jul 11 '16 at 9:52
1

The card may indeed be defective, obviously it must happen on occasion, but before assuming that there are a few simple things you can try.

Since you have a linux system on your laptop, try running fdisk -l /dev/sdb (presuming sdb is the card) and see what that says.

If it actually identifies partitions, try e2fsck /dev/sdb2, although from the sound of things the MBR is screwed up, meaning you won't find the partitions properly and so won't be able to fix any corruption on them (presuming that also exists, which it might not); fdisk will say something weird.

That is not the end of the world, though. The MBR is just a 1/2 kB block that contains basic information about what is supposedly on the card, partition wise, and where it is located. You can recreate the MBR fairly easily and since it is separate from the rest of the data on the disk, doing so should mean that data can be found again (it may actually be fine).

To do this you will need a copy of the image you originally used to flash the card; the image contains an MBR. This answer explains how to examine the information in it for the purpose of mounting the partitions to access them without having to burn to a card. The reason you want the a copy of the one you used originally is that periodically with Raspbian the first partition is expanded a bit, meaning the starting block of the second one changes. I download and mount Raspbian images regularly, and I have noticed this change at least once this year with the "lite" version.

If you do still have a copy of the image, you don't even have to bother looking at the MBR as described above -- you can just copy it onto the card.

dd if=whatever.img of=/dev/sdb bs=512 count=1

Note the of (output file) is the whole device there, not sdb1 or sdb2. This is the same as if you were burning the whole image, but the final two parameters here (bs = block size, count = number of blocks) are very important. It means all you are actually going to copy is the first 1/2 kB -- i.e., the MBR. This remains the same except if you've expanded the second partition; in that case you will want to think about that and make changes to with fdisk to match the real size of what is there.

After you do that, fdisk -l /dev/sdb should show the correct partition table. This doesn't mean you are completely out-of-the woods; you will first want to run e2fsck /dev/sdb2.1 You can also run fsck /dev/sdb1 to check/fix the first partition, but I would actually just try and mount and look at that instead and if it seems okay (you can compare it to the one in the image, read your config.txt, etc.) then not worry about it.

If e2fsck on the second partition comes out okay (if there is corruption, it may take some time; you may want to run it with -y so you do not have to keep saying answering "yes" to questions about fixing things) then you can mount that quickly and look at it. If fsck did a lot of stuff, check the lost+found directory. Normally it is empty, but post-fsck it will contain obscurely named files that are bits and pieces of things that could not be properly recovered. They may be useful for something if you have important stuff you want to try and sew together, but in this context just noting they are there and the total volume will give you a clue about how much data was effectively destroyed. If it is a lot, the partition may be infeasible -- you'll have to try a boot and see.

If in the end the card remains unusable, it's up to you whether you want to give it another chance or replace it. If the same thing then happens again, probably you should replace it; if it happens again with a different card, you should consider getting the Pi replaced, since they can be defective as well.


1. If you did grow the partition but did not set the size correctly in the replacement MBR with fdisk, the consequences may show up at this point, but beware fsck will not be able to correct the problem. A safe bet is to just make that partition as big as possible, since too big is okay, too small is not.

  • Thanks for the extensive answer. fdisk -l did not show any partitions. e2fsck will not work for sdb1 or sdb2, but for sdb it says "Bad magic number in super-block" and other things, so I guess I'll declare the card "lost". – 0__ Jul 11 '16 at 12:18
  • Did you actually try replacing the MBR first? None of this will apply otherwise since it is obviously wrecked (as in scrambled, not physically damaged). If you want to throw it out, throw it out, but there is really not much reason to believe there is anything wrong with it physically, just the data on it has become messed up. If it turns out the pi is defective, then being able to fix the card on another computer will be a be big clue if the pi corrupts it again. We've certainly had people here before reporting pis that repeatedly corrupted any and all cards. – goldilocks Jul 11 '16 at 12:34
  • E.g., "Bad magic number in super-block" does not mean the card is wrecked, it means exactly what it says, and that "magic number" is like any other piece of data that was written to the card. This is particularly likely if the MBR or partition table is screwed up, because the software will look in the wrong place for that magic number, so of course will find the wrong thing. It is not anything that is hardwired in the card. It is an aspect of a particular filesystem type (ext4). – goldilocks Jul 11 '16 at 12:46
0

As @Milliways points out in the comment, most likely the SD committed Harakiri. I bought a new card, it was recognised by the laptop, I installed Raspbian again and the Pi did boot up again.

I still wonder how this can happen - and if it's a warranty issue for the card (it was less than two weeks)...

  • "Most likely" seems like pure assumption. Any piece of hardware can be defective, but there are usually more likely explanations that need to be ruled out first. Note that in this case the laptop does recognize the card -- it just does not recognize it as properly formatted. Blaming the card for corruption or incorrect formatting is a little like blaming your car for running out of gas. It happens to most of us at some point, then we learn to be more mindful of certain realities about how a car works. – goldilocks Jul 11 '16 at 12:42
  • @goldilocks Yes, but the detail in the question shows a Volume of 127MB. You can format that, but it will still remain 127MB. – Milliways Jul 12 '16 at 0:10
  • Could be. I've never used those GUI tools so have no idea what "volume" is supposed to refer to or how seriously to take it. The need for formatting to write a device image is a lot of tripe though, you can take a card filled with random garbage or zeros and dd an image to it, it doesn't matter. Of course, if the card is truly busted and the system believes at the lowest level it cannot do that, then the card is truly busted. I'm just suggesting there are things I'd try before I gave up on it besides what's in the question. – goldilocks Jul 12 '16 at 2:59

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.