Tales of Raspberry Pi SD card corruption are available online by the fistful, and are definitely a constant in Pi-adjacent communities. It’s apparent that some kind of problems tend to arise when a Raspberry Pi meets an SD card – which sounds quite ironic, since an SD card is the official and recommended way of booting a Pi. What is up with all of that?

I can start with a history lesson. Back when Raspberry Pi launched in 2012 – which is now 10 years ago – there were SD card controller driver problems, which makes sense given the wide variety of SD cards available out there. They were verifiably fixed one by one at some point in time, as debugging goes, their impact decreased and bugs with individual cards got smoothed over. This is how the “Pi SD card corruption” meme was originally born; however, if the problems were to end there, so would the meme. Yet, tales of broken SD cards plague us to this day – way less severe than they were in the beginning, but pronounced enough that you’ll see people encounter them every now and then.

Over the years, a devoted base of Pi SD card haters has grown. Their demand has been simple – Raspberry Pi has to get an ability to boot from something else, in large part because of corruption reasons, but also undeniably because of speed and capacity/cost limitations of SD cards. Thanks to their demands and work, we’ve seen a series of projects grow from unofficial efforts and hacks into officially supported Raspberry Pi abilities – USB boot being initially more of a workaround but now something you can enable out of the box, SSD-equipped Pi enclosures becoming more of a norm, and now, NVMe boot appearing on the horizon. Every few years, we get a new way to boot a Pi.

Should You Ditch SD Cards?

I’d like to make it clear – booting from an SSD or USB drive is a very nice option, and when you want your Pi to be fast, responsive, and reliable, you can absolutely try it. The SD card slot has stayed after all this time, is not about to disappear, and neither will all the SD cards in our drawers. Should you personally ditch SD cards? The answer is more likely to be “no” than “yes”.

Not everyone encounters SD card problems, with SD card images being the first thing available whenever you see a cool new project, and an SD-equipped Pi still a staple of an average maker contraption. Proponents of USB and network boot also cite improved latency for Pi-as-desktop usage, easier Pi management in case of network boot, and these alone are good reasons – but definitely not for every project out there. SD cards remain the simplest and cheapest option to boot a Pi.

You cannot always avoid SD card boot either. Booting a Pi Zero from an USB stick requires that you either waste your only USB port or add an entire USB hub into the mix, complicating the setup further, adding pesky cables and failure points. When it comes to portable and battery-powered devices built with a Pi, an SD card is hard to beat in terms of power consumption – USB flash drives aren’t known for being low-power-optimized, and neither are USB hubs, which you’ll notice if you check how warm a USB hub IC can get after passing a relatively low amount of USB packets.

In the end, even the most devoted external SSD booting enthusiasts might still want to add an SD card for the independent additional storage that it brings. The slot is there, and if you have a card to spare – why not use it? Unless you encounter problems, that is – so let’s go through those.

Why Do Cards Still Fail?

First of all, fake and cheap cards ruin the fun for everyone. MicroSD card clones are ever-present and hard to distinguish from legitimately made cards, but certainly not subject to the same quality standards. Cheap cards share the “low quality standards” part, but at least, you can recognize a no-name card by looking at it. Neither fake nor cheap cards are typically suitable for an entire OS to run from. They will not only make your Pi behave way more sluggishly than it actually can run, but will also result in mysterious failures and, later on, pretty explicit corruption. Getting decent cards from reputable places is part of a recipe for a calm Pi exploration journey, and nowadays, it doesn’t even really break the bank anymore, given the hefty amount of storage that you get for your money.

Even genuine cards can cause trouble. Our hackerspace bought a batch of genuine Samsung cards for our Pis back in 2014, and every single one of them has eventually died with the same symptoms – since every Pi used a card from the same batch, it ended up with hackerspace infrastructure dying out device-by-device, frustrating the members relying on it. After all, an SD card is a complex highly-integrated device, with the controller being a small purpose-built CPU – there’s room for firmware errors, manufacturing defects, and just good old hardware randomness. Supposedly, we are past this, but be wary.

It Is Now Safe To Turn Off Your SBC

Like majority of storage devices nowadays, an SD card has two separate entities inside – controller and flash memory. The controller has some flash management busywork to do whenever it gets sent some data to write, but doing it on the spot would be time-consuming, delaying subsequent write operations, and possibly wasteful. Subsequently, the SD card controller has to have a small piece of cache memory, and keep a list of operations that are yet to be performed but haven’t been.

