用BusyBox手工构建嵌入式Linux根文件系统：原理与实践

最近在调一块基于ARM Cortex-A7的板子，需要把整个系统镜像从零开始拼起来。前后折腾了两周，绕了不少弯路，最后发现整套流程里最顺手、也最离不开的，还是BusyBox这套工具集。很多朋友一提嵌入式Linux，要么直接拿Buildroot整包生成，要么干脆用发行版文件系统裁剪，真正愿意从BusyBox手工搭建的人反而不多。我觉得这块内容值得好好聊一聊——它既是理解根文件系统运作原理最快的一条路，也是排查启动问题、做系统瘦身时的基本功。

这篇文章我会从BusyBox的定位和核心机制讲起，再带大家完整走一遍用BusyBox构建根文件系统的流程，最后把我实际踩过的坑和排查经验一并整理出来。无论你刚入门嵌入式Linux，还是已经做了几年开发想回来补补底子，这套思路应该都能用得上。

1. 为什么嵌入式Linux绕不开BusyBox

先聊聊最基础的问题：BusyBox到底解决的是什么。简单说，它是一个把上百个常用Unix命令压缩到单个可执行文件里的工具集合，目标平台就是资源受限的嵌入式系统。一个完整的Linux用户空间动辄几百MB，光coreutils、util-linux、procps这些基础包装下来，Flash存储和内存小的板子根本扛不住。而BusyBox把ls、cp、mount、init、sh这些工具全部塞进同一个二进制，裁剪得当的话，几百KB就能跑起来。

我在项目里最直观的感受是：BusyBox不只是一个命令集合，它实际上扮演了三层角色。第一层是命令层，给系统提供日常操作所需的shell工具；第二层是init层，它内置的init程序直接作为PID 1进程，负责系统启动后的初始化流程；第三层是服务层，像httpd、telnetd、dropbear这些网络服务也能以applet的形式集成进来。这意味着你只要搞定BusyBox，等于同时搞定了用户空间最核心的骨架。

说到这儿必须强调一下：很多人误以为用了BusyBox就不用学标准Linux命令了，这个想法是大错特错的。BusyBox的实现本来就是向POSIX标准看齐的，很多参数选项和GNU工具集不一样，尤其是带了明显瘦身痕迹的功能子集。如果你一开始就抱着“反正命令差不多”的心态上手，后面调试脚本时会非常难受。正确的心态是：BusyBox是标准命令集在受限环境下的一种平衡实现，理解了标准再来看它就很容易懂，反过来直接硬记它那些奇怪选项，效率反而低。

2. BusyBox的核心机制：Applet与构建原理

要真正用好BusyBox，建议先弄明白它的Applet机制。所谓Applet，是指BusyBox内部一个个功能模块的统称，每个模块对应一个传统命令的实现，比如ls applet实现ls、cat applet实现cat。这些Applet共享同一套公共代码，包括内存管理、字符串处理、文件操作封装等等，所以整体占用做得很小。

编译的时候，CONFIG_xxx配置项决定哪些Applet被编译进最终的busybox二进制。比如CONFIG_LS=y表示把ls功能编进去，CONFIG_FEATURE_LS_COLOR=y表示给ls加上颜色显示支持。配置项基本可以分为三类：第一类是功能开关，决定某个命令是否存在；第二类是特性开关，决定该命令支持的参数和高级特性多不多；第三类是全局行为配置，比如是否使用静态链接、交叉编译工具链前缀、安装路径等。实际配置时千万不要直接全选，BusyBox最大的坑之一就是“功能开多了体积失控，开少了干活的时候发现命令不支持某参数”。

再说说多调用（multi-call）原理。BusyBox对外暴露的入口函数叫busybox_main，真正的init、ls、cp这些实现点则命名为ls_main、cp_main。当你在shell里输入命令时，系统通过符号链接或调用路径识别命令名，busybox_main拿到argv[0]里的程序名，在applet表中找到对应的main函数并跳转过去执行。整个过程就是一次数组查表和函数指针调用，所以BusyBox即使带了几百个命令，执行效率也非常可观。

