Turning Off Raspberry Pi LED Guide

How to Disable Raspberry Pi LEDs: A Technical Investigation

Complete guide to turning off Raspberry Pi power, activity, and ethernet LEDs using config.txt parameters and sysfs commands for all Pi models.

The Unseen Challenge of Persistent Illumination

In environments where ambient light control matters—home theaters, darkrooms, discreet server closets—the Raspberry Pi's status LEDs present an understated but genuine problem. The red power indicator and green activity blinker, designed for diagnostic clarity, become sources of visual intrusion when the device operates continuously. This investigation examines the technical pathways available to suppress these lights, revealing a landscape complicated by hardware revisions, firmware updates, and model-specific architectures.

Understanding the LED Architecture

The Three Categories of On-Board Indicators

Raspberry Pi boards typically feature three distinct LED groups, each serving different purposes and controlled through separate mechanisms. The power LED (PWR), usually red, signals adequate voltage supply above 4.65V. The activity LED (ACT), typically green, reflects SD card or storage access patterns. Ethernet ports on models with wired networking include two additional indicators: link status (LNK) and data activity (ACT), colored amber and green respectively [[29]].

Hardware Evolution Complicates Software Control

Early Raspberry Pi models exposed LED control through straightforward sysfs interfaces, allowing direct manipulation via /sys/class/leds/led0 and led1 paths. However, beginning with the Raspberry Pi 3B+ and continuing through the 4B, 400, and Compute Module 4, the Foundation migrated LED control to a GPIO expander managed by the VideoCore processor [[13]]. This architectural shift rendered many legacy commands ineffective and introduced model-specific parameter requirements that persist in current firmware.

Persistent Configuration: The config.txt Method

Primary Parameters for LED Suppression

The most reliable approach for permanent LED deactivation involves editing the boot configuration file. Parameters prefixed with dtparam instruct the firmware to modify device tree behavior before the kernel initializes. For the activity LED, two directives work in concert:

dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

The first removes automatic triggering based on system events; the second ensures the LED remains off regardless of GPIO state [[4]].

Power LED Control Requires Model Awareness

Power LED configuration demands careful attention to firmware version and hardware model. For devices running firmware prior to August 2022, the directive dtparam=pwr_led_trigger=none successfully extinguished the red indicator. However, firmware updates distributed after that date altered this behavior for Raspberry Pi 3B+, 4B, 400, and CM4 models [[7]]. Current best practice for these devices combines two parameters:

dtparam=pwr_led_trigger=default-on
dtparam=pwr_led_activelow=off

This counterintuitive pairing—setting the trigger to "default-on" while inverting the active-low signal—achieves the desired suppression through firmware-level signal manipulation [[1]].

Ethernet LED Parameters Differ by Model

Disabling Ethernet port indicators requires model-specific values. On Raspberry Pi 3B+ hardware, the parameters dtparam=eth_led0=14 and dtparam=eth_led1=14 suppress both amber and green port LEDs. The Raspberry Pi 4B uses different values: dtparam=eth_led0=4 and dtparam=eth_led1=4 [[36]]. Users should note that Ethernet LEDs may remain illuminated for five to twenty minutes after configuration changes, as the network subsystem completes its initialization sequence before honoring the new parameters [[29]].

File Location Variations Across Operating Systems

Configuration file paths vary depending on the installed operating system. Standard Raspberry Pi OS uses /boot/config.txt. Ubuntu Server installations may require edits to /boot/firmware/config.txt or /boot/firmware/syscfg.txt depending on version [[2]]. Home Assistant OS stores the boot partition under the label hassos-boot, requiring users to mount that partition separately when editing from an external system [[6]].

Runtime Control: The sysfs Interface

Immediate but Non-Persistent LED Management

For temporary suppression without rebooting, the sysfs virtual filesystem provides direct access to LED control attributes. The activity LED typically responds to:

echo none | sudo tee /sys/class/leds/led0/trigger

The power LED, on newer systems, may require the explicit path /sys/class/leds/PWR/trigger rather than the legacy led1 designation [[21]]. Available trigger modes—visible by reading the trigger file—include none, default-on, heartbeat, mmc, and gpio, each defining different automatic behavior patterns.

Brightness Manipulation as an Alternative

When trigger modification proves ineffective, direct brightness control offers a fallback mechanism. Writing 0 to the brightness attribute forces the LED off regardless of trigger state:

echo 0 | sudo tee /sys/class/leds/PWR/brightness

This method works across most models but requires reapplication after each reboot, making it suitable for scripted solutions rather than permanent configuration [[14]].

Model-Specific Considerations and Troubleshooting

Raspberry Pi Zero and Zero 2 W

These compact models follow the legacy LED control scheme, with both PWR and ACT LEDs accessible via the led0/led1 sysfs paths. Configuration via config.txt parameters remains fully functional without the firmware complications affecting newer boards [[2]].

Raspberry Pi 4B and Later: Firmware Dependencies

Users attempting LED suppression on Pi 4B hardware should verify their firmware version before applying configuration changes. Systems updated after August 2022 require the pwr_led_activelow=off approach rather than the simpler pwr_led_trigger=none directive [[7]]. Ethernet LED control on the 4B remains partially hardware-bound; while the eth_led parameters reduce brightness, complete suppression may not be achievable through software alone on all revisions [[26]].

Raspberry Pi 5: Emerging Patterns

Early reports indicate the Raspberry Pi 5 introduces additional complexity, with some users reporting that standard Ethernet LED parameters fail to suppress port indicators [[34]]. As this model matures, firmware updates may resolve these inconsistencies, but current guidance suggests testing both Pi 4B parameter sets and monitoring community documentation for emerging solutions.

Frequently Asked Questions

Q: Why won't my Ethernet LEDs turn off after editing config.txt?
A: Ethernet LEDs on Raspberry Pi 4B may require 5–20 minutes to extinguish after configuration changes, as the network subsystem completes initialization before honoring new parameters. Additionally, some hardware revisions route Ethernet LED control directly through the PHY chip, limiting software suppression options [[29]].

Q: Which file should I edit on Ubuntu Server?
A: Ubuntu Server installations typically store boot configuration at /boot/firmware/config.txt. Older versions may use /boot/firmware/syscfg.txt. Verify the correct path by checking which file contains existing dtparam entries before making modifications [[2]].

Q: Can I control LEDs without rebooting?
A: Yes, runtime control via sysfs provides immediate effect. Use commands like echo none | sudo tee /sys/class/leds/PWR/trigger to modify LED behavior instantly. However, these changes reset on reboot; for persistence, combine runtime commands with a startup script or use the config.txt method [[21]].

Q: Why did my previously working config.txt settings stop functioning?
A: Firmware updates distributed in August 2022 altered LED control behavior for Raspberry Pi 3B+, 4B, 400, and CM4 models. The power LED parameter pwr_led_trigger=none ceased functioning on these devices, requiring the alternative pairing of pwr_led_trigger=default-on with pwr_led_activelow=off [[7]].

Q: Is physical obstruction the only option for stubborn Ethernet LEDs?
A: While software methods exist, Ethernet LED control remains partially hardware-dependent on some models. When configuration parameters prove insufficient, non-destructive physical solutions—such as small pieces of opaque tape or specialized LED-dimming stickers—provide reliable suppression without modifying the board [[33]].