2

I need your help on this :

  • How can I protect my read-only Raspian Raspberry pi not to corrupt SD card sectors ?

  • Why does it ever happen and so frequently in my case ? (I did probably did something wrong)

Context

I am building a video-looper on Raspberry Pi that I can cut with power-off. (I know this is weird use of a computer)

I have an omx-player based video looper app running on Raspian.

To make it robust to power-loss I did put my system in read-only with this script : read-only.sh

Tests and results

System : 2015-02-16-raspbian-wheezy

Mini SD card of 8Gb

Video is read from a read-only mounted USB key

Very frequently (1 times out of 3 on some SDs, 1 time out of 15 on others), I get this error, preventing the system to boot (I can still reboot it and it works fine after) :

mmcblk0: error -110 transferring data, sector 855376, nr 8, cmd response 0X900, card status 0xb00
mmcblk0: retrying using single block read
mmc0: Controller never released inhibit bit(s).
// Dump here that I did removed
mmcblk0: unknown error -5 sending read/write command, card status 0x900
blk_update_request: 22 callbacks suppressed
blk_update_request: I/O error, dev mmcblk0, sector 740480
blk_update_request: I/O error, dev mmcblk0, sector 740488
blk_update_request: I/O error, dev mmcblk0, sector 740496
blk_update_request: I/O error, dev mmcblk0, sector 740504
  • Did I not correctly put my system in read-only mode or does a read-only system not prevent a power-loss to corrupt an SD card ?

Any help appreciated !

Community
  • 1
Lyptik
  • 21
  • 1
  • 3

2 Answers2

2

If the pi is working properly, SD card corruption should never happen regardless of whether the card is rw or ro (at least until the card is worn out, which would take quite a long time). The exception would be pulling the plug suddenly on a busy system, in which case a rw filesystem will be more vulnerable. Since you have decided to do that regularly, you've opted for a ro filesystem, which should ensure it will not be left in an inconsistent state on boot. The fact that it seems to be anyway narrows things down.

Here's two possibilities:

  1. The errors you are getting do not represent filesystem corruption, but a hardware level I/O problem.

    I have never had this problem on the pi, but other people here have observed that in cases like this insufficient voltage may be the issue. You need to make sure your supply is sufficient for the pi and everything attached to it. Turning everything on and booting creates a very sudden draw -- the processor is 100% active and everything is coming on line. If it browns out because of this something may fail momentarily, such as the SD card reader.

  2. The errors you are getting are due to filesystem corruption, caused by some power fluctuation when you shut down.

    If this is the case, you have a difficult problem unless you can rearrange something. Anecdotely, I'd say the pi's have some extraordinary sensitivities when it comes to power and voltage fluctuations on the circuit they are on. In addition to that linked story, I have a pi with an FM transmitter that will cut out (presumably because it momentarily loses 3.3 V from the pi) when certain other things are (un)plugged on the same household circuit.

One thing you can do is add this to the beginning of /etc/rc.local1:

echo "-y" > /forcefsck

This will cause a forced e2fsck -y /dev/mmcblk0p2 at boot, which will add 10-15 seconds to the boot time, but should fix any filesystem corruption. If it does not work, or the problem occurs before this can happen, it's again not filesystem corruption, it is something more fundamental. You could try a different brand of SD card. If that does not change anything, try using the pi in a different environment and doing something similar (unplugging it suddenly) and seeing if you get the same result. I try to avoid doing this but I do on occasion and am not really afraid of it because nothing bad has ever happened, which implies either:

  • There is something weird about your situation.
  • There is something wrong with your pi. There have been millions of them made, they can't all be perfect -- here's an example from yesterday.

The only way to rule out the last case would be if you have another pi to test under the same circumstances. If it does the same thing, obviously the circumstances are to blame.

1. Obviously that won't work if the fs is read-only. In that case you could just try mounting it rw and adding that file (/forcefsck, which should just be 3 bytes, -y and a newline). In theory this is erased after the fsck, which is why it needs to be replaced every boot, but that may not happen if the fs is ro.

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

If you have another USB drive, you can move the filesystem to that, using this guide.

This way it will only ever use your SD card for a brief moment on boot (and write firmware updates if you update firmware).

Edit: or you can just put it on your existing drive and then put video file in home (or anywhere else) so you only need the 1 drive, rather than 2.

geoffmcc
  • 621
  • 5
  • 8