静态链接和动态链接的选择也值得展开讲讲。动态链接出来的busybox体积最小，因为依赖的glibc库是外置的，但它要求目标板根文件系统里自带对应的C库和动态链接器（ld-linux）。静态链接则是把所有用到的库代码直接编进二进制，体积会膨胀几倍，但部署起来非常省心，一个文件拷进去就能跑。我的习惯是：调试阶段优先静态链接，减少库文件不匹配带来的不稳定因素；产品化阶段再根据Flash空间评估是否切回动态链接。这里有一个细节：如果你准备在目标板上运行其他动态编译的应用程序，那么根文件系统无论如何都要带C库，这时候BusyBox再选择动态链接更划算，因为库文件是公用的。

3. 手把手实践：用BusyBox构建根文件系统

接下来进入最核心的实操环节。我用的是最经典的做法：交叉编译BusyBox，手动搭建根文件系统目录，然后通过NFS挂载方式启动验证。这样做的好处是修改文件系统里的内容不需要反复刷写Flash，在开发阶段效率极高。

3.1 交叉编译环境准备

先准备好交叉编译工具链。不同目标架构用的工具链前缀不一样，ARM平台常见的有arm-linux-gnueabihf-，aarch64平台则是aarch64-linux-gnu-。检验工具链是否可用的最快方法是执行：

arm-linux-gnueabihf-gcc -v

能看到版本信息就说明环境没问题。然后从BusyBox官网下载源码包，我这里用的是1.36.1版本。解压后进入源码目录，先做一次默认配置的编译，确认整条链路是通的：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8

编译产物就是当前目录下的busybox文件，用file命令查看它的架构信息，确认是ARM格式。这一步不出错，就可以进入精细配置阶段了。

3.2 按需裁剪配置

精细配置的核心是make menuconfig。这里强调一个一定要改的选项：Settings → Build Options → Build static binary (no shared libs)。如果你打算静态链接，就把这项打开；动态链接的话保持关闭。静态链接后你的根文件系统里可以暂时不放任何库文件，调试阶段最省事，推荐新手先从这个模式开始。

其他配置项不要盲目全开。我的建议是先按默认配置走，把目标板真正用到的命令补齐，而不是一开始就追求大而全。比如不需要图形界面就别开dialog相关的组件，不需要拨号上网就别选ppp。保守配置生成的busybox大概1MB左右，对Flash和内存都非常友好。配置完成后同样执行编译：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8

编译通过后，执行安装到指定目录：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_PREFIX=/opt/rootfs install

这会在/opt/rootfs下生成bin、sbin、usr/bin、usr/sbin目录，以及linuxrc这个关键文件。linuxrc实际上是busybox的符号链接，内核启动后第一个执行的就是它，它会完成基础环境初始化后切换到真正的init进程。

3.3 搭建根文件系统目录骨架

安装完BusyBox之后，还需要手动补充其他目录。根文件系统必备的目录有：

cd /opt/rootfs mkdir -p dev proc sys tmp etc/init.d lib mnt opt root home var/log

每个目录的用途要心里有数：dev是设备文件挂载点，proc和sys是虚拟文件系统挂载点，etc存放配置文件，lib放动态库，mnt是外部存储的挂载点。这些不是随便建着好看的，内核启动后init脚本会根据这些路径去做对应操作。

如果选择了动态链接BusyBox，这里一定要把交叉工具链里的C库复制到lib目录。用下面命令查看busybox依赖哪些动态库：

arm-linux-gnueabihf-readelf -d busybox | grep NEEDED

输出会有libc.so.6、ld-linux-armhf.so.3之类的条目，再去工具链的sysroot目录里把这些库文件拷到lib目录。库文件版本一定要和工具链匹配，否则后面启动时会出现init: error while loading shared libraries: 之类的错误。

3.4 配置内核启动参数

根文件系统造好了，怎么让内核找到它？如果是NFS方式挂载，内核命令行需要下面这些参数：

root=/dev/nfs nfsroot=<服务器IP>:<导出路径>,v3,tcp ip=dhcp console=ttyS0,115200

<服务器IP>是Ubuntu主机的IP，<导出路径>是NFS导出的根目录，比如/opt/rootfs。这里尤其要注意nfsroot里不能漏了版本参数，默认NFSv4在内核早期阶段可能因为没加载相关模块而挂载失败，显式指定v3并用tcp是最稳的组合。IP获取方式如果网络环境有DHCP就写ip=dhcp，没有就手动指定静态IP：

ip=<板子IP>:<服务器IP>:<网关>:<子网掩码>:<主机名>:<网卡名>:off

