A Raspberry Pi will not boot: narrow the problem

Preserve the last known state

Write down what changed immediately before the problem: image preparation, update, power supply, display or storage. Record the board model, image release and whether this installation previously worked. A first boot and a regression need different evidence.

Keep the original card intact while collecting information. Reimaging may remove the only copy of settings, history and failure evidence. If a clean comparison is appropriate, prepare separate spare media instead.

Check whether the problem is only the picture

Confirm the display is powered and set to the intended input. Check the documented display connection for the board. If the host already had a working network setup, see whether its dashboard is reachable from another device.

A reachable dashboard with a blank attached display points toward the display path. An unreachable dashboard does not, by itself, prove the operating system failed; networking or the application could be the missing part.

Capture the boot evidence

Observe indicator behavior and any screen message. Record the complete pattern or photograph the diagnostic screen rather than paraphrasing it as “flashing.” Match the evidence to the exact board’s documentation.

Raspberry Pi’s hardware guide describes boot diagnostics and LED warning codes. Use its current table; a remembered flash count from another model or failure can send the investigation in the wrong direction.

Change one variable with a purpose

Review the supply and media against their documented requirements. If using spare verified media, state what the comparison is testing. A supported stock OS boot can help isolate hardware from a particular image, but it does not validate Sunstead’s application or equipment connection.

Do not start by changing bootloader settings or applying random forum commands. Those changes add variables and may alter a previously useful configuration. Follow official recovery instructions only when the evidence points to that layer and you understand what the procedure changes.

Know when the evidence is sufficient to escalate

• Exact board, supply and storage details.
• Release filename and verification results.
• First installation or last successful boot date.
• Exact diagnostic text or indicator pattern.
• Whether another device can reach the host.
• Each comparison performed and its result.

The current Sunstead Pi 5 community image has software and image checks completed, with physical first-boot verification pending. Report a failed first boot against that release status rather than assuming a proven hardware combination.

Stop once the next step would destroy needed data or requires a recovery procedure you cannot verify. A concise report with preserved media is a better starting point for support than several undocumented reinstalls.