0

I'm using a Raspberry Pi 3 model B with Raspbian (latest, with PIXEL) with a 16 GB MicroSD Class 10

I've been using the Raspberry Pi since last May (so about 5 months or so) and it's working just fine until September, when it apparently "shuts down" on it's own. The PWR light turns on but the ACT light doesnt. The mouse and the keyboard does not appear to be on. I managed to fix this issue by formatting the SDCard, and write the image to the SDCard. But after a few days the issue appeared to have returned. My friend suggested to boot from the USB and fsck the SDCard, in case the SDCard was broken, or something. But it won't boot from the USB (perhaps it was because I did something wrong)
Recently I noticed that the ACT light flashed in a specific pattern every few second. I checked the internet and apparently it could mean that the board can not read the SDCard. I've always plugged out the power supply after the ACT light stops flashing (irregularly) to make sure that the SDCard isn't corrupted. And the usual temperature for the board is around 40°C.
What is happening? How do I fix it and what caused it?

Improve this question
1
  • If the Pi doesn't boot and the LEDs flash in a particular way during the boot attempt then that is the failure. Follow the advice given.
    – joan
    Oct 11, 2016 at 12:03

2 Answers 2

Reset to default
1

But it won't boot from the USB

No, not without a bit of prior work.

fsck the SDCard

Yes, that is the most fundamental step in dealing with a potentially corrupt SD card. If you cannot do that you might as well just re-flash the card.

However, all that's required to do that is a computer which can run fsck on an ext4 filesystem; the obvious choice for that OS wise would be some GNU/Linux distro. But if you don't have a normal computer running linux and don't want to install it:

  • You could use a linux "Live CD" (really, a DVD, it won't fit on a CD anymore); although they are quite slow, if you have a computer that will boot from CD/DVD that's probably the easiest way.

  • Although it does require a few GB of storage (but not an actual install), you could use a virtual machine instance from Window/OSX. VMware and VirtualBox, which have free versions, are popular examples of this (you have to get the linux image separately, and, at least with VirtualBox, you can just use a normal DVD installer). These are obviously a bit harder initially than a live DVD, but they are quicker on a multicore machine, more convenient, and can be customized since you can save the image state.

IMO anyone who owns a Pi running Rasbian or another GNU/Linux distro without another linux box should learn to do the latter method. If it is too challenging, I fear so is the Pi. But that's just a opinion.

Recently I noticed that the ACT light flashed in a specific pattern every few second. I checked the internet and apparently it could mean that the board can not read the SDCard.

Well, no. Not being able to read the SD card would be either no green light, or else the green light on solid. Flashing in a regular pattern means it did read the SD card but did not find what it needed on the first partition, which is VFAT and therefore can be checked on pretty much any computer.

Although the first partition isn't actually used by the OS after boot except when you do an update, there's a (small chance) this could happen if you yanked the cord due to the way SD cards work. However, if you aren't doing that and/or it occurs often, it is more likely the card is worn out, or the Pi just doesn't like it. I would try using a completely different one.

If the pattern persists with a new card and the Pi is relatively new you should look into a warranty replacement via the distributor.

Or, if you can get it running again for a while, you could try setting it up for USB boot as per that first link. This may be more stable, I don't know enough to guess.

Improve this answer
7
  • Thank you for your answer. I tried to boot from another SDCard and I ran fsck on the appropriate filesystem (/dev/sda2)
    – algmwc4
    Oct 18, 2016 at 10:31
  • (Sorry, pressed the enter on accident) and fixed the bad blocks. But the new sdcard I'm using apparently has the same issue. Could this be a problem with the hardware instead?
    – algmwc4
    Oct 18, 2016 at 10:32
  • To to make sure: As per my comments on Huygens answer, an actual badblocks check is pointless, and if any are found probably indicates the card is defunct/defective. However, a normal fsck doesn't do that; just plain fsck /dev/sdb2 (or whatever parition) may say it is fixing inodes and other filesystem things, which is a different issue and that's fine. But if you say yes to all the fixes, then you should be able to run it again right afterward and it will say everything is okay (use fsck -f to make sure). If not something weird is going on.
    – goldilocks ♦
    Oct 18, 2016 at 11:16
  • Also, after you burn a fresh image, fsck -f should pass with no problems. If the card then doesn't boot possibly there is something wrong with the pi, such as the SD card holder being loose.
    – goldilocks ♦
    Oct 18, 2016 at 11:17
  • @algmwc4 goldilocks is certainly right. You should try to write the OS image on your microSD card and then before removing it from the host, you should try to fsck it. If all is fine and the RPi is still not booting, I would try to contact your vendor if your RPi is still under warranty.
    – Huygens
    Oct 18, 2016 at 21:55
0

Note: answer amended with input from @goldilocks.

What your friend perhaps meant was to check the SD card for bad sectors.

A SD card, just like SSD, are subject to wear when cells are written. Depending on the card quality and how full the file system is, corruption of cells can happen rather quickly. On a SSD, the embedded microcontroller usually take care of managing this bad cells and has often many spare cells which it can use instead. On a SD card, there are no spare cells and the microcontroller in it does a much simpler job at managing bad cells and there are no interface to report back to the OS of this issue. So basically once a cell has become bad, you need to check your filesystems.

Trying to fix your SD card

Note: the Raspberry Pi has at least 2 partitions, a FAT32 (aka vfat) one where the kernel and releated data (aka firmware) are located. FAT32 can avoid bad sectors if instructed to do so, but I am not sure that the Linux tools support that for FAT32. However, it would be surprising that you have bad sectors on this partition as it is seldom written too.

You need to repair your filesystem and do some simple bad block checking. Run on the other partitions (with the exception of the 1st vfat one):

$ sudo fsck -vcf /dev/<device>

(replace <device> by the partition, example: sdb2 or mmcblk0p2)

As a last resort, you could use the badblocks utility (run badblocks -nsv /dev/<device> on each partition of your SD card, obviously you need to do that from another Linux computer or from within a VM running on your desktop/laptop). This will tell you how many bad blocks are. If you have any bad blocks, you can let know your filesystem so that it avoids them. However there is a limitation, the badblock utility on SD cards will only work for allocated blocks, not the free ones (where you might still have bad blocks).

If the card is not repairable

If you have too many blocks broken, it is possible that you cannot use your SD card anymore as you might not be able to flash the image on the SD card without ending up with a corrupt file system. The solution is most likely to buy a new SD card, but this time not a cheap one :-) I've bought 2 safe brand for SD card, and one is running now for 1,5y and the other for 1y.