这个参数格式顺序固定，写错一个冒号内核都能正确解析，但写错地址一定会导致挂载失败。调试NFS启动时，如果卡在VFS: Unable to mount root fs，优先检查server端的/etc/exports导出配置和参数是否把文件系统权限导出为no_root_squash，否则后续在开发板上操作文件会频繁出现Permission denied。

3.5 编写init进程配置

根文件系统的最后一块拼图是init配置。BusyBox的init进程启动时会读取/etc/inittab文件，逐行执行里面的启动动作。一个最简的inittab长这样：

::sysinit:/etc/init.d/rcS ::askfirst:-/bin/sh ::ctrlaltdel:/sbin/reboot ::shutdown:/bin/umount -a -r

这里的语法结构是 : : : 。大部分嵌入式系统不关心runlevel，直接留空即可。sysinit动作会在系统启动早期执行初始化脚本，askfirst则是在串口终端上显示Please press Enter to activate this console，按回车后才启动shell，避免shell在系统启动过程中抢占串口输出。

然后是/etc/init.d/rcS脚本，这是系统初始化动作的集中营。我常用的rcS内容如下：

#!/bin/sh mount -t proc none /proc mount -t sysfs none /sys mount -t tmpfs none /tmp mdev -s

mount命令分别挂载proc、sysfs和tmpfs，mdev -s是BusyBox内置的设备管理器，用来根据内核sysfs信息自动生成设备节点。如果你在dev目录下手动创建了设备节点但设备不工作，往往就是因为没有运行mdev -s去动态刷新。记得给rcS加执行权限：

chmod +x /opt/rootfs/etc/init.d/rcS

到这里，一个能跑的根文件系统就算基本完工了。用QEMU或者直接烧到开发板上，内核起来后应该能顺利看到BusyBox的init输出，然后进入shell提示符。

4. 实战心得：启动过程中的典型“坑”

构建根文件系统本身不难，难的是出了问题之后怎么快速定位。我把自己调试过程中反复遇到的几类问题整理了出来，希望对你排查时有点帮助。

4.1 内核panic：找不到init进程

最常见的内核恐慌信息是：

Kernel panic - not syncing: No init found. Try passing init= option

这个错误出现时，先确认CONFIG_PREFIX安装目录下有没有linuxrc，以及它的权限是不是可执行。然后是检查内核命令行里root参数是否指向了正确的设备或NFS路径。还有一次我折腾半天，最后发现是/etc/inittab里写错了path，init进程fork出来的shell路径不对，直接秒退导致不断重启循环。排查init问题有个笨办法：内核启动参数里加init=/bin/sh，如果能看到shell，说明文件系统本体是好的，问题在init配置，如果连shell都起不来，那就是文件系统内容或挂载的问题。

4.2 mdev生成的设备节点不对

有些设备需要动态申请主设备号，比如USB转串口芯片，mdev -s如果没在正确时机执行，设备节点就不会生成。最典型的症状是插上USB设备后/dev下面找不到ttyUSB0。排查时可以手动执行mdev -s，然后立即ls /dev查看。如果mdev没有生效，确认内核是否开启了CONFIG_UEVENT_HELPER，以及sysfs是否正确挂载到了/sys。此外mdev的配置文件/etc/mdev.conf也不是必须的，默认行为已经能处理绝大多数设备，需要自定义权限和命名时才需要编写这个文件。

4.3 根文件系统只读导致服务起不来

很多NFS导出的根文件系统默认是只读的，程序写日志、创建临时目录都会失败。遇到这种情况，先mount命令确认根分区的挂载状态。如果要临时让根文件系统可写，重新挂载一下：

mount -o remount,rw /

但要注意NFS导出配置里如果没有rw权限，remount也白搭。排查这类问题的顺序是：先看mount输出确定当前挂载选项，再看NFS服务端的导出参数，最后才去查脚本里的写入路径是否存在。一个很容易忽略的细节是，/tmp目录在rcS里被挂载成tmpfs后才是可写的，如果你在早于rcS执行的脚本里尝试写/tmp，因为tmpfs还没挂载，写入会失败，这在我调试一个开机自启脚本时困扰了很久。

4.4 BusyBox的shell和标准bash差异

在写启动脚本时，建议全程用BusyBox的ash语法规范来约束自己。ash是bash的子集，很多bash的高级特性它不支持。比如数组、[[ ]]条件表达式、${var^^}这种大小写转换操作，ash里要么没有要么行为不同。我的经验是：脚本里尽量避免使用bash特有语法，能用POSIX语法解决的绝不用扩展语法。一个典型的坑是for循环的写法：

