6

I have a Raspberry Pi B+ installed on a local store and when power goes randomly off, SD card tends to get corrupted:

***Error in check_disks:could not repair filesystem, dropping to debug shell, try to run 'fsck' manually:***
### Starting debugging shell... Type exit to quit ###
Sh: can't access tty; job control turned off

This is easily repaired by manually running,

# fsck -fy /dev/mmcblk0p2 
# reboot

Is there a way to avoid this, and let Raspberry do that automatically on that case?

EDIT: It's on running OpenELEC 5.0.3

whitenoisedb
  • 367
  • 1
  • 5
  • 13

2 Answers2

3

Some people seem to have a lot of problems with corruption whereas others do not, which is very puzzling. E.g., I got my first pi more than two years ago, I now have 4, and at least one has been on that whole time. While I usually shut them down properly, I do regularly end up having to kill the power, there have been occasional outages, and I sometimes use a battery that I just let run out.

One of my theories about this is that some small percentage of pis are defective and screwing up cards due to under/over voltage either when power is removed or cut. There have been a number of people here reporting peristent SD card corruption even with a read-only filesystem (#1 -- #2 -- pretty sure there is at least one more I cannot find). That means it is not due to the power being cut with the filesystem out of sync; in other words, shutting down properly would probably not prevent this.

But I have a new theory, after trying to compile a 3.18.x kernel with a cross-compiler I built some time ago. It used gcc 4.8.1, which was released in 2013. Apparently about 7 months ago (looking at the git commits on the kernel), a little bit was added to an ARM specific file in the source such that when I tried to compile it, I got this error:

Your compiler is too buggy; it is known to miscompile kernels

The file this comes from contains a note:

 * GCC 4.8.0-4.8.2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
 *            miscompiles find_get_entry(), and can result in EXT3 and EXT4
 *            filesystem corruption (possibly other FS too).
              ^^^^^^^^^^^^^^^^^^^^^ LOOK

I never had any problems, but one thing I can pretty much guarantee is that for some number of months a lot of raspberry pi distro kernels were built using gcc 4.8.0 - 4.8.2.

I'm sure they are not anymore, so if you have not upgraded your kernel recently, do. You can check the date your kernel was compiled with uname -v. If it was anytime before December 2014, this may be your problem.

Community
  • 1
goldilocks
  • 60,325
  • 17
  • 117
  • 234
2

Is there a way to avoid this, and let Raspberry do that automatically on that case?

There's an easy way to do it generally (i.e., every boot) on Raspbian. Add this to /etc/rc.local:

echo "-fy" > /forcefsck

This will create that file with that content. This will be detected at boot and force a run of fsck -fy on the root filesystem. It's then erased, which is why it must be replaced via rc.local.

If the filesystem is fine, that will add about 10-20 seconds to your boot time, depending on the size of the filesystem.

That only works on SysV style init systems; an equivalent for systemd is documented here.

goldilocks
  • 60,325
  • 17
  • 117
  • 234