Raspberry Pi 4 Green ACT LED Blinking: Boot & SSH Fix
Diagnose Raspberry Pi 4 green ACT LED blinking: bootloader, SD/USB, EEPROM checks, power tests, serial logs and recovery steps to restore boot and SSH.
Raspberry Pi 4 green ACT LED blinking every second: troubleshooting no SSH access after sudden crash
My Raspberry Pi 4 worked normally until yesterday, when all SSH connections dropped and I could no longer connect. SSH shows ‘no route to host’, and ping reports ‘host not found’.
I reflashed the SD card (using a USB adapter for booting, which had worked fine for the past two weeks), but the problem persists. Now, the green LED blinks periodically every second. I also tried creating an empty ‘ssh’ file in the boot partition, but it didn’t enable SSH.
What does the periodic green LED blinking indicate on Raspberry Pi 4? How can I diagnose and fix the issue to regain SSH access?
Periodic one‑second green ACT LED blinking on a Raspberry Pi 4 normally means the boot process is failing early — the bootloader keeps polling the SD/USB device (a boot loop or “no boot device” state), so the network stack never starts and SSH won’t come up. Common causes after a sudden crash are SD/USB corruption or counterfeit media, power/voltage problems, EEPROM/bootloader corruption, or hardware damage; diagnose by checking PWR/LNK LEDs, testing a known‑good boot device, inspecting the boot partition (start.elf/kernel), and, if needed, using EEPROM recovery or a serial console for logs.
Contents
- What the periodic green ACT LED blinking means on Raspberry Pi 4
- Quick checks to try now (power, network, minimal hardware)
- Diagnose boot device: SD card, USB adapter and images
- EEPROM, serial console and advanced recovery for Raspberry Pi 4
- How to restore SSH access after a crash (step‑by‑step)
- Preventive measures to avoid future green‑LED boot loops
- Sources
- Conclusion
What the periodic green ACT LED blinking means on Raspberry Pi 4
The Raspberry Pi’s green ACT LED normally shows SD/boot activity; on failure it’s used to give diagnostic patterns (long flashes + sequences of short flashes) or a simple repeat pattern. A regular ~1‑second blink (an evenly spaced single blink repeating) is different from the multi‑flash error codes — it typically indicates the Pi’s bootloader is repeatedly polling for a boot device or stuck very early in the boot sequence, so the kernel/network never becomes available and SSH can’t start. See the official LED/error‑pattern explanation for details on blink codes and their meanings: the Pi’s ACT patterns are documented in support notes like this one and in community explanations https://support.pishop.ca/article/33-raspberry-pi-act-led-error-patterns and overview articles such as https://raspberrytips.com/green-and-red-light-on-raspberry-pi/.
Common causes for the one‑second periodic blink after a crash
- Boot media corruption (SD card, USB adapter, SSD image) or counterfeit card.
- Boot files missing/corrupt (e.g., start.elf or kernel images) — certain blink codes map to those files. See community notes about 4‑blink / start.elf problems: https://raspberrypi.stackexchange.com/questions/10579/green-led-blinks-4-times-did-i-brick-my-pi.
- Power/voltage instability (under‑voltage will cause odd behavior and crashes).
- EEPROM/bootloader corruption or misconfigured boot order (Pi 4 stores bootloader in EEPROM).
- Hardware damage from a short or surge (fast or unchanged blinking despite no media often points at board-level problems). Community and issue threads show these scenarios are common after a crash: https://github.com/raspberrypi/rpi-eeprom/issues/260.
So — one‑second blinking means “I’m trying, but I can’t find or start the OS” (or I’m stuck before I can start networking). That’s why pings return “host not found” and SSH reports “no route to host”: the Pi never reached the network stage.
Quick checks to try now (power, network, minimal hardware)
Before digging in, run a few quick, low‑risk checks. These often find the problem in minutes.
- Look at the power and Ethernet LEDs
- Red PWR LED should be steady. If it’s dim/absent, suspect the PSU or cable — use a known‑good, official 5.1 V 3 A USB‑C supply for Pi 4. Guides show PSU issues commonly cause boot problems https://www.easeus.com/computer-instruction/raspberry-pi-not-booting.html.
- The Ethernet port’s link/activity LEDs: if the link LED is off, the Pi either isn’t booted or the NIC/link is down — check cable/switch and router DHCP table for the Pi’s MAC/IP.
- Remove all USB peripherals and HATs
- Unplug every USB device, HAT, camera, HDMI capture dongle, and try booting with only power (and an HDMI monitor if available). Peripherals sometimes block or confuse the boot.
- Try a display + keyboard (if practical)
- Attach HDMI (use the HDMI0 port nearest the USB‑C) and a keyboard — if the Pi gets far enough in boot, the console will show errors and you can inspect boot messages.
- Test network discovery locally
- Check your router’s client list or ARP table instead of relying on ping. On your PC:
arp -aor open the router’s DHCP leases page — the Pi may have a different IP than you expect.
- Boot with no SD and note the LED behavior
- Remove the SD card and power on. If you see the specific multi‑blink codes (e.g., 4 blinks = start.elf missing) that’s useful diagnostic info; if the one‑second blink continues with no SD present, suspect EEPROM or hardware.
If any of the quick checks change the LED behavior (for example, the ACT stops one‑second blinking when you remove USB devices), you’ve likely found the culprit.
Diagnose boot device: SD card, USB adapter and images
You said you reflashed the SD card (using a USB adapter). That helps — but double‑check these specifics.
- Reflash with the official image and verify boot files
- Use Raspberry Pi OS (Lite for headless) and a reliable flasher (Raspberry Pi Imager or balenaEtcher). After flashing, mount the boot partition on a PC and confirm essential files exist (config.txt, start.elf, kernel image). If start.elf is missing or corrupt the Pi won’t get past the bootloader — many community threads reference this exact failure mode https://raspberrypi.stackexchange.com/questions/10579/green-led-blinks-4-times-did-i-brick-my-pi.
- Test the SD card and USB adapter on another machine
- Plug the SD card or USB adapter into a PC. Can you mount both partitions (boot and root)? Can you read files? If the adapter/SSD isn’t visible, the adapter may be dead. Counterfeit or failing SD cards are common failure points — test the card with a tool like h2testw (Windows) or by writing and re‑reading data.
- Try a known‑good SD card (or bare SD instead of USB adapter)
- A minimal test: use a different, known‑good microSD card directly (no adapter) flashed with Raspberry Pi OS. If that boots, the problem is your adapter or original media.
- If you were booting from USB (SSD/HDD), test USB boot specifically
- The Pi 4 uses an EEPROM bootloader that may have a set boot order (USB first, SD first, etc.). If the USB device stops being recognized, the Pi will fall back to SD polling and may show periodic blinking. Try the USB drive on a PC to verify it’s intact.
- Workaround for continuous SD polling
- If the Pi keeps polling and you need to stop that behavior to test USB boot, you can edit config.txt on the boot partition and add
dtparam=sd_poll_once(this reduces repeated SD polling — edit carefully). A number of forum posts show this as a useful troubleshooting tweak https://forums.raspberrypi.com/viewtopic.php?t=283125.
If none of these make the Pi boot, move on to EEPROM/serial checks.
EEPROM, serial console and advanced recovery for Raspberry Pi 4
When the ACT keeps blinking regardless of SD/USB presence, or if USB‑boot suddenly stops working after a crash, suspect the Pi 4’s EEPROM/bootloader or hardware fault.
- EEPROM / bootloader recovery
- Follow the Pi’s bootloader recovery procedure (make a recovery SD card and boot the Pi from it). Community recovery threads and the bootloader docs describe the process and expected results (rainbow screen, recovery activity): see the recovery discussion here and the bootloader troubleshooting notes https://forums.raspberrypi.com/viewtopic.php?t=298948 and the official bootloader docs referenced in forum guidance https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/BOOTLOADER.md#troubleshooting-boot-issues.
- Read bootloader logs via serial (best for advanced diagnostics)
- You can force the bootloader to emit logs to the UART by enabling BOOT_UART in the bootconf used by the recovery image and/or adding
uart_2ndstage=1to config.txt so the recovery stages log output. A guide to these tricks is discussed in forum posts about using serial logging for failed boots https://forums.raspberrypi.com/viewtopic.php?t=263609. - Hardware: use a USB‑TTL (3.3 V) serial adapter. Connect ground + TX/RX to the Pi’s UART pins (GPIO14 TXD, GPIO15 RXD — physical pins 8 and 10) while powered off, then power on and open a terminal at 115200 8N1 (e.g.,
screen /dev/ttyUSB0 115200). Watch the bootloader messages for clues.
- Known EEPROM/firmware bugs and crash aftermath
- There are GitHub issues where the Pi continued to flash without classic error codes after a bad update or corruption — that’s another sign to attempt EEPROM recovery rather than repeatedly reflashing the SD: https://github.com/raspberrypi/rpi-eeprom/issues/260.
- When to stop and suspect hardware failure
- If EEPROM recovery fails, serial logs show SDRAM errors, or the ACT behavior is identical with all known‑good media removed, the board may be damaged (short/surge). At that point test the suspected damaged Pi with minimal peripherals and compare behavior to another Pi; if the symptoms persist, contact your supplier or consider RMA/replacement.
How to restore SSH access after a crash (step‑by‑step)
Here’s a prioritized checklist to regain SSH quickly — follow top to bottom until your Pi is reachable.
Quick path (fast wins)
- Confirm power and link:
- Red PWR steady? Ethernet link light on? If not, fix power/cable/hardware first. PSU guidance: use a reliable 5.1 V 3 A USB‑C supply https://www.easeus.com/computer-instruction/raspberry-pi-not-booting.html.
- Swap media:
- Flash a known‑good microSD with official Raspberry Pi OS (use Raspberry Pi Imager). Mount the boot partition on your PC and add an empty file named
ssh(no extension) to enable headless SSH. If you’ve done that already and the Pi won’t boot, the problem is earlier in the chain (bootloader/media/hardware).
- Minimal hardware boot:
- Boot with only power, the test SD (no USB devices). If SSH appears (check router leases or
arp -a), you’re back online.
If the Pi still won’t appear on the network
4. Attach monitor/keyboard or use serial:
- If you can’t get SSH but a local console works, log in and run:
ip ato get the IPsudo systemctl status sshandsudo systemctl enable --now ssh- If you can’t attach a monitor, use the serial console method above to read boot messages.
- EEPROM recovery (if bootloader/USB issues suspected)
- Create and boot the EEPROM recovery SD card as documented and watch for the recovery screen/logs https://forums.raspberrypi.com/viewtopic.php?t=298948. After successful recovery, reflash the OS on your boot media and try again.
- If boots but no network
- Confirm network configuration (DHCP vs static). For headless Wi‑Fi, ensure
wpa_supplicant.confand country code are present on the boot partition before first boot. - Scan local network from your PC to confirm the Pi’s presence:
arp -aorsudo nmap -sn 192.168.1.0/24(only on your LAN). If the Pi shows up but port 22 is closed, remote into the local console and restart/enable sshd.
Last resorts
- Test the suspect SD or USB device in another Pi/PC.
- If serial logs show hardware faults (SDRAM, VPU, or persistent EEPROM errors), the board may be damaged and need replacement.
Preventive measures to avoid future green‑LED boot loops
- Use good power: official or high‑quality 5.1 V 3 A USB‑C supply; avoid cheap chargers.
- Use reputable microSD cards (buy from trusted vendors) or use NVMe/SSD + supported USB adapter, and verify media with tools. Counterfeit cards cause many sudden failures.
- Keep a spare recovery SD card with the EEPROM recovery image and a spare OS image for quick swap.
- Keep the Pi’s EEPROM/firmware reasonably up to date; test updates carefully.
- Configure a small serial console setup or enable remote logging so you can get diagnostics if it dies again.
- Use a UPS or power supervision if the device runs critical services to avoid rough shutdowns that cause corruption.
Sources
- Raspberry Pi Act LED Error Patterns - PiShop.ca Support Portal
- Green LED blinks 4 times, did I brick my Pi? - Raspberry Pi Stack Exchange
- Raspberry Pi Status LEDs Explained (Updated for Pi 5) – RaspberryTips
- Rpi 4 keeps flashing and do not boot · Issue #260 · raspberrypi/rpi-eeprom
- STICKY: Is your Pi not booting? (The Boot Problems Sticky) - Raspberry Pi Forums
- RPi 4 EEPROM recovery / how to use recovery SD - Raspberry Pi Forums
- How to Read Your Raspberry Pi’s LEDs and Troubleshoot Boot Issues - MakeUseOf
- The Red and Green Lights on the Raspberry Pi - Pi My Life Up
- My Raspberry Pi 4 will not boot / is faulty – The Pi Hut Support
Conclusion
A Raspberry Pi 4 whose green ACT LED blinks periodically every second has not completed early boot — the board is repeatedly polling for a boot device (SD/USB) or stuck in the bootloader, so SSH never starts. Work top‑down: verify power and link LEDs, boot a known‑good SD (or test your USB adapter on a PC), inspect the boot partition for start.elf/kernel, and if needed run EEPROM recovery and read serial boot logs to find the root cause. If the board still shows the same one‑second blink with all good media removed, you may be facing EEPROM corruption or hardware damage and should escalate to recovery or replacement.