做嵌入式Linux绕来绕去最终还是绕不过两样东西根文件系统以及那个被称为瑞士军刀的BusyBox。我见过不少刚入行的朋友一提到BusyBox就以为只是个瘦身版Linux命令行拿着它当普通工具包用遇到启动失败时又毫无头绪。这次我就从原理拆到落地完整过一遍BusyBox在嵌入式Linux里的角色、交叉编译方法以及怎么用它在实际项目中组装出一套能跑起来的根文件系统。这篇文章适合刚好在搭开发板环境、被NFS挂载或init启动卡住的读者也适合想系统整理一遍相关知识栈的工程师。1. 为什么嵌入式Linux离不开BusyBox这样的百宝箱1.1 存储和内存约束下的一个顶一百个嵌入式环境里Flash和RAM的价格虽然一直在降但量产产品对BOM成本异常敏感留给软件的空间就是那么点。你很难在4MB的Flash里装一套标准Linux用户态工具但你可以装一个BusyBox。它最核心的设计目标很朴素把几百个常用命令合并进一个可执行文件里共享同一个主程序框架和基础函数从而把体积压到极致。我举个直观的对比。一个标准发行版里coreutils这一组工具ls、cp、mv、cat等等的二进制文件加起来往往几十MB起步如果你再把shell、mount、vi这些算进去体积更大。BusyBox常规编译出来动态链接版本经常几百KB静态版本也就1MB上下。差距不是一个数量级是好几个数量级。当然光看体积还不够。嵌入式设备上每跑一个进程内核都要维护对应的task_struct、页表、代码缓存这些资源。BusyBox把所有applet合并进一个可执行文件里意味着同一份代码段能在内存里被所有applet共享启动命令时也别再逐个从Flash里读取不同的二进制。这个特性在RAM很紧张的老平台上尤其重要很多路由器、IoT模组到现在依然靠这一点活得很好。1.2 applet机制软链接、符号链接与busybox命令分发很多人第一次用BusyBox时都会疑惑为什么/bin/ls是指向/bin/busybox的软链接难道一个程序能同时变成上百个命令答案是能秘密就在applet机制。BusyBox在编译时会生成一个applet名字表。运行时它检查被调用的名称也就是argv[0]在名字表里找到对应的入口然后执行那个命令的逻辑。如果你直接敲busybox ls它同样会取出argv[0]后面的第一个参数当作命令名来分发。从使用者的角度看就是一条软链接唤醒一个命令完全无感。这样做的好处很明显实现一个命令的开销只有一份表项和一段函数代码命令之间还能复用大量基础工具函数。比如ls、cp、mv、rm都要解析路径BusyBox内部的统一代码就能避免重复造轮子。构建时用make install会在指定前缀目录里创建全部软链接如果目标文件系统里不方便放大量链接也可以只创建实际用到的那些甚至什么都不建统一通过busybox命令加参数来调用。1.3 从内核启动到init进程BusyBox的接棒位置根文件系统要真正用起来内核只负责把关真正接管用户态的是init进程。内核把根文件系统挂载好之后会去执行init参数指定的程序默认是/sbin/init。在BusyBox构建的根文件系统里/sbin/init通常就是指向/bin/busybox的软链接。于是事情变得很有意思整个系统的第一个用户态程序是BusyBox后面的shell、命令、守护进程也基本来自BusyBox。它不只是瑞士军刀更像系统从内核态交接给用户态后的第一个接力棒。当init被内核作为PID 1启动后它要负责持续运行、回收孤儿进程、响应shutdown信号。BusyBox的init实现虽然精简但该有的机制都有并且会读取/etc/inittab来决定启动哪些服务、打开哪些控制台。这一步是整个根文件系统能否正常活起来的关键。如果你见过某个板卡停在内核启动成功之后串口没有shell提示符十有八九就是init或inittab出了问题——这个后面我专门讲。2. 从源码到可执行文件一次完整的BusyBox交叉编译2.1 交叉工具链怎么选发行版安装包还是厂商SDKBusyBox不是Docker容器不能在目标板上现场编译编译它需要一个能生成目标平台代码的交叉编译器。选型上有个基本原则工具链的GCC主版本不要和目标平台的内核、libc版本差太多否则容易编译出运行时行为古怪的程序。比较省事的方式是直接用Ubuntu发行版里的交叉工具链。比如目标平台是32位ARM Cortex-A装这个sudo apt-get install gcc-arm-linux-gnueabihf libc6-dev-armhf-cross目标平台是AArch64就换成gcc-aarch64-linux-gnu。这套工具链适合跑Linux的ARM平台glibc版本也比较新编译BusyBox和Dropbear这类用户态程序绰绰有余。如果板子厂商提供了配套SDK比如Buildroot或Yocto生成的工具链优先用厂商的。因为它的内核头文件、libc和板子自带的库更匹配后面做动态链接时不容易出现版本不兼容。没有SDK就用发行版工具链大多数项目都能跑通。关键是在一套项目里从编译内核到编译用户态都用同一个工具链不要混用否则架构相同但ABI不匹配的坑能把人磨疯。2.2 静态编译还是动态编译这是个需要提前拍板的问题在配置BusyBox之前得先想明白一件事根文件系统里的BusyBox打算静态编译还是动态编译。这两个选择的后续影响完全不同。静态编译的BusyBox不依赖任何外部共享库拷到目标板就能跑。制作initramfs、救援系统、以及极简根文件系统时静态编译是首选。这么做的好处是省心彻底避开库依赖问题坏处是生成的二进制体积大几十到一两百KB不过对嵌入式来说这点体积完全可控。动态编译的BusyBox依赖目标板上的libc和动态链接器体积更小也可以跟着系统库升级获得bug修复但代价是拷到rootfs里的库必须一个不少否则启动时直接报line 1: /bin/sh: not found这类诡异错误。开发初期用NFS挂载rootfs时动态编译能省点Flash空间但排查库依赖会比较麻烦。我的习惯是做量产镜像倾向静态编译少一个变量做快速调试环境则无所谓怎么顺手怎么来。配置方式是在menuconfig里找到Settings - Build static binary对应CONFIG_STATIC打开后重新编译。2.3 配置裁剪项目里到底要留哪些命令执行下面的命令会得到一个比较全的功能集合make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- defconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig进入图形界面后按项目需求裁剪。我的裁剪思路是按功能域分块shell类必须有ash文件操作类留ls、cp、mv、rm、mkdir、tar挂载和网络类留mount、umount、ifconfig、ip、ping、udhcpc进程和系统类留ps、top、kill、dmesg、sysctl编辑和文本处理类留vi、grep、sed、awk设备管理留mdev。打印机、模块加载、各种用不到的杂项全部砍掉。裁剪不是单纯追求小。每少一个applet就少一分被攻击面。尤其是设备要暴露到公网的场景BusyBox里用不到的网络服务applet应尽量关掉。编译完成后make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- install CONFIG_PREFIX$PWD/_install产物放在_install目录后面组装根文件系统要用的就是它。2.4 交叉编译中的常见报错与我的处置习惯第一次用新版本源码编译时最容易遇到的报错是缺少bison、flex、make等构建工具。Ubuntu上一条命令全解决sudo apt-get install bison flex make gcc还有一类报错是编译到某个applet时提示头文件里的函数不存在这多半是工具链太老或太新导致的kernel API漂移。遇到这种问题我一般直接降级到较稳定的BusyBox版本或者看一下release note里对应的编译要求。如果你拿的还是老项目里锁定的BusyBox源码比如某个产品用了v1.22.1这样的老版本记得同时关注工具链版本。老的BusyBox碰到新版GCC可能在某些文件上警告特别多但只要make没挂掉基本不影响最终产物。真正要小心的是不同版本之间配置结构差异不小不要拿新版本的defconfig直接套老代码。编译全部完成后检查一下输出目录里有没有busybox文件以及file命令显示的架构是否正确。这一步只要走神一次后面整个rootfs都会白忙一场。我见过有人拿着x86的busybox往ARM rootfs里塞启动时卡在init执行排查了几个小时才反应过来非常浪费时间。3. 组装根文件系统的实战顺序与关键命令3.1 一个最小rootfs的目录清单拿到_install目录之后第一步不是急着拷贝而是先规划rootfs的目录骨架。哪怕是最小的根文件系统也至少需要下面这些目录目录用途bin系统命令sbin管理员命令etc配置文件lib动态库与内核模块dev设备节点proc进程信息虚拟文件系统挂载点sys设备与驱动信息虚拟文件系统挂载点tmp临时文件var运行时数据home用户目录rootroot用户目录这些目录不是拍脑袋建的。比如/proc和/sys是内核虚拟文件系统的挂载点没有它们ps、mdev这类命令拿不到内核数据没有/dev设备节点无处安放没有/tmp很多临时文件程序直接崩。目录建好后把_install下的内容复制过去mkdir -p rootfs/{bin,sbin,etc,lib,dev,proc,sys,tmp,var,home,root} cp -a _install/* rootfs/这一步会把busybox及其软链接全部拷入rootfs。3.2 拷动态库最容易被忽略的下一步如果你的BusyBox是动态编译的现在就要处理动态库。先看它依赖哪些库arm-linux-gnueabihf-readelf -d rootfs/bin/busybox | grep NEEDED输出里一般有libc.so.6还有动态链接器lib/ld-linux-armhf.so.3。从交叉工具链的sysroot把这些库拷到rootfs对应目录。sysroot位置可以用工具链命令所在的路径推出来比如arm-linux-gnueabihf-gcc -print-sysroot然后把libc.so.6、ld-linux-armhf.so.3等拷到rootfs/lib。使用动态BusyBox时很多人就在这一步翻车文件明明在但系统报告找不到。原因往往是动态链接器本身不在标准路径或者库版本不对。用file和readelf逐项核对最保险。有一回我排查一个init: No such file or directory最后发现是interpreter路径写的/lib/ld-linux-armhf.so.3但我的rootfs里只有/lib/ld-linux-armhf.so.3.5文件名不完全一致内核exec时无法加载就报错。这个坑非常隐蔽建议拷完库后先ls核对文件名。3.3 设备节点/dev/console与/dev/null的玄机经过上面的处理rootfs里还没有/dev目录的实质内容。这里有两种方案。方案一手动创建最基础的静态节点。哪怕是最小的系统也必须有两个节点/dev/console和/dev/null。原因很实际内核向init进程传递的是console这个设备而很多命令要求标准输入输出存在。创建命令如下sudo mkdir -p rootfs/dev sudo mknod -m 600 rootfs/dev/console c 5 1 sudo mknod -m 666 rootfs/dev/null c 1 3方案二依赖内核的devtmpfs和BusyBox的mdev。devtmpfs能让内核在启动时自动创建设备节点mdev再基于/sys里的uevent事件动态维护。生产环境我基本都用这套rcS脚本里写mount -t devtmpfs devtmpfs /devmount -t sysfs sysfs /sysmdev -s。这样就不用手工维护一堆节点文件。静态节点方案适合早期调试优点是环境完全可控。但你得记得手动创建ttyS0、mmcblk0这类调试需要用到的节点否则后面访问串口和磁盘都会找不到设备。3.4 必备配置文件inittab、rcS、fstab、passwd有了busybox和库系统还是没法自己醒来因为还缺配置脚本。最基础的四份文件/etc/inittab决定init启动哪些程序初期可以先写极简版::sysinit:/etc/init.d/rcS ::askfirst:-/bin/sh ::ctrlaltdel:/sbin/reboot ::shutdown:/bin/umount -a -r/etc/init.d/rcS负责初始化脚本最基础的内容#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mdev -s/etc/fstab用于mount -a时自动挂载没有可以暂时留空但建议写上tmpfs挂到/tmp和/var。/etc/passwd和/etc/group可以先放一行root用户信息不然login时会提示无法识别用户。权限方面四个坑经常踩rcS必须可执行inittab文件权限普通644即可所有脚本换行符必须是LF而不是CRLFbusybox最好加上setuid位。做法是chmod 755 rootfs/etc/init.d/rcS chmod 4755 rootfs/bin/busybox4. init进程、设备节点与挂载流程让系统真正跑起来4.1 内核是怎么找到并挂载根文件系统的内核启动过程中start_kernel会最终走到挂载根文件系统这一步。根文件系统在哪由cmdline里的root参数决定。比如root/dev/mmcblk0p2表示从MMC设备的第二分区启动root/dev/nfs表示通过网络启动rootfstypeext4可以指定文件系统类型防止内核逐个探测。这里要理解一点对VFS虚拟文件系统层来说所有文件系统最终都挂载到同一个根目录树上。内核在启动初期先用一个简易ramfs作为临时根随后根据root参数把真正的文件系统挂载到根目录并切换过去。很多底层问题就出在找到设备-识别文件系统-挂载这条链路上设备驱动没编进内核或文件系统模块没编进内核都会导致无法挂载。等到挂载成功后内核会尝试执行/sbin/init。若成功PID 1从此接管若失败就会看到经典的kernel panic或者Attempted to kill init!。4.2 /etc/inittab 配置项逐段拆解BusyBox的init读取的/etc/inittab格式比SysV init简单得多四段用冒号分开id:runlevels:action:process。BusyBox并不严格使用runlevels习惯上这部分留空。action字段决定进程行为最常用到以下几种sysinit开机最先执行一次通常拉起rcSrespawn进程退出后自动重新拉起常用于shell或gettyaskfirst向控制台打印Please press Enter to activate this console等用户敲回车再启动一个shellctrlaltdel按CtrlAltDel时要执行的命令shutdown关机时要执行的命令。我常用的组合是sysinit拉起rcSaskfirst在串口上给出第一个shellshutdown时先卸载文件系统。这段看起来小但它直接决定你的串口会不会出现可交互的登录提示。如果inittab写错比如路径写错init会发现命令唤醒失败但通常不会panic只是反复打log系统看起来没反应其实内核还活着。4.3 rcS 里mount proc/sysfs/devpts到底有什么用rcS作为系统初始化脚本行使的是原来SysV init里一大堆rc脚本的职责。它至少要完成三件事第一挂载proc和sysfs。ps、mdev、lsmod这些命令都依赖它们。没有/proc系统里很多状态信息就是空的。第二挂载devpts。这是为PTY准备的SSH、telnet登录、串口getty都会用到。第三启动mdev或配置网络。mdev正常工作的前提是sysfs已挂载所以顺序必须是proc - sysfs - dev - mdev。一个常见版本如下#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mkdir -p /dev/pts mount -t devpts devpts /dev/pts mdev -s hostname myboard注意mdev -s必须放在/dev挂载完成之后执行否则/dev节点是空的。即使内核用了devtmpfs很多测量工具、USB设备接入的动态节点还是靠mdev补全。rcS里每个命令执行失败也要留意比如mkdir -p已经存在不会报错可如果前一步mount失败后面接mdev只会拿到一个不完整的设备列表。4.4 站在VFS与sync的角度看根文件系统把根文件系统和VFS放一起看很多问题突然清晰。VFS是内核的一个抽象层它以树形结构组织所有文件系统。根文件系统是这棵树的最原始挂载点而每个分区、每个U盘、每个tmpfs都是树上的一个子节点。嵌入式调试时经常遇到sync相关的问题。比如你往文件系统里写了一个文件断电重启后文件不见了。原因可能是数据还在页缓存里没刷回Flash。sync命令就是强制把脏页刷回底层设备。在关机流程里inittab的shutdown动作最好也安排sync再umount可以有效减少文件系统损坏的概率。另一个常见场景是启动早期要修改只读文件系统。嵌入式产品里根文件系统可能是只读的ext4或squashfs调试时可以用mount -o remount,rw /把根重新挂载成可写。这个动作背后就是VFS的mount系统调用在重新处理挂载标志。理解这一层再去排查为什么文件写不进去为什么umount提示Device or resource busy就顺手多了。5. 集成Dropbear与NFS调试让根文件系统变得好用5.1 为什么选择Dropbear而不是OpenSSH或telnetd到了系统能开机、能进shell下一步就是怎么高效调试。很多新手第一反应是开telnetd顺手是顺手但明文传输在现在的网络安全背景下基本是裸奔。完整OpenSSH又重依赖一堆库。Dropbear正好卡中间体积小、功能足够、支持SCP还方便静态编译。嵌入式Linux里说busybox集成dropbear指的就是在BusyBox根文件系统基础上把Dropbear作为SSH服务端装进去。选择Dropbear还有个好处它和BusyBox在技术路线上很合拍都是为嵌入式场景设计的精简实现。Dropbear提供dropbear主服务、dropbearkey密钥生成工具、dropbearconvert转换工具。整套体系很小可以静态链接成一个独立的sshd替代品。5.2 交叉编译Dropbear并在rcS中拉起集成Dropbear大致分三步交叉编译、生成主机密钥、启动服务。交叉编译的命令大概是./configure --hostarm-linux-gnueabihf --disable-zlib make PROGRAMSdropbear dropbearkey dropbearconvert make install如果遇到头文件缺失可以先跑autoreconf。想静态编译就加CFLAGS-static但要注意库依赖。生成密钥在目标板上更稳妥因为Dropbear会按配置路径读取。可以在rcS里放一行/usr/bin/dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key /usr/sbin/dropbear -R-R参数让它自动生成缺失的host key方便调试量产固件则建议提前固化密钥否则每次启动都不一样客户端连接时要重新确认指纹。启动脚本里别忘了把PATH和LD_LIBRARY_PATH写清楚。动态编译的Dropbear若提示找不到库多半是rootfs里没有libnss或libutil用readelf查一下依赖再补齐就行。5.3 用NFS把板子的根文件系统放在开发机上嵌入式开发初期最爽的方式是让目标板子的根文件系统直接放在开发机上通过网络NFS挂载。这样在开发机上改代码、改配置板子重启就能看到省去烧写Flash的时间和消耗。先在开发机上安装并配置NFS Server。Ubuntu上sudo apt-get install nfs-kernel-server然后在/etc/exports里加一行/srv/nfs/rootfs 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)注意no_root_squash很关键。目标板的root账号在NFS访问时一般会被映射成nobody如果不开no_root_squashrootfs里很多文件会没有权限写。开发调试时可以开量产环境还是建议规规矩矩按最小权限来。板端一侧需要内核支持NFS客户端和Root over NFS对应配置项CONFIG_NFS_FS、CONFIG_ROOT_NFS。U-Boot的bootargs里改成root/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs,v3,tcp rw ipdhcpipdhcp让板子先拿到IPNFS客户端才知道去哪找服务端。5.4 从烧写到共享文件系统的调试流NFS根文件系统调试流里我最常用的是三层结构U-Boot用tftp加载内核和设备树根文件系统用NFS挂远程目录。这样内核换新、rootfs换版本都不用重烧Flash只要重启板子。第一次接触NFS启动很多人会卡在挂载超时。建议先确认板子能不能ping通开发机然后在bootargs里手动指定ipip192.168.1.50:192.168.1.100:192.168.1.1:255.255.255.0::eth0:off等挂载成功后在开发机上直接往rootfs目录里丢文件板子上立刻可见。需要改动rcS或inittab时改完开发机侧同步一下即可板上重启生效。这套流程能极大缩短改配置-重新打包-烧写的循环。NFS调试也有一些边界不要在rootfs里写太多日志否则大量IO走网络会拖慢系统不要在no_root_squash的rootfs上跑生产服务权限太开放了如果NFS挂载正常但系统启动后卡住往往不是NFS的问题而是rcS脚本或服务依赖问题需要回到串口log去看。6. 根文件系统起不来时的高频坑位与排查思路6.1 VFS: Unable to mount root fs不一定是文件系统损坏内核日志里出现VFS: Unable to mount root fs on unknown-block这类信息时很多人第一反应是文件系统坏了。实际上一大半情况不是分区坏了而是内核根本找不到root参数指定的设备。排查顺序我建议这样先看启动日志里有没有注册出对应的块设备。比如root/dev/mmcblk0p2那日志里有没有mmc0和mmcblk0如果没有说明mmc驱动没编进内核或者设备树没配置好。如果有设备但mount不上再查rootfstype是不是写错或者这个分区上是不是空的。手边有串口就全程盯着一句unknown-block(179,2)能给你省很多事。还要留意一个常见差异SPI Nor Flash上很多用的是mtdblock设备root/dev/mtdblock3而NAND/MMC用mmcblk两者不能混写。网上很多例程只按自己的平台来照抄容易翻车。6.2 init进程找不到的三种死法系统能挂载根文件系统但在init这里挂掉通常有三种表现第一种日志是No init found. Try passing init option to kernel说明内核没在默认位置找到/sbin/init。这时先ls一下rootfs的/sbin/init是否存在有没有被软链接指错地方。第二种日志显示文件存在但exec失败比如Failed to execute /init (error -2)。-2是ENOENT常见原因不是文件不存在而是动态链接器或共享库缺失。用readelf看interpreter到rootfs里确认动态链接器对应文件是否在标准路径。上面说的ld-linux-armhf.so.3那个坑就是这一类的经典案例。-8则是EXEC格式错误八成是架构不对拷成了x86版busybox。第三种init起来了但inittab里配置的shell或脚本全部失败表现为串口无提示符或反复打印cant access tty或Job control turned off。这种要回到/etc/inittab和/etc/init.d/rcS逐行排查尤其注意换行符和权限。6.3 CRLF、文件权限和setuid这类隐形杀手嵌入式rootfs的脚本文件经常是在Windows下编辑后直接放进来的CRLF换行会在Linux下引发各种灵异事件。最典型的是rcS第一行#!/bin/sh\r内核挑中了但/bin/sh把\r当成命令的一部分执行时直接not found。排查这类问题很简单在开发机上用file或cat -A查看rootfs里的脚本如果有^M$说明混入了CRLF。一次性转换可以用sed -i s/\r$// rootfs/etc/init.d/rcS另外脚本权限和busybox的setuid位也容易被忽略。BusyBox如果需要提供login、su这类能力/bin/busybox必须带setuid位否则很多操作会静默拒绝。还有两类文件权限问题一是/etc/passwd如果写错会导致login起不来二是rootfs里目录权限如果全是777生产环境看着都头疼。一个比较稳妥的习惯是组装完rootfs后把所有脚本和可执行文件过一遍权限尤其是setuid位不要全盘一把梭。6.4 我的排查路线先用最小ramdisk把系统救活遇到根文件系统一直起不来的棘手情况我的固定打法是用一个最小静态BusyBox ramdisk先启动系统再做二次排查。这个ramdisk不用大包含busybox和busybox --install再加一个最简单的init脚本把shell拉起来就行。通过initramfs进入后系统已经有一个可用的shell环境再去mount真正的rootfs分区逐项检查文件、权限、库依赖。具体做法是编译一个静态BusyBox做成cpio格式initramfs在U-Boot或QEMU里指定initrd加载。起来的系统里什么高级功能都没有但足够你观察硬件寄存器、块设备节点、分区表也可以把挂不上的rootfs挂到/mnt下chroot进去慢慢定位。曾经有个板子顽固地报No working init found我用最小ramdisk进去后发现它真正的rootfs分区根本没被格式化工厂镜像里放的是一个空文件系统这个问题光看线上日志很难想到。这套思路也适用于BusyBox和Dropbear集成后突然出现的新问题。先用最小系统验证基础链路再逐步引入业务组件定位面立刻缩小一大半。如果你现在也正被某个rootfs启动问题卡住不妨先别盯着日志焦虑把问题想象成一条链路内核加载rootfs、exec init、inittab拉服务、rcS做初始化顺着这个链路一层层验证大多数问题都能在半小时内找到根因。
嵌入式Linux根文件系统实战：BusyBox交叉编译与启动排查
做嵌入式Linux绕来绕去最终还是绕不过两样东西根文件系统以及那个被称为瑞士军刀的BusyBox。我见过不少刚入行的朋友一提到BusyBox就以为只是个瘦身版Linux命令行拿着它当普通工具包用遇到启动失败时又毫无头绪。这次我就从原理拆到落地完整过一遍BusyBox在嵌入式Linux里的角色、交叉编译方法以及怎么用它在实际项目中组装出一套能跑起来的根文件系统。这篇文章适合刚好在搭开发板环境、被NFS挂载或init启动卡住的读者也适合想系统整理一遍相关知识栈的工程师。1. 为什么嵌入式Linux离不开BusyBox这样的百宝箱1.1 存储和内存约束下的一个顶一百个嵌入式环境里Flash和RAM的价格虽然一直在降但量产产品对BOM成本异常敏感留给软件的空间就是那么点。你很难在4MB的Flash里装一套标准Linux用户态工具但你可以装一个BusyBox。它最核心的设计目标很朴素把几百个常用命令合并进一个可执行文件里共享同一个主程序框架和基础函数从而把体积压到极致。我举个直观的对比。一个标准发行版里coreutils这一组工具ls、cp、mv、cat等等的二进制文件加起来往往几十MB起步如果你再把shell、mount、vi这些算进去体积更大。BusyBox常规编译出来动态链接版本经常几百KB静态版本也就1MB上下。差距不是一个数量级是好几个数量级。当然光看体积还不够。嵌入式设备上每跑一个进程内核都要维护对应的task_struct、页表、代码缓存这些资源。BusyBox把所有applet合并进一个可执行文件里意味着同一份代码段能在内存里被所有applet共享启动命令时也别再逐个从Flash里读取不同的二进制。这个特性在RAM很紧张的老平台上尤其重要很多路由器、IoT模组到现在依然靠这一点活得很好。1.2 applet机制软链接、符号链接与busybox命令分发很多人第一次用BusyBox时都会疑惑为什么/bin/ls是指向/bin/busybox的软链接难道一个程序能同时变成上百个命令答案是能秘密就在applet机制。BusyBox在编译时会生成一个applet名字表。运行时它检查被调用的名称也就是argv[0]在名字表里找到对应的入口然后执行那个命令的逻辑。如果你直接敲busybox ls它同样会取出argv[0]后面的第一个参数当作命令名来分发。从使用者的角度看就是一条软链接唤醒一个命令完全无感。这样做的好处很明显实现一个命令的开销只有一份表项和一段函数代码命令之间还能复用大量基础工具函数。比如ls、cp、mv、rm都要解析路径BusyBox内部的统一代码就能避免重复造轮子。构建时用make install会在指定前缀目录里创建全部软链接如果目标文件系统里不方便放大量链接也可以只创建实际用到的那些甚至什么都不建统一通过busybox命令加参数来调用。1.3 从内核启动到init进程BusyBox的接棒位置根文件系统要真正用起来内核只负责把关真正接管用户态的是init进程。内核把根文件系统挂载好之后会去执行init参数指定的程序默认是/sbin/init。在BusyBox构建的根文件系统里/sbin/init通常就是指向/bin/busybox的软链接。于是事情变得很有意思整个系统的第一个用户态程序是BusyBox后面的shell、命令、守护进程也基本来自BusyBox。它不只是瑞士军刀更像系统从内核态交接给用户态后的第一个接力棒。当init被内核作为PID 1启动后它要负责持续运行、回收孤儿进程、响应shutdown信号。BusyBox的init实现虽然精简但该有的机制都有并且会读取/etc/inittab来决定启动哪些服务、打开哪些控制台。这一步是整个根文件系统能否正常活起来的关键。如果你见过某个板卡停在内核启动成功之后串口没有shell提示符十有八九就是init或inittab出了问题——这个后面我专门讲。2. 从源码到可执行文件一次完整的BusyBox交叉编译2.1 交叉工具链怎么选发行版安装包还是厂商SDKBusyBox不是Docker容器不能在目标板上现场编译编译它需要一个能生成目标平台代码的交叉编译器。选型上有个基本原则工具链的GCC主版本不要和目标平台的内核、libc版本差太多否则容易编译出运行时行为古怪的程序。比较省事的方式是直接用Ubuntu发行版里的交叉工具链。比如目标平台是32位ARM Cortex-A装这个sudo apt-get install gcc-arm-linux-gnueabihf libc6-dev-armhf-cross目标平台是AArch64就换成gcc-aarch64-linux-gnu。这套工具链适合跑Linux的ARM平台glibc版本也比较新编译BusyBox和Dropbear这类用户态程序绰绰有余。如果板子厂商提供了配套SDK比如Buildroot或Yocto生成的工具链优先用厂商的。因为它的内核头文件、libc和板子自带的库更匹配后面做动态链接时不容易出现版本不兼容。没有SDK就用发行版工具链大多数项目都能跑通。关键是在一套项目里从编译内核到编译用户态都用同一个工具链不要混用否则架构相同但ABI不匹配的坑能把人磨疯。2.2 静态编译还是动态编译这是个需要提前拍板的问题在配置BusyBox之前得先想明白一件事根文件系统里的BusyBox打算静态编译还是动态编译。这两个选择的后续影响完全不同。静态编译的BusyBox不依赖任何外部共享库拷到目标板就能跑。制作initramfs、救援系统、以及极简根文件系统时静态编译是首选。这么做的好处是省心彻底避开库依赖问题坏处是生成的二进制体积大几十到一两百KB不过对嵌入式来说这点体积完全可控。动态编译的BusyBox依赖目标板上的libc和动态链接器体积更小也可以跟着系统库升级获得bug修复但代价是拷到rootfs里的库必须一个不少否则启动时直接报line 1: /bin/sh: not found这类诡异错误。开发初期用NFS挂载rootfs时动态编译能省点Flash空间但排查库依赖会比较麻烦。我的习惯是做量产镜像倾向静态编译少一个变量做快速调试环境则无所谓怎么顺手怎么来。配置方式是在menuconfig里找到Settings - Build static binary对应CONFIG_STATIC打开后重新编译。2.3 配置裁剪项目里到底要留哪些命令执行下面的命令会得到一个比较全的功能集合make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- defconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig进入图形界面后按项目需求裁剪。我的裁剪思路是按功能域分块shell类必须有ash文件操作类留ls、cp、mv、rm、mkdir、tar挂载和网络类留mount、umount、ifconfig、ip、ping、udhcpc进程和系统类留ps、top、kill、dmesg、sysctl编辑和文本处理类留vi、grep、sed、awk设备管理留mdev。打印机、模块加载、各种用不到的杂项全部砍掉。裁剪不是单纯追求小。每少一个applet就少一分被攻击面。尤其是设备要暴露到公网的场景BusyBox里用不到的网络服务applet应尽量关掉。编译完成后make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- install CONFIG_PREFIX$PWD/_install产物放在_install目录后面组装根文件系统要用的就是它。2.4 交叉编译中的常见报错与我的处置习惯第一次用新版本源码编译时最容易遇到的报错是缺少bison、flex、make等构建工具。Ubuntu上一条命令全解决sudo apt-get install bison flex make gcc还有一类报错是编译到某个applet时提示头文件里的函数不存在这多半是工具链太老或太新导致的kernel API漂移。遇到这种问题我一般直接降级到较稳定的BusyBox版本或者看一下release note里对应的编译要求。如果你拿的还是老项目里锁定的BusyBox源码比如某个产品用了v1.22.1这样的老版本记得同时关注工具链版本。老的BusyBox碰到新版GCC可能在某些文件上警告特别多但只要make没挂掉基本不影响最终产物。真正要小心的是不同版本之间配置结构差异不小不要拿新版本的defconfig直接套老代码。编译全部完成后检查一下输出目录里有没有busybox文件以及file命令显示的架构是否正确。这一步只要走神一次后面整个rootfs都会白忙一场。我见过有人拿着x86的busybox往ARM rootfs里塞启动时卡在init执行排查了几个小时才反应过来非常浪费时间。3. 组装根文件系统的实战顺序与关键命令3.1 一个最小rootfs的目录清单拿到_install目录之后第一步不是急着拷贝而是先规划rootfs的目录骨架。哪怕是最小的根文件系统也至少需要下面这些目录目录用途bin系统命令sbin管理员命令etc配置文件lib动态库与内核模块dev设备节点proc进程信息虚拟文件系统挂载点sys设备与驱动信息虚拟文件系统挂载点tmp临时文件var运行时数据home用户目录rootroot用户目录这些目录不是拍脑袋建的。比如/proc和/sys是内核虚拟文件系统的挂载点没有它们ps、mdev这类命令拿不到内核数据没有/dev设备节点无处安放没有/tmp很多临时文件程序直接崩。目录建好后把_install下的内容复制过去mkdir -p rootfs/{bin,sbin,etc,lib,dev,proc,sys,tmp,var,home,root} cp -a _install/* rootfs/这一步会把busybox及其软链接全部拷入rootfs。3.2 拷动态库最容易被忽略的下一步如果你的BusyBox是动态编译的现在就要处理动态库。先看它依赖哪些库arm-linux-gnueabihf-readelf -d rootfs/bin/busybox | grep NEEDED输出里一般有libc.so.6还有动态链接器lib/ld-linux-armhf.so.3。从交叉工具链的sysroot把这些库拷到rootfs对应目录。sysroot位置可以用工具链命令所在的路径推出来比如arm-linux-gnueabihf-gcc -print-sysroot然后把libc.so.6、ld-linux-armhf.so.3等拷到rootfs/lib。使用动态BusyBox时很多人就在这一步翻车文件明明在但系统报告找不到。原因往往是动态链接器本身不在标准路径或者库版本不对。用file和readelf逐项核对最保险。有一回我排查一个init: No such file or directory最后发现是interpreter路径写的/lib/ld-linux-armhf.so.3但我的rootfs里只有/lib/ld-linux-armhf.so.3.5文件名不完全一致内核exec时无法加载就报错。这个坑非常隐蔽建议拷完库后先ls核对文件名。3.3 设备节点/dev/console与/dev/null的玄机经过上面的处理rootfs里还没有/dev目录的实质内容。这里有两种方案。方案一手动创建最基础的静态节点。哪怕是最小的系统也必须有两个节点/dev/console和/dev/null。原因很实际内核向init进程传递的是console这个设备而很多命令要求标准输入输出存在。创建命令如下sudo mkdir -p rootfs/dev sudo mknod -m 600 rootfs/dev/console c 5 1 sudo mknod -m 666 rootfs/dev/null c 1 3方案二依赖内核的devtmpfs和BusyBox的mdev。devtmpfs能让内核在启动时自动创建设备节点mdev再基于/sys里的uevent事件动态维护。生产环境我基本都用这套rcS脚本里写mount -t devtmpfs devtmpfs /devmount -t sysfs sysfs /sysmdev -s。这样就不用手工维护一堆节点文件。静态节点方案适合早期调试优点是环境完全可控。但你得记得手动创建ttyS0、mmcblk0这类调试需要用到的节点否则后面访问串口和磁盘都会找不到设备。3.4 必备配置文件inittab、rcS、fstab、passwd有了busybox和库系统还是没法自己醒来因为还缺配置脚本。最基础的四份文件/etc/inittab决定init启动哪些程序初期可以先写极简版::sysinit:/etc/init.d/rcS ::askfirst:-/bin/sh ::ctrlaltdel:/sbin/reboot ::shutdown:/bin/umount -a -r/etc/init.d/rcS负责初始化脚本最基础的内容#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mdev -s/etc/fstab用于mount -a时自动挂载没有可以暂时留空但建议写上tmpfs挂到/tmp和/var。/etc/passwd和/etc/group可以先放一行root用户信息不然login时会提示无法识别用户。权限方面四个坑经常踩rcS必须可执行inittab文件权限普通644即可所有脚本换行符必须是LF而不是CRLFbusybox最好加上setuid位。做法是chmod 755 rootfs/etc/init.d/rcS chmod 4755 rootfs/bin/busybox4. init进程、设备节点与挂载流程让系统真正跑起来4.1 内核是怎么找到并挂载根文件系统的内核启动过程中start_kernel会最终走到挂载根文件系统这一步。根文件系统在哪由cmdline里的root参数决定。比如root/dev/mmcblk0p2表示从MMC设备的第二分区启动root/dev/nfs表示通过网络启动rootfstypeext4可以指定文件系统类型防止内核逐个探测。这里要理解一点对VFS虚拟文件系统层来说所有文件系统最终都挂载到同一个根目录树上。内核在启动初期先用一个简易ramfs作为临时根随后根据root参数把真正的文件系统挂载到根目录并切换过去。很多底层问题就出在找到设备-识别文件系统-挂载这条链路上设备驱动没编进内核或文件系统模块没编进内核都会导致无法挂载。等到挂载成功后内核会尝试执行/sbin/init。若成功PID 1从此接管若失败就会看到经典的kernel panic或者Attempted to kill init!。4.2 /etc/inittab 配置项逐段拆解BusyBox的init读取的/etc/inittab格式比SysV init简单得多四段用冒号分开id:runlevels:action:process。BusyBox并不严格使用runlevels习惯上这部分留空。action字段决定进程行为最常用到以下几种sysinit开机最先执行一次通常拉起rcSrespawn进程退出后自动重新拉起常用于shell或gettyaskfirst向控制台打印Please press Enter to activate this console等用户敲回车再启动一个shellctrlaltdel按CtrlAltDel时要执行的命令shutdown关机时要执行的命令。我常用的组合是sysinit拉起rcSaskfirst在串口上给出第一个shellshutdown时先卸载文件系统。这段看起来小但它直接决定你的串口会不会出现可交互的登录提示。如果inittab写错比如路径写错init会发现命令唤醒失败但通常不会panic只是反复打log系统看起来没反应其实内核还活着。4.3 rcS 里mount proc/sysfs/devpts到底有什么用rcS作为系统初始化脚本行使的是原来SysV init里一大堆rc脚本的职责。它至少要完成三件事第一挂载proc和sysfs。ps、mdev、lsmod这些命令都依赖它们。没有/proc系统里很多状态信息就是空的。第二挂载devpts。这是为PTY准备的SSH、telnet登录、串口getty都会用到。第三启动mdev或配置网络。mdev正常工作的前提是sysfs已挂载所以顺序必须是proc - sysfs - dev - mdev。一个常见版本如下#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mkdir -p /dev/pts mount -t devpts devpts /dev/pts mdev -s hostname myboard注意mdev -s必须放在/dev挂载完成之后执行否则/dev节点是空的。即使内核用了devtmpfs很多测量工具、USB设备接入的动态节点还是靠mdev补全。rcS里每个命令执行失败也要留意比如mkdir -p已经存在不会报错可如果前一步mount失败后面接mdev只会拿到一个不完整的设备列表。4.4 站在VFS与sync的角度看根文件系统把根文件系统和VFS放一起看很多问题突然清晰。VFS是内核的一个抽象层它以树形结构组织所有文件系统。根文件系统是这棵树的最原始挂载点而每个分区、每个U盘、每个tmpfs都是树上的一个子节点。嵌入式调试时经常遇到sync相关的问题。比如你往文件系统里写了一个文件断电重启后文件不见了。原因可能是数据还在页缓存里没刷回Flash。sync命令就是强制把脏页刷回底层设备。在关机流程里inittab的shutdown动作最好也安排sync再umount可以有效减少文件系统损坏的概率。另一个常见场景是启动早期要修改只读文件系统。嵌入式产品里根文件系统可能是只读的ext4或squashfs调试时可以用mount -o remount,rw /把根重新挂载成可写。这个动作背后就是VFS的mount系统调用在重新处理挂载标志。理解这一层再去排查为什么文件写不进去为什么umount提示Device or resource busy就顺手多了。5. 集成Dropbear与NFS调试让根文件系统变得好用5.1 为什么选择Dropbear而不是OpenSSH或telnetd到了系统能开机、能进shell下一步就是怎么高效调试。很多新手第一反应是开telnetd顺手是顺手但明文传输在现在的网络安全背景下基本是裸奔。完整OpenSSH又重依赖一堆库。Dropbear正好卡中间体积小、功能足够、支持SCP还方便静态编译。嵌入式Linux里说busybox集成dropbear指的就是在BusyBox根文件系统基础上把Dropbear作为SSH服务端装进去。选择Dropbear还有个好处它和BusyBox在技术路线上很合拍都是为嵌入式场景设计的精简实现。Dropbear提供dropbear主服务、dropbearkey密钥生成工具、dropbearconvert转换工具。整套体系很小可以静态链接成一个独立的sshd替代品。5.2 交叉编译Dropbear并在rcS中拉起集成Dropbear大致分三步交叉编译、生成主机密钥、启动服务。交叉编译的命令大概是./configure --hostarm-linux-gnueabihf --disable-zlib make PROGRAMSdropbear dropbearkey dropbearconvert make install如果遇到头文件缺失可以先跑autoreconf。想静态编译就加CFLAGS-static但要注意库依赖。生成密钥在目标板上更稳妥因为Dropbear会按配置路径读取。可以在rcS里放一行/usr/bin/dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key /usr/sbin/dropbear -R-R参数让它自动生成缺失的host key方便调试量产固件则建议提前固化密钥否则每次启动都不一样客户端连接时要重新确认指纹。启动脚本里别忘了把PATH和LD_LIBRARY_PATH写清楚。动态编译的Dropbear若提示找不到库多半是rootfs里没有libnss或libutil用readelf查一下依赖再补齐就行。5.3 用NFS把板子的根文件系统放在开发机上嵌入式开发初期最爽的方式是让目标板子的根文件系统直接放在开发机上通过网络NFS挂载。这样在开发机上改代码、改配置板子重启就能看到省去烧写Flash的时间和消耗。先在开发机上安装并配置NFS Server。Ubuntu上sudo apt-get install nfs-kernel-server然后在/etc/exports里加一行/srv/nfs/rootfs 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)注意no_root_squash很关键。目标板的root账号在NFS访问时一般会被映射成nobody如果不开no_root_squashrootfs里很多文件会没有权限写。开发调试时可以开量产环境还是建议规规矩矩按最小权限来。板端一侧需要内核支持NFS客户端和Root over NFS对应配置项CONFIG_NFS_FS、CONFIG_ROOT_NFS。U-Boot的bootargs里改成root/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs,v3,tcp rw ipdhcpipdhcp让板子先拿到IPNFS客户端才知道去哪找服务端。5.4 从烧写到共享文件系统的调试流NFS根文件系统调试流里我最常用的是三层结构U-Boot用tftp加载内核和设备树根文件系统用NFS挂远程目录。这样内核换新、rootfs换版本都不用重烧Flash只要重启板子。第一次接触NFS启动很多人会卡在挂载超时。建议先确认板子能不能ping通开发机然后在bootargs里手动指定ipip192.168.1.50:192.168.1.100:192.168.1.1:255.255.255.0::eth0:off等挂载成功后在开发机上直接往rootfs目录里丢文件板子上立刻可见。需要改动rcS或inittab时改完开发机侧同步一下即可板上重启生效。这套流程能极大缩短改配置-重新打包-烧写的循环。NFS调试也有一些边界不要在rootfs里写太多日志否则大量IO走网络会拖慢系统不要在no_root_squash的rootfs上跑生产服务权限太开放了如果NFS挂载正常但系统启动后卡住往往不是NFS的问题而是rcS脚本或服务依赖问题需要回到串口log去看。6. 根文件系统起不来时的高频坑位与排查思路6.1 VFS: Unable to mount root fs不一定是文件系统损坏内核日志里出现VFS: Unable to mount root fs on unknown-block这类信息时很多人第一反应是文件系统坏了。实际上一大半情况不是分区坏了而是内核根本找不到root参数指定的设备。排查顺序我建议这样先看启动日志里有没有注册出对应的块设备。比如root/dev/mmcblk0p2那日志里有没有mmc0和mmcblk0如果没有说明mmc驱动没编进内核或者设备树没配置好。如果有设备但mount不上再查rootfstype是不是写错或者这个分区上是不是空的。手边有串口就全程盯着一句unknown-block(179,2)能给你省很多事。还要留意一个常见差异SPI Nor Flash上很多用的是mtdblock设备root/dev/mtdblock3而NAND/MMC用mmcblk两者不能混写。网上很多例程只按自己的平台来照抄容易翻车。6.2 init进程找不到的三种死法系统能挂载根文件系统但在init这里挂掉通常有三种表现第一种日志是No init found. Try passing init option to kernel说明内核没在默认位置找到/sbin/init。这时先ls一下rootfs的/sbin/init是否存在有没有被软链接指错地方。第二种日志显示文件存在但exec失败比如Failed to execute /init (error -2)。-2是ENOENT常见原因不是文件不存在而是动态链接器或共享库缺失。用readelf看interpreter到rootfs里确认动态链接器对应文件是否在标准路径。上面说的ld-linux-armhf.so.3那个坑就是这一类的经典案例。-8则是EXEC格式错误八成是架构不对拷成了x86版busybox。第三种init起来了但inittab里配置的shell或脚本全部失败表现为串口无提示符或反复打印cant access tty或Job control turned off。这种要回到/etc/inittab和/etc/init.d/rcS逐行排查尤其注意换行符和权限。6.3 CRLF、文件权限和setuid这类隐形杀手嵌入式rootfs的脚本文件经常是在Windows下编辑后直接放进来的CRLF换行会在Linux下引发各种灵异事件。最典型的是rcS第一行#!/bin/sh\r内核挑中了但/bin/sh把\r当成命令的一部分执行时直接not found。排查这类问题很简单在开发机上用file或cat -A查看rootfs里的脚本如果有^M$说明混入了CRLF。一次性转换可以用sed -i s/\r$// rootfs/etc/init.d/rcS另外脚本权限和busybox的setuid位也容易被忽略。BusyBox如果需要提供login、su这类能力/bin/busybox必须带setuid位否则很多操作会静默拒绝。还有两类文件权限问题一是/etc/passwd如果写错会导致login起不来二是rootfs里目录权限如果全是777生产环境看着都头疼。一个比较稳妥的习惯是组装完rootfs后把所有脚本和可执行文件过一遍权限尤其是setuid位不要全盘一把梭。6.4 我的排查路线先用最小ramdisk把系统救活遇到根文件系统一直起不来的棘手情况我的固定打法是用一个最小静态BusyBox ramdisk先启动系统再做二次排查。这个ramdisk不用大包含busybox和busybox --install再加一个最简单的init脚本把shell拉起来就行。通过initramfs进入后系统已经有一个可用的shell环境再去mount真正的rootfs分区逐项检查文件、权限、库依赖。具体做法是编译一个静态BusyBox做成cpio格式initramfs在U-Boot或QEMU里指定initrd加载。起来的系统里什么高级功能都没有但足够你观察硬件寄存器、块设备节点、分区表也可以把挂不上的rootfs挂到/mnt下chroot进去慢慢定位。曾经有个板子顽固地报No working init found我用最小ramdisk进去后发现它真正的rootfs分区根本没被格式化工厂镜像里放的是一个空文件系统这个问题光看线上日志很难想到。这套思路也适用于BusyBox和Dropbear集成后突然出现的新问题。先用最小系统验证基础链路再逐步引入业务组件定位面立刻缩小一大半。如果你现在也正被某个rootfs启动问题卡住不妨先别盯着日志焦虑把问题想象成一条链路内核加载rootfs、exec init、inittab拉服务、rcS做初始化顺着这个链路一层层验证大多数问题都能在半小时内找到根因。
