Raspberry Pi Gets Turned On

The Raspberry Pi and other similar Linux-based single board computers simplify many projects. However, one issue with Linux is that it doesn’t like being turned off abruptly. Things have gotten better, and you can certainly configure things to minimize the risk, but–in general–shutting a Linux system down while it is running will eventually lead to file system corruption.

If your project has an interface, you can always provide a shutdown option, but that doesn’t help if your application is headless. You can provide a shutdown button, but that leaves the problem of turning the device back on.

[Ivan] solved this problem with–what else–an Arduino (see the video below). Simplistically, the Arduino reads a button and uses a FET to turn off the power to the Pi. The reason for the Arduino, is that the tiny processor (which draws less than a Pi and doesn’t mind being shut down abruptly) can log into the Pi and properly shut it down. The real advantage, though, is that you could use other Arduino inputs to determine when to turn the Pi on and off.

For example, it is easy to imagine a Pi in an automotive application where the Arduino would sense the ignition was off for a certain period of time and then go ahead and shut off the Pi. Or maybe the Pi needs to be turned on when a motion sensor fires and then turned off again once there is no motion for a particular time period. Any of these strategies would be simple to build with the Arduino.

We’ve seen a similar project that used an IR remote as the trigger instead of a physical button. If you are afraid the Pi will just lose power unexpectedly, you might consider a battery backup. If powering a Pi with regular electricity is too tame for you, try steam.

