0

I have these mini-servers based on raspberry pi. Lots of them. But currently we have relatively frequent malfunctions because for some reason or another the filesystem on the SD card gets corrupted and the device will no longer function correctly.

We are going to attach the problem by moving to CM3+ so we gat MMC which is more reliable, but we would also like to increase reliability of each individual device.

So, the question:

Is it possible to create such a disk layout that there would be two boot / root partition - one primary and one backup in case primary gets messed up. Then a boot loader (grub?) would log boot attempts and a successfully booted system would reset them. If number of unsuccessful boots exceeded a given number, we would either copy the backup over primary or boot from backup.

velis
  • 367
  • 1
  • 4
  • 16

1 Answers1

0

I have these mini-servers based on raspberry pi. Lots of them. But currently we have relatively frequent malfunctions because for some reason or another the filesystem on the SD card gets corrupted and the device will no longer function correctly.

SD card for rootfs isn't a good idea. At least:

  • Do not log. Or log to a tmpfs.
  • Tweak mount options to avoid useless FS modification (noatime, nodiratime, ...)

We are going to attach the problem by moving to CM3+ so we gat MMC which is more reliable, but we would also like to increase reliability of each individual device.

The eMMC should be better.

Is it possible to create such a disk layout that there would be two boot / root partition - one primary and one backup in case primary gets messed up.

Not sure this is THE solution. Instead, i would study a better filesystem. For example, F2FS or something similar.

Then a boot loader (grub?) would log boot attempts and a successfully booted system would reset them. If number of unsuccessful boots exceeded a given number, we would either copy the backup over primary or boot from backup.

See this post regarding Grub & Raspberry Pi. The problem is that you need the rapsberry pi specific loader which, i'm opinion, isn't able to do such a trick.

If i had to solve a problem like your, what i would do is:

  1. Build a minimal OS (for example with Yocto or with a hand-crafted raspbian).
  2. Boot it using NFS or TFTP using a tmpfs as rootfs
  3. Use the eMMC only for persistent storage and, obviously, optmize my use of it.

The advantages:

  • System files are only living in RAM, so no fear of burning the eMMC or SD card.
  • Only one tree to update (on the NFS/TFTP server) + a reboot, and all your rapsberry pi are updated.

The disadvantages:

  • Since your rootfs is stored in RAM, less RAM is available for your applications.
binarym
  • 2,639
  • 9
  • 12
  • I don't know: while f2fs seems a good suggestion, it's hardly even supported on the platform. As for booting from tmpfs, I fear that would bring little benefit: we're running a database server in there... Seems further investigation will be needed. – velis Jan 14 '20 at 15:48