手把手教你写开机启动脚本，让Armbian设备一开机就亮灯

手把手教你写开机启动脚本，让Armbian设备一开机就亮灯

1. 为什么你的LED总在开机后“迟到”？

你刚把Armbian刷进SD卡，接上LED，兴奋地按下电源——结果等了十几秒，LED才慢悠悠亮起来。你反复检查接线、确认GPIO编号、重试echo 1 > /sys/class/gpio/gpio6/value……手动执行完全没问题，可一重启，又回到原点。

这不是硬件故障，也不是系统bug，而是启动时机没踩准。

Armbian启动时，内核先加载驱动，再初始化用户空间，最后才轮到你的脚本。如果脚本跑得太早（比如在GPIO子系统还没准备好时就去操作/sys/class/gpio/），系统会直接报错：“No such file or directory”。如果跑得太晚，你已经看到登录提示符了，LED才姗姗来迟。

这篇文章不讲抽象理论，只做一件事：给你一套能立刻复制粘贴、开机即亮、稳定不翻车的完整方案。全程基于Armbian官方镜像（Debian/Ubuntu底座），不依赖第三方工具，不修改内核，不碰复杂配置——只用两段代码、三个命令，搞定从零到亮灯。

2. 先搞清：Armbian到底用什么管开机？

2.1 systemd才是真正的“总调度员”

Armbian默认使用systemd作为PID 1进程，这是它和老式Linux最根本的区别。你可以马上验证：

ps -p 1 -o comm=

输出一定是：

systemd

这意味着：
所有开机任务，最终都由systemd统一调度；
即使你写了/etc/init.d/gpio-init.sh，systemd也会把它包装成一个临时服务来运行；
直接写systemd service文件，才能真正掌控启动顺序、依赖关系和错误处理。

2.2 别被/etc/init.d/目录骗了

Armbian保留/etc/init.d/目录，是为了兼容旧脚本。但它的本质是“systemd的翻译层”——当你执行sudo update-rc.d gpio-init.sh defaults，systemd会在后台生成一个等效的unit文件，并注册到启动流程中。这种兼容模式有两大隐患：

• 启动顺序靠文件名排序（S01、S02），无法精确指定“必须在GPIO驱动加载之后”；
• 出错时日志分散，排查困难。

所以结论很明确：新项目，一律用systemd service。这不是炫技，是让脚本真正可靠的第一步。

3. 实战：三步写出“一开机就亮”的LED脚本

我们以GPIO6控制LED为例（实际请根据你的开发板手册确认引脚编号）。整个过程无需重启即可验证，每一步都有明确反馈。

3.1 第一步：写一个干净、健壮的LED控制脚本

创建脚本文件，路径固定为/usr/local/bin/led-on-boot.sh（放在这里符合FHS标准，且不会被系统更新覆盖）：

sudo nano /usr/local/bin/led-on-boot.sh

粘贴以下内容（已做关键加固）：

#!/bin/bash # 设置严格错误处理：任何命令失败立即退出 set -e # 定义LED引脚（按需修改） LED_PIN=6 # 确保GPIO子系统已就绪（等待最多5秒） for i in $(seq 1 5); do if [ -d "/sys/class/gpio/gpio${LED_PIN}" ]; then break fi if [ -e "/sys/class/gpio/export" ]; then echo ${LED_PIN} > /sys/class/gpio/export 2>/dev/null || true sleep 0.5 else sleep 1 fi done # 配置引脚方向为输出 echo "out" > /sys/class/gpio/gpio${LED_PIN}/direction 2>/dev/null || { echo "ERROR: Failed to set direction for GPIO ${LED_PIN}" >&2 exit 1 } # 点亮LED（高电平点亮，若为低电平有效请改为echo 0） echo "1" > /sys/class/gpio/gpio${LED_PIN}/value 2>/dev/null || { echo "ERROR: Failed to set value for GPIO ${LED_PIN}" >&2 exit 1 } # 可选：记录成功日志（便于后续排查） logger "LED on GPIO ${LED_PIN} turned ON at boot"

关键设计说明：

• set -e确保任意步骤失败立即终止，避免半截操作导致状态混乱；
• 循环等待/sys/class/gpio/gpio6目录出现，解决“驱动未就绪”问题；
• 所有echo操作加2>/dev/null || { ... }，失败时输出清晰错误信息；
• 使用logger写入系统日志，后续可用journalctl -u led-on-boot.service查看。

保存后赋予执行权限：

sudo chmod +x /usr/local/bin/led-on-boot.sh

3.2 第二步：创建systemd服务单元文件

创建service文件，路径必须为/etc/systemd/system/led-on-boot.service：

sudo nano /etc/systemd/system/led-on-boot.service

内容如下（精简无冗余，专注核心逻辑）：

[Unit] Description=Turn ON LED at boot Documentation=https://armbian.com After=multi-user.target # 关键：确保在GPIO子系统就绪后再启动 Wants=sys-devices-platform-soc-soc:gpio-keys.device BindsTo=sys-devices-platform-soc-soc:gpio-keys.device # 若你的板子无gpio-keys，改用通用等待（取消下一行注释） # After=sysinit.target [Service] Type=oneshot ExecStart=/usr/local/bin/led-on-boot.sh RemainAfterExit=yes # 防止因权限问题失败 User=root Group=root [Install] WantedBy=multi-user.target

为什么这样写？

• After=multi-user.target：确保在基础系统服务启动完毕后运行；
• Wants+BindsTo：强制依赖GPIO硬件设备（Armbian常见路径），比单纯After更可靠；
• Type=oneshot+RemainAfterExit=yes：脚本执行完不退出服务，方便后续状态查询；
• 显式指定User=root：避免systemd默认以非root用户运行导致权限不足。

