Raspberry Pi will not boot after power was cut: SD card corruption

Pulling the power while the Pi writes to the card can corrupt it. Shut down cleanly, and keep a backup image.

What the message means

The operating system writes logs and files all the time. A cut during a write leaves the file system inconsistent, and the boot may stop.

Fix it in this order

Shut the Pi down with the shutdown command before removing power.
Try the card in a computer and let it check and repair the file system.
Restore from a backup image if the repair fails.
Use a good brand card with enough capacity.
For a robot that loses power often, add a shutdown button or a small battery backup board.
Consider booting from an SSD, or keep the system partition read-only.

Why it happens

The operating system writes logs and other files in the background all the time. If power is cut during a write, the file system can be left half updated, and at the next boot the system may find damage it cannot repair on its own.

A clean shutdown finishes the pending writes first. Cards also differ in how well they cope with sudden power loss, so a backup image is the dependable way back, whichever card you use.

If you see this, do this

You see	Do this
Will not boot after a power cut	Repair or restore the card.
Cards fail often	Check power and card quality.

under-voltage, battery sag.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

An SD card is not a simple disk. Inside is a flash translation layer that moves data around, and the Pi’s file system keeps a journal of recent changes. If power is cut during a write, either layer can be left half-finished. The journal can usually replay at the next boot, but the card can still lose recently written blocks, and a card that is old or poor quality is more likely to fail.

A power supply that dips under load (the lightning bolt warning) causes the same kind of damage as a cut, because writes happen during the dip. Also, ‘will not boot’ can mean different things: nothing on the display, a rainbow screen, a stop at a kernel message or a prompt to repair the file system. Each points at a different layer.

How to confirm the cause

Watch the green activity LED after power-on. No flicker at all suggests the card is not read; a short flicker then nothing suggests missing or damaged boot files.
Connect a display and note the last message. File-system errors name the problem; ‘Kernel panic’ suggests a root partition problem.
Put the card in another computer. The small boot partition should show files such as cmdline.txt and config.txt; an unreadable card is a hardware failure.
Check the power supply separately with a meter at the test points or a known-good supply.
Make an image of the card before repair attempts.

Worked example

On another Linux machine, copy the card first, then check the root partition. Replace sdb with the device name that lsblk shows for your card; a wrong name can destroy other data.

lsblk                                    # find the card, e.g. sdb
sudo dd if=/dev/sdb of=backup.img bs=4M status=progress
sudo umount /dev/sdb2                    # must not be mounted
sudo fsck.ext4 -f /dev/sdb2              # check and repair root partition

Common mistakes

Running fsck on a mounted partition.
Picking the wrong device name.
Re-flashing straight away and losing files that could have been copied off.
Blaming the card when the real fault is an under-rated power supply.
Pulling the plug instead of running a proper shutdown.

If this did not fix it

The card is wearing out; test with a different, good brand card.
A damaged boot partition or a wrong entry in cmdline.txt.
A faulty card reader or cable making the card look unreadable.
Prevention for later: shut down with sudo shutdown -h now, wait for the LED to stop, or consider a read-only overlay file system for robots.