This is the rationale behind “shutting down your Pi safely” aka “running poweroff before unplugging power” talking point – if you don’t give your SD card a bit of time and maybe even an automated advance notification from the OS, there might be pending write operations that will never get completed, resulting in garbled storage when you next power up the card. Some seasoned engineers claim that such shutdowns are eventually guaranteed to irreversibly break an average SD card long-term, due to how the cards work internally, and I wouldn’t argue with them on that.

Can you rely on an SD card even if unsafe shutdowns happen every now and then? My experience says “yes”. One of my first “engineering” role jobs was testing a Pi-based commercial device for exactly this problem, where I’ve built a test setup powering down a Pi during SD card writes and ran it for a few days, with our software still passing all the tests. To my knowledge, we shipped that hardware combination successfully long-term. With ZeroPhone, unconventional power management without a software counterpart to compensate for its shortcomings led to regular (sometimes even cyclical) brownouts every few days during a span of few years, whenever I’d forget to charge it. The SD cards I used survived quite well long-term and live to this day, save for an uneventful fsck every now and then.

My conclusion is that, while safe powerdowns are desired, being lax is not the end of the world, and many a hobbyist who has yanked the power cable out of their Pi carelessly will confirm this experience. However, if your software does a considerable amount of writing to the same SD card you run your OS from, perhaps you’d like to offload it somewhere else.

Don’t Cheap Out On Your PSU Either

There’s an unusual suspect to be mentioned, and that is power supply quality. Sometimes mentioned offhand, it’s an underappreciated reason, and I’ve had a years-long corruption-plagued hackerspace Pi debugging quest where that turned out to be the culprit. The Pi in question was the only one from an entire Pi network to get these issues, and was also powered by a hand-soldered LM2576 SMPS without a ground plane in sight – obviously the only viable solution at the time of build, which stayed there for ages because of the “hey, it works” human factor.

While the DC-DC doesn’t power the SD card directly — there’s a 5 V to 3.3 V regulator onboard for that — every single part of that setup, from the Pi to the filesystem, was replaced. Pis can be current-hungry, especially if they’re powering other USB devices. Thin cables and underspec supplies can lead to brownouts, and the poor SD cards pay the price.

Swapping the DC-DC to a regular blue “LM2596” module, reinforced with extra capacitors and thicker wires, was the solution that actually made the corruption problems disappear. There might be a lesson about noise propagation somewhere in there. For you, the conclusion I recommend, based on this and other similar but less puzzling experiences, is – obey the Ohm’s law in spirit, and make sure the path for juices to flow to your Pi isn’t constricted by an awfully thin and long MicroUSB or Type-C cable, or a DC-DC setup that turns out to be subpar.

New And Underappreciated Helpers

Nifty tricks appeared over the years that, if suitable for your use-case, will give you extra anti-corruption protection and undoubtedly provide some peace of mind. One such thing is the OverlayFS option in Raspbian, a small menu entry in raspi-config that was added sometime in 2019. If you enable it and reboot, your Pi will behave the same, but none of the changes you make will actually get written to your SD card – which also means they won’t get saved and will disappear after your reboot. If you want to change files on your SD card, you’ll want to disable OverlayFS, reboot, make the changes, re-enable OverlayFS and reboot again. There might be a way around this, but that’s for you to figure out.

A similar option is also available with sdtool, which is small piece of software you can run on your Pi that instead directs your MicroSD card to go into read-only mode – which all SD cards, big and small, are capable of. If you don’t run the latest Raspbian, or maybe you want to switch your card’s read-only status without reboot, this approach might could be basically made for you.

Something else you might want to try are eMMC chips. Designed to be suitable for an OS to run from, they also happen to be compatible with the SD card interface on the Raspberry Pi, and you’ll find some Pi-compatible ones for sale using your search engine of choice. Recently, someone who swore that they held one of these mythical Pi 4 Compute Modules (reportedly, for a few seconds) told me that they use onboard eMMC storage. Not that the Out Of Stock warnings make me feel hopeful I could ever really verify, but if that’s indeed the case, how bad could it be?

A Little Corruption Can’t Hurt

The amount of stories about Raspberry Pi card corruption is daunting, but it’s a drop in a bucket when you consider that forty million of them have been sold. This is the gist of what goes into a typical SD card corruption case. If you ever need to deal with pesky SD corruption problems, you now know what to look for, and likely learned some new variables you can tweak. Get a good card, a good power supply, and don’t let others’ negative experiences, real or rumored, get you down!