27 thoughts on “Raspberry Pi Gets Turned On

        1. It is better but not perfect. When the arduino is put on sleep the linear voltage regulator still consumes ~7mA which is not perfect for the car project. To really make it in uA area the linear regulator has to be chopped of and replaced with a impulse one. With this board https://www.olimex.com/Products/Duino/PIC32/PIC32-PINGUINO/open-source-hardware I was able to really go in the ~100uA consumption when the uC is in sleep mode … but PIC32 is a bit of an overkill for such a project … sooo let’s see how it will evolve

        1. >it reset the F/F and cuts off power.
          Can you share some more details? How the F/F will be reset? It cannot be done from the pi as then this will not be a graceful shutdown. One needs to wait for the PI to go off and only then cut the power.

  1. “shutting a Linux system down while it is running will eventually lead to file system corruption”
    Correct me if I’m wrong but I don’t think this is a Linux issue but an SD card issue, I’ve never had problems running Linux from a HD or SSD with occasional power disruptions.

    1. “shutting a Linux system down while it is running will eventually lead to file system corruption”
      best system to use on smartphones, routers, home entertainment and more ;)

      1. Y’all tend to forget they use different types of filesystems on all those set-top boxes, routers, smartphones etc. Nowadays it’s the filesystem that makes it possible. There were issues with Raspberries and SD cards which were a fault of the Pi software or even hardware, but I’m inclined to believe they’re gone now.
        Raspberry Pi still uses EXT4 (the FS that desktops/laptops typically use) though, and Raspberries are much more likely to get shutdown improperly than desktop PCs/laptops are.

          1. So you run your file system in ram anyway and limit SD card data with flags, so how is shutting down a problem? a cap and some simple discrete UPS circuit takes care of maintaining power to finish writes before shutdown. An Arduino is overkill.

          2. Which is why you almost always want to use a ro rootfs optionally with a rw overlayfs ontop of it.

            Thats how routers/phones etc handle this reliably. Worst case you reformat the rw partition.

            For updates etc either remount youur rootfs, or replace your underlaying fs (squashfs for example). using a rw fileaystem otherwise is high risk, even if it works out 99/100 times

    2. I tend to agree. There are countless embedded Linux based devices that can tolerate being powered off without ever having a problem (including my Roku that I do that to every single day). I was under the impression that this issue was unique to the Pi.

      1. The roku, your router, your tv all the other Linux embedded devices around you aren’t writing to a file system nearly ever and when they are it’s a separate volume in the device usually settings data that is no big deal to lose.
        The raspberry pi is essentially a desktop computer if you run default linux on it, it doesn’t intrinsically know it is any different than a laptop or desktop computer with an ssd and will access disk space accordingly.

        In short this is a hardware workaround a software problem, if you were to harden the OS into something more like an embedded system you could use the 12v switched power line to power your in vehicle PI.

    3. As someone who did shitloads and shitloads of testing on this subject. I can confirm. I never had filesystem corruption with recent journaling filesystems. SD cards on the other hand, they get random corruption, and corruption that NEVER goes away, not even after a full wipe with zeros. It looks like SD cards internal wear leveling can get corrupt and have “pointers” of 2 sectors to the same internal storage. Which pretty much means mayhem for your filesystem no matter the amount of journaling you have.

      1. TRIM/DISCARD should fix that unless the SD card has a buggy wear leveller.

        Such as some Samsung eMMCs which had such buggy wear levellers that issuing a secure erase command could send the thing permanently out into la-la-land.

    4. Most flash based linux devices use filesystem adapted to it (mainly ubifs, yaffs), but they requires MTD devices, not block SD cards.
      These filesystem are much more robust than ext4 on SD card.

    5. An SSD can give you corruption as well. It’s doing the same stuff as an SD card does. Lots of SSDs have big freaking caps on them to hold up the power supply for a brief bit to allow them to finish what they’re doing, though, so it hides it more. Still possible for them to get corrupted, though, it’s just much, much more unlikely. Enterprise computing SSDs have even bigger caps that allow them to do more, so it’s even more unlikely. But it’s “unlikely,” not “impossible.”

      It’s not just wear levelling that they’re doing, either. It’s probably error correction that’s the bigger culprit: NAND flash has errors that creep up over time, since *reading* data actually causes errors in adjacent cells, and NAND flash controllers hide this by detecting bit errors increasing, and rewriting the data (recovered via ECC) back to restore the data.

      That’s why even mounting an NAND-based filesystem read-only isn’t good enough to completely avoid filesystem corruption.

    6. Maybe there was an SD issue too. Some people here sound like they have heard of one but that it was fixed. The unfixed issue though is in that a Raspi is usually set up like a ‘real’ multi-purpose computer, even if you are really using it as an embedded device. Those set-top boxes, phones* and tablets* we are all used to powering off at will are not.

      Yes, the difference is the filesystem but it’s not as simple as “X filesystem can be corrupted if shut down properly while Y cannot”. If it was that simple why would even a desktop use a filesystem that can become corrupted?!?! The difference is that your embedded devices use READ ONLY filesystems. You aren’t going to make the mistake of powering off during some critical write operation because there are no write operations! Sure, maybe there is some area that gets written to for saving preferences. That area can be on a separate partition and mounted read only whenever you are not in the process of saving preferences. Also, the system can be smart enough so that if this preference area does get corrupted it reformats and writes default values automatically so the device keeps working to some degree. If there is anything else that is writable it’s some sort of cache area and that can easily just be reformatted if corrupted, no worries.

      As some have noted, Linux’s major writable filesystem types have gotten pretty good at recovering from journals and not getting corrupted from improper reboots. It is no surprise to see anecdotes that some people power them off live and don’t experience a problem. There is still some chance that one could get a disk corruption that way in fact I have experienced it myself with EXT4! They have made it really good but a writable filesystem is still a writable filesystem.

      * – Yes, smartphones/tablets are multi-purpose like a desktop but the part that is actually Linux (at least on Android) is usually set up as read/only. The actual general purpose computer part is something else running in a java-ish virtual machine on top of an embedded Linux system. The Linux part is normally read only. The exception is when you are in the process of changing the ROM image or performing some other kinds of ‘hacks’. For that you have to remount the normally read only filesystem as read/write so if something goes wrong you get corruption and thus no simple reboot for you!

      1. Read-only filesystems don’t help with MLC NAND flash filesystems, as in most SSDs and SD cards. For MLC NAND, simply reading the device can damage data (“read disturb”) and therefore observed ECC errors have to be fixed (by writing back the corrected data) to avoid lost data in the future. So writes occur to the medium even if no writes actually are issued to the controller.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.