9

Many sd cards are rather fragile. I've had a pi for about 2 years now and the main failures were due to the sd card getting corrupted for a reason or another.

I'm wondering if there is some development done to "strengthen" the sd card on boot. I remember having something like this in a past project, where uboot would choose between 12 tarballs if any of them had an invalid crc32 checksum. It would then recopy the validated one to all the others that were modified after a successful boot.

I'd like to use my pi in "permanent" setup and it would be great if it could work without ever reflashing the card.

Is there some development already done in this way? While the general idea is rather trivial, getting uboot to work properly is usually a rather painful process that I'd like to avoid.

EDIT :

After some deeper digging, it seems that what I was envisioning might not be possible, or possible in a way that would give any meaningful advantage. Here the boot process is described. The code I worked on was running at the first boot level since my board had a programmable flash for this. With the pi, this is stored in a ROM from factory. Everything else comes from the sd card so if the card gets damaged, the second stage bootloader has as much chances to get destroyed as any other partition.

Maybe it is possible to abuse the ROM boot loader for this purpose, but it is hard to say how. The code also seems proprietary.

Edit 2 :

The actual boot process explanation is conflicted depending on sources. I'll try to read more on it

Community
  • 1
Eric
  • 226
  • 1
  • 6

4 Answers4

9

If you have problems with SD-cards you should try (in order):

  1. Use another (bigger) power supply.
  2. Connect a powered hub in between the Raspberry and any USB peripheral you may have.
  3. Use SD-cards of well known brands.
  4. Use a bigger SD-card (for distributed wear leveling).
  5. Set your rootfs to read-only and thus avoid writing to the SD-card.
  6. Use a "live" distro which runs entirely from RAM. My project Nard SDK is one of them (but there are others too). With Nard the SD-card is used only at boot time. Once up and running the filesystem is never used again, you may even hotplug the SD-card...

See: http://www.arbetsmyra.dyndns.org/nard/

Ronny Nilsson
  • 888
  • 5
  • 13
  • I'd add that you can also run the OS from a usb-connected HDD - same as your item #6. – Phil B. Jun 08 '15 at 11:49
  • Thank you for the suggestions. However the sd card is subject to corruption when the power is lost. Maybe putting the card in read only would help. I agree that preventing the corruption in the first place is a better solution, but it is difficult fully prevent. – Eric Jun 08 '15 at 11:57
  • If corruption at loss of power is the issue then a live distro is the remedy. – Ronny Nilsson Jun 09 '15 at 09:05
1

You should not be experiencing frequent dramatic corruption, even if the power is occasionally lost.

If a filesystem has a non zero value in the sixth column of /etc/fstab, it will be checked to see if it is necessary to scan it for errors before it is mounted. Regular pi distros (should) have this set for /dev/mmcblk0p1 and the root filesystem partition (on Raspbian, mmcblk0p2). What this means for ext4 filesystems (such as the root fs) is that this happens regardless every N mounts; for the value of N, see "Maximum mount count" in the output from tune2fs -l /dev/[partition]; you can adjust this value using tune2fs -c (see man tune2fs).

It will also be scanned if the filesystem was not properly unmounted. This is done with e2fsck. In most cases, everything will work out fine. There is, however, the chance that you may lose data to corruption; evidence of this will be left in /lost+found. If possible (and it usually is), the filesystem will still be left in a usable, non-corrupted state afterward. The question then is whether some critical component was lost in the fix -- but again, this would be very unusual.

The reason that it's unlikely to affect something critical is that most of that stuff, while technically not read-only, isn't changed in the normal course of things. The system has tons of stuff from /bin and /lib loaded into memory at any given point, but there's no intention of altering their source on disk, so no chance the disk will fall out of sync with those non-existent changes.

Although I don't know what the rules are for the first vfat partition containing the kernel and firmware (since it is not ext formatted), I'd assume some similar check is possible, and in any case, the logic of the last paragraph applies -- that stuff only changes for system updates. In fact, if you want to be really paranoid, you could have it mounted read-only except for updates (or not mounted at all, since it is not necessary once normal boot is complete).

After all this, you should pretty much never experience serious corruption unless you really frequently roll the dice by cutting the power (and even then it should be infrequent). If you do often experience corruption, there is something very seriously wrong. There have been at least a few people here reporting corruption issues even when using a read-only filesystem, which is a bit perplexing. It implies the corruption is arbitrarily caused by defective hardware, or a software bug.

And indeed, I think there was such a bug that might have affected pis arbitrarily from sometime in 2013 to sometime in mid-late 2014 (presuming the OS is kept up to date). I have a hunch we have had fewer "My SD card is corrupt!" posts in the last 4-6 months (but Nb. I have not done any real accounting to confirm that).

Community
  • 1
goldilocks
  • 56,430
  • 17
  • 109
  • 217
1

You might want to use a USB flash drive/USB hard drive.

They're useully more reliable then SD cards

Here's a thread that describes how to do it

nkizz
  • 41
  • 2
0

Self-healing is a problem with any Linux distribution where fsck is on the file system most prone to corruption. That's a problem raspbian shares with pretty much all Linux distributions - these days they like to put everything [including /boot in the case of Ubuntu!!??] on one big ext4 partition.

A read-only root partition does wonders for avoiding the boot-killing problem where Linux runs into file system problems before it has had a chance to run fsck.

But even a read/write root that is rarely updated is a massive step forward.

Raspbian works fine on a read-only root. It takes a bit of effort to set up, and of course you have to be prepared to "mount -o remount,rw /" before any changes to the root filesystem.

David Sainty
  • 249
  • 2
  • 3