Power cycling RPi

Product support balenaOS
1

Hey All,

I have read a few anecdotes and comments about power-cycling the RPi in order to reset it, and I wanted some official guidance on this. In general, power-cycling a Raspberry Pi is a bad thing, due to the active file system on the SD card getting corrupted, or in extreme cases, the loss of power during a power-hungry operation against the SD card causes a brown-out condition, which can actually damage the SD card. Data corruption is a problem with all Linux-based OSes, not just RPis. The brown-out issue seems specific to RPis and other tiny computing devices.

Does balenaOS somehow tolerate sudden loss of power without corrupting or damaging the SD card?

Thanks!

1 Like
5

Hi @koyaanisqatsi,

You’re correct that a sudden power-cycle can invalidate data in the SD card. We’ve actually designed balenaOS to mount root partition as read-only, to ensure the host OS is stateless. More information about the architecture here.

Moreover, balenaEngine syncs directly to disk as it pulls any image (as opposed to docker/moby, which pulls to memory first), and unless the whole of the image arrived it won’t be used.

The above means that the devices are protected against power-cycle/loss. This doesn’t include application data though. If your application does write to disk, you’ll need to make sure such cases are taken care of.

Hope this helps!

Cheers,
Nico.

1 Like
7

Excellent! Thank you, Nico.

8

Maintaining an adequate power source is not limited to tiny embedded systems, designers struggle with this everywhere.

To avoid this you should design the system with adequate power to supply the peak load plus 10 or so percent as a cushion.

If your system supports it, you can implement a battery monitor process that will write an error to the system log and formally shut down the system if the power source drops below a preset value.

1 Like
10

Indeed - a lot of folks have come up with such UPS (Uninterrupted Power Supplies) that can handle such situations gracefully by buying a little time to give the OS a fair chance.
For example see this one - https://uk.pi-supply.com/products/pi-ups-uninterrupted-power-supply-raspberry-pi

2 Likes
12

As the article suggests, NiMH batteries are essentially mandatory. I know from the bitter reapings of experience that “normal” alkaline batteries don’t cut it, regardless of the number of dancing bunnies or slamming lids they may have.

If your application draws any kind of power, (i.e. A Pi-4, has current-hungry add-ons like motors or higher powered sensors, etc.), you will need batteries rated 2000 mAh to give you any kind of run-time on battery power.

1 Like
14

I appreciate the info on using battery backup to maintain power to the RPi.

However, the concern I had for posting this question was centered around people suggesting to power-cycle an RPi in order to reset it. As I know that is generally bad for the SD card, I wanted to understand whether balenaOS had some form of protections against the issues caused by dropping the power like that.

The selected response answered the question as well as can be answered, which is basically, “Yes, it does protect to some degree by making the key partitions read-only. But the application data partition(s) can still be corrupted.”

So, it seems that while a power failure isn’t likely to hurt the OS, it can still corrupt some parts of the SD card where application data may be stored. Depending on your setup, that may be fully acceptable or just as dangerous as any other case.

If the entire setup can be abstracted from the SD card, and the card is used only to start everything, but then becomes COMPLETELY read-only, including all application data and binaries, and SD partitions, then you have a fully tolerant setup that can be power-cycled and doesn’t need any form of battery backup, except to maintain uptime.

1 Like
16

One thing you can do to engrave this in cast titanium is to take the fully built and running SD card and mount it on the Linux distribution of your choice. (I use a bootable CD/flash-drive of Linux Mint.)

Once mounted, run Gparted to find the SD card, identify its device name, (something like /dev/sda, /dev/sdb, etc.), and note the partitions on it. (/dev/sda1, /dev/sda2, or whatever they are on your system.)

Look to see if the partitions are formatted as “ext” type partitions.

Note:  Tune2fs ONLY works on “ext” formatted partitions. FAT, FAT-32, NTFS, etc., won’t work.

For every “ext” formatted partition, one at a time, run tune2fs as root, or use sudo.

tune2fs -l /dev/sda1

(replace the device and partition with whatever is on your system), will list all the current file-system attributes for that particular partition.

The ones you are most interested in are “maximum mount count”, “interval between checks” and “mount count”

You want to set “interval between checks” to something reasonable, based on your usage scenario - I set my robot to “10”- every ten days it checks the partition if it hasn’t been checked before then.

You set “maximum mount count” to something reasonable. I set my 'bot to “5” - every five reboots, it checks the partition.

Set “mount count” to some number greater than the max mount count. This will force a fsck, (checkdisk), immediately when the device is rebooted.

Do this for every partition, even if it is normally read-only.

Set the interval between checks to slightly different values for each partition to prevent every partition from fsck’ing all at once, (except for the first reboot after these settings are set).

You can, and possibly should, set the error behavior to something like “remount read-only” to prevent your file system from being trashed if it discovers an unfixable error on boot.

Example:
Assume your SD card (in a USB adapter) is located at /dev/sdc. Also assume that there are two ext-3/ext-4 partitions located at /dev/sdc1 and /dev/sdc2.

tune2fs -c 7 -i 5 -C 8 -e remount-ro /dev/sdc1

. . . will set the first partition on /dev/sdc to:

  • Automatically check every seventh time the partition is mounted, typically seven reboots.
  • Automatically check the partition every fifth day if it hasn’t been rebooted seven times before then. (Assuming that the system is rebooted less often than seven times within those five days.)
  • Sets the “number of times it has been mounted” to “8” (which is larger than seven, so it will check itself on the very next reboot).
  • If the system detects a filesystem error, it will re-mount the partition as read-only, regardless of what it would normally do.

I set my 'bot to really short values because I reboot it a lot, occasionally kill battery power accidentally, run untested software I am working on, and other similarly evil things. My desktop/laptop systems are set to much larger values like every 27 days, 21 mounts, or something like that.

You will have to decide what is reasonably conservative, (more often is better than less, you can always change it later), based onyour needs.

In any event, “tune2fs” is a good trick to know to help keep your file systems happy.