for i in {1..10}; do echo $i; done

这段在bash里能跑，在ash里会直接输出{1..10}字面量。正确写法是：

i=1 while [ $i -le 10 ]; do echo $i; i=$((i+1)); done

这类问题往往在开发机上测试完全没有异常，一放到开发板上就各种诡异，排查起来又不容易想到是shell解析器的锅。

5. 丰富的扩展：把BusyBox用得更顺手

当你的根文件系统能正常启动后，可以陆续把一些实用组件集成进来，让开发调试效率大幅提升。这里分享几个我经常用的扩展方向。

5.1 集成Dropbear实现SSH登录

板子插着串口线调试确实能凑合用，但串口线长了不方便，还是SSH最舒服。Dropbear是一套专为嵌入式环境设计的轻量SSH服务端，和BusyBox配合非常默契。集成流程是：先交叉编译dropbear，把生成的可执行文件和密钥生成工具拷贝到根文件系统，然后在rcS里加上启动语句。默认配置下dropbear会监听22端口，登录方式和OpenSSH完全一致。生成的host key注意用绝对路径存放，建议放在/etc/dropbear目录。

5.2 开启BusyBox内置的HTTP服务

如果你只是想简单看一下板子上的运行状态，BusyBox自带了一个迷你httpd，几十行配置就能启动：

httpd -p 8080 -h /www

把一些监控页面放到/www目录，浏览器里直接访问即可。这个httpd功能虽然简单，但支持CGI脚本，可以用来做一些简单的远程控制页面。需要注意默认的index.html文件名大小写，服务器是区分大小写的，而且访问目录时如果找不到index文件会返回Forbidden，调试时经常被这两个细节坑到。

5.3 加入网络调试工具

开发板的网络调试离不开一些基础的网络命令。BusyBox默认带了ping、ifconfig、route、nslookup等命令，但像tcpdump、iperf这类更专业的工具就需要额外集成。tcpdump交叉编译有点繁琐，依赖libpcap，但有了它之后排查网络问题会方便很多。如果资源紧张，busybox自带的nc（netcat）也能解决很多问题，比如快速测试某个TCP端口是否开放、转发文件等。

5.4 结合AWTK等GUI框架的场景

群里经常有人问AWTK这种GUI框架怎么跑在嵌入式Linux上，会不会和BusyBox冲突。其实它们之间完全不冲突：BusyBox管理的是系统基础服务和shell环境，GUI框架是用户空间的一个应用程序。但要注意的是，如果你要在板子上跑AWTK或Qt这类图形程序，文件系统里至少要有framebuffer设备节点（/dev/fb0），同时需要确认内核开启了对应的显示驱动。很多情况下还要为GUI程序准备足够的内存和swap空间，这就回到了我们前面说的，根文件系统的可写性、tmpfs挂载等基础配置必须正确，否则图形程序启动时会莫名其妙崩溃。

6. 问答速查与学习路线建议

6.1 BusyBox常见问题速查

6.2 学习路径建议

想做扎实的嵌入式Linux开发，建议学习路径不要倒着走。我的顺序建议是：先学会编译内核，理解设备树和启动流程；接着用BusyBox手工搭建根文件系统，这一步能强迫你理解init、挂载、设备节点、C库依赖这些最核心的概念；然后开始给板子移植驱动，把设备节点和实际硬件对应起来；最后再引入构建工具（Buildroot/Yocto）做产品化打包。直接拿着Buildroot点几个选项就生成镜像，容易造成很多环节知其然不知其所以然，遇到问题会无从下手。

韦东山老师那套视频教程也是不少朋友入门的首选，它的路径差不多也是从裸机到内核再到根文件系统，这个顺序本身就是经历过大量实践验证的，跟着走基本不会偏。

从我个人的体会来说，刚开始手工搭建根文件系统确实比较繁琐，尤其是库依赖、设备节点加上mdev这块，很容易把人绕晕。但正因为经历了这个“笨功夫”，我对Linux系统启动过程的每一个步骤才有了真正具体的认知——内核到init之间发生了什么、为什么dev目录必须存在、动态库版本不匹配会造成什么样的后果，这些问题不再是书本上的概念，而是亲眼见过、亲手调试过的东西。这套基本功，哪怕后来你用再高级的构建工具，也永远是排查问题的底层底气。