Improve this answer
10
  • badblocks is useless for this purpose on an SD card because SD cards use virtual addressing. I.e., the block 1234 that appears to the OS and thus badblocks is not necessarily physical block 1234; it may be block 5678. This difference is opaque to the OS or any other software; the SD card is a black box to that extent. What's more, the SD card does this to implement wear leveling, so next time block 1234 (really 5678) is written to it may become block 2987.
    – goldilocks ♦
    Oct 11, 2016 at 12:42
  • In fact, because of the difference in proportion between filesystem blocks (smaller) and physical erase blocks (bigger) used by the card, changing a completely different block could cause 1234 to be moved. Badblocks was not (and could not be) designed to work in that context and assumes fs blocks correspond to literal physical sections of a spinning disk, so it can go through and check all of them sequentially. On an SD card, the card could literally just hand it the same block over and over again
    – goldilocks ♦
    Oct 11, 2016 at 12:43
  • (except to the extent that they are actually in use, meaning it might in theory work on a card that is 100% full -- unless you do the read-write test which will throw the ordering out). However, SD cards do pretty much what badblocks does all by themselves; they note and blacklist failed segments up to some threshold (after which they should be considered junk).
    – goldilocks ♦
    Oct 11, 2016 at 12:43
  • @goldilocks what you describe is true for SSD, which have full-blown microcontrollers and firmware running on them. But SD card are much simpler and there are no microcontroller as far as I know, but I could not open one to verify ;-) Do you have any source for what you state?
    – Huygens
    Oct 11, 2016 at 13:25
  • 1
    Yes there is a microcontroller: bunniestudios.com/blog/?p=3554 They can be very small ;) WRT wear levelling, it isn't a prerequisite or necessarily implemented by all SD cards (meaning, ironinically, badblocks may work on some low quality cards) but I think if you search around you will find it is probably in use on most of them currently. Vendors actually tend to consider it proprietary information although since it is a feature, they may choose to indicate it for specific models somewhere -- the problem is you cannot assume it is not used just because it is not explicit.
    – goldilocks ♦
    Oct 11, 2016 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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