3.3 第三步：启用并验证服务

刷新systemd配置，启用服务，立即启动测试：

sudo systemctl daemon-reload sudo systemctl enable led-on-boot.service sudo systemctl start led-on-boot.service

验证是否成功：

# 检查服务状态（应显示active (exited)） sudo systemctl status led-on-boot.service # 查看详细日志（重点关注最后一行是否含"turned ON"） sudo journalctl -u led-on-boot.service -n 20 --no-pager # 手动检查LED物理状态（万用表测电压或肉眼观察） cat /sys/class/gpio/gpio6/value

如果cat输出1且LED亮起，说明脚本已生效。此时重启设备：

sudo reboot

等待约10秒，LED应在系统登录提示符出现前即点亮——这才是真正的“开机即亮”。

4. 常见问题与稳如磐石的解决方案

4.1 问题：重启后LED不亮，systemctl status显示failed

原因：GPIO引脚被其他服务占用（如串口、I2C、SPI复用），或硬件初始化顺序异常。

解决：

1. 先查冲突：dmesg | grep -i "gpio\|pinmux"，看是否有警告；
2. 换一个确定未被占用的GPIO（如GPIO12、GPIO13，避开UART/TX/RX）；
3. 在service文件中增加延迟（不推荐，仅作临时诊断）：

   ExecStartPre=/bin/sleep 2

4.2 问题：/sys/class/gpio/gpio6目录始终不存在

原因：内核未启用该GPIO，或设备树未正确配置。

解决：

• 查看当前支持的GPIO：ls /sys/class/gpio/，若为空，说明驱动未加载；
• 加载GPIO模块（Armbian通常已内置，此步备用）：

  sudo modprobe gpio-mockup

• 检查设备树：sudo armbian-config→ System → Hardware → 确认GPIO选项已启用。

4.3 问题：想让LED闪烁而非常亮，怎么改？

只需修改脚本中的echo "1"部分。例如实现开机后闪烁3次再常亮：

# 替换原脚本中"点亮LED"部分为： # 先闪烁3次 for i in {1..3}; do echo "1" > /sys/class/gpio/gpio${LED_PIN}/value sleep 0.3 echo "0" > /sys/class/gpio/gpio${LED_PIN}/value sleep 0.3 done # 最后常亮 echo "1" > /sys/class/gpio/gpio${LED_PIN}/value

注意：sleep在systemd服务中默认可用，无需额外安装。

5. 进阶技巧：让脚本更智能、更省心

5.1 一键部署脚本（复制即用）

把上述所有步骤封装成一个可执行脚本，存为deploy-led.sh：

#!/bin/bash LED_PIN=${1:-6} SCRIPT_PATH="/usr/local/bin/led-on-boot.sh" SERVICE_PATH="/etc/systemd/system/led-on-boot.service" # 写脚本 cat > "$SCRIPT_PATH" << EOF #!/bin/bash set -e LED_PIN=$LED_PIN for i in \$(seq 1 5); do if [ -d "/sys/class/gpio/gpio\${LED_PIN}" ]; then break; fi if [ -e "/sys/class/gpio/export" ]; then echo \${LED_PIN} > /sys/class/gpio/export 2>/dev/null || true; sleep 0.5; else sleep 1; fi done echo "out" > /sys/class/gpio/gpio\${LED_PIN}/direction 2>/dev/null || { echo "ERROR"; exit 1; } echo "1" > /sys/class/gpio/gpio\${LED_PIN}/value 2>/dev/null || { echo "ERROR"; exit 1; } logger "LED on GPIO \${LED_PIN} ON" EOF # 写service cat > "$SERVICE_PATH" << EOF [Unit] Description=LED on GPIO $LED_PIN After=multi-user.target Wants=sys-devices-platform-soc-soc:gpio-keys.device BindsTo=sys-devices-platform-soc-soc:gpio-keys.device [Service] Type=oneshot ExecStart=$SCRIPT_PATH RemainAfterExit=yes User=root [Install] WantedBy=multi-user.target EOF # 赋权并启用 sudo chmod +x "$SCRIPT_PATH" sudo systemctl daemon-reload sudo systemctl enable led-on-boot.service sudo systemctl start led-on-boot.service echo " Deployed! LED on GPIO $LED_PIN will light at next boot."

使用方法：

chmod +x deploy-led.sh sudo ./deploy-led.sh 12 # 指定GPIO12

5.2 多LED协同控制

只需扩展脚本中的引脚列表。例如同时控制GPIO6、GPIO12、GPIO13：

# 在led-on-boot.sh中替换LED配置部分： LED_PINS=(6 12 13) for pin in "\${LED_PINS[@]}"; do echo \${pin} > /sys/class/gpio/export 2>/dev/null || true echo "out" > /sys/class/gpio/gpio\${pin}/direction echo "1" > /sys/class/gpio/gpio\${pin}/value done

6. 总结：你真正掌握的不是脚本，而是启动控制权

到这里，你已经完成了三件关键事：
写出一个带错误处理、自动等待、日志记录的健壮LED脚本；
创建了精准依赖GPIO硬件的systemd service，彻底告别启动时机失控；
掌握了从验证、调试到一键部署的完整工程化流程。

这不再是一个“让灯亮”的小技巧，而是你深入Armbian启动机制的第一块基石。后续无论是挂载USB硬盘、启动AI模型服务，还是配置网络摄像头，你都能用同一套思路：找准依赖、写好脚本、交给systemd。

真正的嵌入式开发，从来不是堆砌功能，而是对每一毫秒启动时机的掌控。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。