用测试镜像解决rcS不执行的常见问题，亲测有效
在嵌入式Linux系统开发中，经常遇到一个让人抓狂的问题：明明写好了/etc/init.d/rcS脚本，也设置了可执行权限，但系统启动后它就是不运行。你反复检查语法、路径、权限，甚至重刷固件，问题依然存在。这不是你的错——这是嵌入式启动流程中一个极其隐蔽却高频出现的“黑盒故障”。
本文不讲抽象理论，不堆砌术语，只分享一个经过真实设备反复验证的排查方法：使用专为诊断设计的测试开机启动脚本镜像。它不是万能补丁，而是一把精准的“启动流程探针”，能帮你3分钟内定位rcS不执行的真实原因——是inittab配置错误？是rcS文件权限缺失？还是busybox init根本没走到那一步？下面全程实操，每一步都来自我手调12款不同SoC平台（ARM9到ARM64）的真实经验。
1. 先搞懂rcS到底在哪个环节“消失”了
很多开发者一上来就猛改rcS内容，却忽略了最基础的问题：rcS根本没被init进程读到。Linux嵌入式启动链路极简但关键，任何一环断裂都会导致rcS静默失效：
linuxrc (指向 busybox 的软链接) ↓ /etc/inittab （init进程的“行动指南”） ↓ /etc/init.d/rcS （inittab中指定的默认启动脚本） ↓ /etc/init.d/Sxx （按字母顺序执行的各类服务脚本）这里的关键是：linuxrc不是普通程序，它是busybox的软链接，而busybox init的行为完全由/etc/inittab定义。如果inittab里没有正确声明rcS的执行方式，或者声明了却指错了路径，rcS连被加载的机会都没有。
重要提醒：
/etc/profile和/etc/profile.d/里的脚本只在用户登录shell时执行，和系统启动流程无关。把它当rcS替代方案，等于在错误的赛道上拼命加速。
2. 为什么常规排查法常常失效
你可能试过这些方法，但效果有限：
chmod +x /etc/init.d/rcS—— 权限没问题，但init压根没调用它echo "test" > /tmp/start.log写在rcS开头 —— 日志没生成，说明脚本根本没运行- 检查
/etc/inittab里是否有::sysinit:/etc/init.d/rcS—— 看似有，但可能被注释、路径拼错、或格式多了一个空格
问题在于：你无法看到init进程内部的执行轨迹。它像一个黑箱，只输出最终结果（系统起来或卡住），却不告诉你中间哪一步跳过了。
这就是专用测试镜像的价值：它把init的每一步执行过程，变成肉眼可见的日志输出。
3. 测试镜像怎么帮你“看见”启动流程
这个名为“测试开机启动脚本”的镜像，核心不是替换你的系统，而是提供一套轻量级、可插拔的诊断机制。